This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Blah blah blah
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
We've been grappling with this issue for some time now on atom-syntax. There's no way around RFC 3023, and believe me we've tried. If you've been downloading XML and throwing it blindly into your XML parser without looking at the Content-type header, *you are doing it wrong*. There's no two ways to look at it. You're just wrong. Stop doing that.
It all depends on context. In a business application, this matters, a lot. You don't want to make assumptions about data there; your assumptions could be disasterously wrong. However, it's not the same thing at all in a consumer context with textual content. For news aggregators, making assumptions about the sort of content you have is fine, because the end user just wants to read the blasted content - we typically aren't talking about B to B data interchange here any more than we are in usenet content. Telling aggregators to reject data that can be interpreted fairly accurately is like telling people to toss the newspaper if parts of the front page are smudged.
Based on current real world feeds, an aggregator simply can't toss feeds based on RFC 3023; you would end up rejecting feeds in large numbers and - trust me on this - have end users telling you that you have bugs in your application. At this point, the best you can do with Content-Type headers is use them as a hint when you see them - because actual practice varies too widely.
Previous Topic
