JSON vs. XML and the impact of design decisions
Connecting state and local government leaders
IT architects must understand their environment and requirements before they can wisely choose the programming tools that best meet their system or enterprise needs.
I have designed and programmed IT systems using the eXtensible Markup Language (XML) for many years. I wrote and taught a training course on XML two years before it was a standard (XML 1.0 became a W3C Recommendation on February 10, 1998) and have also written books and articles on the efficacy of XML for information management. Given all of that, it is fair to say that I have a bias toward the use of XML in IT architectures.
However, JSON challenges XML for some use cases. JSON stands for JavaScript Object Notation, and it is a very simple and concise data format fully described in a single Web page at http://json.org. The question is which is more suitable in the context of making the right technology choices for your IT architecture.
The purpose of JSON is to encode data structures in a text format as efficiently as possible. It is worth noting that this corrects one of the most common complaints about XML which is its verbosity (in some situations). The verbosity of XML in data serialization is primarily due to its use of both start and end tags to wrap elements like this: <FirstName> Michael </FirstName>. The duplication of the label “FirstName” is a source of concern for many programmers who hate to waste any bandwidth or processing power. In JSON, this would be { FirstName: Michael }.
In general, JSON wins the battle on brevity which is why many web applications are using JSON for RESTful data transfer. Additionally, some NoSQL stores like CouchDB and MongoDB leverage JSON. Finally, as we examined in a previous article, linked data can also be expressed in JSON.
So, why use XML at all if JSON is more efficient? There are at least four situations where XML may be better than JSON. To set the stage, it is important to remember that efficiency is not always the No. 1 priority. As Donald Knuth famously stated, “We should forget about small efficiencies, say about 97 percent of the time: premature optimization is the root of all evil.”
First, the ‘M’ in XML stands for Markup, and XML can be used to markup or “tag” text documents, which is something JSON does not do.
Second, XML schema allows users to validate whether an XML document is correct before transmission. So if validation is important, than XML may be a better choice.
Third, XML allows extension of the elements in a document via techniques like substitution groups, the extension element, and the “any” element.
Fourth, there is a plethora of tools and standards that augment XML like XSLT, XPath, XQuery and many more.
So, there are situations where XML is a better choice than JSON, and there are certainly situations where JSON is a better alternative than XML. The key point is that you must know the situation, know the architecture and then choose the technology best fits the system or enterprise needs.
The choices you make for design are critical to the robust operation of a system. Almost every time that I have been called in for an IT rescue operation, the problems always stem from poor design choices. So, first – analyze the environment, the requirements and the use cases for which the technology must be well suited. Then, and only then, choose carefully.
Michael C. Daconta (mdaconta@incadencecorp.com or @mdaconta) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.