I think JSON's power comes from the fact that it is a subset of a programming language. I organize data in arrays and hash tables (or objects, which can be implemented as hash tables), and that is what JSON provides.
I remember teaching classes in '99 where I needed to explain XML. I could do it in five minutes -- it's like HTML, but you get to make up tags that are case-sensitive. Every start tag needs to have an end tag, and attributes need to be quoted. Put this magic tag at the start, so parsers know it's XML. Here's the special case for a tag that closes itself.
Then what happened? Validation, the gigantic stack of useless WS-* protocols, XSLT, SOAP, horrific parser interfaces, and a whole slew of enterprise-y technologies that cause more problems than they solve. Like COBRA, Ada, and every other "enterprise" technology that was specified first and implemented later, all of the XML add-ons are nice in theory but completely suck to use.
XML has changed from a mildly verbose but eminently human-readable and machine-parsable data representation into a "technology" that has become over-specialized and covered with encrustations to the point that it is approaching regex's on the "now you have two problems" scale. JSON just gets back to a format that both the machine and I can read reliably and with ease.
A widely quoted aphorism, originally from a USENET post:
"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."
—Jamie Zawinski,
This as a re-purposed quote, originally referencing sed or awk, and numerous people since have substituted in XML.
While regexps can look intimidating try this: write something that does a regexp using just "normal" language features. Greenspun's law applies equally here; any sufficiently complex parser will include a DSL for regular expressions...
I think the root issue is deeper than that; regexps can't handle tree data structures of undefined depth. So while you can often get the common cases to work just fine, some of the edge case are often literally impossible to solve with regexps.
PS: Parsing is one of those cases where you need to have the program do the types of things people are used to the source code doing. AKA, simply nesting if statements does not get you to a solution, which often leads to people tossing out lot's of buggy code. Creating a DSL (or Yet another LISP) can be really useful, but regexps is a dead end for a wide range of problems.
Okay, that's a little bit flip. Regexes are fine when used in well-understood cases when they're properly documented for whatever guy comes after you and has to deal with them. The "now you have two problems" part, IMO, comes more from the way most people use them instead of any particular flaw in regexes themselves.
Regex themselves are fine, but people try to do ridiculous things with them such as "parse" HTML. They're used when they shouldn't be, and they go unused when they should be used. :)
Some languages are hostile to plain old XML too though, mix one namespace declaration with an XML novice and you'll end up with much head scratching as to how to actually get the data out.
And then you have to add a few utterly pointless lines of code to deal with that namespace.
And people defending XML namespaces will appear in 3, 2, 1...
TBH at one point I thought the XML/XSLT combination for generating html server and clientside would be the next big thing, it was amazing for me, much, much better than jQuery.tmpl or any other js templating language as it acted identically on server/client. Unfortunately non-trivial XSLTs are a little much for many programmers to grok, you have to be able think functional. People want their loops. So I've given up on them as too high maintenance (even I had trouble reading xslts I'd written even a month ago).
> And people defending XML namespaces will appear in 3, 2, 1...
0. I don't really like XML (and most stuff around XML), but I rather like XML namespaces. Not all of them, mind you, but my issues mostly have to do with default namespaces and the way they're treated on elements versus attributes.
All-in-all, XML namespaces solve real issues in rather smart a manner.
Now tooling access to XML namespaces is a completely different bucket of filth, most APIs and XML-related stuff don't fare well there.
> Unfortunately non-trivial XSLTs are a little much for many programmers to grok, you have to be able think functional.
To think shit functional. Functional without real functions, with broken scoping, with an implicit state throughout, ... A "functional" language where you need something like 6 likes to write a recursive function which does nothing but recurse is closer to dysfunctional.
XSLT had a smart idea (only one) in XPath-selected templates, but the whole implementation is garbage.
> People want their loops.
XSLT has loops. It's not loops which throw people off, it's the unreadable verbosity and having to jump through hoops in order to do the simplest processing. It is also hard (as in, you need quite a bit of experience) to create anything even remotely reusable, and even then XSLT has no modularity worth speaking about. And the namespace handling is a mess.
The keys things about XSLT are that it exists and it works: it's better than nothing. I agree it's horrible to use e.g. "if (i<10)" are you kidding me? Though, many people use a graphical front end to generate it these days (mapforce, biztalk mapper, stylus studio, IBM and Oracle have their own - there's even a free one with an online demo
http://jamper.sourceforge.net/).
I think several healthy businesses supplying a GUI for XSLT suggests two things: 1. there's a need for what XSLT does; and 2. XSLT sucks
Of course, it could be that GUIs indicate a kind of disruption - making a difficult technology simpler to use, and therefore accessible by less-skilled people (or skilled people with less time). The potential disruptees are the XSLT experts (who in turn displaced people who wrote manual transformers, before XSLT).
Having said all that: there isn't anything comparable for JSON. And yet, communication between different apps - or even communication between different versions of the same app - is pretty much a given.
I remember teaching classes in '99 where I needed to explain XML. I could do it in five minutes -- it's like HTML, but you get to make up tags that are case-sensitive. Every start tag needs to have an end tag, and attributes need to be quoted. Put this magic tag at the start, so parsers know it's XML. Here's the special case for a tag that closes itself.
Then what happened? Validation, the gigantic stack of useless WS-* protocols, XSLT, SOAP, horrific parser interfaces, and a whole slew of enterprise-y technologies that cause more problems than they solve. Like COBRA, Ada, and every other "enterprise" technology that was specified first and implemented later, all of the XML add-ons are nice in theory but completely suck to use.
XML has changed from a mildly verbose but eminently human-readable and machine-parsable data representation into a "technology" that has become over-specialized and covered with encrustations to the point that it is approaching regex's on the "now you have two problems" scale. JSON just gets back to a format that both the machine and I can read reliably and with ease.