In answer to my request (which Danny claims is a demand) Danny Ayers has posted a rather elucidating response. I have answers to some of his quibbles below........
"We want BOTH RSS 1.0 & RSS 2.0!".
"We want BOTH RSS 1.0 & RSS 2.0!"
So demandeth Marc, talking about using data structures via RSS 2.0 + RSS-Data and RSS 1.0 + RDF. (What's that word for when part of a statement is redundant? This latter combination is one of them).
I think this is exactly the kind of issue that Atom should be dealing with, but in the meantime, assuming that this is a worthwhile endeavor...
Bridging between core RSS 2.0/1.0 is pretty easy thanks to XSLT. It's not too bad for moderate extensions either - one approach is to map the extended RSS 2.0 to an RDF equivalent (this is what I was on about with the Simple Semantic Resolution idea).
It's a little trickier bridging when you get to the kind of structuring that Jeremy and Roger were talking about.
Stepping back from the pros and cons, what's being passed around in XML-RPC is a text serialisation of simple data structures, akin to those used in non-OO languages. What's being passed around in RDF/XML is a text serialization of simple data structures, akin to those used in relational databases.
As l.m.orchard elucidates very nicely, there needs to be some sort of common understanding to do useful things with the data - a schema is one approach, some receptive code is another. RDF has a model that can make some sense of arbitrary data in an RSS 1.0 feed (though having an RDF schema magnifies this n-fold), Roger's parser demonstrates that some sense can be made of XML-RPC data in an RSS 2.0 feed, but it should be noted that there is no defined way of using this information alongside other available information. Only humans can provide context for the names of the fields, the strings in the arrays or whatever. In the RDF model the descriptions can be merged and processed alongside any other information that refers to the same resources. I am beginning to drift into the 'why RDF is cool' discussion here, but there is a point.
Back to Marc's suggestion of bridging this stuff. First of all, let's clarify the purpose, which is a bit unclear. Maybe the point is to pass dataX from producer app (that understands the structure and semantics of dataX) to consumer app (that understands dataX) then the same can be achieved directly with namespaced RSS 2.0. Maybe the point is to pass dataX from producer app (that doesn't understand dataX) to consumer app (that doesn't understand dataX) then the receiver of the RSS-Data just gets some stuff and as Roger says :
So maybe Carl J. Coder doesn't understand what my app is trying to say... so what? At least as far as I'm concerned, it ain't that kind of deal.
So what we're looking at is application-specific data structures being passed through XML-RPC. Errm, what do we need RSS for then? Sorry, drifting again...
Start again.
What we're looking at is application-specific data structures being encoded in XML-RPC and RSS being used as a blind transport. Ok. So how do go to RSS 1.0? One way would be to express the structures covered by XML-RPC in RDF. This should be pretty straightforward - simple XML schema datatypes are supported in RDF, arrays can be defined as collections. Bung the feed containing RSS-Data through a stylesheet, out pops RDF. Then the application uses a mapping between the data in the RDF model and the application model.
RSS 2.0 itself is defined essentially as a application for pumping newslike information. Nothing else. You can extend it using namespaces, but there is no standard way of doing so, so every new extension module exists as a parallel pipe. The RSS-Data approach looks to me like an alternate way of creating a single-application-specific pipe. But I honestly can't think why you would want to reduce your application model down to structs and so on, when you could define a data model that maps better to the application domain and put it in a namespace. This point is touched on by both Les and Roger, and their conclusions in this regard aren't too far from mine.
Anyhow, I guess you could use XSLT to bridge going RSS 1.0 -> RSS 2.0 + RSS-Data, but it would mean making the RSS 1.0 extension vocabulary view the world as a bunch of integer arrays or whatever, and I really can't think why you might want to do that, any more than you'd want to in RSS 2.0. You probably could get a richer extension of RSS 1.0 down to RSS 2.0 + RSS-Data, but you'd almost certainly have to throw a lot away.
In answer to Marc's demand then - I don't think bridging would be a problem, at least for RDF people receiving RSS 2.0 + RSS-Data. But beyond very simple stuff, getting RSS-Data from RDF would almost certainly be a waste of time because it's so lossy.
(btw, I mentioned Atom earlier, and it's been nicely demonstrated there that RDF/XML is not the only ExtensibilityFramework)
PS. I like you a lot too, Marc!
[Raw]
In answer to Danny's confusion over WHY - it's simple: Mr. and Ms. Aggregator vendor want to support as wide of a range of formats and micro-content as possible. Mr. and Mrs. Content and Services 'publisher' want to get their 'stuff' out to as many end-users as possible. Last I looked there ain't ONE subscription format - so that means supporting BOTH formats is the way to go (despite claims of superiority - ego based or not.)
Intellectual arguments aside, practically speaking Calendar Events, Reviews, Resumes, Recipes and/or Media itself is not the domain of either the simple or complex approach folks. Upstream the data structures can be agreed to and downstream subscription formats can shovel the shit out - ad infinitum - to whoever subscribes to it.
Each format (RSS 1.0 & 2.0) has it's own installed based, group of believers and tools supporting it. Can't we all live together?
About 3 years later Marc was sitting in my office using my slow dial-up connection to download a presentation he was supposed to give the next day in Trieste for an important gig. We spent most of the following year working together.
