I spent yesterday at the XML 2007 conference in Boston. It’s smaller than last year’s conference, which is a shame because I liked the sessions I attended better than last year’s. The knowledge and skills of the attendees as well as the presenters seemed impressive. Here are a few musings that resulted.

Orthogonal structures

A presentation on microformats by Melissa Itzinger of the MITRE Corporation led me to thinking about attributes, those unruly sidekicks to elements in XML and HTML. (For instance, IMG is an element, whereas WIDTH is an attribute to that element.) Attributes are unnecessary in theory (anything you specify as an attribute could syntactically be a subelement) but their usefulness is universally acknowledged. Besides reducing clutter and simplifying syntax, attributes can easily accommodate multiple values.

But their slyest contribution to XML and HTML is to allow new features to be added without needing to be specified in a schema or DTD. This is where attributes get unruly. Any structure they have must be rigorously obeyed by the programmer, because the browser or XML parser will not enforce the structure.

And if you do obey a structure, you can create an entirely different structure–or an unlimited number of such structures–orthogonal to the schema. You can mark certain paragraphs class=”false_statement” and write a program to strip them out and store the true statements somewhere private. But I’m being unnecessarily provocative–of course you can do many useful things too. The microformats movement is one example, More generally, this orthogonal structure provides the same access to cross-cutting concerns as aspect-oriented programming.

The main idea here is that what the browser or other output medium displays can be completely different from other uses to which the content is put, thanks to attributes. Thus, any HTML or XML document can easily be multi-structured.

Truly, the tree yields bad fruit

Microsoft has a strong presence at this conference, partly reflecting some promising technologies such as LINQ that they’ve developed for web development. Controversy exists, however, as to whether OOXML–the specification for converting Office documents into XML–is one of those promising technologies. I don’t want to go off on a tangent about the activities of the ECMA and ISO standards committees (search Andy Updegrove’s authoritative Standards Blog for great information), but the question here is whether OOXML is robust and simple enough to let programmers productively interact with Office documents.

Seemingly, OOXML represents progress and offers a door into new applications using Office formats for people willing to deal with its eccentricities. A cautiously enthusiastic presentation by Matt Turner (I originally wrote that it was Kelly Stirman, the name on the conference program) of Mark Logic indicated that OOXML is ready for use with promising mash-up tools such as XQuery and REST, and that you can do many things with “varying degrees of success.” He described the format as mostly readable, although it still contained a good deal of ugliness to maintain backward compatibility with decades of accrued features.

Turner dextrously converted a couple plays of Shakespeare, including As You Like It, from Jon Bosak’s XML project format to OOXML. He cut and pasted a paragraph to show how easy it was to manipulate the format–but as an O’Reilly colleague pointed out to me, the resulting file was invalid, and could be displayed by Office only because it quietly fixed the inconsistency.

Turner then demonstrated simple programs that could add elements to Office documents from databases through XQuery, and integrate this feature with the Office ribbon (its equivalent to a menu bar). He said he had put all this together in a few weeks, which lets me grudgingly admit that a 6000-plus-page specification doesn’t have to be a barrier to useful applications. In any case, the popularity of Office will lead many more programmers to try OOXML.

Hope for headachy DOM programmers

Why is DOM so hard to use? I simply assumed that JavaScript and DOM were developed by different organizations that didn’t talk to each other. Kurt Cagle of Metaphorical Web, who gracefully conducted a presentation over a phone link about DOM and alternatives, gave a different historical perspective. He says that W3C expected its unwieldy API to be hidden by language developers under higher-level APIs. But the language developers didn’t know want to anticipate what programmers wanted to do and therefore simply exposed the ugly class structure in high-level code.

Recently I’ve been using jQuery, which steps back, takes a look at what programmers want from a document, and provides it in a streamlined format. Cagle was pushing an even more elegant variant of the idea, E4X, which can carry off such miracles as converting a valid string of XML into a DOM structure, and let programmers traverse the structure the way they’d do any structure they define in their own program (with addition of support for multiple nodes that match a particular tag–the key feature Cagle identified as missing from JSON).

Although Cagle anticipated that E4X would become important because of data transfer savings it offered mobile applications, other people told me it was unlikely to go far because IE has no prospects of including it; Microsoft offers related functionality through LINQ.