Tim Bray – currently working at Sun, is talking on the Atom protocl as a case study. What lessons can we take away from Atom – was it necessary, was it done in the right way, and what is the right way to try and standardize Internet interop protocols.
slides at tbray.org/talks/etech2006
At the moment RSS is the most successful use of XML in the world – 27 million known feeds – 2 million feeds being updated every week. So why try to replace it with something new?
Enclosures – the current RSS spec says you can only have one per feed, though many podcast feeds use multiple enclosure – clients vary unpredictably in how they support them.
Silent Data Loss – if you put in a string like “AT&T” that’s not well-formed XML, the kind of markup you have to do to work in the different clients vary widely. What happens when you want to post something like ” up $1.32 – the ticker vanishes.
Especially problematic if you need to put characters like angle brackets in feed titles.
Links – RSS feeds don’t know about relative linking paths.
Problems – URLs that aren’t all ASCII – like characters with umlauts. There’s a standard called IRIs for this.
Problem with APIs – the MetaWeblog and Blogger APIs are under-specified, under-secured, poorly debugged, offer little interoperability, and omit many important authoring features.
So we have issues in RSS. We have a lot of experience with RSS now and where the problems are. THe normal course of affairs with the Internet is that when you have a successfully deployed protocol that needs new features you revise it.
Once you want to fix these things the RSS road map suggests you ought to do it under a different name. Then there’s the issue of syndication culture – apparently civil discourse is hard to have in the RSS community. The culture had become sufficiently toxic that it necessitated starting something new.
Sometime in 2003 Sam Ruby started a wiki to discuss this new syndication format. the email archive on the discussion on the format took 17,944 email messages to decide.
How could this been so hard? You can’t imagine how insane the debate on publishing dates was. Feed aggregation was another set of issues.
In July of 2005 RFC 1287 was approved.
The publishing protocol – had it’s own set of issues – took from Sept 2004 to March 2006 to get to a stable draft.
Was this a good idea?
Up till now all the standards were created by one guy or a few in a lightweight process.
The IETF process – all done by email/wiki – consensus decreed by chair; may be appealed. Trolls can be banned for 30 days; may appeal. General review by whole IETF. It’s irritating and slow, and it takes time. Having said that, Tim’s prepared to argue that it’s a good thing. The whole notion of a civilized society is that you don’t take out disagreements by force, but you go to court instead – it’s not pleasant, but it’s better than violence. The IETF process insures that nobody can say that the process wasn’t followed, or that people didn’t have a chance to have a say. The IETF review
Atom is a lot liek RSS2, except –
Feeds & entries must have unique IDs, timestamps, & human-readable labels. Text can provided plain, in HTML, or XHTML, with clear signaling. Can provide both summary and full content. Namespaces & extensibility are clean.
Atom seems sufficiently extensible that there shouldn’t need to do an Atom 2.0.
Atom is the general-purpose collection idiom that XML has never before had. A whole lot of business processes require exchanging collections of various kinds.
In Atom Publishing you put something out on the server, and then the server comes back and gives the client a URI where it put it.
Atom publishing should allow for a proliferation of blog authoring software – the APP is the missing infrastructure link in making the WEb writable by everyone.
Most feed-reading applications and libraries handle Atom 1.0 well, except Bloglines.
Google uses Atom 1.0 in its AJAX APIs.
Will Atom be mainstream, or a footnote? The odds are pretty good that it becomes mainstream.