Weblogs: Atom
Why Atom was created
Saturday, September 25, 2010Being part of the community that created Atom is something I look back at with pride. I spent a great deal of time in the Atom community, learning firsthand how open and vendor-neutral standards are created.
I taught myself REST while refactoring the original Echo wiki debate between XML-RPC and REST. I built prototypes in various languages and platforms to prove that the Rest based approach was feasible, even spent a few hours trying to figure out whether Flash could do REST. It was a wonderful hive of activity, productivity, and collaboration. Every time I come across a library or a piece of software that supports AtomPub, I take some pride in the tiny part I played in it's creation.
Rough consensus and running code
, that was the mantra of the Atom community; a way of working I could appreciate. So the better ideas won out, because they were backed by actual running code that could be dissected and reviewed. Atompub validated REST as a viable web services architecture, and vast swathes of REST-based webservices today can probably trace their inspirational routes to Atompub, or to people working on Atompub.
In Why Use RSS, Dave Winer reblogs a stackoverflow comment, and claims that Atom didn't solve any problems, it just added another feed format that developers have to support
.
An hour later, one commenter asked why Atom was created and what 'problem' was it trying to solve. I replied to that comment with the following:
It's not a dumb question at all. Before Atom, RSS suffered from a number of well-documented problems:
- Acceptable / best practices were at the whim of one man, and thousands of Movable Type feeds went from examples of best practice to being 'funky', and no clear direction of how to satisfactorily resolve this problem.
- Silent data loss of content because the specification was ambigious/unclear. There was no clear way to add in something as common as a stock ticker identifier in a story inside an RSS feed - Reuters business feeds suffered from this silent data loss, and there was no satisfactory way of working around the problem consistently in aggregators.
- RFC 822 (email) time stamps leave room for lots of ambiguity, particularly across timezones, languages and cultures. Atom uses ISO-8601, which is more amenable to internationalisation.
At the time the RSS2.0 spec was declared a frozen spec, so attempts to correct any of these problems ran into a brick wall. The RSS 2.0 spec made it clear that any further work should be done in "completely new specification formats" - that avenue lead to Atom.
There was a concerted effort to fix these problems in RSS2.0. The contributors did try that, but continued to get roadblocked. So they really had no other workable option but to do a new specification. The previous solution of using namespaced elements from other vocabularies (Dublin Core, RDF) ran into the funkiness problem, and we were left with RSS 2.0 feeds with duplication of information as the troublesome elements had to remain in their evidently broken state so that the appearance of backwards compatibility could be maintained. It made far more sense at that time to branch into a new better specified format.
The upside of starting with a clean state of Atom was we could think through every part of the specification, and use the collective experience of the syndication developers to produce a better specification. Also the discussions around the Atom Publishing Protocol helped kickstart REST as a viable and simpler way of offering web services.
After sitting in a moderation queue my comment was approved and appeared as a reply to the question. But less than an hour later, both comments had been deleted and my disqus account has been blocked from posting any further comments to scripting.com. (His blog, his rules)
[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]