To be fair, while I agree that JSON is bad for config, I would argue that JSON&#x27;s objects and arrays eliminate the need for DTDs and standard query languages altogether in many cases.  Of course, with sufficiently lqrge and complex data stores, you&#x27;ll want a documented structure and method for accessing that data no matter what format you use, but unlike XML, JSON provides structure to get started on a small scale very easily.
 Consider this python:<p><pre><code>    import json
    import sys
    sys.stdout.write(&quot;%s\n&quot; % json.dumps(json.load(sys.stdin).get(sys.argv[1], None)))
</code></pre>
This will accept JSON on standard input and will return the value of an object with the key name specified by the first command-line argument.<p><pre><code>    $ echo &#x27;{ &quot;value1&quot; : { &quot;sub-value&quot;: 5 }, &quot;value2&quot;: 99 }&#x27; | python json-test.py value1
    {&quot;sub-value&quot;: 5}
    $ echo &#x27;{ &quot;value1&quot; : { &quot;sub-value&quot;: 5 }, &quot;value2&quot;: 99 }&#x27; | python json-test.py value2
    99
</code></pre>
Such a program will look similar in any language with a json library that maps objects and arrays to native data structures.  Granted, my simple tool will fail if the JSON isn&#x27;t an object, but it&#x27;s a very simple matter to extend it to handle lists and literals.  For many applications this is a huge advantage over XML, especially if the point of the JSON isn&#x27;t configuration but rather inter-application communication (aka data serialization).