MagMax Blog

Aviso: En este blog puede encontrar código!

XML vs JSON (En)

| Comments

Lately I am seeing lots of comparatives between JSON and XML. I do not want to be less than them, so I investigated a little to enter in this kind of comparatives.

Sadly, I realized that they are not comparable. To compare XML with JSON is just like compare an OpenOffice document with a text file. They are completely different things.

A JSON file is a set of grouped data. Nothing more. It allows a hierarchical structure, but you only have objects, vectors, vars and values.

An XML file is lots of things more. It is a set of structured data. It can be queried (xpath), checks (DTD, XML Schema), viaualization (CSS), process (XSL), etc.

But lots of people continue on comparing them. Let’s see their arguments:

Updated 2012/02/03: Applying some changes, thanks to Manuel Rivero. Thank you very much!

Size

It is very common to say that JSON is smaller than XML, so it is better to share data in networks.

I calculated it, and a JSON file is, more or less, 3/4 of an XML file (comparing “equivalent” files, because you can find lots of examples of JSON files that have not the same hierarchy that its “equal” in XML), so it seems they are right.

Despite of this, if you want to save space, it is better to use a binary format or a comprised JSON/XML. As far as they are text files, it is possible that both of them will be comprised a lot, giving to you very similar sizes.

In addition, XML can have inner references and entities, so you can use macros; with JSON you cannot. What is more, XML supports outter files references which can be already in the target host, and they do not need to be sent again, so it can be quicklier to send, in theory.

Another thing to say is that a JSON file always must be coded as little endian UTF-16, because it was thought only to use with javascript/java, but XML can be coded in every system. This way, depending on the content, XML can be much smaller than JSON.

Speed

Lots of sites say that JSON, being smaller than XML, is quicklier to be processed.

That is not true. JSON, as far as has less characteristics than XML, must be quicklier to be processed.

But it is not possible to use Firefox as a tester (I saw it), because the process speed depends on the library you use.

The problem in this comparation is that it is very dangerous and is not reliable because, as I said before, we are comparing things that are not comparable. How much does the JSON structure check cost? How much is the price of re-write, again and again, this checker? With XML it is very easy, because you have only to say which XML Schema to use and our library will do the work.

Variety

Like everything in live, XML was built with a goal and JSON was built with another one totally different. XML is a way to structure data, while JSON is a way to share data between a language that should be easy (javascript) and another language (java).

Despite of this, like we found lots of usages for XML with time, like SOAP, it is possible that JSON has lots of usages.

Personal Opinion

My advise is that both of them are valid, but it depends on why you are going to use them. As long as you do not use an OpenOffice file or a TXT file for everything, it is trivial to think that you must not use XML or JSON for everything.

By the way, everything that you can do with JSON can be done with XML, but not in the other way. Nobody must ignore that XML has metadata (attributes) while that does not exists in JSON. This characteristic can be simulated with JSON by using data, but it is much pretty to use XML attributes.

Finally, I think that JSON is a good choice to very little data structures they can have lots of data, but structure is small, while XML can hold structures much more complex.

And I think that everything tries to get complex, so a little data structure tries to grow, and to change a JSON to XML can be less funny we want…

So, I like XML. This only means that I will try to use XML, but it is perfectly reasonable that, sometimes, I find JSON to fit better.

Comments