Atomic RSS

Suppose you’re generating an RSS feed, or you’re thinking about generating an RSS feed, and you’re wondering how Atom fits into the picture. The future of technology is hard to predict, but there’s a good way to hedge your bets. You can generate an RSS feed and, by following a few simple rules, be really sure that there’s a 100%-equivalent Atom 1.0 feed, so that if you’re generating both, they’ll be in sync, and if you need to switch back and forth, it’s just a matter of changing a few strings. Let’s call this future-proofed flavor “Atomic RSS”. It turns out that using Atomic RSS is a Good Thing anyhow, because it will help software in general and news aggregators in particular produce better results. [Ed. note: This is a first cut, and probably has errors; corrections gratefully received. Thanks to Sam Ruby for substantial contributions.]

Use RSS 2.0 · RSS 2.0 is semantically very close to Atom 1.0, close enough to make Atomic RSS practical. I suspect doing this with RSS 0.9 would be difficult. I’m pretty sure that RSS 1.0 would be doable, but I won’t pay the RDF Tax, so someone else can write those rules.

There’s a detailed discussion of the differences between RSS 2.0 and Atom 1.0 here; it may be useful if you’re considering the alternatives.

Required Elements · At the top level of your feed (channel in RSS), Atom requires the title, a last-updated time-stamp, and a unique feed identifier. In RSS-talk, the first two are the title and lastBuildDate elements—the date formats are different, but there’s software to take care of that.

The unique identifier is a bit more of a problem. If you only have one feed per site, you’re OK, because the address in your link element will work just fine as a unique identifier; URIs are like that. If you have multiple feeds per site, or you don’t like using HTTP addresses that way, you could just borrow Atom’s id element. Remember to put it in the Atom namespace, http://www.w3.org/2005/Atom; it’s perfectly legal to have elements from other namespaces in RSS feeds.

Since it’s identifying the feed, not the ever-changing items in the feed, it doesn’t need to change, you can make up one of these things and just use it forever.

For example:

<rss version="2.0">
  <channel>
   <title>I Love Garlic</title>
   <id xmlns="http://www.w3.org/2005/Atom">urn:uuid:60a76c80-d399-11d9-b93C-0003939e19f6</id>
...
  </channel>
</rss>

At the per-entry level, Atom also requires these same three things (title, identifier, and time-stamp); the first two correspond to the RSS title and guid elements, so that should be easy. You’re going to have to go to some extra work to make sure your guid contents are really unique and stable, but there are lots of software libraries available to generate unique identifiers.

As for the date-stamp, the semantics of pubDate in RSS and updated in Atom are subtly different, and worth a little study, but treating them as more or less equivalent won’t break any software.

At the top level, RSS also requires the link and description elements, but don’t worry, when you want an Atom version, there are exact equivalents.

Finally, Atom requires that each entry have an author element, either directly or by inheritance from one at the feed-level. RSS has an author element, but it’s not really the same because it’s an email address (you can have a name too, in parentheses), while Atom requires a name (but also allows an email address in a separate child element). So what you might want to do is, instead of author, use the dc:creator element, which lots of RSS feeds already do and pretty well all the software supports.

Forbidden Elements · There are a few things that RSS has but Atom 1.0 doesn’t, so you shouldn’t use them in Atomic RSS.

• At the feed level, RSS has webMaster and managingEditor. Atom has author and contributor, but as noted above, they’re not the same, and in this case, there’s not much software that does anything useful with webMaster or managingEditor anyhow. Once again dc:creator may be your friend.

• Atom doesn’t have anything corresponding to docs, cloud, ttl, rating, textInput, skipHours, or skipDays. However, there’s not much in the way of software that uses these things, so you probably won’t miss them.

• Atom doesn’t have an equivalent of comments. There is some software support out there for the this RSS element, but it’s not very widespread or consistent. A lot of people would like to have a useful, agreed-on comment-tracking facility, and work is under way to hammer out a useful extension (which should work in both RSS and Atom).

Other Good Ideas · It would be perfectly legal to put an
<atom:link rel="self" href="[your feed address here]"/>
in your RSS 2.0; this is designed to support one-click subscription, which is something the world needs. Randy Charles Morin is proposing that existing RSS-reading software start supporting this.

This notion, of adding Atom markup to RSS feeds, is hardly new; here and here are some threads from last year, out of the JournURL space.

Although descriptions are completely optional in RSS, Atom (which calls them summary) strongly encourages them, and including them will make your feed more useful; you’ll find that most client software acts better when they’re provided.

In fact, feed-reader performance will also improve as a result of your providing the per-entry title, identifier, and date-stamp, even though RSS doesn’t require them.

Conclusion · Atomic RSS is pretty easy, really. First, use RSS 2.0. Second, make sure you’ve got title, lastBuildDate, and either a unique link URI or atom:id at the top level, and title, pubDate, and guid per-item. Third, stay away from the RSS elements without Atom equivalents (you probably won’t miss them).

Then, when you decide you want to use Atom—for example, if you want multi-model enclosures, or to use unescaped XHTML, or to inject your feed into the SOAP ecosystem, or to use the Atom Publishing Protocol—it’ll be simple and easy and straightforward.

---