詹姆斯 James

Atom Namespace Problems

November 12th, 2007

My name means the shape I am – and a good handsome shape it is, too. With a name like yours, you might be any shape, almost. Lewis Carroll, 1832–1898

In a recent post on the Feed Validator mailing list, Sam Ruby asked whether there was still a widespread problem with using atom: and xhtml: prefixes in Atom 1 feeds. Having just finished running a set of namespace tests on the aggregators I have installed, I would have to say that matters haven’t improved much since this issue was first discussed nearly two years ago.

Technically this is an XML issue which should be handled automatically by an XML parser; the problem is that many feed readers don’t use one. Being able to handle feeds that aren’t well-formed is usually more of a priority, so feed readers tend to implement a simple regex parser, which often won’t be capable of handling some of the more obscure features of XML.

Of the thirty-odd products I tested, ten 2 were incapable of subscribing to a feed that used prefixed names for the Atom elements. Interestingly, though, some of those that failed were still capable of understanding prefixed elements if the feed at least started off with the Atom namespace as default (not very useful, I know).

More of an issue was the xhtml prefix, which caused problems for nearly two thirds of the aggregators tested. 3 While the feed could still be read and the content was still visible (most of the time at least 4), none of the markup was rendered. Also of interest: Bloglines, while capable of handling an xhtml prefix declared in the root of the feed, wouldn’t handle one declared in the initial div of the content.

Of all the products I tested, there were only three that managed to pass every one of the tests: Snarfer (yeah, I know that doesn’t count), the feed preview in Firefox, and the SimplePie feed parsing library (which I have to say has a neat demo page – makes testing a breeze).

Now some of these tests were fairly obscure, and most likely only of interest to someone like me, but I think at least one of them is worth further mention: Including a namespaced element in a feed item that shares the same local name as another Atom element. Thirteen of the aggregators I tested 5 would misinterpret the element as if it were in the Atom namespace.

This could be a real problem if one were using an extension like Media RSS whose local names conflict with Atom, yet the Feed Validator currently provides no warning on such a feed.

Anyway, for those of you that want to check out the tests for yourself, there are two feeds that I used: one with Atom as the default namespace; and one with the Atom elements prefixed. Both feeds contain essentially the same tests and will likely produce the same results – it’s just that some aggregators flat out refuse to subscribe to the second feed while still passing the prefix test from the first feed (which was meant to predict such a failure).

1 RSS, by not having its own namespace, manages to avoid a lot of these problems (at least the 2.0 side of the family tree).
2 Including FeedDemon 2.6.0.8 beta 3, FeedReader 3.11, GreatNews 1.0.0.383, and RSSOwl 1.2.3 (this problem seems to have been fixed in the 2.0 beta though).
3 Including Google Reader, NewsGator Online, FeedDemon, Thunderbird 1.5.0.13, and RSS Bandit 1.5.0.17.
4 Safari 3.0.3 displayed no content for the item.
5 Including Bloglines, MyYahoo!, FeedDemon, and Planet Venus (revno 264).