As an editor, it’s all to easy to spend a lot of time reading (and responding to) blogs and articles on the web, and as the editor for xml.com, I find my time is disproportionately allocated to trying to correct misperceptions and even hostile snipings about XML. One such post came yesterday, in Jeff Atwood’s excellent Coding Horrors blog, one that (my comments in this article not withstanding) is a must read for anyone who programs for a living.

In The Angle Bracket Tax , Jeff lays out what he perceives as the flaws of XML, and why they detract from the language. I could attempt to refute him point by point, but in the main, he’s pretty much spot on with regards to his particular complaints - XML is a verbose, complex, oft-misused language that has been pushed into areas where it has no business belonging (more or less) and there are far better formats for doing everything from describing data structures to writing processes to sending messages. Yet he also misses a major, perhaps even a fundamental, point -XML is not a programming language.

Now, before you start scratching you head in puzzlement, let me explain. XML is a way of creating a declaration of the way that things are - it’s one of the reasons that it is referred to as a declarative language. If you were to take a snapshot of the property values of a complex model, the XML infoset is actually a pretty nice balance of property values and property descriptors, especially if you get away from the notion that everything has to be encapsulated in a single XML document or schema and move toward the idea of collections of documents and collections of schemas. It may not be ideal for the description of certain types of models (those that represent “pure” data structures for instance) but the key point is that it is capable of representing them.

Suppose for the moment that you wanted to represent an invoice as a JSON object. It’s not a hard process putting together such a structured invoice as a JavaScript object - most programmers could do it in a few minutes. They could do it in XML in a few minutes as well, though perhaps with the use of a few more keystrokes (though with the right tools, such as a decent XML editor, even that’s not generally the case). Now, write a script for a screen play in JSON. Go on, I dare you. What you will likely find is that it is possible to do, but requires that you make a number of convention assumptions and requires that you think harder about the best way of encoding each statement. XML can do it without breaking a sweat.

Is XML better for creating an invoice here? Perhaps, perhaps not. Yet, if XML is not working for you, then there is no reason for you to use it. There are no XML police out there telling you that thou shalt employ angle brackets. XML is an abstraction language, which means that no matter where you turn, there will always be something that has to implement that abstraction, and that’s always closer to the metal. If your concern is speed, then maybe JSON is a better alternative for you, or perhaps YAML.

I think a part of the reason that people continue to insist on trying to encode things in XML that don’t belong there is that they have been trained that there is one and only one paradigm to data modeling - the Object Oriented Programming model. XML is predicated on a declarative existence, one where you can give the state of a given set of objects be enumerating, for each such object the values that a given property may expose, and where there are, ingeneral no “verbs” defined on the XML itself. Yet most OOP works upon the assumption that the state of any given object is in theory unknowable outside of the scope of the object’s boundaries, and that they only way that you can expose a semblance of state is to create getter/setter type methods that pass external state into or out of the object itself. Yet for the expediency of getting to use port 80 as a transport window for web services, we try to force fit OOP on XML - in schema (XSDL), in messaging (SOAP/WSDL), even with post-schema-validated infosets, then complain loudly when it ’s an awkward fit.

There are places where XML works very well, in some cases better than any other format. Transformations and validations are two good examples of this. A transformation is an example of a state machine - in a document traversal where the context shifts down each node of the document, whenever a given pattern is found that satisfies a given pattern or rule, a particular output is generated. Simple compilers work upon similar principles, though in general the pattern matching there is lexical rather than structural. One consequence of this is that such state machines are particularly amenable to recursion - they tend to use it quite effectively, whereas recursion in imperative programming always invariably is discouraged because it is an “unnatural” action that can blow fragile data stacks.

XSLT can be cryptic and cumbersome if you approach it with imperative principles in mind. Treat it as a pattern matching state engine, though, and it’s capable of profound feats of code generation. That’s why a good XSLT programmer can replace the work of several imperative programmers … in the domains where such state machines are themselves useful (and is usually why imperative programmers usually give up on XSLT, for some reason).

XML is good at describing recursive structure as well, but the presence of mixing XML structural content with imperative scripting can typically weaken this advantage. Consider for instance a typical web page. The imperative approach to web page development is to place the scripts in a script block that is usually initialized upon some event - onload, onclick, whatever, typically adding behavior in that has no direct correlation with the structure itself - designating an arbitrary div via an id and then writing scripts that are invoked on various event handlers, with those handlers in turn writing out to dig deep into other structures on the web page - which in turn makes for very tightly bound architectures.

Yet change that approach - establish one or more XML-based data models, encapsulate behavior within binding files that are associated with elements rather than ids, bind the state of a given component or element on the page to a particular part of the data model such that changing the component changes the model but changing the data model also changes the component, and what you end up with is a system where “concerns” are separated, where presentation and model and controller are all clearly delineated and where you can create validation constraints on the fly. XForms is built around this model, but other applications can be built just as readily this way.

There are a lot of things that detractors of XML can point to that they don’t like - namespaces, character encodings, verbosity, legibility (and yes, angle tags are not as smoothing on the eye), yet many of these complaints deal with syntactical sugar. That’s what SGML was all about. Change the notation a little bit as in Example 1. Alternate XML

