4 ms·

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 thing

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.

jmspring 15y ago
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?"
sureshv 15y ago
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.
wicknicks 15y ago
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.
- justin_vanw 15y ago
  You can use MSGPack over HTTP just as easily as JSON. In fact, it performs better in most browsers.
benatkin 15y ago
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.
- justin_vanw 15y ago
  Being 'well documented' doesn't make it less of a pain.
  - mistercow 15y ago
    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.
supersillyus 15y ago
For comparison, what do the automatically generated XML versions of those JSON examples look like?
Yarnage 15y ago
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?

jmspring 15y ago

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?"

sureshv 15y ago

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.

wicknicks 15y ago

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.

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

benatkin 15y ago

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.

justin_vanw 15y ago
Being 'well documented' doesn't make it less of a pain.
- mistercow 15y ago
  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.

supersillyus 15y ago

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

Yarnage 15y ago

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?