Click here to show or hide the menubar.

Home >  Archive >  2010 >  June >  15

Previous / Next

A bug in the OPML validator?
By Dave Winer on Tuesday, June 15, 2010 at 12:03 PM.

Chris Janton pointed out that some of my OPML isn't properly handled by another OPML-processing application, and that my own validator rejects it as invalid.  permalink

Here's an example of a file that's rejected as invalid. It says: "The type attribute on an <outline> element should be a known type." permalink

But the OPML 2.0 spec says this is okay. "OPML can also be extended by the addition of new values for the type attribute." permalink

It continues: "When specifying such an extension, following the example of this specification, say which attributes are required and which are optional, and explain the roles each of the attributes plays, how they relate to each other, and what rules they must conform to." permalink

A picture named bigfly.gifThe reason it is this way is that the OPML Editor, the app that OPML is the file format for, has an extension mechanism that allows this. When I give an <outline> element a type attribute with a value of foo, when the user double-clicks on that element, the editor looks for a nodetype definition called foo. If it has a method for handling a double-click, it gets control, does its thing, and returns, overriding the default functionality. It's essential to the way the editor works that the type attribute be allowed to have unforseen values. permalink

So it's clearly a bug that the OPML Validator rejects these OPML docs. permalink

Not sure what the OPML-processing app should do, I'd have to know more about what the concern is. But the spec clearly allows what we're doing with Scripting2's OPML. permalink

RSS feed for Scripting News
This site contributes to the community river.

© Copyright 1997-2012 Dave Winer. Last update: Tuesday, June 15, 2010 at 12:45 PM Eastern. Last build: 8/26/2012; 5:47:44 PM. "It's even worse than it appears."

RSS feed for Scripting News

Previous / Next