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. 
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."
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."
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."
The 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.
So it's clearly a bug that the OPML Validator rejects these OPML docs.
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.
;){kind=spacer}
