A few weeks back we had our release of Information Server 9.2 containing JSON parsing/composing (added into Assembly Editor for hierarchical transformation of new JSON docs that Big Data projects want). In this blog I want to discuss my understanding on the drivers that are making JSON (JavaScript Object Notation) prominent as an alternative to XML in the world of data interchange.

APIs and Web Services
XML and JSON were designed for two distinct purposes. XML originated as a way to give semantic definition to text in documents. JSON on the other hand is specifically for serializing data structures. Both can do what each other can do. XML can represent data structures, but an example of describing structures like empty arrays in XML shows off how JSON is much better at describing data structures. JSON on the other hand is mismatched to describe semantic meaning behind text in documents, which is where XML excels (think HTML).

The requirements of your connection client and the type of data you need to serialize are the main aspect that drives the decision between using XML and JSON. The web service’s APIs have become very important to the web. On top of that, REST is replacing SOAP as a data transfer protocol. XML is not compatible with REST, so if SOAP continues its decline, then XML usage will shrink along with it.

Data bases and Big Data
JSON is a key player in database technologies. JSON is the preferred format in “NoSQL” databases. These databases are intended to accommodate massive scalability, designed to deal with data that often does not seamlessly conform to a columnar/relational model, and to be web-oriented at their very core. The most well-known examples of databases of this sort are MongoDB, CouchDB, and Riak. These three are JSON-based,  horizontally scalable, and deeply web-driven databases. Also Amazon’s DynamoDB is REST/JSON architecture. Neo4J data base has a REST/JSON API, with no corresponding XML support.

There are a few databases out there that are XML-based (such as MarkLogic), but there isn’t any movement in this area similar to what we’re seeing involving the rapid adoption of JSON-based storage models.

The Internet and JavaScript
JavaScript is the new booming and that probably won’t change anytime soon.
“JSON is better adapted [than XML] to devices with limited capabilities such as smart things. Furthermore, it can be parsed to JavaScript objects. This makes it an ideal candidate for integration into Web Mashups” as per “Architecting the Internet of Things”.
Sure, there’s an XML parser for node, but it’s largely geared toward dealing with legacy XML-based endpoints. But the fact remains that JSON fits javascript “as JSON is derived from it”.

One way or another, the future is bright for JSON, but on other hand there are voices say that JSON possesses a very limited set of data types. It’s essentially restricted to null, Booleans, numeric, strings, arrays, and dictionaries. It doesn’t even have a Date data type. JSON is thus not only generally less verbose than XML it is more parsimonious in its use of data types. Restricting itself to primitive data types makes JSON interoperable with pretty much any programming language that exists out there.

3 thoughts on “JSON Vs XML

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s