Solipsism Gradient

Sam, thanks for the fast feedback…

Sam Ruby wrote:

internal tags don’t need the prefix, they need the namespace.

By setting the default namespace locally on the xhtml:body (or xhtml:div if we all change to that), then no extra characters are required.

Thanks for the correction, I overlooked that. For some reason, when I first implemented my RSS 2.0 feed, I assumed that declaring namespaces was a RSS 0.9x or 1.0 thing only, and although I learned otherwise later, somehow didn’t connect this to the <xhtml:body> case.

Posted by Guest:
internal tags don’t need the prefix, they need the namespace.

By setting the default namespace locally on the xhtml:body (or xhtml:div if we all change to that), then no extra characters are required.

See my http://www.intertwingly.net/blog/index.rss2 for an example.

The poor brain boggles. Let’s see if I can make sense of this…

First Don Box switches his RSS feed to support <content:encoded> (which is what I did from early on, BTW). Then Sam Ruby gently chides him for that, proposing the use of <xhtml:body> instead, a form which I hadn’t read about previously.

Then, Don immediately agrees and posts examples – curiously enough, they mess up his <content:encoded> RSS feed to illegibility (at least in NetNewsWire). Looking at the source, I see nested <content:encoded>s and CDATAs, and many unescaped tag delimiters; all this may possibly be syntactically valid, but it’s extremely confusing; I tried to hand-parse it and didn’t go very far. FWIW NetNewsWire seems to agree with me … my own feed never nests these things. Don promised to fix this by Monday.

Comments at Sam Ruby’s post soon discuss details and a few samples appear. Sam himself updates his own feed to <xhtml:body>, saying it’s “more bandwidth friendly” than <content:encoded>, which probably won’t be true if all internal tags must also contain the xhtml: prefix, as some argue.

Meanwhile, Jorgen Thelin asks for more stability, arguing that such fast changes in the interpretation of RSS makes compliance impossible. The comments to that by Sam and Don are very thought-provoking, and I’ll read them again carefully tomorrow, before I make any changes to my feed.

Sjoerd Visscher, in the meantime, proposes using <xhtml:div> instead of <xhtml:body>; Don disagrees, saying this would not convey the meaning that this tag brackets the real content. Sam arguments that the purpose of the whole exercise is avoid making the structure of the comment opaque; he also changes his own feed to the new scheme. NetNewsWire apparently doesn’t understand it, and falls back to using the <description>.

It’ll be interesting to see what newsreader authors say about this. Greg Reinacker says he’s already made the necessary changes in NewsGator. Purely from a newsreader’s perspective, I’m not sure if Sam’s comments about opaqueness apply; newsreader software always has to try to show something, even if the feed is malformed. I suppose NetNewsWire, for instance, whenever it sees a <content:encoded> tag it just shoves the contents into the lower-right pane, trusting the built-in HTML parser to do the right thing. And once Brent switches over to Apple’s upcoming WebCore, he’ll have even less to worry about. Meanwhile, I’m not sure supporting xhtml: prefixes in NetNewsWire will be trivial; he’ll probably have to prescan and take them out…

On the other hand, I agree that making the contents more structured may help Feedster and similar efforts.

Regarding the <xhtml:div> vs. <xhtml:body> question, my (probably naïve) first reaction is that <xhtml:div> will make things easier for browser-based aggregators, as the contents will be easily insertable into another page; whereas <xhtml:body> tags will have to be removed or converted, and also must contain block elements… isn’t it easier to treat the contents as a div and add an implicit body around it whenever necessary? For my weblog at least, a post is never displayed separately on a page, so my feed reflects exactly my top page, as a list of over a dozen posts. Perhaps both options should be allowed?

I’m looking forward to learning more about XML, XHTML and RSS from this discussion. Thanks, everybody!

For several reasons I decided to rename this weblog “Solipsism Gradient”. Blame it on having reread all of Iain M. Banks‘s Culture novels in a row…

…on the practical side, it’s shorter and easier to remember than “Stochastic Aleatory Ontological Expostulations”, or whatever it was before. At least for me. 😛

Now, can someone explain to me why weblogs are traditionally named like rock bands? (Or Culture starships, for that matter?)

As the subject says , now and then I’ll post interesting links and/or talk about random subjects here. More structured topics will be added.

Currently, nobody else is allowed to post comments here – at least until I figure out a way of initially hiding these comments from others. Stay tuned…

x AKA M. wrote:

I had missed the point being to communicate with spiders. It became more clear due to Kevins patient explanation at Joi Ito’s blog in this thread. I thought it was so people could vote on links, not spiders.

Yes, Kevin’s explanations are great. However, just for whoever else’s reading this, I’d like to make clear that people (or at least whoever puts the links on the site) do vote on the links, but it’s the spiders (not other people) who count the votes.

I had not thought about, spiders, bots, and engines out there secretly logging your activities and words and generating Whuffie points. Cool thought.

Exactly, having an attribute would make all that much easier; see how TechnoRati and Google have to jump through hoops to do their rankings, and still they have no clue whether my links are meant to be positive or negative. Also, votes will not depend on anything whatsoever being installed on the site being voted on, which is extremely important.

Posted by x AKA M.:
I had missed the point being to communicate with spiders. It became more clear due to Kevins patient explanation at Joi Ito’s blog in this thread. I thought it was so people could vote on links, not spiders. My bad. It does bring up a thought closer to the heart of the Whuffie concept: Automated Whuffie. Though Doctorow’s book is not that clear on how one’s Whuffie is built, (or torn down for that matter), thus far the discussions I have had (OK I admit they are with myself most of the time) have pointed to merit being added by people. I had not thought about, spiders, bots, and engines out there secretly logging your activities and words and generating Whuffie points. Cool thought.

Ciao

M. (or is it X?) at Whuffie comments:

Kevin Marks and Rainer Brokerhoff blogs are ‘abuzz with talk of adding a value system to your html links. That way when you create a link you can assign a value to it to show how much you “approve” or “disapprove” of what you are linking to. While this seems to create a quick and easy Whuffie like system, it is not at all comprehensive, and I have to question if it would really be worth the trouble. Why not just put a header above the link: “I hate this blog, I don’t trust them, they suck, but check them out to mock their very existance” Same effect, no?

I don’t think this is the same effect at all. The proposed link value system is to have a simple way to tell spiders (and similar robots) that scan the HTML for links whether you approve or disapprove of that link. Of course, as Kevin points out, one often will complement this by user-visible styling (or even a header).

While it of course is a “Whuffie”-like system, the effects are not exactly the same – since valued links will usually point at individual posts or news items, the resulting values will not necessarily apply to the whole site. They may not even apply to the item’s author. I agree that it isn’t comprehensive – by design. Rating systems that are installed on a particular site solve other problems entirely, but I’d like a way to say to search engines “here’s a link to this item, but I disagree with it; don’t tally my link on the same list with people who agreed with it”.