Curiouser and Curiouser!

About

Wherein Matt Mower (aka rubymatt on FreeNode) rambles about technology, the love of a good MacTop, ruby coding, rails, topics, knowledge management and learning, and politics.

Navigation

Blogroll

Syndication

Curiouser and Curiouser! on rss-data http://matt.blogs.it/ RSS feed for topic rss-data Copyright 2006 Matt Mower Squib/0.1 self@mattmower.com self@mattmower.com en-gb Ungrokked RSS-Data Wed, 08 Oct 2003 13:25:54 +0100 <div style="margin-left: 40px;"><a href="http://www.docuverse.com/blog/donpark/2003/10/07.html#a959">RSS-Data</a>. </div> What I like about <a href="http://radio.weblogs.com/0113297/2003/10/01.html">Jeremy Allaire's RSS-Data proposal</a>: <ol style="margin-left: 40px;"> <li>Reduced need to change RSS schema, binding, and parser to support new payloads. </li><li>Possibility of reusing XML-RPC code and SOAP code. </li><li>Arguably faster to parse. In my experience, element-rich XML documents are faster to parse than attribute-rich XML documents. But this is not important given readily available processing power at the consuming end.</li></ol> What I dislike: <ol style="margin-left: 40px;"> <li>Ugly and harder to read although not as bad as RDF. </li><li>Increased need to change RSS application to support new payloads. </li><li>Contextually inconsistent and verbose. <name> <name>value</name>  <name> <name>name</name>  <value>value</value> </name> </name> </li></ol> With RSS-Data, developer's attention will shift from RSS parsers to RSS application frameworks capable of supporting new payload types and routing mechanics via plugins. Despite <a href="http://www.kuro5hin.org/story/2003/10/7/172247/665">irksome cosmetic downsides</a> of RSS-Data, I like that. Only problem is that one can make the same arguments for RDF which makes me a hypocrite. No news there, but I find it ironic to see RDF folks attacking RSS-Data. <div style="margin-left: 40px;"> [<a href="http://www.docuverse.com/blog/donpark/">Don Park's Daily Habit</a>] </div> Hmm... .I tried to read Jeremy's posts on RSS-Data but found there was too much stuff in the way of understanding the basic proposal.  What seems to be suggested is a generic framework for transporting data in an RSS item which isn't terribly astounding so I guess there must be something more exciting going on to raise all this fuss. Is there an RSS-Data in a Nutshell post to be had? http://matt.blogs.it/entries/00001661.html Considering RSS-Data Wed, 08 Oct 2003 23:09:56 +0100 I was going to leave this as a comment on <a href="http://www.docuverse.com/blog/donpark/2003/10/08.html#a961">Don's piece on RSS-Data</a> (hello Don!) but it grew to the point where a post felt more appropriate.  Anyway my grateful thanks to Don, for his short but sweet explanation. <div style="margin-left: 40px;">RSS-Data = Typed maps for RSS2.0 right? </div> Okay i'm glad it's an RSS2.0 extension.  But is it a good thing? I guess I have bought into the idea that one of the things we bought when we paid for XML was the notion that the tags carry semantic value. Applications having to understand the semantics is one of the prices of doing something useful.  Or at least that was what I thought. But maybe that shouldn't be the case for things such as extensions.  I guess i'm wondering whether <a href="http://matt.blogs.it/specs/ENT/1.0/">ENT</a> would have been written as a separate module if RSS-Data had been around in April.  Maybe it would have been easier to simply identify a few RSS-Data entries to add to an item to convey topic information...? My gut instinct is that it might have been easier to sell, but that it wouldn't make as much sense.  Describing ENT tags strictly as a set of attribute:value pairs would be more confusing and possibly harder to process.  I think ENT has a distinct flavour and that this is not a bad thing. There's room for both approaches, we'll just have to see. Oh and a caveat:  Your data isn't going to be named signature, value and cert unless you want them clashing with any other possible applications of those names, so you'll probably end up prefixing them as in: <ul> <li>com.docuverse.blah.signature</li> <li>com.docuverse.blah.value</li> <li>com.docuverse.blah.cert</li> </ul> http://matt.blogs.it/entries/00001664.html