"key: function(){alert("Oh joy, someone used <em>eval!</em>");}"
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."
Agreed. But isn't a language defined largely by what people are willing to do with it? XML has some wonky specifications that ultimately mean parsing XML is entirely indeterminate - external, over-http schemas, for instance. If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys? Would every subsequent parser that supported single-quoted keys be wrong for doing so? Same thing for namespaces: because people have abused them so horribly, they're almost useless.
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.
> But isn't a language defined largely by what people are willing to do with it?
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.
Tons of highly popular languages don't have XML parsers built to the spec. Very few of them can handle schemas at all, or recursive definitions in schemas, or external document types, or external entities or schemas (and the few that can are usually disabled intentionally, because they can make parsing a tiny XML file take minutes if the server of the schema doesn't serve it up fast enough). That the XML spec defines such things is irrelevant if they're wholly unreliable because enough parsers refuse to handle them. And there are more than enough horror stories out there to argue that a significant amount of systems don't handle to-spec XML.
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?
And if JSON did all of those things the libraries that implemented it would suck as well: the complexity comes from the semantics of what all of those things are and do (schema validation is a complex problem, and that has nothing to do with whether you are validating XML or JSON), not how to parse a silly file 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."