Is XML Dying?

Since the beginning, web developers have always needed to transport and store data, and there’s an entire generation of web developers that has only ever used JSON (JavaScript Object Notation) for that purpose. That choice makes sense; JSON is easy to read and conforms to JavaScript syntax. Some developers may not have even heard of XML (eXtensible Markup Language). XML was also designed to be both human- and machine-readable. Its purpose is primarily to handle the transportation and storage of data. And this data exchange was not meant for web only. Most importantly, distributing data of different flavors works fantastically well with XML, all because XML is designed to be highly flexible within a strict structure. Yet JSON continues to be the first choice for many developers. Which prompts the question: is XML dying??

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:

1. Are designed to store and transfer data.
2. Are designed to be human- and machine-readable.
3. Can be parsed (i.e., broken down into component parts for further analysis) by most programming languages.
4. Can work well with?AJAX, a method for refreshing data without reloading the entire webpage

Here are the key differences:

1. XML is more verbose and more structured than JSON.
2. 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).
3. 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.
4. 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.
5. 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

1. querying the data on the document;
2. enforcing a strict data type;
3. designing customized data types; or
4. designing your own dialects of the format,

use XML.

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.

1. Specialized document formats (e.g., Microsoft Word, Microsoft Excel, Kindle, EPub, etc.)
2. Highly specialized data that relies on XML as single source of truth (e.g., financial data, code documentation, etc.)
3. 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.

Conclusion

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.

About the author

T.J. Simmons

Contributing Author

KimSia writes under the nom de plume TJ Simmons. He started his own developer firm five years ago, building solutions for professionals in telecoms and the finance industry who were overwhelmed by too many Excel spreadsheets. He?s now proficient with the automation of document generation and data extraction from varied sources.

This author does not have any more posts.