I just watched Phone Booth, so I should know better than to pick up this call, however, I’m not getting RSS:Data.
RSS-Data would require no changes or revisions†to RSS 2.0, though developers wishing to support RSS-Data would obvioulsy need to write RSS parsers that recognized and deserialized RSS-data in the <sdl:data> namespace.† But, rather than writing custom parsers for every new namespace extension to RSS, developers could confidently work with just one RSS/Data parser that handled 99% of their application meta-data needs.
I’m not following his argument. Reducing the amount of work to understand a new namespace is a good thing, but all it seems that RSS/Data would tell me is the structure and type data, it doesn’t tell me what I’m supposed to do with the information. Wait, the feed does provide the name for each member of the struct, however, theres much more work (from an XSLT standpoint) to get the names. If I got a non RSS/Data feed with an heretofore unseen namespace riding in on it, there’s a fair chance I could reverse engineer the sender’s intent as long as they weren’t intentionally obfuscating by sending elements named fnord:quertyuiop.
My understanding thus far is that RSS/Data pushes the interpretation out of the feed. You get a block of data, and somewhere, out of band, there’s an interface or signature you implement on your end. So if you send me a vector in RSS/Data, you have to provide me a clue as to how to use that vector: do I sum it, do I average the values, or plot them?
An RSS/Data library provides me with the machinery to read the structure, without resort to a secondary key (an XSD or other schema). I don’t however have a way to validate that structure: is it too long/short, are the members the right type, etc. An external XSD schema would allow me to verify that you’ve sent me the right structure. And as L. M. Orchard points out, I can use that schema to generate the stub of a method or function that uses the data. RSS/Data can do the later, but it doesn’t provide the validity check.
One suggestion would be for RSS/Data to mention XSD types. So if I point to the simple, and my defined set complex XSD types I could generate:
<sdl:struct name="scores" type="myxsdextension:vector"> <sdl:data name="score" type="xsd:integer">5</score> <sdl:data name="score" type="xsd:integer">8</score> <sdl:data name="score" type="xsd:integer">3</score> </sdl:struct>
That’d simplify the syntax, and provide a first order hook for validation. So I’d make the suggestion that RSS/Data define the data types in terms of XSD.
