OPML is a simple, widely used, yet often misunderstood, XML format created by Dave Winer. IMHO, misunderstandings stem from overexposure to traditional ways of using XML. I must admit, I also laughed at OPML when I first looked at it years ago. But when I cocked my head (a technique anyone can learn from their dogs), it began to make a lot of sense.
This is what I saw:
Infoset:
- An OPML document is a collection of objects.
- An object may have properties and contents.
- An object's properties are unordered map of name/value pairs.
- An object's contents are ordered list of objects.
Syntax:
- Objects are encoded as XML elements named 'outline'.
- Properties are encoded as XML attributes.
- Content objects are encoded as child XML elements.
Once you get this picture in your mind, you start to appreciate OPML more. Throw in display and interaction semantics builted into the format along with distributed object linking and embedding Dave often raves about and you got quite a beast of a language.
As to the question of who defines the properties, the answer is everybody does. OPML is a kind of Emergent Markup Language in that common properties are expected to emerge through industry practices rather than standardization through committees.
There are some shortcomings with OPML though which I would like to see addressed.
OPML Wiki
OPML needs a wiki for OPML developers to interact with each other and to document how each of them are using OPML so that standard or type-specific properties may emerge.
Structured Properties
One weakness of XML is that, while elements may be structured, attributes may not. Since properties are encoded as XML attributes in OPML, (semi) structured properties (i.e. HTML fragments) have to be encoded at the cost of readability.
I think the need for a wiki is far more serious than the need for structured property support.
Ok Don, you have one interpretation/model for OPML which makes sense. One of the biggest problems with the format is that everyone else can have their own interpretation which also make sense, but isn't necessarily compatible with your interpretation. It *is* all things to all men, simply because so much is undefined.
But the format falls between two stools - it's lost the flexibility of XML in general (try replacing 'OPML' with 'XML' in your lists for Infoset), but the constraints don't actually bring any benefit. There is flexibility, but it comes through ambiguity. What does it mean for one element to be the child of another?
Sure, OPML may have its uses, for outliners like Radio and to a lesser extent blogrolls. But its loose specification has meant that the utility in both cases declines in proportion to your distance from Userland. It's taken a long time (and presumably a lot of trial and error) for anything approximating a standard to be followed by aggregators. I've not tried recently, but a few months ago I wasn't able to import/export between many of the leading aggregators without manual intervention.
Yes, developers could use a Wiki to enable type-specific properties to emerge. But why couldn't that happen with any other XML format - something better suited to the application domain?
If you're wanting to map out relationships between resources in a more general way that can be shared, you can use a language which has designed beyond anything-goes-anywhere. RDF is my favourite but Topic Maps support similar flexibility. ("As to the question of who defines the properties, the answer is everybody does." - you can still have that in RDF or XTM, without the potential for naming clashes, thanks to XML namespaces).
It is possible to mix in display and interaction semantics - right, why did we ever consider separating content and presentation? We simply have to write tools that all behave in exactly the same way.
Like the man said, "All that glisters is not gold".
From my perspective, OPML is a very natural format for representing a list of hierarchical objects. Is OPML a good format to map out relationships between resources? No. Is RDF? No. XML? No.
Re "All that glisters is not gold", beer is golden, in and out. LOL.
In and out indeed ;-)
OPML seems to me to be a perfect example of the simple thing XML does fine, which is delimiting fields/values and grouping fields/values into sets.
But, it's almost like it's not XML that does that, but just the angle brackets, e.g., you could get rid of most of what XML is supposed to be, replace the angle brackets with another means of delimiting, and have a format that is the equivalent of OPML.
I don't think that's a problem with OPML as much as it makes me question the value of some of the "esotericism" of XML altogether. In other words, a better XML version of what OPML is maybe isn't that much more useful. (And, I say that as someone who has been a user / big fan of SGML/XML for a long time!)
http://semtext.org/wiki/index.php/OpmlDtd
I whipped it up a while ago, while trying (mostly unsuccessfully) to work /with/ OPML.
Don, I should have linked to that earlier - it's on a Wiki.
Comment has been disabled for this post.
