I could be missing a lot here, as I've only worked with JSON as a way to transmit data between components of an AJAX app. But here's my attempt to respond, with corrections and counter-examples welcome.
For starters, there are already a huge number of tools out there for XML. Docbook comes with stylesheets for converting to any number of formats, which we have only to extend for our purposes. That's not really a quality of the language per se, but it is a valid practical consideration.
Then there are things like xpath, which make it possible to do (at least from what I can tell) much more powerful searches of an xml document than of the same data in the JSON libraries I've seen, which basically just import the JSON into native data types and that's that. It seems to me that storing data as an array or basic object is simple, but limiting. For example, how would I say "retrieve all elements of type foo that are nested one or more levels below elements of type bar and have the property baz set to 'hi!'" ("//bar//foo[@baz='hi!']" in xpath) using JSON tools without having to write my own function to iterate over the data? (note: it actually looks like there has been some work to implement xpath for JSON, but only in a couple of languages and not ones I use, so I'm not counting it :P)
Setting tools aside, though, looking at the JSON/XML comparisons on the JSON site, I don't really see it as being that much more "lightweight", at least in terms of producing it. I mean, just looking at the first example, the difference in character counts is only about 5%. Plus, I can't imagine the JSON equivalent of something like:
<para> The <filename>/etc/passwd</filename> file contains user account definitions. One way to view its contents is with the <command>cat</command> command as follows: </para> <screen><prompt>[user@host ~]$</prompt> <userinput>cat /etc/passwd</userinput> <computeroutput>root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin ... etc ... </computeroutput></screen>
being less cumbersome than the xml version. I can see JSON being good for describing objects, but it doesn't seem to be a good fit for actual pages worth of prose with inline formatting information. Counter-examples welcome, though.
no subject
For starters, there are already a huge number of tools out there for XML. Docbook comes with stylesheets for converting to any number of formats, which we have only to extend for our purposes. That's not really a quality of the language per se, but it is a valid practical consideration.
Then there are things like xpath, which make it possible to do (at least from what I can tell) much more powerful searches of an xml document than of the same data in the JSON libraries I've seen, which basically just import the JSON into native data types and that's that. It seems to me that storing data as an array or basic object is simple, but limiting. For example, how would I say "retrieve all elements of type foo that are nested one or more levels below elements of type bar and have the property baz set to 'hi!'" ("//bar//foo[@baz='hi!']" in xpath) using JSON tools without having to write my own function to iterate over the data? (note: it actually looks like there has been some work to implement xpath for JSON, but only in a couple of languages and not ones I use, so I'm not counting it :P)
Setting tools aside, though, looking at the JSON/XML comparisons on the JSON site, I don't really see it as being that much more "lightweight", at least in terms of producing it. I mean, just looking at the first example, the difference in character counts is only about 5%. Plus, I can't imagine the JSON equivalent of something like:
being less cumbersome than the xml version. I can see JSON being good for describing objects, but it doesn't seem to be a good fit for actual pages worth of prose with inline formatting information. Counter-examples welcome, though.