Technical Ramblings

The response Sean, Cody and myself have had to RSS 1.1 has been mostly positive, and we’ve gotten a number of suggestions for ways to make it better. We’re going to be working over the weekend to implement these changes into the schema, and releasing a second draft on Monday sometime.

The response was, all in all, pretty good: We’ve had some good people on our side, offering encouraging comments on the specification. At the same time, there is the all too common “Oh no, not another RSS version” that you get in the case of anything new. I can honestly say that I think most of these comments misunderstand the goals that were being worked towards by RSS 1.1.

If you are not using RSS 1.0 right now, do not worry about RSS 1.1. It is designed only to fix the bugs that RSS 1.0 has, due to the fact that it’s 5 years old. If you try to drag me into politics: whether it be on whether another RSS format is good or bad, or on other things which are unrelated in a change from 1.0 to 1.1, you are misunderstanding the original intentions behind this format.

It is a possibility that given a better defined specification, using the current version of RDF rather than the one that was available 5 years ago, some people who are not using RSS 1.0 now may want to make the switch to RSS 1.1 (if it achieves support in the community). If you do, great. If you don’t, also great. I have no interest in converting those of you using RSS 2.0. I have no interest in telling you to stop using Atom. I want a technical improvment over RSS 1.0: and RSS 1.1 does that.

At the same time RSS 1.1 was designed to fix bugs with RSS 1.0, it was also designed to make it easy for aggregator developers to develop support for it. Complete backwards compatibility, although wonderful, would have been so limiting as to make any changes to the schema useless.

RSS 1.0, although it still had an existing working group, was not being developed further. To work in the working group atmosphere would most likely have stifled creation of the new specification. Although some may think this is a bad thing, I think that RSS 1.1 does fit the needs of a small group of people without putting an ardurous strain on the people who develop tools for it.

In the end, lots of people will be unhappy with any new syndication format. The motivations behind this move, however, are entirely technical, rather than political, so, as Sean said at one point, most political arguments against it “concern us not”. The technical questions, on the other hand, do concern us, which is why we’ll be working to craft a second draft as quickly as possible, to get further feedback from the community.

As a developer, for a long time, I believed RSS 2.0 to be significantly superior to RSS 1.0. It was a more popular format, more people had heard of it, but most importantly, it was easy to create. In comparison to RSS 1.0, creating RSS 2.0 documents was downright trivial. There was no need to have the goofy “rdf:RDF” tag at the top, with all those weird looking URIs for some reason no one could tell me. Clearly, at the time when I was thinking this, I was not aware of RDF or the benefits of it. As time went on, I realized the benefits of the RSS 1.0 way of doing things, most importantly, that the content is RDF.

However, RSS 1.0 is still a relatively confusing format to implement to a non-RDF aware developer. The “table of contents” listed in the rdf:Seq is redundant, and to a lot of people who are used to working in XML and not under the constraints of RDF, confusing. The documentation on all the RSS formats is quite weak. A table comparing what each one offers is hard, if not impossible, to find, especially since most such lists are biased towards the writer of said list.

As I’ve become more and more involved in developing tools relating to RDF and the Semantic Web, RSS 1.0 has become more and more of a sticking spot in my experiences with people. They are soured by their 1.0 experience: a feeling I can not blame them for, as RSS 1.0 is constrained in many ways by the circumstances under which it was developed.

Fed up with dealing with a less than optimal format that was truly leaving people feeling negatively towards RDF in general, I decided that I was going to work on something that would be better for RDF and RSS. I was just going to write it myself, but luckily for me, I had the help of a couple of friends.

sbp, and myself, along with many a helping hand from d8uv, have written a specification we are labeling RSS 1.1. From the Specification:

This specification is therefore made available by users of the RSS 1.0 format who wanted to update the specification to make use of the latest features of RDF in order to reduce the redundancy in the format, and the ambiguity in the specification, while at the same time implementing a series of bugfixes from the lessons learned in developing the other descendent of RSS 1.0, Atom.

This specification comes with a full Test Suite, a validator, and a number of other resources, from background information to implementation details in several different types of configuration.

We have formed a channel for discussion of RSS 1.1 related issues on Freenode: #rss1.1 on irc.freenode.net. If you are interested in using the specification, or would like to offer your opinions, you can stop by there to talk to us.

This specification is not designed as competition for Atom: it is designed only as a bugfix release for RSS 1.0, and is not designed to compete with any other existing efforts. There were a significant number of issues with RSS 1.0 that had been raised over the years, some of which were relatively important from the standpoint of a lazy developer such as myself. Hopefully others will feel a similar way.