Tim Bray’s statistics show a small but growing number of people prefer his Atom feed over his RSS 2.0 feed.
As my weblog supports more feed formats, my data is a bit more spread out. About 45% are subscribed to my RSS 0.91 feed, 10% to my RSS 1.0 feed, and the remainder are pretty evenly split between RSS 2.0 and Atom 1.0. The other feed formats get trace amounts.
This leads me to wonder how many aggregators actually support RSS 0.91 correctly, as that is the one feed format that is unambiguously <plaintext> from top to bottom.
Last year, I removed all of my redundant comment feeds. Perhaps it is time to weed out my primary feeds too.
The fact that you make 10 feeds available, all of which have the same content, does make for confusion. I appreciate that offering an RSS 3.0 feed may be making a political statement, but it’s not exactly useful to many people. Same goes for CDF which is essentially dead.
The best advice I’ve heard is to choose one feed format and stick to it. I personally chose Atom 1.0 because it’s the only one that is a firm standard, and I’ve had no complaints about it not working.
Turns out I’m reading the rss2 feed via Bloglines ... and you broke it this morning. :)
It began with .... (dropped the < before one P tag to avoid interpretation by your weblog comment form) :
</a></h3> p><table cellspacing=0 cellpadding=0 width="100%"><tr><td class="article">45% are subscribed to my RSS 0.91 feed. This leads me to wonder how many aggregators actually support RSS 0.91 correctly, as that is the one feed format that is <a href="http://my.netscape.com/publish/formats/rss-spec-0.91.html" target=_top class=blines3 title="Link outside of this blog"> unambiguously</a> <plaintext> from top to bottom.
... and munches the remainder of the Bloglines page (all the HTML markup is visible/uninterpreted).
As Tim just noted, it is not just the .rss2 feed that broke. I switched the the .atom feed with similar results.
First bit of visible/uninterpreted HTML begins at a different point (again dropping the < before P to avoid interpretation):
</a></h3> p><table cellspacing=0 cellpadding=0 width="100%"><tr><td class="article"><div xmlns="http://www.w3.org/1999/xhtml"> p>Tim Bray’s<a href="http://www.tbray.org/ongoing/When/200x/2004/12/12/-big/Feeds.png" target=_top class=blines3 title="Link outside of this blog">statistics</a>show a small but growing number of people prefer his Atom feed over his RSS 2.0 feed.
Hah, apparently I was subscribed to the .91 feed as well. This PLAINTEXT thingy broke the display of the description (but not the title) in Opera 9. AFAIK, feed aggregators don’t always believe that users will abstain from using markup in their descriptions, whatever the spec says.
The Atom feed work perfectly fine. I think I’ll switch permanently...
This leads me to wonder how many aggregators actually support
RSS 0.91 correctly ...
This comment demonstrates why I read Intertwingly. You’re like Kurtz in Apocalypse Now, heading further upriver even though you know in that direction lies madness.
Like Captain Willard, rather.
And no, nobody needs to finish the characterization.
Sam, your link to Tim’s graph returns a forbidden error (assumedly it’s checking the referer). It may appear to work if you had previously viewed the graph from his site and it was saved in your cache, but for a first time viewer it’s going to complain.
As for RSS 0.91 support in aggregators, every client that I have tested (of which there are 15) interpreted descriptions as HTML. As for titles, about 80% interpret them as HTML, but there’s some variation depending on what kind of markup you’re using (I suspect this is more a case of buggy code than fancy heuristics, but I could be wrong).
I don’t think you’re going to convince many aggregators that they’re doing the wrong thing though. And while the RSS 0.91 spec may have been clear, it could be argued that RSS 2.0 made it ambiguous the minute it allowed HTML in descriptions while claiming compatibility with RSS 0.91.
I’m in a good news/bad news situation. The entry didn’t break JournURL’s display like it did Bloglines and Newzcrawler, but there was silent data-loss as the tag was stripped rather than escaped.
Fixed now... thanks for pointing this out, Sam.
hi sam,
Once I use a feed URL, I usually don’t change it — especially now since OPML has come and I can export/import from various readers (not all readers are smart as of now but I’m sure that will change)
Is there a way you can inform your old RSS version readers that they’re using an OLD feed standard ? Maybe, you could generate a small header message with a link to the new feed (ATOM) ?
BR,
~A
your link to Tim’s graph returns a forbidden error
OK, I’ve changed to link to Tim’s piece that includes the graph.
it could be argued that RSS 2.0 made it ambiguous the minute it allowed HTML in descriptions while claiming compatibility with RSS 0.91.
To my knowledge, the only compatibility claims that RSS 2.0 made were that all RSS 0.91 feeds were valid RSS 2.0 feeds (modulo the version attribute on the rss attribute). Of course, the present RSS 2.0 skipHours
element is only compatible with Netscape’s 0.91, and RSS 2.0’s textInput
is only compatible with UserLand’s 0.91.
if this post broke your reader, then your reader is broken
Bloglines now strips <plaintext>. As near as I can tell, none of the other problems have been fixed.
To my knowledge, the only compatibility claims that RSS 2.0 made were that all RSS 0.91 feeds were valid RSS 2.0 feeds (modulo the version attribute on the rss attribute).
Ok, look at it this way. Say you wanted to include a description in an RSS 0.91 feed like this:
“An HTML anchor starts with <a”
RSS 0.91 descriptions are supposed to be plain text so no escaping is needed for the less than sign (other than the XML escaping obviously). Run it through the feedvalidator and you’ll get a happy little “RSS Valid” icon.
Now try changing the version number from 0.91 to 2.0 and see what happens. The feedvalidator will report “Invalid HTML: EOF in middle of construct”. Only a warning, mind you, but the reality of the situation is that the feed is broken. No RSS 2.0 aggregator is going to handle it correctly.
If the RSS 2.0 spec is correct in claiming that a version 0.91 feed is also a valid 2.0 feed, then this sort of thing shouldn’t be a problem. Clearly it is as problem, hence the confusion.
“An HTML anchor starts with <a”
Oh, you mean like this? Yeah, that changed between Userland RSS 0.91 and RSS 0.92.
The Atom feed doesn’t have pictures, and it doesn’t have the “Read More” link that takes you to the actual post.
It does have pictures, but it uses xml:base
to shorten their URIs, which Safari evidently does not support after all. (It would be nice if someone could fill in the Safari rows in those tables.)
Also, the Atom feed is full-text, so you don’t need a “Read more” link. In case you want to bring up the article on Tim’s site, you can just go to the permalink. (Then again, it too relies on xml:base
, so Safari may be falling flat on its face with that one too.) But for those who only want a summaries, the feed does have atom:summary
elements, which, if used, should be adequately distinguished from atom:content
by the aggregator – f.ex. by offering such a “Read more” link. This is the right distribution of responsibilities; the presence and presentation of such a link should not depend on the whims/tastes of the feed publisher.
In other words, these are bugs and shortcomings of Safari, not of Tim’s Atom feed.
The Atom feed doesn’t have pictures
Actually, it does. But due to Tim’s liberal use of xml:base, many aggregators don’t know how to get to them.