Search This Blog


Saturday, November 12, 2011

JSON: JSON Compared to XML

XML is a much older specification and has been used for over a decade. JSON is much newer, requiring a much smaller string to define an object and the data the string contains.  

XML was designed to define, organize and contain data. JSON was designed to pass objects from one process to another in the form of a string.

Because the nature of XML is data centric, it is often used as data storage. There are XML data engines utilizing XML as a complete definition.

Although JSON was intended to transfer objects across string only transport protocols (ie. HTTP Port 80), it also has been used to store data. Mongo DB very closely resembles JSON in object definitions, etc.

JSON is most often the result of serializing an object. In contrast, XML often is a specification against which objects are built. This doesn't mean that either technique can't work in the opposite process.

Here are some further comments from others:

When I was a kid the question “who is stronger a rhino or an elephant?” was in the center of my universe. Fortunately or not I grew up.

On the practical note, is there something like XSD for JASON? 

Just a few thoughts on the above topic.

XML has been an industry standard for several years and many applications have built in XML based generation modules including the process of direct retrieval of data from database objects.

Apart from this the features that are embedded in the XML and their dependency on XML schema makes JSON object vulnerable to meet this requirement. Hence XML approach would need to continue if directly used to communicate between client and web server.

Another approach is to enhance the conversion process from XML standard to JSON standard using data compression methods to meet the equivalent better suited optimized JSON string based approach. To achieve this new functional library objects needs to be created both on the server end and client end.

This leads to the next question whether these java scripting objects libraries are likely to be supported by current web browsers. Hence all these issues need to be addressed before we can find the answer whether JSON would replace XML in future.
As a web developer, I use both XML and JSON.  They are both viable technologies for different scenarios.

JSON is a great light-weight data transfer format for powering web applications.  It's main niche is with AJAX widgets, web mash-ups and similar technologies due to the fact that it is, in essence, serialized JavaScript objects.  However, given that JSON is "JavaScript Object Notation", it goes without saying that its usefulness is pretty much limited to JavaScript-based usage. :)

XML is a better suited to discoverable services and disparate system integration.  It's ability to be consumed by nearly any data integration system and its strong data modeling and enforcement capabilities via schemas make it ideal for ETL-style operations.  The downside is that XML will need to be transformed in some way (either by XSL or through manual DOM/X-Path querying) to be useful.  That extra transformation overhead makes it a poor candidate for web-based JavaScript applications since JSON markup is lighter-weight and it's deserialzation mechanism is generally faster and more robust in modern browsers.

So, to answer the question of "Do you use XML or JSON", I answer "Yes".  :)