Live data from Hacker News

JSON or XML: Just Decide

mnot.net

1–10 of 44 posts

Re: JSON or XML: Just Decide

#2
JSON. I've decided. Actually, I think I decided in 2001 or so when I decided that XML was just a bear.

Seems most people have decided to go with JSON as well, and that XML is more used for legacy systems and systems where there's some enterprise component you have to interface with.

Frankly, I hope JSON wins, but if it doesn't, XML needs to have a resurgence really quickly.

Re: JSON or XML: Just Decide

#3
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.

Re: JSON or XML: Just Decide

#4

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]: dump…

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

Re: JSON or XML: Just Decide

#6

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]: dump…

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.

Re: JSON or XML: Just Decide

#7

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]: dump…

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.

Re: JSON or XML: Just Decide

#8

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]: dump…

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.

Re: JSON or XML: Just Decide

#9
Use the right tool for the job. I wouldn't say that XML or JSON is always right. But I will say that I believe XML has a better ecosystem around it; with things like XSD, XSLT, XQuery/XPath, etc., and some pretty easy to use data-binding frameworks like JAX-B. My feeling is that XML makes it a lot easier to do certain classes of things that I want to do, like taking a business event message off a queue, match it against an XQuery expression, route it to the appropriate place based on that matching, store it in an XML database where I can later locate it using XQuery, and then render it into a web-based activity stream by applying an XSLT transform.

Sure, you could get there from here with JSON as well, but it sure seems more natural using XML.

Post reply on HN