In Defense of XML

Over the last few years XML has become a very unfashionable standard and especially in the Haxe world has drawn a lot of fire for being too verbose and containing too much redundancy.
I still use XML when I feel it’s appropriate, and I wanted to explain why.

When is XML the wrong choice?

In the past, XML has been used as a way of serialising data as input for a known web application (either from the back-end or from a file). I see this as a misuse of the technology. If it is not a public service, it has no reason to be be easily human readable and deserialising XML at runtime is wasteful. Ironically, this is what happens every time your browser loads a page and no-one seems too concerned about that.

Syntax problems with XML

I will also happily admit that the closing tag in XML is absolutely useless. Some might argue that it adds checkable redundancy to the file and avoids misspelling an opening tag, but that begs the question; Why not make all XML structures have redundancy? (Anyone think closing an attribute by retyping it’s name sound good?)

This could also be argued of the CDATA tag, which seems to be avoided simply because of it’s utter ugliness.


YAML is like Brittany Murphy (was), it’s pretty, but it has some problems. Firstly, it doesn’t scale well, because it uses indentation as syntax, the deeper your heirarchies become the heavier each individual item is (so that a simple piece of information can use 10x the necessary characters, if deep enough). Sometimes removing indentations can make code more readable, and XML allows this (as does JSON), or it can be removed all-together when needed. In XML and JSON, you may choose to put several bits of information on the same line for brevity (normally as attributes), but YAML does not allow this behaviour.

This is not to say YAML does not have it’s uses. I believe it will find it’s place representing small pieces of structured data in broadly editable systems (like Wikipedia or something).


In my opinion JSON is a strong contender to topple XML, and should be used in many public web-services instead of XML/SOAP. It’s human-readable and light on it’s feet. I have had many more issues resolving JSON serialisation incompatibilities than XML, but this is probably a result of it’s more organic evolution into a standard.

Where I see XML rise above JSON is when it comes to namespaces. Lots of developers will go their whole careers without needing to understand XML namespaces, but once you do, you’ll realise that XML is a little more than serialisation format. It allows different nodes to be scoped differently and to avoid any naming collisions. This might sound trivial but it means that XML data-sources can be annotated with tags from multiple different systems each of which can process the file without disturbing the other nodes, all without any need for delimiting anything (as in some template languages).

I’ll give you an example, you could use XSLT(an XML based language) to transform Android layout files (another XML based language) into XHTML. Neither of these standards were build to be aware of the other. And the output XHTML tags within your XSLT files can live as first class citizens alongside your transformation tags only because of namespaces. In this scenario, the resulting format does not even have to use namespaces to benefit from having them. So by using XML as an input for your application, you will have made it many times more flexible than otherwise.

When is XML appropriate?

When interpreted at compile-time, XML performance issues all but disappear, and the opportunities in pre-processing the XML add a huge degree of flexibility to a system.
I would argue that this is where XML belongs and will hopefully thrive as it’s misuse recedes.


  1. Hi Tom,

    Good post! I think that XML really shines in visual layout description.
    This could be done in JSON too but there’s another great value in xml besides namespaces.

    Adding a schema to an xml gives you nice code completion in any advanced IDE. That could be a nice feat for guise 🙂


Leave a Reply

Your email address will not be published.


© 2020 Thomas Byrne

Theme by Anders NorenUp ↑