XML's detail-oriented approach eventually became its nemesis. It was not long before people discovered that XML was unnecessarily verbose. The average verbosity level was around 80%, which meant that in an XML document, you have 20% of the bytes dedicated to values and the remaining to metadata. Such a high overload is not only expensive but a drag on the clock as well.

Javascript Object Notation or JSON emerged as much light-weight alternative to XML. It followed the same key/value pair design principle. But its origin lies in object serialization.

To understand how JSON works, we need to look at building blocks of the language.

So there are only two types of data: a) value & b) list of values.

All the keys should be unique. We may imagine a key being an identifier or a tag - as a sort of formal name for the hitherto unnamed chunk of data."Value" can be anything: simple alphanumeric sequence or a complex object. This rule applies to any "value" whether inside a list or outside.

The last rule of the game is that everything should be broken down to printable characters, as JSON is a purely text-based format.

For this use case, we have some issues to be handled around object to text transformation.

{"name": "John Doe", "address":, "phone_numbers": [6785549808, 7659450088, 5436789093], "academics": <[objects]>}

For address, we have this in plain text:

3869 Edgewood Avenue


CA 93721

We cannot use that as it is. We need to convert that into a proper JSON object.

Something like this:

{"door_no": 3869, "street": "Edgewood Avenue", "city": "Fresno", "state": "CA", "ZIP": 93721}

For academics, we again have some text dump:

PhD in English May 2010

University of Illinois at Urbana-Champaign

Dissertation title: "Down on the Farm: World War One and the Emergence of LiteraryModernism in the American South"

Committee: Margaret Black, Naomi Blue, John Jay, Robert Roberts (Chair)

MA in English 2003

University of Illinois at Urbana-Champaign

BA in English and Communications, summa cum laude 2000

Butler University, Indianapolis, IN

I have color-coded the text to emphasize the point that for each differently colored section, we need to create a JSON object. Then all such objects should be collected in a list.

Here we go:

[{"degree": "PhD in English", "year": 2010, "institute": "University of Illinois at Urbana-Champaign"},

{"degree": "MA in English", "year": 2003, "institute": "University of Illinois at Urbana-Champaign"},

{"degree": "BA in English and Communications", "year": 2000, "institute": "Butler University"}]

The final structure looks like this:

In this format, data is quite readable in spite of being considerably less verbose. In the field those two qualities translate into: a) easy to debug and b) faster processing and transmission.
After the epic battle of standards like NTSC vs. PAL and VHS vs. Betamax, Blu-Ray vs. HD-DVD, JSON vs. XML is the latest one. XML is subtly backed by big software firms, as its complexity requires specialized and hence expensive tools to just produce and consume it. On the other hand, JSON is pretty easy to handle. Run-of-the-mill programming languages like Python and Ruby can handle JSON with ease. In the next installment of this article, I will show how easily base Python handles JSON.

Clear Vision