Bottom line: the imprecise RSS specification resulted in a lot of guess work, which complicated things for developers, end users and feed producers. The solution? We clarified the RSS spec.
The solution? We clarified the RSS spec. While problems with entity-encoded HTML haven't disappeared completely, in my experience they're far less common than they used to be (and when they do occur, we now have examples to point to).
And that's all that's needed here, too. Clarify the OPML spec, and we can skip another prolonged format battle.
Clearly RSS feeds have gotten much better, but I think the Feed Validator had a much greater impact on that clean-up then the clarification Nick sites. Don't forget RSS 1.0 and 0.9x feeds were equally as busted as the 2.0 version he points to.
Having had my fair share of frustration with both RSS and OPML and OPML's "spec" is far more ridiculous then RSS ever was and that is saying something. I have to wonder -- is it worth saving OPML? I'm not so sure. By default OPML is used as an import/export format by aggregators -- there was nothing else proposed and it just spread as the market for tools exploded. This isn't too dissimilar to how RSS grew. The difference here though is that OPML's use is quite limited in comparison to its intended scope. OPML was specified to be a general purpose outline format however it is only really used for representing blog rolls and it does that poorly. Without a real specification of the values, attributes or even the attributes case there are many variants of the OPML blogroll format in the wild. So is it "really" fixable if it were specified? Not without a lot of breakage really and you'd still need to be ready for all the crazy variants from the void left by the lack of a good specification.
I guess what I'm saying is it doesn't really matter whether it gets better specified or not. Best of luck who are taking it on. My view is that the toothpaste is out of the tube and OPML as a blog roll format will only be a bit player a best.
I'm much more interested and intriuged by XHTML outlines -- the microformat better known as XOXO. I've used it before in a few instances and its worked very well. (X)HTML's system of providing outlines has been around longer, is better specified and more widely supported in the grand scheme of Internet software that I have to wonder what does OPML provide that makes it better? What does specifying and developing another format buy us? I can't think of anything. The current universal support of import/export by aggregators is nothing to sneer at, but how hard would it be to convert current blog rolls to XOXO? Trivial. OPML blog rolls don't contain any more information per entry then the XHTML link tag. Which require more effort: fixing the spec and then all the OPML blog rolls or just converting to XOXO? I think its a tie. Which would provides the better footing going forward? I think clearly XHTML because you can do more now and its already here, well specified and well supported.
It's understandable why OPML is supported in aggregators and that that should continue to be exploited, however I just don't see furthering OPML for blog rolls. Let sleeping dogs lie. It's served it purpose. Lets not get trapped in past foibles and move on to new and better things.
UPDATE: Sam Ruby who I believe is the most patient and persistent person you'll ever find in technology has entered into the OPML conversation. The Feed Validator that he was instrumental in driving has OPML validation with a call for more tests. This I believe supports my assertion that his validator was more instrumental in cleaning up bad RSS then clarify the specification as Nick Bradbury wrote. So perhaps there is a bit more hope of a clean up then I had before.
