Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins

Why do sites still publish RSS?

In my travels all over the web looking for examples to use as the basis for AtomActivity it was interesting to note the number of sites that are still publishing both Atom and RSS feeds in parallel.

Given that Atom was designed to be the "cure to all ills" of RSS, it seems like you ought to be able to publish anything you can publish in RSS as an Atom feed, even just as a mechanical transformation. Perhaps it's just the ease of doing it that's the motivation? "Neither are hard to generate, so let's just do both."

Where this becomes troublesome is the definition of extensions. AtomActivity, by virtue of being an Atom extension, can't be used directly in RSS. While it's true that you can plug the namespaced XML elements that are specified into an RSS item element, there are still several incongruities: first and most obvious is that activity:object is defined to contain the same elements you find in the atom:entry element (more or less), but also some of the object types we'll be adding in will also have a description of how to extract their properties (such as a photo's image URL) from an Atom entry, and that description won't work without modification on an RSS item.

So what's an extension author to do? Do I need to write a parallel "RSSActivity" spec that's fundamentally the same but uses RSS elements in place of Atom ones? Do we need to define for every object type a mapping for both Atom and RSS?

Another place this problem manifests is libraries that act as an abstraction layer over RSS and Atom. It's true that for the basic case of publishing feeds of weblog entries the interface to both of those is basically the same, but Atom is in fact a superset of RSS (functionality-wise) and so any such libraries are necessarily restricted to supporting only what RSS can do. The use-case for these libraries is "Here's the URL for a feed. Parse it at all costs. I don't care what format it's in". That sounds useful on the surface, but are there really any significant sites left that publish RSS but don't also publish Atom? Can't we just leave RSS to die and use Atom-specific libraries?

Browsers suffer in this department also. On just about every site I visited, when I clicked the "Feed" icon in my browser I got a pop-up menu with two options: "Feed (Atom)" and "Feed (RSS)". Do we really want to be forcing users to make the choice between two options that, as far as their browser is concerned, behave in exactly the same way? Firefox and Opera -- and, I assume, every other major browser -- supports Atom, so can't we just remove the RSS autodiscovery links, even if the underlying feeds remain? Consign RSS to the bucket of "we maintain this for backwards compatibility" rather than "this is functionality we actively promote". In an ideal world, browsers would ignore the RSS feed if an Atom feed is present, but since the browser can't reliably determine that the RSS and that Atom versions really are the same content, it's left to the page author to make that decision.

If you publish both RSS and Atom feeds on your site I'd love to hear why. If you're publishing exclusively RSS I'd love to hear why as well.


  • Moved to TypePad is now hosted on TypePad rather than LiveJournal. All of the old content remains over here in LiveJournal land, but those who are…

  • Moving the Goalposts

    In the few weeks since I published the first drafts of AtomActivity, ActivitySchema and friends several things have come about: FriendFeed is…

  • Activity Streams and Comment Aggregation

    One pain point that exists for activity streams right now is the dispersal of responses over various networks. When I post a blog entry like this…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.