Internet technology hosted by Berkman Center

Archive: myPublicFeeds.opml

Monday, October 13, 2003

A few weeks back, a question was raised by Jeremy Zawodny on behalf of Yahoo. They have a large number of RSS feeds that they want to make available to aggregators. They need a machine-readable format and a default location for the file. Further, this file should be able to contain links to other files in this format so that directories can be distributed. A format and location is proposed in this document.


10/17/03: Withdrawn.

When this was an RFC comments were here.


An application that wishes to find public feeds for a Web site, say, should request If it can find this document, it should read the contents and look for a sequence of top-level s with at least the following attributes: type, text, description, xmlUrl. These attributes provide enough information so that the aggregator can provide a reasonable user interface for choosing one or more feeds from the site.

Type must be rss; text is the name of the feed; description is a one or two sentence description of the feed; xmlUrl points to the feed. Even though the type is rss, the feed it points to may be in any common syndication format understood by aggregators.

An may contain a type attribute with the value link, and an xmlUrl attribute that points to an OPML file to be included, allowing directories to be distributed. Included files may also include links to other files, without limit.

In general, the names of OPML files should end with ".opml".


There seem to be two options: 1. a custom format, or 2. use OPML.

I like using OPML although I see advantages in using a custom format.

A custom format would be like changes.xml for, a flat list of files, each with a name, description, and url, and perhaps some other data, as attributes, or as sub-elements. Lots of choices, all subject to taste, relatively easy to implement on both the production and consumption sides. Would require new code for aggregators. Would require a new convention for linking.

Most aggregators can already read OPML because it is the default format for collections of subscriptions, which is exactly what this application is. Further, OPML already has a convention for n-level inclusion, implemented in hierarchic Web directories. It's also quite easy for content systems to produce OPML files.

I decided to go with OPML because of its familiarity to aggregator developers.


Robots Exclusion.

OPML 1.0.