It seems that RSS-Data is confusing to some people (hello Matt ;-p) so I'll attempt to clarify.
RSS-Data is a proposal to create an RSS 2.0 extention that allows arbitrary instances of generic data to be embedded in RSS 2.0 feeds without requiring introducing new elements with their own micro-schema and namespace.
It is just a proposal at this stage meaning there is no concrete format yet. Examples out there are just sketchs of what it might look like.
It is an RSS 2.0 extension that adds a new way to extend RSS 2.0, an extension extension, if you will.
A typical way to extend RSS 2.0 involves adding a set of new elements belonging to a namespace like this:
<item>
<link>blah</link>
<description>blah</link>
<my:element xmlns:my="http://...">value</my:element>
<your:element xmlns:your="http://...">value</your:element>
<Signature xmlns="http://www.w3.org/...">...</Signature>
</item>
Note that 'my:element' has it's own schema and a namespace, knowledge of which leaks to the application layer even if RSS parsers pushed up all unknown elements up to the application layer. At application level, these new elements and attributes have to be fetched and navigated somehow. Unfortunately this is cumbersome for most languages. Think about having to compare URL to distinguish elements and how one could differentiate attributes from child elements. XPath could be used, but there are performance and readability penalties.
An extension by RSS-Data might look like this:
<item>
<link>blah</link>
<description>blah</link>
<data xmlns="http://rss-data.org/..."
name="signature" type="structure">
<data name="value" type="binary">Akjdfaiwjfqeesdah=</data>
<data name="cert" type="binary" transform="base64, asn.1">
askjdfa;kljalkjweqasdf
</data>
</data>
</item>
With just one legal RSS 2.0 extension that adds one new element plus a set of attributes, I can add arbitrary data into RSS 2.0 feed. While this rendition of RSS-Data removes the need to define new elements and associated namespace for each type of data, there are two problems:
- Language bindings are still problematic. 'Name', value, and 'type' can be mapped fairly well to language specific features, but mapping 'transform' is difficult. I suppose 'transform' can be removed, but it is nice to have.
- Existing XML standards like XML-Signature are not being used.
Solving the first problem involves turning all attributes into child elements and mapping and pushing child elements down another level. This is essentially what XML-RPC and SOAP has done. A nice bonus is that this approach works very well with modern scripting languages (i.e. item.signature.cert[0].name).
The second problem is harder to solve and RSS-Data proposal is silent on the problem.
Obvious use of RSS-Data is shoveling data with dynamic structure (i.e. database query result) out through RSS 2.0 feeds and having the data be displayed in a scrollable grid or a nice chart by RSS clients without them really understanding what the data is.
Given that RSS-Data is ultimately just an extension of RSS 2.0 and does not prevent other extensions, I think RSS-Data is a Good Thing. Let people vote with their feet.
Don Park's Weekly Habit 