Data Exchange – JSON and XML

JSON is everywhere these days. But XML still persists. How data exchange has “changed”

JSON has seen a lot of use lately, but what about XML? Both were meant to be a data exchange format; what is it about JSON that has made it the go to?

JSON vs XML is an interesting topic and debate that I recently had with some coworkers. Sure, I can understand the JSON circlejerk, but XML is still around for a reason.. or will it still be? I know especially in healthcare, the way data is, there is just too large of a structure already in XML that it just is not cost effective to convert to JSON, which is why HL7/FHIR are both available and optimized for either XML or JSON. However, XML is still the dominant format so far in terms of data exchange due to a standardized schema with its built in validation properties. With the rise of AJAX-powered sites, JSON is becoming more and more important to load data quickly and asynchronously without the reload allowing agility and responsiveness to shine. Image SourceData ExchangeSo, let’s talk about JSON first. In a way JSON serializes data that it becomes JavaScript code. Known as JavaScript Object Notation, it is called a lightweight format used in data interchanging. Although it can be serialized into JavaScript, some JS is not JSON and some JSON is not JS. Although XML was the primary data format for transmitting data back and forth, JSON has since taken the crown due to its lightweight syntax. As we saw in the image above, it’s so much more simple due to the brackets and colon to declare the objects. XML, is similar to HTML in that it is based off of a simple text file and uses similar tags to declare the necessary fields. JSON has seen continued use in API libraries as well as in PHP back-end frameworks. In addition, other than being a web service library, a php library, it also is a datatype in databases! Just as we have SOAP vs REST, the comparison can also be made for JSON and XML. 

comparison chart

Image Source

XML on the other hand is a markup language with a very simple base format with standards and interfacing languages. It is a bit more beefy and robust due to its formatting though. As a result, it is more verbose. It is also able to describe and analyze these text files, and store them in the XML file. However, XML provides the XML Schema that ensures type and structure so there is a more verbose validity for it. Especially in healthcare, it is verbose in that it can declare fields and type check. Because of the schema definition, the XML document has specific guidelines to be structured thus allowing validation for consistency and completion, splitting the responsibility from the code that processes the data.

In the diagram above, it indicates some of the limitations of JSON compared to the versatility of XML. In the Oracle post, it mentions that XML technologies support a complex ecosystem of semantics, particularly for interoperability, security, and rules. However, from what we know about the lightweight, human readable and quick JSON, it really is restricted to the structure and content capabilities. XML on the other hand is just more versatile in this case.


JSON is simpler to get data from the server and use it as a persistent memory for a program. You have to know the structure of the data to use it, you must be the owner of the data file preferably. It is lighter than XML and saves resources because there is less data transferred. Parsing is dependent on the parser of course and how it is “turning” the code into a data structure (like a map). However its weakness lies in the lack of defined data structures, having really only defined variables, arrays, and hashes, there is little else for JSON. Good for RESTful APIs, which emphasize speed, reliability and ease of use. As a result, JSON is designed for quick web client interfaces that can utilize RESTful APIs for asynchronous information for quick and flexible interactions as needed. Essentially a serialized Javascript object, it is great because it is considered native to all client side scripting for all web browsers.

Data Exchange Comparison Source

XML is better for presentation purpose. It is the language of several graphical user interfaces for now: XAML, XUL, MXML, etc., while QML is similar to JSON. In the first case, the data is stored in a form and used in another form. You can use XML from external sources and even make XML databases. Generalized. XML schema is useful for datatype and structure validation. Has other libraries like XSLT for transformation into different outputs. As well as XPath and XQuery for extraction of information, which can make parsing information in deeply nested structures more simple then with JSON. This makes it terrific for highly structured information that JSON simply does not support yet! In XML, you can add a child element or an attribute simple enough, namespaces can be used to prevent clashes (although that’s not much of a problem) and for the most part these extended attributes and elements don’t break due to the robustness of the structure.

In the end, I believe having a strong understanding of both is key to having clear and simple data exchange. It’s not too difficult to convert from XML to JSON, so depending on the project work in the best language for yourself and convert it as needed. Until JSON increases its verbosity and extensibility, the draconian XML APIs are here to stay and its important to be familiar of both concepts.

Article by Sir. Lappleton III

I'm a happy-go-lucky recent graduate that started a blog as a way to not only document my education and my experiences, but also to share it with whoever stumbles upon my site! Hopefully I can keep you guys entertained as well as learn about a few things from IT as well as from my time and experiences as I plunge deeper and deeper into healthcare! A couple of my areas of focus is data management, system security (cyber security), as well as information technology policy.