XML libraries have been around for a long time. As have problems with XML libraries. Apparently it's not correctable over time, there's too much legacy to fight against.
---
>I say use JSON now unless you are actually dealing with marked-up text, in which case XML is superior.
I've heard that argument before. How, precisely, is it superior? It's denser than would be doable in my example, but is denser better? A lot of the arguments around both languages revolve around human vs computer readability. Is <em>text</em> more computer-readable than {#:"em", $:"text"} ? A bit more human-readable, yes, but I'll take "text" over either as often as I can.
This isn't true for a formalized language. Heck, it isn't even true for FRENCH where there is an official bureau that determines what is "proper" french, and any deviations from it are not part of the standard language.
> If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys?
It might in the absence of a formal spec, but not all JSON parsers accept single quotes.
For example, the official Python JSON parser does not.
>>> import json >>> json.loads("{'foo':'bar'}") ValueError: Expecting property name: line 1 column 1 (char 1)
I question how many other highly popular languages have JSON parsers built to the spec.
There are plenty of RFCs out there that define things that no longer practically exist - should they be used, because the spec defines something that you need? Especially if it's meant to be used as an interchange format?
Hell: a lot of highly popular languages, to be quite honest for a minute, probably don't even have compliant JSON parsers. The real problem here is cowboy developers who think "oh, JSON/XML/whatever is easy, I can throw one of those together in a few minutes" and then /don't even read the spec/ before committing their project into some poor language's standard library.
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."