XML, data and regularity

Alex James warns that XML is tomorrow's COBOL: "XML is cumbersome, we do a lot of work to get our database records into XML format, we do a lot of work when we modify it, and finally we do a lot of work to get it back into a database."

XML is a victim of its own success. XML is an excellent format for documents, from traditional documents such as XHTML pages, XSL-FO renderings, DocBook manuals or even insurance policies to more abstract descriptive documents such as the CML description of a molecular structure or the XAML rendering of a heterogeneous object graph (typically a WPF visual or a WF workflow, but could be anything; I've used XAML to mark up business logic).

What these have in common is that there's not a lot of regularity to them. An XHTML page has huge freedom to intermix text runs, bold elements, headings, images and so on and so forth. The same applies to something like DocBook. My business logic XAML listed components each of which could have its own configuration schema. Try to create a pseudo-relational structure for these, as Alex does for his "list of books" XML, and it would be a nightmare. XML succeeds in these cases precisely because it provides the structure inline with the content.

Once you move out of this realm and into the realm of highly structured data, such as Alex's list of books, the inline structure becomes a weakness not a strength. The repetition of the structural information against every element creates bloat, and more worryingly it creates duplication. I don't really want to admit the possibility that one of my books might have an "Authro" instead of an "Author". So for strictly schematised data, a representation that carries the schema only once, and implicitly associates content to schema in some way, is safer and more efficient. Alex proposes a tabular representation. This works fine for tabular data, as you would expect. When hierarchies enter the picture, however, he has to reintroduce relational complexities like keys and joins to make it work. Of course, it does still work, because it's just the relational model. Nevertheless, it isn't as natural as a true hierarchical schema, but I'm not sure what such a schema would look like, and that would reintroduce the issue of mapping in and out of relational databases.

For the time being, then, XML is being wildly overused, and many if not most applications of XML would be better served by Alex's vision of transporting mini-databases around. But it's unfair to blame XML for not being a relational database, just as it would be unfair to blame the relational model for being a lousy way to represent documents.