Dave Winer suggested to me to start a mailing list for developers that want to support RSS 2.0. I looked if there would be an existing list for this purpose, but coulnd't find anything. RSS-DEV is a lot about developing a standard, and also has to much traffic. So I created a new list. RSS2-Support. The description is:

If you are a developer, and you want to use RSS 2.0 in some way (reading or writing), you can come here to ask questions. This is not a list for long discussions! Let's focus on productivity.

Based on a feature request by Mark Pilgrim, I designed my first RSS module today, called blogChannel. It was fun. Scripting News already supports it. [Scripting News]

Interesting module. Looks fine with me! It would be cool if Userland would add some code to Radio to make it easy to implement RSS modules. Something like a table for each module with namespace and defaultPrefix fields, 2 scripts for serializing extra elements for the channel and for an item and 2 scripts as callbacks. The callbacks are called by the aggregator whenever a channel or an item contains elements from the module.

Sean B. Palmer notified me that the conversion of the Scripting News RSS file to RDF wasn't working properly. That's because while I was sleeping, Dave added a namespace to the RSS file. It's fixed now.

Sean also told me he is working on Semantic Schemata. We're very much on the same line. I'll quote from his proposal:

"Decentalization" and "grounding semantics in the Web" are cliches, but for a good reason. As stated before, the semantics behind particular markup constructs vary over the contexts in which they are created, used, and otherwise interpreted. With the Web, we have the real opportunity to create some semblance of a shared context - we can agree to use terms without any one particular group dictating what will be.

With the introduction of XML namespaces, it made many buzzwords possible (for each new acronym created, at least ten buzzwords appear); decentralization, evolution, transformability. One of the key technologies for connecting the semantics of each language together is RDF. In fact, the various serializations of RDF are not important, but the model is.

One possible implementation of semantic schemas is to convert XML to RDF with XSLT. So I created an XSLT file to convert RSS 0.94/2.0 to RDF. The result is better than RSS 1.0, because it doesn't have to be backwards compatible. For example, title elements can become dc:title elements. I only used the standard modules, not the proposed ones. If anyone has suggestions for improvement (like an RDF/RSS specialist) I'd like to hear them. You can try it for your own RSS file at the W3C XSLT service. Examples: w3future, Scripting News. Try to post the results in the W3C RDF Validator. That will result in some fancy graph images.

Tomorrow morning I plan to remove the caveat on the draft RSS 2.0 specification. Before then, if you see any problems (not mega-problems, please), let me know. [Scripting News]

There's one thing: most blogs have permalinks, so the guid element is almost always going to be a permalink. Therefore I suggest to make a guid to be a permalink by default. Add noLink="true" if it is not a URL.

Also my gut feeling is that calling this RSS 2.0 is a bit hasty. Let's first call it 0.94 and play with it a bit. It's the first time that namespaces are allowed. Maybe this adds big incompatibilities nobody thought of yet. RSS 2.0 deserves a bit of practical experience.

Shelley Powers proposed an RDF friendly version of RSS 2.0. I have a proposal too. It uses rdf:parseType="Collection". This is new. And that the problem. RDF is in a state of flux. Yes, there is a recommendation, but later it was realised that a few mistakes were made. And work was started on refactoring the RDF/XML syntax. RDF is simply not a solid foundation on which to build RSS.

The new table of elements in the RSS 0.94 spec is a big improvement in clearity. One small suggestion: split it in two, required elements and optional elements. That saves one column.

By the way, if everybody hates textInput and skipHours, can't we just say so in the spec? Actually I think that's what deprecated means: Everybody hates it, but it's there so use it if you want to, but don't use it if you don't have to.

Thinking more about the semantic schemas I wrote about last night, I realized that it has more uses. XLink for example has the same problems as RDF. For XLinks to work, you have to add XLink specific syntax to your document. This is far from ideal, which became painfully clear when the first XHTML 2.0 draft was released without XLink support. A semantic schema for XHTML 2.0 can declare that the href attributes generate XLinks.

Another example. A month ago, when I tried to add support for XHTML 2.0 to the various browsers, I found out that there's no way to tell the browser what the title of the document is. A semantic schema can declare what the title of a document is. Google needs to know what the title of an xml document is too.

OK, the discussions aren't over yet, but it looks like RDF is no longer an option for RSS. This may worry the RDF fans, because RDF should have been a perfect match for RSS. RDF is designed to be a format to describe website meta-data. And that is exactly what RSS is. So is RDF a failure?

There are two problems that have prevented wide-spread adoption of RDF-style RSS. The first one is that there is no added value in using RDF over plain XML. All applications that use RSS, are RSS specific applications. They don't combine the data with loads of other information, simply because there isn't any except other RSS files. So these applications don't need a general semantic format, because they have the RSS semantics built-in. The second problem is the added complexity of the syntax. It's a bit ugly and the purpose of the extra syntax is far from self-explaining, which quickly lead to mistakes in implementations. Also the first mentioned problem makes it just not worth the trouble.

Note that these 2 problems are hardly RSS specific. They will also arise in other attempts to deploy RDF in a community. RDF seems doomed. But I think RDF still has the future, or at least the model of RDF has the future. The problems are in the serialization of RDF. Serialization is all about making concessions to conciseness, file size, readability, streamability etc. It depends on the situation which of these properties are more important than others. So if you design a general format, it is always going to be inferior to a specificly designed format. With RDF this is even worse because RDF can make absolutely no concessions towards semantics.

Given all this it is unlikely that RDF as serialized in XML is going to be widely adopted. People want their XML the way they want it, and don't want to be bothered with the semantics. That's also because they already know the semantics of their own XML. It's those that want to put it all together that want a semantic format, not those who design a single format. But the information is already there, in all those XML files everywhere. Once there's a way to specify how to convert an XML format to the RDF model, you have both the freedom of the XML format, and the exciting features of the RDF model that will give us the Semantic Web. And once there's such a “semantics schema” for RSS, I'm sure the RSS developers are very willing to add that one extra attribute or element to point to the schema, if that's the only thing it takes to take part in the Semantic Web.

It seems that the future of RSS is emerging. “What do you think?” asks Dave. I like it! Modules are just perfect for the next step in RSS use. And there's no burdon of the crippled syntax of RDF. There's no doubt in my mind that this is the way to go. But then there remains the issue of putting some of the old elements in modules.

Imagine a core RSS of these elements: rss, channel with title, link, description and language, and item with title, link and description. This is a core which you can't touch, because most older RSS implementations use these. This is also a core that's very useful and a low barrier to implement. The other elements should be grouped in modules, using namespaces. I believe that applications that use these elements are in active development, and can be easily changed. This requires some effort from implementors, but the result is a clean future-compatible RSS basis, that can remain popular as long as XML remains popular.

It is important though that older RSS files never become invalid, and that never any essential information is lost. So elements like image should become deprecated. And future RSS application might only support the module version of the image element, and they will ignore the old image element without namespace. But the application will still read the essential information that is available in the old RSS file.

My colleague at Q42 who runs the Xopus project put a stable release online last friday. There's even some good documentation in the package! You can start making your XML/XSL based website editable in the browser right now. Remember, it runs both in IE and Mozilla.