Developers outline their issues with OPML

Members of the OPML-DEV mailing list are discussing a proposed new version of OPML that would be more like other XML dialects, supporting child elements inside of the outline element in place of attributes.

As I wrote on the list, OPML is extended in a way that's unusual for XML: Anyone can add new attributes to the outline element, as long as they give it a type attribute that lets programmers know what attributes to expect.

This is an odd way to do things, as Danny Ayers explains on his weblog. (I wasn't aware that XML guru Simon St. Laurent is using OPML as a how-not-to example.)

However, before anyone makes the case that OPML needs to be changed or replaced, they should document the problems that are preventing them from adopting it in their own code. OPML is supported in numerous places, including OmniOutliner, AmphetaDesk, NetNewsWire, Blogrolling.Com, hnb, and Syndirella. Clearly it's working for a lot of people as currently specified.


It's 'working' in those environments because of existing data. Save for OmniOutliner and hnb, the rest are simply using it as an import format for newsfeed subscription lists. Mainly to allow direct and painless transition away from using Radio.

The issues of failing to use good design practices in favor of vendor laziness should be taken into account. What of the utter lack of effective DTD or schemata for it?

Add a Comment

All comments are moderated before publication. These HTML tags are permitted: <p>, <b>, <i>, <a>, and <blockquote>. This site is protected by reCAPTCHA (for which the Google Privacy Policy and Terms of Service apply).