XML: Contrary to popular belief, it doesn't always kill babies

That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?"

I also have a feeling, that jQuery reinvents XPath.

That is not JSON. JSON is a rigidly specified serialization format as described at http://json.org , and exactly that. It is not merely "whatever some Javascript intepreter will accept", because that is a terrible data exchange format. Functions are not allowed in JSON.

Also you forgot to double-quote your key, which is required. In fact using single-quotes for keys in JSON is forbidden, even though Javascript permits it. But this is less important than claiming JSON can carry function definitions.

"XSLT can be modified to work on JSON, ..."

Anything can be made to work on anything. XML does have a large stack of standards that contains stuff that already is defined and exists, so you don't have to do the job of making the things that work; you just go grab a parser and an XSLT transformer, rather than writing it yourself. My personal favorite is namespaces, though nobody ever uses them correctly and consequently they're much less useful than I'd like. That's what it means to say XML does something when JSON does not; Turing complete languages can accomplish any task on either format, but you can't just go grab things for JSON as easily. You mention non-compliant libraries which absolutely is a big problem, but compliant libraries can be found.

This is correctable over time, certainly, but bear in mind that the very act of correcting JSON will turn it into the same monster that XML is, albeit perhaps a bit simpler. A JSON schema language will be the same pile of complicated stuff that the XML schema languages are. The problem is the complicated thing there, not the solution, and your solution may not be simpler than the problem. Some of the other "XML problems" are of the same nature; the problems with SOAP, for instance, have almost nothing to do with XML and everything to do with trying to be The Ultimate Solution to Everything Everywhere and consequently being a complicated pile of useless garbage.

Don't mistake me for an XML partisan. I say use JSON now unless you are actually dealing with marked-up text, in which case XML is superior. But if you're going to make good decisions about what to use, you need to understand both very well and the reasons behind that rule-of-thumb I give, not "XML bad, JSON good."

    {
      "name":"Product",
      "properties":{
        "id":{
          "type":"number",
          "description":"Product identifier",
          "required":true
        },
      ...

There isn't that much difference between hierarchical data formats. Even here, some people favour s-exps or YAML over JSON. So once one gets established it's difficult to dislodge due to standardization, network effects, tools, user familiarity etc. However, it can change when there is a new platform, which starts fresh with a different format.

JSON already owns browser communication (though note the pesky X in AJAX...), since browsers already use JavaScript, but it seems unlikely to usurp XML much further (exception: JS becomes prevalent on the server-side).

Obviously, we could use JSON or YAML or S-Expressions for representing something like a parse tree, but none of them have the same robust tool chain for tree manipulation that XML has.

1. You forgot namespaces. Gotta put SVG in your XHTML.

2. By the time you've done your translation, you've created json that is uglier and harder for a human to visually parse than the equivalent xml.

It turns out that json is useful when you don't want xml's features. Trying to shoehorn every one of xml's features into json creates another brand of hell.

Seriously, there are places where XML is the right tool, which the poster does a fine job of bringing up.

There are a lot of places where it is not, but was used because something better for those specific use cases hadn't been invented yet - JSON is barely 10 years old, whereas XML's SGML roots go back over 30.

Whatever the case, we're better off with ANY structured data format than old delimited and fixed column width formats from the dinosaur days.

  element = '<' + element_name + '>' + element + '</' + $1 + '>'
          | nil

And he knows what he was talking about—he was one of the people who worked on XQuery, after all.