The logic (or lack thereof) behind xhtml:body

When Sam started a small revolution last month by using <xhtml:body> in his rss-feed, he said this was because it was "more bandwidth and xpath friendly". I can see it's more xpath friendly (though I'm not sure why anyone would want to xpath into the description of an item), but bandwidth friendly? All you're saving in comparison with <content:encoded> is "<![CDATA[" and "]]>", big deal.

On top of that, it seems like every rss feed that uses xhtml:body, uses tags like <body xmlns=""> for every item, instead of declaring the namespace once at the top of the rss document, and using (the more bandwidth friendly) <xhtml:body>. Anybody care to explain the logic behind this?

TrackBack URL for this entry:

a.) If they use an XHTML prefix then they'd have to explicitly prefix all XHTML tags and no one likes writing verbose crap like xhtml:p, xhtml:br or xhtml:b in their documents.

b.) If they made XHTML the default namespace at the root of their document that would effectively be placing all the RSS items in the XHTML namespace unless they undeclared the default namespace for each item but then they'd have to redeclare it each xhtml:body thus making the top level declaration pointless.

It's all quite logical when you think about it.

Posted by Dare Obasanjo at April 23, 2003 1:38 AM

Ah that explains it... and shows my ignorance regarding xhtml ;-)

Thanks Dare.

I still don't see how this is more bandwidth friendly than content:encoded btw...

Posted by Luke Hutteman at April 23, 2003 1:45 AM

I don't see how it's more bandwidth friendly either.

Posted by Dare Obasanjo at April 23, 2003 2:20 AM

Also using <xhtml:body> instead of <body xmlns="..."> would probably break some of the RSS aggregators out there, as many are a bit "dumb" about the XML, using the Tag-Name instead of the element's local-name() to find content.

Of course, you could declare it with a prefix of "x", assuming people are using smart aggregators, since they never really care what prefix you use for a namespace, just what namespace that prefix points to. This would still require <x:body> <x:p> <x:table> etc, and on a post of any reasonable size would probably use more bandwidth than using the default namespace declaration, so there's no real benefit gained.

Oh, and I agree that it doesn't seem more bandwidth friendly.

Posted by Tim Walters at April 23, 2003 7:53 PM

Ack! my last post had all the <tags> stripped out!

Who wrote this buggy comments page? :)

Posted by Tim Walters at April 23, 2003 7:55 PM

I edited Tim's first comment and replaced all <'s with &lt;'s to make the tags show. This should make it a bit more legible ;-)

I guess I should follow phil's suggestion and put some info here as to allowed tags etc.

Posted by Luke Hutteman at April 23, 2003 10:23 PM

nice page. ga zo verder.hopelijk alles goed bij jullie.groetjes en veel liefs voor jullie allen.
paps en mams.

Posted by herman hutteman at April 24, 2003 4:21 AM

More stats for my blog...
More stats for my blog...

Trackback from Keith Pleas Blog at April 24, 2003 2:27 PM

The bandwidth issue looks like a red herring I think. I mentioned these on my site the other week, where Sam said

"All in all, RSS usage is a bit loose, and the specs are best guidelines. Given how valuable this technology is to me, I'd like to nudge it towards being more consistent, well formed, and valid." - source

I think this, along with his recent ghosts and "it's not just for syndication anymore" post, is a pretty reasonable argument for supporting xhtml:body.

Posted by Phil Wilson at April 24, 2003 6:22 PM

The logic (or lack thereof) behind xhtml:body
The logic (or lack thereof) behind xhtml:body

Trackback from .NET Blog - Chris Frazier Style at April 25, 2003 2:41 PM
This discussion has been closed. If you wish to contact me about this post, you can do so by email.