How to Avoid Being Called a Bozo When Producing XML (2005)

An advantage of names in end tags is human readability. Consider this XML fragment:

  1234567890

Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose:

  (12(34(56(78(90)))))

Discussions about XML and JSON often remind me of this comment on HN: https://news.ycombinator.com/item?id=5702868

Partial quote:

> XML can certainly be shorter than JSON and often is, and repeated tags are the best showcase for it:

     
        123456789
        321654987
    

> This turns into this beautiful JSON:

     [
      "users": [
	{
	  "id": "abc",
	  "phoneNos": [
	    { "type": "home", "value": "123456789" }, 
	    { "type": "work", "value": "321654987" }
	  ]
	}
      ]
    ]

I thought of that same exchange when I read this post but remembered it more as a lament that JSON doesn't support namespaces - so JSON is always context dependent.

I use XML for a combination of features that I consider very important but are also perceived as "overkill": A source syntax that has already handled text escaping and encoding, lets me add some abstract structure, and lets me encode the text in a way that lets me nest different parsing modes for various kinds of structured data.

The first two are easy enough to get with your pick of JSON or S-Expressions. For a lot of things even CSV is enough, although CSV has the downside of being so simple that people opt to write an incorrect toolchain for it themselves instead of adding a dependency.

But it's the last feature that really produces the complexity. Once you get into "I want the inner structure to contain a different and unambiguous semantic meaning from the outer structure" you have a pretty substantial engineering problem. Less structured approaches like JSON or S-Expr's drop the problem on the floor by declaring one universal semantic, making the programmer deal with adding anything else on top. XML's compromises to achieve a more detailed representation of data involve the angle bracket tax, schema languages, etc.

If you want a guarantee that a rich data source can be processed correctly through an n-tier architecture that emits various radically different outputs, these compromises become compelling. I'm a big fan of DocBook, for example, and its canonical toolchain is an XSLT style sheet: The workflow I end up with is initial writing in a light syntax of choice, compile to DocBook XML, add additional formatting and styling in the XML, and then emit the final document in whatever forms needed - HTML, PDF, etc. It's extremely flexible, and you wouldn't get the same quality of result with a less extensive treatment.

For ordinary data serialization problems and one-offs, it is considerably less interesting.

> What I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess.

Namespaces, which then gives you easy answers for Internationalisation (xml:lang), a subject-predicate-object data structure (RDF), which can lead on to logical meaning/modelling of data (RDFS/OWL), which then lets you look at harder questions like trust/provenance.

There's also schema validation (XSD), transformation (XSLT), which then provides you tools like XPath.

Most of that is on the front page for the technology: https://www.w3.org/standards/xml/

The real problem is not syntax, its communication between groups with differing experiences and interests - how do I know your messages mean the same thing as what my system expects?

If you prove to be malicious, do I have to write a strict validator before I trust your input?

If you want to ensure your messages are well formed before they are sent, do you also have to write a validator?

How do I know our validators are checking the same things?

If you want to send a large document oriented data structure, but I only care about a specific section relating to my interests; do I have to understand where to look and what all of the surrounding material is; or can I query for the relevant bits?

On the more complicated RDF side of things - if you want to share identifiers with me, how do we both avoid calling everything record id=1?

If we are both talking about the same thing but know different parts of the story, how can I recognize your information as describing the same thing I know about?

If we both know about the same Thing, and know certain logical facts about that Thing, can we check those facts actually make sense against shared rules?

If we both know about the same Thing, and can see a logical inconsistency in data, can we reason about which data to Trust and why?

Unfortunately, communicating properly is hard even with all of the tools to help.

We tend to opt towards subjecting systems to an ongoing fuzzing test because we don't value many of the above things - we tend to work in organisations with a short attention span focused on the now and a narrow set of interests. It just kind of works for the 80% of the time, so we move on.

Contrast that with something like a library or museum, and you see why ideas like Dublin Core really catch on there.