In this article, we will explore the differences between XML and JSON. We will address which conditions best suit which format. At the end, we’ll dig into a few scenarios where XML will continue to play a crucial role in data exchange.
Similarities and Differences Between XML and JSON
Here’s a simple, high-level overview of these two standards.
Both XML and JSON:
- Are designed to store and transfer data.
- Are designed to be human- and machine-readable.
- Can be parsed (i.e., broken down into component parts for further analysis) by most programming languages.
- Can work well with?AJAX, a method for refreshing data without reloading the entire webpage
Here are the key differences:
- XML is more verbose and more structured than JSON.
- As a W3C recommendation, XML has its specifications well-documented. JSON, while generally well understood, is not a W3C recommendation. (There is a?JSON-LD?that’s a W3C recommendation. It has a far more narrow scope than the general JSON we are familiar with).
- XSLT?is XML’s styling language, which helps transform XML to other formats (like HTML or JSON). JSON has no dedicated styling language and has no need for one.
- XML has its own query language,?XQuery, which is what SQL query language is to databases. There are some work-in-progress query languages for JSON, though none have stood out.
- JSON has a few simple data types, whereas?XML allows you to design your own customized data types.
Essentially, JSON is less verbose, which means it’s simpler to understand (by humans) and has a smaller payload compared to XML for the same amount of data. Some tests even suggest data transfers will take 20 percent more time if you choose XML over JSON.?On the other hand, because XML is more structured, it has more powerful features like the ability to query it directly, design your own dialects of the format, and even design your own data types.
Which Scenarios Require JSON? XML?
Basically, if you have a simple use case like a simple transfer of data, use JSON.
If you need to do something more advanced, like
- querying the data on the document;
- enforcing a strict data type;
- designing customized data types; or
- designing your own dialects of the format,
Scenarios That Still Require XML
Here’s a diagram to explain the usage trends before and after JSON came onto the scene.
Unless there’s a new competing standard, XML is here to stay; it will continue to occupy the “for complex use cases” end of the data transfer market. Here are the complex use cases that still require XML and will continue to do so for the foreseeable future. I’ve ranked them from the least to most likely to move away from requiring XML.
- Specialized document formats (e.g., Microsoft Word, Microsoft Excel, Kindle, EPub, etc.)
- Highly specialized data that relies on XML as single source of truth (e.g., financial data, code documentation, etc.)
- Data exchanges between legacy systems that use XML
Specialized Document Formats
I have quite a bit of experience in this because I’ve done consulting work that involved exporting data from databases into Microsoft Excel and Word documents. People?sometimes even developers?are surprised to find that MS Excel/Word documents are actually giant zip files containing numerous XML files. Because of this, you cannot underestimate the importance of XML in general (and incidentally, the importance of an XML editor). Imagine the difference between reading and editing something that looks like this:
compared to this:
In addition, if you accidentally make a mistake editing the Word document, you end up with error messages like:
So do you want to use a specialized XML editor or stick with your regular code editor? Yeah, I thought so.
Highly Specialized Data
Remember that XML allows you to strictly define and enforce data types. This is a particularly compelling feature for situations when you’re working with highly specialized data and need both accuracy and precision. Let’s take financial data, for example. You want to transport such data clearly and precisely, as any mistakes might cost you dearly. In a less scary (but no less important) scenario, you have situations where you want to decorate code methods with XML style document comments.
Just like how the right XML editor helps with debugging XML documents, a proper tool can help greatly with code documentation in XML style. This is where SubMain’s GhostDoc truly shines. Writing code is already hard enough. Don’t add unnecessary pain to the process by worrying about conforming to strict XML structure for your comments.
Imagine automatically create comments like this:
This is what file headers look like.
And we have all worked on teams where the level of documentation across the developers has been uneven, leading to inconsistent quality throughout. Don’t spend more time exhorting your team to do the right thing. Lower the barrier to success by using a tool to enforce quality.
Data Exchanges Between Legacy Systems
I once spoke with an elderly Japanese gentleman who owned a family business that spanned three generations. They were in the porcelain industry, and he took immense pride in their products. He told me how he had all the disparate systems his business needed, ranging from warehouse inventory to customer relations systems, all “talking” to one another using a very common file format: CSV (comma-separated values). It blew my mind that a business owner who was completely un-savvy when it came to technology could still instinctively obey the principle of keeping it simple.
The same thing will happen with legacy systems that were built at the height of XML’s popularity. These legacy systems will be highly unlikely to accommodate JSON because JSON doesn’t support their needs. They’re also unlikely to adopt different standards other than XML due to the costs involved. Companies often follow the path of least resistance. Legacy systems that use XML will likely continue to do so. If there’s any change made to these systems, most likely the change will be replacing them altogether.
Even as JSON is replacing XML in the simpler data transfer scenarios, XML is definitely here to stay. As data systems get increasingly more complex, XML has proven itself to be well designed for these complex cases. So are you building a new system? Deciding which format to go with? Do you want to support the older yet richer XML format? Now you know a lot more about both formats, but ultimately, you know for sure that XML is not going away anytime soon. In fact, as the W3C recommendations for?XML seem to suggest, the more specialized formats such as books and invoices become XML-based, the more likely the markup language itself will persist over time, probably in increasingly diverse ways.
With the “Cambrian explosion” of XML document types, it is imperative we developers arm ourselves with tools that are good at handling complexities. That way, we can focus our greatest resource (our attention) on solving real problems. Choose your XML editing and integration tools wisely. As Peter Drucker once wrote in 1963, “There’s nothing quite so useless as doing with great efficiency what should not be done at all.”?Outsource your undifferentiated heavy lifting as much as you can.
Learn how GhostDoc can help to simplify your XML Comments, produce and maintain quality help documentation.
Have you ever heard of XPath or JPath?
[…] Is XML Dying? […]
For interfaces where you need a strict format, XML is the way to go. With XSLT you can translate between two different XML formats pretty easy. I don’t think there exists something similar for JSON (except writing a lot of JS code, of course) 🙂
Having worked with both, there are many instances involving JSON when I miss the visual cues provided by the structure of XML documents. In particular, reading JSON representations of multidimensional arrays and deeply nested structures is much harder than reading those same structures from a well formatted XML document. Those opening and closing tags make it much easier to visualize the structure of the data; JSON’s nested square brackets are no match.
You mention it being easy to read a “well formatted XML document” JSON when printed correctly has the same results. Both are unreadable when not formatted.
Great article. Thank you!
Just a note…Nobody remembers ASN.1?
Not all modern communications are on “cable” were you have the luxury to add more bytes to pack the message. In radio links (and 5G is radio) what you need is a compact and fast way to exchange messages, and being those human readable or not, is the last one of your worries. And it’s still heavily used.