Sam Ruby had taken a first shot at RSS 2.0 with an RSS document demonstrating the new, simplified RSS syntax. No evidence of RDF, RSS version, no RDF Seq.
Mark expanded on this with what looks to be the same specification, different examples and the use of included HTML (parseLiteral in RDF terms). (Correct me if I misread this Mark).
Since Sam has published an example of his version, allow me to work with the assumption that whatever works with his proposed RSS 2.0 should work with Mark’s, with the addition of HTML literals.
In this weblog page, I have PHP processing for the Book recommendation list. I copied the page and modified it to process Sam’s new proposed RSS file. You can see it in action here. The process took me about 10 minutes because the SHIFT key on my laptop doesn’t work well, and I am using vi to make the edits.
Now, I want to show you something. Here is my MT generated RDF/RSS file. Taking this and Sam’s and Mark’s proposed RSS 2.0, I came up with a simplified RDF/RSS syntax, seen in this file and also duplicated here:
<?xml version=”1.0″?>
<rdf:RDF xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:dc=”http://purl.org/dc/elements/1.1/” xmlns=”http://purl.org/rss/1.0/”>
<channel rdf:about=”http://weblog.burningbird.net/”>
<title>Burningbird</title>
<link>http://weblog.burningbird.net/</link>
<description></description>
<item>
<rdf:Description rdf:about=”http://weblog.burningbird.net/archives/000514.php”>
<link>http://weblog.burningbird.net/archives/000514.php</link>
<title>Myths about RDF/RSS</title>
<description>Lots of discussion about the direction that RSS is going to take, which I think is good. However, the first thing that
happens any time a conversation about RSS occurs is people start questioning the use of RDF within the…</description>
<dc:subject>Technology</dc:subject>
<dc:creator>shelley</dc:creator>
<dc:date>2002-09-06T00:53:16-06:00</dc:date>
</rdf:Description>
</item>
<item>
<rdf:Description rdf:about=”http;//weblog.burningbird.net/archives/000515.php”>
<link>http://weblog.burningbird.net/archives/000515.php</link>
<title>ThreadNeedle Status</title>
<description>I provided a status on ThreadNeedle at the QuickTopic discussion group. I wish I had toys for you to play with, but no
such luck. To those who were counting on this technology, my apologies for not having it for…</description>
<dc:subject>Technology</dc:subject>
<dc:creator>shelley</dc:creator>
<dc:date>2002-09-06T00:19:28-06:00</dc:date>
</rdf:Description>
</item>
</channel>
</rdf:RDF>
Differences are:
- RDF element rather than RSS
- No versioning – not necessary with the concept of namespaces
- Use of namespaces to differentiate modules
- Surrounding the ITEM’s properties with a RDF:Description. The ITEM can have either literal data or XML elements that should be parsed. By using RDF:Description, I’m giving a hint to the processors that what follows is XML data to be parsed for new elements, so turn off literal text processing optimization, and use the more memory and CPU intensive XML parser, please.
Notice that there is no RDF:Seq in this RDF/RSS version. Why? You don’t have to use the Seq element for valid RDF. I believe Seq was used with RSS 1.0 because the originators of RSS 1.0 wanted to provide ordering information to the tool builders. However, this really seems to be an absolute sticking point with everyone. Fine. Dump it.
Run my new RDF/RSS through the RDF validator (here), and you’ll see it’s valid RDF.
Now, I created a third copy of my weblog page with the PHP processing and had it parse and print out this new RSS file. The changes necessary? I changed DC:DATE to DC:CREATOR — I wanted to print out the latter not the former. Here’s the new page.
Next, I copied the PHP page and had the code process my original RDF/RSS 1.0 file, the one that’s generated automatically from MovableType. Changes to the code? Nada. Not one single change other than the name of the RDF file. Time to make change? 4 seconds. See the new page here.
Now, all of these pages (including this one) use PHP-based XML processing to process the data (xml_parser). No specialized RSS or RDF APIs. Pure XML processing. And it took me about, well, honestly, probably a couple of hours to write the original code for my Books RDF/RSS application. That darn shift key you know.
I’m not trying to downplay other’s concerns or existing work or effort, and I realize that I have a better understanding of RDF than most of you (not bragging, but give me this as an accepted for discussion purposes at this moment) and that this gives me an edge when working with RDF.
What I’m trying to show is that keeping RDF in the RSS specification doesn’t nececssarily mean that simplified processing is impossible, or that we can’t use ‘regular’ XML tools, and that there will be a huge burden on tool writers.
We don’t have to keep Seq if it really bothers everyone. Let’s work this change. Let’s. Let us work this change. I like that phrase, don’t you?
By keeping RDF in RSS now — and really are those changes I made to the proposed RSS 2.0 so hard to swallow? — we keep the door open for the benefits that will be accured some day when RDF does have broader use.
I guess what I’m trying to show, demonstrate, prove is that RDF doesn’t have to make things arbitrarily complicated, or confusing. That we can write documentation that clarifies those few bits of RDF in the specification so that it isn’t complicated for folks writing or reading this stuff by hand (or processing it with various languages).
I’m hoping with this demonstration that I’ll convince a few of you that we can keep the door open on this discussion rather than arbitrarily throwing RDF out — a specification I’d like to gently remind you all that’s been in work for years by some of the best markup minds in the business. And as easy as it is to criticize the RDF working group for taking time, remember that they’re trying to create a specification that will stand the test of of time, rather than break through every version, as we had with HTML.
Mark provided a summary of the RSS issue, and I know that this discussion has been going on for years. And I know that there are a lot of people who say, let’s just fork. But folks, this didn’t work for SQL and QUEL (remember QUEL?) years ago when the decision was being made about which query format to use when accessing relational database data. I really do want to see these specs come together, with members and players from all sides.
And I’ll also be honest and say that I really don’t want to see this owned by any private company or person. Sorry, but I just can’t accept this, it goes everything I believe in. I am not belittling Dave’s and Userland’s contribution to RSS. I realize that Userland popularized RSS and a debt is owed.
What I am asking is that Dave become part of a team working on this, a team that’s open to people who literally have something to contribute on this issue, each with an equal vote. Yes, people like me, like Mark, like Sam, Jon, Joe, Bill — all the people who have something to contribute to make this specification rock. And hopefully prevent something like this from happening again in the future.
Am I too late though? Is the decision made? Can’t we talk?
Where’s the fire?
(Archived page and comments at Wayback Machine)