This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: More on that RSS oddness
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.
I pushed an update to BottomFeeder last night that deals with the XHTML <body> tag in Sam Ruby's RSS 2 feed. Here's my problem with what Sam's done (apparently quite awhile back; it's discussed here) - it's not sitting in a defined module, and it's not part of the RSS spec. Yes, it's sitting in a namespace. However, it's a "private" module for all intents and purposes, put forth - from what I can glean from Sam's site - because there's some thought that it's "bandwidth friendly", and easier to parse. The former, maybe. The latter? Here's a cluestick - if you have a halfway decent XML parser library, neither the XHTML nor the encoded html is any harder or easier to parse - as an application developer, you never see either one. This is a silly concern over utterly irrelevant technical points. There's also the fact that - as a non-standard extension - aggregator developers are only going to notice this IF they happen to subscribe to a feed doing this, and IF they notice that the content disappeared (which is what I noticed yesterday).
I did a seach on Blogdigger for "xhtml body" - and one on Feedster. Blogdigger brought back 3 results, none of them relevant. Feedster answered zero results. Google actually got me to the relevant blog posts (no pages describing this as a proper RSS Module though). This is a private extension dreamed up by a few people not actually creating aggregators themselves under some delusion that it makes life "easier". Not to mention that all of them are doing it slightly differently - some of them just slapped a <body> tag around the text in <description> - some are throwing out a separate tag, like a module (but again, not documented as such). I dealt with the body tag inside descriptions months ago when I stumbled on it.
Contrast this with something like the Comment API - there's an actual page describing the module - what it is, what it's for, how to implement it. As opposed to this atrocity - described in a few blog postings and foisted on aggregator developers for absolutely absurd reasons. This makes me oh so confident in the eventual outcome for Atom - how many "because we can!" things will end up being tossed into that spec? Or worse, how many won't be, but will start getting used anyway?
Previous Topic
