If someone wanted to extend OPML into another domain, even if they got others to agree on their proposed type value and the new attributes added to support that type, there's nothing to stop a collision with somebody else choosing the same attribute names.
There also is nothing to stop the author of the OPML specification from opposing the new type.
It would be far easier to create a new XML format.
I love love love XML, but when I encounter an effort to use it to carry presentation like HTML alongside executable code -- such as Apache Jelly -- I regret the choices that brought me to that place in my life.
I wouldn't call OPML a good example of XML for reasons I detail elsewhere in the thread. But if you need a subscription list of feeds for import or export it's alright.
OPML is useful because people use it, but it was a bad design decision to store long blocks of HTML inside XML attributes instead of XML elements. Look at the escaped HTML inside these "text" attributes:
Because the HTML is stored in attributes, it can't be wrapped in a CDATA block. There's also no limit to how long the text can be.
OPML is also a moving target without a standard. Any time there's a desire to represent something new with the format, attributes are added without any public participation from existing implementers. The value of the "type" attribute on outline elements determines whether new arbitrary attributes can be present.
Because of this unorthodox extension process, the OPML format has become a catch-all for unrelated uses: outlines, blog posts, RSS/Atom subscription lists, programming source code, and more.
All of the uses could've been represented as XML formats. XML didn't need OPML for storing and transmitted arbitrary data. We already had XML for that.
The original thing OPML was created to do -- represent outlines -- is severely hampered by the fact there's no way to store the expansion state of collapsed nodes of an outline.