Jim Moore’s blog: Innovation, Strategy, Public Policy

The following chapter is a work in progress.

My intent here is to convey the power of OPLM by revealing its structure, while setting aside for the moment how the language expresses this structure.

OPML, like any successful language, has been pushed by the developer community beyond what it was originally intended to do.

It has been “generalised” and its general capabilities, its most profoundly important capabilities, are being revealed as people continue to push its application.

It has been my experience that a good way to help others see this potential is to explain OPML in the most general terms. Once you see the general structure, which is both simple and powerful, I believe that many of you will then be able to envision even more new creative uses of the format. So here goes:

In structure, an OPML file has looks like this:

Node, Frame, Procedure list

Node, Frame, Procedure list

Node, Frame, Procedure list

Node, Frame, Procedure list

Nodes: Nodes are elements in an outline. The indenting of the nodes enables the author to set up outlines, with a root node, nodes, sub-nodes, and so on as far as you like.

The power of the outlline structure of is that it can act as the definition of a relation–as in relational database. When combined with the node’s ability to reference other code, by way of frames and what frames give access to, and procedure lists and the actions they evoke, OPML can become a vastly open way of reaching out to resources across the entire web.

OPML becomes, with an OPML interpreter, a database controller that takes the entire web as its dataset.

Frames: Frames are like picture frames. They carry HTML and anything that can be conveyed to a browser by an HTML call. This includes widgets. This includes the YouTube and Google Video “embed code” that shows a movie by invoking a flash/shockwave viewer. Frames can display flash animation, animated gif graphics, and Second Life addresses. Frames can show anything that a conventional web page can display.

Procedure lists: Procedure lists are can act as an procedural programming language, interpreted at run time. They are general lists of actions. In OPML these have traditionally been used to refer to other files, either other OPML files, or perhaps RSS sources, podcast lists, and so on.

But the actions in the list can do much more. For example, they can apply CSS to the display in the frame. They can contain Creative Commons and related copyright license information. They can contain meta tags and microformats. They can contain name/value pairs and feed other instructions.

Thus an OPML file has three important structural parts, each of which can be used by a creative programmer to accomplish complementary aims.

In practice, one must work around what I consider a bit of legacy terminology. This is not, I want to emphasize, much of a problem once one understands the basic structure of OPML. But it must be dealt with.

Nodes: Once again, an OPML file represents an outline with one or more nodes. When these nodes are indented relative to each other in the file, they are treated by OPML viewers as hierarchically-organized–i.e., as an outline of nodes and subnodes. This is OP as in “Outline Processing,” Dave’s original and still official meaning for the acronym. The hierarchical nature of OPML makes it possible to express complex relationships among the nodes in an OPML file, as well as among the items referenced by the nodes.

Nodes, in an OPML file, are called “outlines.” In Dave’s OPML terminology an OPML file is composed of many outlines. Nodes are called outlines, according to this parlance, because at each level in a file a node/outline can carry/include sub-nodes below it in the outline. What I might call a single node would be called, in these terms, an outline with only a single top-level member. I am not against this nomenclature and in some ways I agree with its conceptual elegance. On the other hand, after two years trying to explain to others how OPML works, I find that calling each element a “node” seems to work better for most folks. And I note that the same issue exists in everday non-digital outlines, and over time, folks have standardized on having a distinct term–usually “outline”–for a collection of nodes, and another term, sometimes “node,” “element,” “line” and so on, for individual nodes.

Frames: Each node has a field that is not treated as XML by an OPML viewer. Instead, the material in this field is passed through to the HTML interpreter in the associated web browser. This means that this field becomes a frame within which complex HTML can be embedded, and this complex HTML will be enacted when the frame is read by the Web browser. Further, one can embed scripts into the frame field of a node, and these scripts can in turn call Flash and Shockwave viewers as well as other widgets designs.

This frame field is called “text” in OPML. It was originally designed so that what was in the text field not be interpreted as XML. The contents of the “text” field is sent on, raw, to the browser for display to the user. Over time, with HTML, embed code, etc. etc. this text can represent and invoke in the browser a vary wide range of rich text, especially audio and video.

Procedure lists: In OPML, what I am calling procedures are called “attributes.” By convention, if the program reading the OPML knows what to do with an procedure, it does so, and if it does not know the procedure specifically, it ignores it.

Also, by the nature of the spec, the universe of procedures can be added to by the person writing the OPML file.

These two generous provisions bring imporant benefits for innovation in the OPML community. One can write an OPML file with procedures that are widely recognized in the ecosystem of code for rendering OPML, and be sure that these will be treated as you wish. At the most fundamental level, references to OPML, RSS, and HTML files are always supported.

One can also add procedures that are outside of the current universe, and they will be ignored in the positive sense. They will not choke the current generation of code.

On the other hand, if procedures that are added are proven to be useful, they will spread across the community, across the ecosystem of code for interpreting OPML, and will become widely available. The OPML ecosystem is open to profound innnovaton.

In the actual OPML spec, what I am calling “procedures” are called “attributes.” A specific node can have an unlimited number of such attributes.

——————————————————–

I hope this has helped. I find it useful to think in terms of these simple structures. I find it exciting to explore the possibilities opened up by the general use of OPML.