Hacker News Reader

Comment by nikolay | Hacker News Reader

I agree. When people started to move towards the "better" JSON standard from XML, I was puzzled. The inability to have comments, the need to "escape" every key name, the lack (in the past) of a schema and query language standard, etc.

View on HN

To be fair, while I agree that JSON is bad for config, I would argue that JSON'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'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:

    import json
    import sys
    sys.stdout.write("%s\n" % json.dumps(json.load(sys.stdin).get(sys.argv[1], None)))

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.

    $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value1
    {"sub-value": 5}
    $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value2
    99

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't an object, but it'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't configuration but rather inter-application communication (aka data serialization).

Reply on news.ycombinator.com