When XML Is Still the Right Format and When It Is Not

The question "is XML dead" gets asked every year, and the answer is that it has found its niche and holds it. Developers who started after about 2012 mostly meet XML as something to be converted into JSON, and there are good reasons for that. There are also situations where converting is the wrong move, and where XML does something no other common format does. This post lists those situations so you can recognize them, and the ones where you should walk away.

1. Documents with inline markup

The defining strength of XML, inherited from SGML, is text with structure inside it. A paragraph in which some words are code, some are emphasized, one is a link: that is a tree of text and elements, and it has no good representation in a format built for records.

<article xmlns="urn:example:doc">
  <title>Backups</title>
  <para>Run <cmd>pg_dump</cmd> before you <emph>change</emph> the schema, then check the <cmd>exit code</cmd>.</para>
</article>

With a ten-line stylesheet this becomes HTML, preserving every inline element in place:

xsltproc doc.xsl doc.xml

<article>
  <h1>Backups</h1>
  <p>Run <code>pg_dump</code> before you <em>change</em> the schema, then check the <code>exit code</code>.</p>
</article>

And one XPath call returns the sentence as plain text, for search or a summary:

Run pg_dump before you change the schema, then check the exit code.

Try that with JSON: you would invent a list of text and element nodes and write your own renderer. Publishing formats such as DocBook, DITA, JATS (journal articles) and TEI (humanities texts) are XML for this reason, and so is XHTML. If your content is prose with structure, you want a document format, and the mainstream ones are XML (mixed content in XML and why it hurts mapping is the other side of the coin).

2. Exchange governed by a schema

When two organizations exchange data under a contract, they need an unambiguous definition and a way to check conformance. XML Schema (XSD) and RELAX NG are mature, standardized, and supported by every platform. A sender can validate before sending, a receiver can reject on arrival, and the error message names the element (validating XML against an XSD schema). Many industries standardized their vocabularies in XML: UBL and national e-invoicing formats, FpML for derivatives, HL7 CDA in health, XBRL in financial reporting, NIEM and many national statistics formats. If your partner's contract says XSD, you do not have a choice, and you do not need one: the tooling is good.

JSON Schema covers similar ground and is the right tool for JSON APIs. The point is not that XML validates better in principle. It is that decades of specifications are already written in it.

3. Signatures and long-term records

XML Digital Signature and canonicalization were designed for documents that are signed, transformed in transit and verified later (canonical XML and why diffs need it explains the canonical form they rely on). Electronic signatures in several jurisdictions, SAML assertions for single sign-on, and signed financial messages use it. JSON has equivalents (JWS), and they solve a different shape of problem, a signature over a compact payload rather than over a structured document with parts that can be signed independently.

For archives, plain-text XML with a published schema is among the safest formats for the long term: any future tool can read it, the structure is explicit, and there is no binary layout to reverse. Libraries, archives and governments choose it for that.

4. Ecosystems that already speak it

Often the decision is already made. Office files (DOCX, XLSX, PPTX) are zips of XML (reading Office Open XML (docx)). SVG, GPX, KML, RSS, Atom, sitemaps, Maven and Ant builds, Android layouts, SOAP services, .NET project files, and countless enterprise integration tools use XML. When your task is to read or produce one of these, XML is not a design choice, it is the interface. Treat it as a first-class skill: learn XPath, XSLT and a streaming parser, because they will serve you for years (handy command-line tools for XML).

5. Tooling that is better in XML

A few capabilities are best in the XML world, and if you need them, they are a reason to choose it:

• XSLT for declarative transformation between document shapes, with identity transform plus overrides.

• XPath and XQuery for queries over documents of any structure.

• Namespaces for mixing vocabularies in one document without clashes (using XML namespaces for extensions).

• Comments, processing instructions and entities that make it a good authoring format.

The test

Ask one question: would I choose XML if nothing around it already read it? If the answer is yes, because the content is a document, a standard demands it or you need signatures, keep it. If the answer is no, because the content is application data going to code you control, choose JSON, or Protocol Buffers for internal service calls. The cost of XML in the second case is not size, which compression erases, but ceremony: a mapping layer, namespace handling, and developers who find it unfamiliar.

A quick audit of your own case

Write down the five situations and score your project against each, honestly. Is any of your content prose with inline structure? Does a contract with an outside party name a schema? Will a signature or a long-term archive ever be required? Does a tool you depend on already read or write XML? Do you use XSLT or XPath for something that would take more code elsewhere?

Zero yes answers means XML would be a choice made out of habit, and you should look at JSON first. One or two usually mean XML at the edges, at the interface where the requirement lives, and something simpler inside. Three or more mean you are in XML territory, and the productive move is to get good at the tools instead of looking for a way out. The audit takes ten minutes and replaces an argument that otherwise tends to run for weeks.

Related reading

The cluster hub is choosing XML over the alternatives, or not. For the contrasts, see XML versus JSON versus YAML for configuration and XML versus Protocol Buffers for services. The history and design goals are in the XML 1.0 specification, and the publishing vocabularies at OASIS DocBook and TEI. Try the transformation yourself in the XML formatter.

When another format is the better default

Application data between your own services. JSON is smaller uncompressed, universally supported and cheap to produce. Use Protocol Buffers when volume demands it.

Public web APIs. Developers expect JSON, browsers parse it natively, and the examples in every tutorial are JSON.

Configuration edited by hand. YAML or TOML read more easily, though XML works if your tooling needs it.

Tabular data. CSV is smaller and loads straight into databases and spreadsheets (XML versus CSV for exchanging tabular data).

Quick scripts. A one-off between two programs of yours needs no schema, namespace or declaration. Use whatever is easiest.