December 26, 2003
@ 04:07 PM

Mark Pilgrim's most recent entry in his RSS feed contains the following text

The best things in life are not things. (11 words)

Note: The "dive into mark" feed you are currently subscribed to is deprecated. If your aggregator supports it, you should upgrade to my Atom feed, which includes both summaries and full content.

A lot of the ATOM vs. RSS discussion has been mired in childishness and personality conflicts with the main proponents of ATOM claiming that the creation of the ATOM syndication format will be a good thing for users of syndication and blogging software. Now let's pretend this is true and the only people who have to bear the burden are aggregator authors like me who now have to add support for yet another syndication format. Let's see what my users get out of ATOM feeds compared to RSS feeds.

  1. Mark Pilgrim's ATOM feed: As I write this his feed contains the following elements per entry;  id, created, issued, modifed, link, summary,title, dc:subject and content. The aformentioned elements are equivalent to guid, pubDate, issued, modified, link, description, title, dc:subject and content:encoded/xhtml:body that exist in RSS feeds today. In fact an RSS feed with those elements and Mark Pilgrim's feed will be treated identically by RSS Bandit. The only problematic pieces are that his feed contains three dates that express when the entry was issued, when it was modified and when it was created. Most puzzling is that the issued date is before its created date. I have no idea what this distinction means and quite frankly I doubt many people will care.

    Basically, it looks like Mark Pilgrim's ATOM feed doesn't give users anything they couldn't get from an equivalent RSS feed except the fact that they have to upgrade their news aggregators and deal with potential bugs in the implementations of these features [because there are always bugs in new features]
  2. LiveJournal's ATOM feeds: As I write this a sample feed from Live Journal (in this case Jamie Zawinski's) contains the following elements per entry;  id, modified, issued, link, titleauthor and content . The aformentioned elements are equivalent to guid, modified, issued, link, titleauthor/dc:author and content:encoded/xhtml:body. Comparing this feed to Mark Pilgrim's I already see a bunch of ambiguity which supposedly is not supposed to exist since what ATOM supposedly gives consumers over RSS is that it will be better defined and less ambiguous than RSS. How are news aggregators supposed to treat the three date types defined in ATOM? In RSS I could always use the pubDate or dc:date now I have to figure out which of <modified>, <issued> or <created> is the most relevant one to show the user. Another point is what do I do if a feed contains <content rel="fragment"> amd a <summary>? Which one do I show the user?
  3. Movable Type's ATOM feeds: As I write this the MovableType ATOM template contains the following elements; id, modified, issued, link, titleauthor, dc:subject. summary and content. The aformentioned elements are equivalent to guid, modified, issued, link, titleauthor/dc:author, dc:subject, description and content:encoded/xhtml:body. Again besides the weirdness with dates (and I suspect RSS Bandit will end up treating <modifed> equivalent to <pubDate>) there isn't anything users get from the ATOM feed that they don't get from the equivalent RSS feed. Interesting, I'd expected that I'd find at least one of the first 3 sample ATOM feeds that I took a look at would show me why it was worth it that I spend a weekend or more implementing ATOM support in RSS Bandit. 

The fundamental conceit of the ATOM effort is that they think writing specifications is easy. Many of its proponents deride RSS for being ambiguous and not well defined yet they are producing a more complex specification with more significant ambiguities in it than I've seen in RSS. I actually have a mental list of significant issues with ATOM that I haven't even posted yet, the ones I mentioned above were just from glancing at the aforementioned feeds. My day job involves reading or writing specs all day. Most of the specs I read either were produced by the W3C or by folks within Microsoft. Every one of them contains contradictions, ambiguities and lack crucial information for determining in edge cases. Some are better than others but they all are never well-defined enough. Every spec has errata.

The ATOM people seem to think that if a simple spec like RSS can have ambiguities they can fix it with a more complex spec, which anyone who actually does this stuff for a living will tell you just leads to more complex ambiguities to deal with not less.

I wish them luck. As I implement their spec I at least hope that some of these ATOM supporters get a clue and actually use some of the features of ATOM that RSS users have enjoyed for a while and are lacking in all of the feeds I linked to above such as the ATOM equivalent to wfw:commentRss. It's quite irritating to be able to read the comments to any .TEXT or dasBlog weblog in my news aggregator but then have to navigate to the website when I'm reading a Movable Type or LiveJournal feed to see the comments.  


Sunday, December 28, 2003 11:40:01 PM (GMT Standard Time, UTC+00:00)
I think that Atom is just starting and may evolve to a better thing. Supporting features that we don't envision yet.

RSS is just fine for what we are doing now, but it can't evolve: "Therefore, the RSS spec is, for all practical purposes, frozen at version 2.0.1" [from the spec]

On the other hand, the best thing so far about Atom is that its development fostered the clarification of the RSS spec. :)
Sérgio N.
Tuesday, December 30, 2003 6:23:35 PM (GMT Standard Time, UTC+00:00)
"Boy, I'll tell you, these engine-powered automobiles will never replace my trusty old horse-and-buggy. They don't do anything I can't do already, and I don't have the vision to think about how they might evolve to do things I can't do now."

Puhleeze. Spare us the sanctimony, Dare. Nobody really cares.

My current Atom feed highlights one of many things that RSS (as-written) can't do: it includes both hand-crafted summaries and full content. Don't lecture me with your "well, there's this undocumented content:encoded namespace thingie that we stole from RSS 1.0 and appropriated and you just wave your hands and it works" crap. That's funky and you know it. You are once again trying to make RSS complicated, and you are redefining core elements, and that would get you in trouble if the spec author didn't have his head so far up his ass that he can't figure out what you're talking about. And don't lecture me about xhtml:body, that's *completely* undocumented. There's ambiguity and then there's piling shit on top of shit, and if you can't tell the difference, shame on you.

Atom has a real content model. RSS has an offhand comment buried 2/3 of the way down the spec when it mentions that the [description] element "may contain HTML". Or maybe not. I can't tell you, and you can't guess.

You don't exist to make coherent arguments, Dare. You exist solely to pick fights and taunt from the sidelines while real people write real specs and real code that have a hope and a prayer of actually getting used someday.
Comments are closed.