Over the last month or two, there have been desultory swirls of conversation on What To Do With RSS? In particular the drumbeats are loud right now chez Sam Ruby. (Snicker: here it is 9PM Pacific on Saturday and all the geeks are rockin' out by debating RSS syntax.) I'm wondering if it's time to bring in the dreaded S-word: standardization. This will require a brief survey of what standards are good for and what writing a standard is all about.
No Innovation, Please · Standards have nothing to do with innovation; a good standard is what happens when an industry has basically shaken the bugs out of a technology and then, after the fact, writes it down. This is true of all the really successful standards: grams and meters, voltage, the calendar, octane ratings, TCP/IP, XML.
There have been attempts to innovate in standards space, let's see: ODA, HyTime, X.400. What, you've never heard of any of those? Exactly.
The one time I was in the room (for XML) what we did was take something that had been invented a decade before (SGML), fix up the internationalization, rationalize the error handling, and throw out the 90% that nobody ever used (we should have thrown out more).
Standardization Sucks · The process sucks, I mean. It's bureaucratic and slow and irritating and error-prone, and this is despite the fact that the people involved are usually pretty interesting and nice; the one or two who aren't can make your life hell. In fact, it's kind of like democracy, or legislation, or the court system: severe suckage, but better than the alternatives.
Why Do It? · There are a few reasons why, despite all this unpleasantness, standards are worth doing:
- The standardization process often lets you do some good bugfixes and tweaks, e.g. the XML internationalization work.
- The delay introduced by the process is (weirdly enough) sometimes a win, it keeps the vendors from charging out and locking people in with proprietary kludges because everybody knows this is work-in-progress.
- It gives you a club to beat up the bad guys. When some salesdroid has a brainlock on a clueless manager, or a vendor has decided to “embrace and extend” something that used to be open, or a government department is in danger of standardizating on something really proprietary and stupid, that official bureaucratic blessing can be a highly effective political weapon.
Is Now the Time for RSS? · It's not a slam-dunk, but there are reasons to think so.
It Works ·
- For ongoing, I went and checked the spec and looked at a couple of examples and coded up the RSS feed and it worked first time.
- I wanted to do a little bit of research on some RSS stuff, so I whacked together a bunch of perl code in an afternoon and was able to read about 80% of the ones I tried for.
- It's painfully obvious to anyone who watches web server logs that there is a large, fast-growing ecosystem of RSS readers and writers out there, and they mostly just get along.
Thus, we need codification not innovation.
Some Bugfixing is Called For · I'm not going deep here on this one, check out some of those discussion threads; but a lot of serious, credible people are wanting to do some tweaks and fixes, nothing major.
I'm one of them, and Don Box's proposed profile seems like a sensible stake in the ground.
We Might Need That Club · Dave Winer points out exactly how someone could do a dirty on the industry and try to get a lock-in. When (not if) that happens, we're going to need to hold them to task, and having a formal standards process under way is going to help big-time.
Right now such a hypothetical villain could get nasty and point to comments like this, wondering why some California weblogging vendor's spec is more legitimate than the villain's extensions to it.
If it's not obvious, I think that RSS is real important, and not just for Weblogs either; thus I expect there to be lots of incentive for vendors to get villainous in this territory. Let's lock up our daughters.
If So, Where? · The world has more than enough standards organizations. Let me provide a brief tour.
ISO · The big daddy, and as recently as a couple of years ago I would have laughed at the idea, but James Clark and Murata Makoto have shown how you can ram something good through if you're willing to put in the cycles.
W3C · Got famous because of HTML and XML and CSS and SVG, has had some failures too. The penalty of that success is an insanely large and slow process. The big advantage of W3C is that because of TimBL and his science projects, the W3C is able to retain some rather clueful staff, something not usually the case at standards orgs.
W3C is a natural home for RSS, it seems to be pretty deeply of the Web, but they're already pretty maxed out and there's the risk of it turning into another bloat-fest.
Oasis · Anyone, corporate or individual, can join, and can launch a committee. The process is fairly sane. But they don't really stand for anything.
IETF · Anyone can launch an RFC, and the system works in such a way that if it gets very far past launch, there are reasons to take it somewhat seriously. The mantra is “Rough consensus and running code” which certainly smells like RSS to me.
If I had to pick a path, I'd probably go IETF; and I see that Mark Nottingham has started work on RFCifying RSS.
If So, How? · This is the easy part. Standards happen when someone is willing to get behind them and burn the cycles and the brain cells and not stop till it's done. If someone's willing to find the time, it can be done, otherwise not.
If So, Who? ·
