The IETF Atom Working Group has been discussing a new Atom extension for creating threaded discussions between blog. The biggest bone of contention has been two new attributes for the link element which indicate the number of comments in a comments feed and the last time the comments feed was updated. There are two objections to these:

1) Some Atom processing libraries don't expect to see extension attributes on the link element, so they don't preserve them.

2) This data changes independent of the entry itself and can continue changing long after the entry itself has been set in stone, so including it in a feed may result in Atom clients downloading the same entries over and over despite the fact that nothing that they care about (or even process at all) has changed.

The first issue doesn't concern me particularly, but the second could have a significant negative impact. The server can't simply refuse to send out updates to entries just because they don't contain changes to anything but those attributes, or else those attributes will be useless to software that makes use of it (since it will almost always be severely out of date). But sending the updates out to everyone could cause a significant waste of bandwidth and processing power.

My solution is to create a new type of document which would act as a companion to the Atom feed and would carry any data like comment counts and update dates which are directly related to the entries in the feed, but are not central to the entry and tend to be more volatile the the entries themselves. The following pseudo-XML will give you an idea of what it might look like:

<feed ...>
<id>foobar</id>
...
<link rel="volatile" xhref="..." mce_href="..." />
...
<entry>
<id>foo</id>
...
</entry>
<entry>
<id>bar</td>
...
</entry>
...
</feed>

The data above shows how the feed would point to the volatile data document. The following shows what the volatile data document would look like and how it associates its data with the entries in the feed.

<v:volatile ref="foobar" xmlns:v="..." xmlns="http://www.w3.org/2005/Atom" xmlns:thr="...">
<link rel="related" xhref="URL of the feed" ... />
<updated>...</updated>
<v:entry ref="foo">
<updated>...</updated>
<link rel="comments" xhref="..." mce_href="..." type="..." hreflang="..." thr:count="5" thr:when="..." />
<link rel="comments" xhref="..." mce_href="..." type="..." hreflang="..." thr:count="3" thr:when="..." />
</v:entry>
<v:entry ref="bar">
<updated>...</updated>
<link rel="comments" xhref="..." mce_href="..." type="..." hreflang="..." thr:count="0" thr:when="..." />
<link rel="comments" xhref="..." mce_href="..." type="..." hreflang="..." thr:count="1" thr:when="..." />
</v:entry>
...
</v:volatile>

An Atom client application that understands the volatile data document format would subscribe to both the feed and the other document. Assuming the publisher's server supports If-Modified-Since and/or ETag's, it would often send 304 Not Modified responses when clients requested the feed, saving lots of bandwidth, and would only need to send the relatively-small volatile data document more often, and only to client software that knew how to use it.

Someday, I'll have to get around to writing a spec for this...