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."

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'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've used XML because .NET has a parser, and I'll probably use JSON because parsers are widespread... are there good standard parsers for S-expressions for .NET or other popular platforms?

A quick googling sends me here

http://stackoverflow.com/questions/3051254/parsing-lisp-s-ex...

which makes me believe.NET can't natively process s-expressions with ease, and that's a HUGE minus for me.

That holds if you want to use S-expressions as data exchange format (or like network protocol as is done by Subversion). Parsing Common Lisp source is entirely different matter.

I agree with the poster's reply to that: "Yes I agree that this is simple and fast, but.. What I really want is a 1-D list of my own object types." I get that when using XML web services with .NET (though mostly when consumed with other .NET or similar languages !!! which goes against it being an universal data transfer language )

Unfortunately, even when presented with numerous implementations of interesting algorithms like schema validators, tree transformation tools, etc. that /happen/ to use XML (for our purposes, a specific verbose dialect of s-expressions) as an interchange format, the entirely opposite problem occurs: people ask the question "could there be a better way?" needlessly, and then reinvent some subset of all of that tested and working code based on around something they made up, or even something people generally like (JSON), and throw away all of that existing ecosystem; and, in the end, the only way in which it is better is that it isn't XML.

    {
      "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).

> though note the pesky X in AJAX... it also sometimes called AJAJ

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.

  ns:node => {#:"ns:node"}
  xmlns="http://www.w3.org/1999/xhtml" =>
    {"xmlns":"http://www.w3.org/1999/xhtml"}

2) The point wasn't to say JSON is better than XML - apparently you didn't read my second sentence. I said they're trivially identical - they're the same thing, with the same capabilities, but with minimally different ways of representing the same data. The point is that claiming XML can do X because it's XML and JSON can't because it's not XML is complete nonsense. All the schema / XSLT / etc tools are just that - external tools, algorithms to run against data, which have nothing to do with how the data is transmitted.

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.

How could they not? It's JavaScript Object Notation. Objects which refer to sub-objects form a tree.

As to CSS selectors for JSON: the same functionality can exist, because as per above they have literally identical capabilities for representing data. I'll readily admit though, I've not seen one (though one of my side-projects could probably be tweaked to do this; maybe I will).

I have nothing against XML. It's useful, widely supported, and has quite possibly more tools than any other interchange format. The problem isn't with XML, it's with the inconsistencies of (and between) those tools that make the whole interchange part of XML with specs (the only really useful part - it's a horribly wasteful storage format) almost a moot point. And due to legacy systems, it's unlikely to change any time soon, or perhaps ever.

So a clean break is likely necessary to really improve things.

  {"key":"value" // comment
  or 
  {
    // comment
    "key":"value"

I'd think this problem of comments in JSON requires a solution that is part of the JSON specifications rather than dependent on individual parsers implementations.

Or perhaps JSON only really shines as a data interchange format and not much else.

I also have a feeling, that jQuery reinvents XPath.

  "document()/html//div[class='title']//img[class='icon']/@src"

  $("html div.title img.icon").attr("src")

You can also do arbitrary attribute searches:

  $("html div[class~='title'] img[src*='google']")
  // "~=" == "contains word" - space-delimited to match html classes
  // "*=" == "contains substring"