Atom Torture Test
For somewhat inexplicable reasons, I got into a conversation about RSS feeds in general, and mine in particular, over at Sam’s blog.
As you might have noticed, I’ve deprecated several of my RSS 2.0 feeds, in favour of their Atom alternatives. There’s a reason for that. If you’ve subscribed to a full-content feed, it’s probably because you want to be able to read the content of my posts in your feedreader. That’s cool with me, but for a variety of reasons, those RSS 2.0 feeds will not display the content correctly. And there is really no way to fix them.
At least in principle, the Atom alternatives ought to be better. But are they?
Here are 4 areas where your RSS feedreader fell on the floor. Let’s see if its Atom support is any better. For the first one, there are already tests in the suite of Atom conformance tests. For the latter three, I wrote a little test feed of my own.
- Relative URLs: relative URLs in my posts (or in comments thereon) should have been interpreted as relative to the URL in the
<link>element of each<item>. Since such eventualities are not actually covered in the RSS 2.0 “Spec”, chances are those links were broken. Atom adds explicit support forxml:base. Does your feedreader actually implement it properly? - XHTML: RSS 2.0 has no mechanism for telling your feedreader that the markup in the posts is anything other than tag-soup. In fact, without explicit extensions, like
<content:encoded>, it doesn’t even have a mechanism for telling the feedreader that it contains markup at all (the feedreader has to guess). Atom includes atype="xhtml"attribute which tells the feedreader that the content is actually XHTML. Does your feedreader pay attention, or does it just assume that everything anyone writes is tag-soup? - MathML: if your feedreader recognizes the content is XHTML, and the rendering engine it uses is MathML-aware, then you might just be able to see the equations. (Thunderbird ought to fall into this class, as do, I am told, some Windows-based feedreaders when the MathPlayer Plugin is installed.)
- SVG: I use SVG for figures. No, I don’t include the SVG inline (thought that would make a nice torture-test). I include them using the
<object>element. Nested as the content of the<object>element is a GIF image, to be used as a fallback alternative.
Now, many feedreaders quite properly sanitize their inputs to eliminate hostile applets (loaded via the<object type="image/svg+xml" data="http://golem.ph.utexas.edu/~distler/blog/svg/bhformation.svg"> <img src="http://golem.ph.utexas.edu/~distler/blog/svg/bhformation.gif" alt="..." /> </object><object>element). I suppose I can forgive feedreader authors for stripping out all<object>elements, rather than trying to distinguish between potentially hostile ones, like applets, and obviously benign ones, like SVG files. But, either way, it is inexcusable to also strip out the fallback content of the<object>element. You should, at the very least, see the GIF image.
So how did your feedreader do? Did switching to Atom actually fix any of these issues for you?
Re: Atom Torture Test
Care to create a ConformanceTest page on the Atom wiki, and seed it with a row or two of results? If you do, I’m sure that others will add additional rows and maintain it from there.
The hope behind capturing pointers to all such tests in one place is that eventually all actively maintained aggregators will converge on the correct behavior.