As I demonstrated with my blogroll, OPML has its uses. I went further and built John G�tze’s OPML Directory Browser, which is an OPML-driven directory browser for browsing loosely coupled OPML-files from my own GotzeLinked. The OPML-browser is based on Austin Marshall‘s PHP-OPML toolkit. Thanks to Austin for creating this nice tool.
I wanted to use a semi-large directory (GotzeLinked has more than 1000 links with descriptions) to demonstrate an architectural principle, loosely coupling, in practice. Rather than having one large file with all data, I use a meta-OPML-file (“father”) and a set of individual, thematic (category-based) OPML-files (“siblings”). I created a new (?) attribute called opmlurl, with which I in the father-file points to the OPML-files of each sibling.
In terms of interoperability, OPML sucks. It is not “real” XML – it’s more like HTML on steroids actually, using non-standard attributes to store important data, rendering it very difficult to work with in the modern XML-world. That, together with the fact that the OPML specification is closed (Dave Winer has the IPR on the spec), and non-specific about attributes, makes it virually impossible to make OPML-systems interoperable. Some use “url” to describe everything available on an URL, while others use “htmlurl”, “xmlurl”, or “opmlurl” (like I do) to distinguish between various formats.
Ray Grieselhuber announces OML and writes that
the reason I decided to go forward with OML, is that as the number of applications using an outline XML format increase, with the current extension mechanism in place, it is going to be very difficult for these applications to interoperate. Not only is there nothing that specifies the names of the most common attributes, but the fact that there can be any number of varying attributes in the outline element, is in the opinion of many, a big problem.
Hence, OML is less attribute-oriented than OPML, and instead uses a number of well-defined outline-attributes, text, created, etc, but also differs form OPML in using two important data-bearing elements, data and item.
I’m tempted to shift to OML … on the other hand, I don’t really give OML much of a chance. I don’t know Grieselhuber’s real mission, but I would bet he’d be aiming at getting OPML to embrace the OML spec. That would IMO be the best solution. Please don’t repeat the RSS-history.
3 Comments.
You’re welcome.
I read your comments regarding OML, and I’m glad that people are taking notice. My “real mission” is pretty simple – create an spec that makes sense and that everybody who uses it has a say in how it’s defined.
The two biggest problems with OPML are, as you mentioned, 1) OPML sucks for interoperabilty and 2) despite claims otherwise, it’s a closed spec. It’s owned by one person and he has indicated very clearly that it will stay that way. This means there is not going to be any standardization.
I originally made my proposal to the OPML list as a way of getting closer to conventional uses of XML, but no dice.
We’re not trying to recreate RSS-history, just create something that makes sense. I personally don’t think any outline spec has enough momentum to be called the de-facto leader, and this includeds OPML.
It’s our goal to get as much support and input for OML as possible so that we can achieve true interoperability.
In the few short weeks that we’ve been active, we have already received promises of support from several vendors, including some prominent makers of outline software.
Join us!
Gotzeblogged: Who wants some OPML?
More information on OPML from gotzeblogged
Browsing with OPML
Opening up for OPML
More OPML than Dave
Gotzeblogged: Who wants some OPML?I already have my GotzeLinked directory, and there at least three categories I’m passionate about and knowledgable o…