RSS and Atom guru James Holderness just issued a report on the how well namespaces are being handled by feed readers that understand Atom. The results are dismal:

…Matters haven’t improved much since this issue was first discussed nearly two years ago.

… Of the thirty-odd products I tested, ten ² were incapable of subscribing to a feed that used prefixed names for the Atom elements.

… More of an issue was the xhtml prefix, which caused problems for nearly two thirds of the aggregators tested.

… Of all the products I tested, there were only three that managed to pass every one of the test.

Appalling. This isn’t a reflection on Atom, however, but rather on how programmers are parsing XML itself.

In olden days (2001-2003) I worked for a company that was building a native XML database. At the time, namespace handling was probably the biggest headache around. Our product didn’t do it well, but few others did either. Considering how many parsing libraries and products there are now on the market, and how ubiquitous XML has become, I would have hoped that namespacing problems would be a thing of the past.

<bubble>burst</bubble>

All too often our applications are filled with XML seemingly drawn with crayons when the authors should have used a drafting pencil and a straight edge.

I believe one of the fundamental problems with XML is that nearly every app developer uses it, but few actually grok how to model data in it. Note that I said model data… not just dump it. Elements versus attributes, namespaces, attribute scopes, self-closing versus empty-value… these decisions can make or break a data model. If your data matters, then the form in which you represent it - and the precision derived from that form - should matter as well.

The Atom spec has model and precision down pat. Now we just need feed readers to be as careful consuming XML as the specification was in creating it.