XML Is Only Complicated In Our Minds

I have a common history. I heard of XML and jumped all over it. It was king. Then I decided it was overly complicated and unneeded. Then JSON (simplifying concepts in YAML) came along promising a happier and simpler data interchange. Who needs namespaces and schemas and canonical forms and InfoSet and who knows what else?

Well, um, I'm back to liking XML, just a happier-go-luckier kind.

First, my beeves with JSON:

1. No comments. So that means not human readable.

2. The spec fits on the home page, but when people say "JSON" they often mean incompatible, nice things that don't involve quotation marks in the keys. And things like that.

3. A more extreme form of 2, along with the obvious implementation in browsers, assumes that all JavaScript is JSON. Just use "eval". Well, I know regex can validate it, but lazy code can lead to pain.

4. Heterogeneous lists are awkward. As in, first a text field, then a button, and so on. Note that some of the JSON examples simplify this issue because doing it right would look uglier. I think it applies at least to the "widget" example.

Back to XML, we really just try too hard to over-engineer things. It's the mindset. Take a sample from the JSON site. Here's the XML:

<menu>
  <header>Adobe SVG Viewer</header>
  <item action="Open" id="Open">Open</item>
  <item action="OpenNew" id="OpenNew">Open New</item>
  <separator/>
  ...

And the "equivalent" JSON:

{"menu": {
  "header": "SVG Viewer",
  "items": [
    {"id": "Open"},
    {"id": "OpenNew", "label": "Open New"},
    null,
    ...

Is that really simpler? Well, "the action and label values only need to be provided if they are not the same as the id". Um, shouldn't that apply to XML, too?

<menu>
  <header>Adobe SVG Viewer</header>
  <item id="Open">Open</item>
  <item id="OpenNew">Open New</item>
  <separator/>
  ...

Looking better. How about name value pairs? Isn't text data better than attribute values? Because it's extensible and you can wrap it in more markup, right? Well, how about just calming down. If JSON can have plain strings, I think XML can, too. Instead of this:

<init-param>
  <param-name>configGlossary:installationAt</param-name>
  <param-value>Philadelphia, PA</param-value>
</init-param>

say this:

<init-param
  name="configGlossary:installationAt"
  value="Philadelphia, PA"/>

Wow! Almost looks like JSON with those name value pairs! I didn't know XML had JSON features! But what if I wanted an object instead of a string? Just go back to using elements.

But it seems so very ad hoc. Um, well, yep. If you can be ad hoc (somewhat) with JSON, why not XML. And while you could write a schema for JSON (surely something exists?), do you usually? And is that okay? Now, I know schemas can be nice, but do you need them in every case?

Do you always need namespaces? Do you need them in JSON? If not, why not?

Meanwhile, the official DOM (especially originally) is just a terrible API, but plenty of good alternatives exist for just about every language in common use. And we're familiar with them.

So, remember, XML has lots of fancy specs and features which have proper occasions for use, but _don't use them when you don't need them_. Think happy thoughts, and XML can still be a good friend.