Comment by justin_vanw | Hacker News Reader

Comment by justin_vanw | Hacker News Reader

JSON is great, but it is not nearly as flexible as XML, partly because of attributes. Also, because of it's JS heritage and compatibility, lots of common things are not representable in JSON. This is mostly because object keys MUST be strings.

Examples:

    In [1]: from simplejson import dumps

    In [2]: dumps({1: 5, '1': 0})
    Out[2]: '{"1": 0, "1": 5}'

Derp, good luck figuring out what that is supposed to mean.

    In [3]: dumps({None: None})
    Out[3]: '{"null": null}'
    In [4]: dumps({False: False})
    Out[4]: '{"false": false}'

Oh snap! That's an ugly bug waiting to happen!

Of course, Python is not immune from such uglyness:

    In [5]: {True: 'true', 1: '1'}
    Out[5]: {True: '1'}

WTF!

My new favorite method of encoding data is MSGPack. It's efficient, fast, available for all popular languages, and doesn't have inherited uglyness. Disadvantages: not human readable (it's a compact binary format), and no Unicode support. The unicode support issue can be worked around by convention (for example, always encode strings as utf-8), still very annoying though.

I think we can all agree that XML is gross.

Another major issue with XML is bad programmers. XML is an interchange format, it's meant to be used when you have to give out or accept data from the 'outside'. However, it is very rare to come across industry created XML that validates. And dealing with invalid XML is a complete shitshow.

JSON may not be as flexible, but, you know what? XML's flexibility really hasn't made it a winner.

JSON is more compact and less ambiguous...

For me, JSON wins.

Of course, I remember the days of "binary XML" and could only think "um, isn't that ASN.1?"

I don't really understand your point here. Those JSON data dumps don't make any sense...and wouldn't make sense as XML either. Why wouldn't you enforce a schema? I've never worked on a system that didn't do validation and schema enforcement regardless of xsd, json, etc; you need to have well defined ways of laying out your data or it's going to be useless regardless of the format used.

>JSON is great, but it is not nearly as flexible as XML, partly because of attributes.

Attributes can be stored in JSON as well. XML and JSON simply store data in different ways.

>Also, because of it's JS heritage and compatibility, lots of common things are not representable in JSON.

Like what? You can actually put real values in their correct types with JSON. You can't do that with XML, so what types of items are not representable?

>This is mostly because object keys MUST be strings.

The same is true for XML so I'm not sure what your point is. Don't nodes and attribute names need to be strings in XML?

I have spent equal amounts of time with XML and JSON. Here is what my experience told me:

1] XML is painful to write.

2] Languages don't natively support it. It always requires additional drivers/libraries.

3] Its non-trivial to store XML also. With the solutions that were out there we would always run into some requirements which the database didn't support, and had to done in the business logic. JSON databases (I use Mongo) have a very clear interface, about what they support and what they don't.

4] Finally, most websites support JSON, if they don't then I resort to the XML interface. Tools like MsgPack and Google protocol buffers are great, but can only be used in house. Not over HTTP.

In short, JSON wins for me.

You can use MSGPack over HTTP just as easily as JSON. In fact, it performs better in most browsers.

For comparison, what do the automatically generated XML versions of those JSON examples look like?

You're feigning outrage.

It's a valid and well-documented design decision that keys in JSON are strings.

If you want a language-specific serialization format based on JSON, come up with a dialect.

Being 'well documented' doesn't make it less of a pain.

But I mean, yes it does. Imagine if implementations were inconsistent as to what they allowed for JSON keys so that your browser couldn't understand the JSON your python code sent it. That scenario is prevented by the limitation being well documented.

If you are you looking for typing or schema then JSON would be an issue. OTOH almost every XML/SOAP endpoint that I've used could be switched over to use JSON.

Reply on news.ycombinator.com