Détente Dilemma
Rogers is looking for a way to legitimately jam extended characters into RSS feeds -
If that's supposed to be the final word on RSS, can somebody tell me how to build détente?
– Workbench.
Problem is, the specification is unclear, so it appears that there’s no legitimate way to do this – this means that developers working on different projects might try and solve the problem differently. This leads to different users seeing content in different ways depending on the tool that they are using to read it – regardless of what the original publisher intended.
Rogers tested out a bunch of different RSS clients to see exactly what these differences are in the real world.
Here’s how Bloglines looks:
…and here’s the same headline in Internet Explorer 7:
I also did a capture of how this same headline looks in Skydasher as parsed by our shiny new Feedcache:
Personally, I think the answer is simple – stop trying to build RSS that validates and instead, try and build RSS that works in the way that you need it to. This means that its pretty unlikely that you will ever deploy RSS that actually atorns to the RSS specification. But you know what? I don’t think it much matters – not to real users anyways. I could wax eloquently about how a proper RSS parser won’t ever expose any of this ugliness to an end-user and that such issues are solely a problem for developers to negotiate. But I won’t.
After all, I’ve got user requirements to tend to. 
See this post as it first appeared on Blogware.
3 comments
Comments are closed - these are kept exactly as they were left.
Phil Ringnalda, March 1, 2006
I'm sorry to be so slow, but I don't get your point. I've got user requirements, too: I made the mistake of touching the feeds from Mozilla's Bugzilla install, so now I own an infinite number of search feeds from 300K bug reports, a huge share of which have less-than characters. How are you saying I should deal with that problem, given that when we did RSS with plain text titles, Bloglines would actually render the HTML, so a bug about form buttons would have an actual button in the title, and when I tried escaping it as though titles were HTML instead of text, then Google Reader double-decoded it, and displayed actual form buttons?
I'm not specsturbating here, I have literally hundreds of thousands of items, and enough volunteers and willingness to persuade aggregator developers to do the right thing (Mozilla's done lots of "this is the right way, so we're going to do it and teach you and teach you until you do the right thing, too"), but there just wasn't any way to say what the right thing was. Either answer is reasonable, neither is clearly superior, but it has to be one or the other, it can't be "eh, whatever, dude" without our developers reading about "Crash with , , or when or ."
Of course, I don't know why I'm spending so much time trying to make RSS usable, when there's the simple answer I already took ;)
Jas, March 2, 2006
I too don't get it -- what does "works in the way that you need it to" mean? For me, my syndication feeds "work" when the content contained within them is reproduced reliably by syndication feed consumers; in a real sense, my feeds "validate" only when parsers are able to transform their content back into the original data which was used to create the feed. Rogers has done a good job of showing how that's completely impossible using the RSS 2.0 spec as it stands.
Ross, March 2, 2006
Implicit in the "answer" that I gave was the notion that developers, lacking the benefit of a clear spec, must fend for themselves and their users. This means one of two things - build/parse feeds in a way that suits your users or deal with the spec literally and roll with the punches. Implicit in the notion of build/parse in a way that suits your users is being flexible enough, in code and in working with other developers, to get to a point where the "right" thing is possible. That might mean more complex code, or more complex relationships, but in my experience, it inevitably ends up meaning that users get the results they expect.