Standardizing the Atom Thread Extension

I have been an advocate for the Atom Feed Thread extension for quite sometime, and am an active developer of it. Within Six Apart I have helped deploy the extension across over 1 million Friendster blogs, I have developed my own plugin for Movable Type to make it easier for users to take advantage of this extension and I am actively working to deploy the extension across all Six Apart products and services.

This extension is actually in the final stages of becoming a standard – which is fantastic. Fantastic for James because he may finally see the fruits of his labor which entailed ushering this specification through the IETF (no small task), taking feedback in the form of hundreds of emails and countless phone calls, and authoring over 10 different drafts of the Feed Thread specification.

But James’ ego aside, this extension is great for syndication industry as well.

First, when this extension becomes a standard it will validate and fulfill an important part of the Atom Working Group charter - to define a feed format that was easily extended by third parties. Some will argue that this has already been accomplished by companies like Google which released their own custom Atom extension(s) to support Google Calendar, but I believe this milestone of the Thread extension becoming a standard is much more significant because it sets an important precedent. It demonstrates the value of the standards process plays not only in defining the core protocol, but in defining extensions as well.

To illustrate why this process can be important, let’s take a look at a similar effort to solve the comment feed problem through a process driven primarily by individuals operating in a relative vacuum: RSS.

The first implementation of a comments element in RSS was introduced by slashdot. In this first incarnation of a comment extension to RSS, slashdot was only trying to syndicate the number of comments associated with a post. There was no desire to syndicate the comments themselves. To this day, slashdot’s implementation remains the same: a <slash:comments> element containing the number of comments associated with an item.

This suited the market for a time, but eventually it failed to meet the market’s evolving demands. So the market invented another comment extension for RSS. This time, a comments element was introduced by an individual that would provide a pointer to an endpoint where new comments could be posted via a proprietary Comment API.

Ok, I can see how this is useful, and perhaps even “cool.” It also serves as another example of how extensible RSS really is. But yet again, this new extension failed to meet the market’s needs. So yet another individual proposed and created yet another RSS comments extension. This extension provided a new element called <wfw:commentsRss> which provided a pointer to an RSS feed which would contain all the comments associated with the containing item. Now we are getting somewhere, finally there is a predictable way to syndicate data that might actually be useful to third parties hungry to consume more and more data in an easier fashion.

In fact, this extension proved useful enough that is was eventually folded into the RSS 2.0 specification - proof positive that RSS is open to change and that the efforts by the community are realized and folded into the core specification.

One of the problems as I see it though are that by using any or all of them in combination with one another one can royally confuse the semantics of their feed by having elements named: <slash:comments>, <wfw:comments>, <wfw:commentsRss> and/or <rss:comments> (depending). Some may not think this is a problem, but others want their XML documents to actually be descriptive and semantically valid. (I happen to be one of those people.)

But semantics aside, none of these extenstions, even when combining all three, are sufficient, because they were all developed in a vaccuum to solve a specific problem. Never could I find someone taking a step back and asking, “ok, what are all the problems that I should solve with this extension?” For example, how can these extensions satisfy these simple use cases?

  • The ability for a third party to easily detect when a new comment is added to a specific item or entry.
  • The ability for a third party to determine what a given comment is in response to, both comments in response to posts and to other comments (in the case of a system supporting threaded comments).

They can’t, at least not without requiring clients to parse a number of different RSS feeds to deduce the information they need. And even then, there are edge cases that are difficult to address, because you are leaving discovery to a deduction process without being direct and clear within the semantics of the protocol.

So in the end, what has this process delivered to us? Four different RSS specifications that overlap semantically, duplicate functionality and don’t address all the needs of the market; ultimately leading to confused implementers which don’t know exactly which extension to implement and implementations that fall short.

Now, let’s return the Thread Extension for Atom. I admire James for his patience in ushering the Thread extension through the standards process. Let’s face it, there are some real trolls out there, and not everyone whose opinion you really should consider are always polite, open-minded or reasonable as you want them to be. In the end James managed to author a robust and tested specification despite it all.

And the proof is in the pudding. The Atom community now has an incredibly robust specification for how to syndicate comments in Atom feeds, and one that has already begun to be adopted by the market - including one the largest blogging service providers on the Internet.

Personally, I like the extension because it offers a single and clearer alternative to the four RSS comment feed variations, and an easier and less ambiguous specification to implement; while at the same time meeting all the requirements my use cases demand. What follows is a brief overview of the functionality this extension provides.

The “replies” link relation allows me to refer to a URL where I can find a list of comments, but unlike the <wfw:comments> extension in RSS I can refer to the HTML representation of those comments, or the Atom representation of those comments - providing greater flexibility for the implementer. For example:

<link rel="replies" type="application/atom+xml" href="http://foo.com/11/comments.xml" />

vs.

<link rel="replies" type="text/html" href="http://foo.com/11.html" />

The <thr:count> attribute provides the same functionality as the <slash:comments> element in RSS, but again, this capability is not in another specification I have to implement, it is semantically clear and does not conflict with other elements with the same name.

The <thr:when> attribute is unique to the Thread extension and provides a completely unambiguous mechanism for third parties to know when a new comment has been published, without requiring the client to parse an additional feed for an <updated> element (which may or may not refer to the time a comment was published).

The <thr:in-reply-to> element is also unique to the Atom Thread Extension and provides a way for an entry to express to what it is in response to. This element can not only refer to a post, but it can also refer to another comment allowing for threaded or hierarchical conversations to be represented by this format. This is a powerful concept in LiveJournal and WordPress which support threaded comments.

That’s it. There are only a handful of elements. Their meaning is clear, their utility obvious. What more can you want from a spec?

Kudos to James and all the people in the Atom community who helped him get this thing written. It is a great effort.



Close