(html 
    (head 
        (title 'Valid Infosets')
     ) 
    (body 
        (h1 .class(block) 'Valid Infosets') 
        (p 'This is a valid infoset')
     ) 
     %(http://www.w3.org/1999/xhtml)
     )
            

and you have something that people might not complain as much about, but what’s important to understand is that the above form is precisely the same as Example 2. Canonical XML (and bears a surprising degree of similarity to the Curl language).

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Valid Infosets</title>                    
    </head>
    <body>
        <h1 class="block">Valid Infosets</h1>
        <p>This is a valid infoset.</p>
    </body>
</html>
            

Similarly, consider Example 3. JSON-Like Syntax .

{html:
    {head:
        {title:'Valid Infosets'},
     body:
        {h1:
            {@class:'block",'Valid Infosets'},
          p:'This is a valid infoset'
          }
    },
    #:'http://www.w3.org/1999/xhtml'
}
            

This could nearly pass for a JSON expression, save for the need to declare a few additional symbols (an @ or attribute symbol, and a # or namespace symbol) and the fact that a second paragraph would violate the one property per object level principle that JSON uses. The key point to consider in both of these examples is that while the syntax differs fairly dramatically between instances, the underlying infoset is the same in all three cases.

This particular point will take on additional salience as the Efficient XML Interchange format comes online later next year. EXI will look nothing like the angle bracket syntax - indeed, it will likely be indecipherable as XML unless you’re skilled at reading and interpreting binary characters. However, EXI will provide an alternate encoding of the infoset, one which should, in fact, be fully serializable to angle bracket notation and back.

Does this mean its time to reintroduce SGML into XML? No. One of the major lessons learned from SGML was that the cost of changing that syntactic sugar could be high, especially in terms of interoperability. That doesn’t mean that you couldn’t write your own custom parser and serializer for the infoset, one that let you write the notation the way that you want, though it probably wouldn’t hurt to be able to superclass existing parsers and serializers to do it. Whether it would be worth the effort is debatable, but the point is that when you are questioning XML, ask whether it is in fact that infoset that you’re having problems with or the sometimes less than legible notation, then consider the fact that in many, many cases, neither you nor the people who will be working with that code will likely ever see that XML in its “raw” serialized state.

I think there is one area where anger about XML may be justified, and that is in the realm of DOM. The W3C XML Document Object Model is verbose, is too granular, and for the most part was written with a “treewalker” view in mind. DOM was in fact intended to be used primarily as a mechanism for developing intermediate tools, rather than being exposed directly to end-developers - with XPath in turn supposed to fill the gap of providing a fairly simple selection mechanism for doing most operations needed within an XML document. However, at some point, somebody decided that XPath was too complex a language for someone to have to master, and it in turn became a very much secondary language accessible only through (you guessed it) a hideously complex DOM.

Here’s a thought - thirty years of developers have learned how to master languages such as C++, SQL and even the singularly bizarre APL language (which, granted, required a keyboard that is in fact not manufactured anywhere anymore). If you are going to use XML, learn XPath. It’s not hard, it’s very expressive, and it’s the foundation of both XSLT and XQuery, not to mention a host of other languages. Write a couple of wrapper functions around the ugly nasty DOM functions to call XPath easily, and use XPath for most of your operations to avoid DOM in the future. Other languages, such as E4X for Mozilla JavaScript and Adobe ActionScript, or LINQ for Microsoft Visual Basic or C++, can also simplify the burden considerably, but if you hate working with DOM, there are alternatives.

XML has been around long enough that it has become fairly frozen. Even W3C core XML members, contemplating making changes to the XML 1.0 standard with a 1.1 release, will admit that its pretty much a hopeless cause. This both makes it easy to complain about XML and almost impossible to really affect it. For that reason, I’ll reiterate what I said at the beginning:

XML is a powerful metalanguage, capable of an astonishingly large number of uses and now become such an ubiquitous part of the environment that it is probably permanently entrenched. However, there are alternatives that, individually, are better optimized for specific tasks. If you are more comfortable using them, use them. XML is a way of creating micro-languages - not necessarily the only one, but certainly one of the most potent. This means that if you find that someone’s XML microlanguage doesn’t work for you, more often than not it isn’t the XML itself that’s at fault, but the way that the microlanguage was developed (usually in a way that tries to make XML work in ways that it just simply was never designed for).

Write your own microlanguage, keeping in mind the power that XSLT and XPath and XQuery (and soon XProc) bring to the table. Actually this does bring up one last point - there are some things that have been solved and solved well. If you’re writing your own XML parser, your own transformation engine, your own selection language, you’re doing something wrong. Chances are if you’re doing this, you’re also abusing XML in other ways, and like anything else that’s abused, the results of your efforts will be an irredeemable mess. Learn your tools (and XML is just that, a tool) and respect them, and they will do wonders for you. It’s just that simple.

Note: As this was about to go to press I found this absolute gem of a response to Jeff Atwood’s article: Defending the Tax by Norm Walsh. Particularly relevant to me was a comment to this article that I thought was especially succinct:

Rolling your own is for those with no imagination or foresight. Some people cannot imagine that data or information has any value other than in the particular context of a single task. XML is all about capturing data and information in ways that preserve value for unknown uses. Not only is XML extensible, but XSLT allows reformatting from a particular vocabulary to another. That this is always perfect, but there are rules and tools and organizations to support it worldwide. IT should not be about making the programmer’s task easier at any point (as many seem to think), but about giving the most utility to the data or information now and in the future.

’nuff said.