https://marcosmagueta.com/blog/the-lost-art-of-xml/

The lost art of XML

January 20, 2026

Preamble

There exists a peculiar amnesia in software engineering regarding
XML. Mention it in most circles and you will receive knowing smiles,
dismissive waves, the sort of patronizing acknowledgment reserved for
technologies deemed passe. "Oh, XML," they say, as if the very
syllables carry the weight of obsolescence. "We use JSON now. Much
cleaner."

This is nonsense.

XML was not abandoned because it was inadequate; it was abandoned
because JavaScript won. The browser won. And in that victory, we
collectively agreed to pretend that a format designed for human
readability in a REPL was suitable for machine-to-machine
communication, for configuration, for anything requiring rigor. We
relinquished the logical formalism for convenience with our tools.

The Case for XML

Consider what XML actually offers, what we surrendered in our rush
toward minimalism:

Schemas. XML Schema Definition (XSD) provides genuine type checking
at the document level. You can specify that an element must contain
an integer, that it must appear exactly once, that certain attributes
are required. The schema is itself a document; it can be validated,
versioned, referenced. When you receive an XML document, you can
verify its structure before you ever parse its content. This is not a
luxury. This is basic engineering hygiene.

JSON has no such mechanism built into the format. Yes, JSON Schema
exists, but it is an afterthought, a third-party addition that never
achieved universal adoption. Most JSON is validated (if at all)
through ad-hoc code that checks for the presence of expected keys and
hopes for the best. This is insanity masquerading as pragmatism.

Namespaces. XML allows you to compose documents from multiple schemas
without collision. You can embed XHTML inside a custom vocabulary,
reference external definitions, maintain clear boundaries between
different semantic domains. This is not theoretical; this is how
standards like SVG, MathML, and SOAP actually work in practice.

JSON has no answer to this. If two libraries use the same key name,
you improvise. You prefix. You nest arbitrarily. You pray.

Comments. XML supports comments as a first-class feature. You can
annotate your configuration, explain why a particular value exists,
leave notes for future maintainers. JSON does not support comments.
The official specification forbids them. The rationale, as I have
repeatedly heard, is that comments would make parsing more complex.

Self-description. An XML document carries its schema with it, or
references it explicitly. The structure is declarative. The types are
manifest. You can hand someone an XML file and they can, with
reasonable effort, understand what it represents without consulting
external documentation.

JSON is a series of nested dictionaries and arrays with string keys.
What does "status": 1 mean? What values are valid for "type"? Is
"timestamp" an integer or a string? You will need to read the API
documentation. You will need to hope that documentation exists and is
current.

The S-Expression Connection

For those who have spent time with Lisp, XML's structure is
immediately familiar. It is essentially s-expressions with angle
brackets instead of parentheses. An element is a tagged list;
attributes are metadata; nesting is composition. The mapping is
direct:

(person (name "Alice") (age 30))

<person>
  <name>Alice</name>
  <age>30</age>
</person>

Or with attributes:

<person name="Alice" age="30" />

This is not accidental. XML inherits from SGML, which inherits from
earlier markup traditions, but the fundamental insight (that data can
be represented as nested, tagged structures) is the same insight that
drives Lisp's power. Code as data. Structure as meaning.

JSON, by contrast, is an object literal from JavaScript. It is a
notation for initializing dictionaries. It was never designed to be a
data interchange format; it was promoted to that role because it was
already in the browser and developers were already familiar with it.
Convenience over correctness.

Why We Chose Poorly

The abandonment of XML in favor of JSON and other lobotomized formats
like YAML is a case study in how developer experience can override
technical merit. XML is verbose. It requires closing tags. It looks
"heavy" compared to JSON's minimalism. These are aesthetic complaints
dressed up as engineering concerns.

While verbosity is often a hazard, it is not a vice when it serves
clarity. These are not mutually exclusive. Closing tags make
structure explicit; they eliminate ambiguity in parsing. The angle
brackets are not there to annoy you; they are there to separate
markup from content, to make the document's structure immediately
visible.

YAML, the other pretender, manages to be both ambiguous and fragile.
Indentation-sensitive syntax in a data format? Implicit typing that
guesses whether no means a boolean or a string? A specification so
complex that implementations disagree on edge cases? This is
context-dependent parsing that we supposedly left behind.

On Developer Convenience and Self-Deception

There is a distinction that the industry refuses to acknowledge:
developer convenience and correctness are different concerns. They
are not opposed, necessarily, but they are not the same thing. A
format can be inconvenient to type and still be the right choice. A
format can be pleasant to work with and still be fundamentally
inadequate.

We have spent billions of dollars and countless engineering hours
making terrible technologies fast. The JVM is perhaps the canonical
example; a virtual machine originally designed for remote controls,
turned into the foundation of enterprise software through sheer force
of optimization, millions of developer hours and central bank funny
money. Decades of work went into JIT compilation, garbage collection
algorithms, escape analysis, all to make a fundamentally awkward
platform perform acceptably. And it worked! The JVM is now genuinely
fast.

But imagine if a fraction of that effort had gone into something
better from the start. Imagine if we had chosen a platform designed
for the problems we actually needed to solve, rather than
retrofitting a toy into production use. We spent billions making
wrong choices work, when we could have spent millions making the
right choice pleasant.

This is the pattern with JSON. We chose it because it was convenient,
because it was already in the browser, because developers already
understood object literals. Then, when its limitations became
apparent, we spent enormous effort working around them: creating
validation libraries, inventing type systems (TypeScript), building
code generators for API clients, developing entire frameworks to
manage the chaos of untyped data structures.

We could have just used XML. The schema validation was already there.
The type systems were already there. The tooling was already there.
But XML looked ugly, and closing tags felt verbose, so we chose JSON
and then spent years rebuilding what XML already provided.

The rationalization is remarkable. "JSON is simpler", they say, while
maintaining thousands of lines of validation code. "JSON is more
readable", they claim, while debugging subtle bugs caused by typos in
key names that a schema would have caught immediately. "JSON is
lightweight", they insist, while transmitting megabytes of redundant
field names that binary XML would have compressed away.

This is not engineering. This is fashion masquerading as technical
judgment.

The Physical and the Conceptual

Here is another confusion: we have allowed the physical
representation to dictate the conceptual model. XML's angle brackets
are a serialization choice; they are not the essence of what XML is.
The essence is the Information Set, the abstract model of elements,
attributes, and content. How that model is physically encoded (text
with angle brackets, binary with Fast Infoset, compressed with EXI)
is a separate concern.

But because the text serialization looks "heavy" we rejected the
entire model. We threw away schemas, namespaces, validation,
self-description, all because we didn't like angle brackets. This is
like rejecting relational databases because you don't like SQL. SQL
is not the relational model. Truth be told, most of the hate on XML
comes from protocols and arcane tools people had to deal with over
the years: a friend told me about his horrors on making an
integration with the central bank of Nigeria once, and they
apparently used SOAP; but these are implementation problems. While
it's a nice idea to analyze how much we have committed to a model,
it's also important to realise the formalism doesn't bear the blame
on how the central bank of Nigeria applies it.

JSON conflates these layers. It is simultaneously a data model
(nested objects and arrays) and a serialization format (braces and
brackets with string keys). There is no abstract model separate from
the text representation. This means you cannot have binary JSON that
preserves the same semantics, because the semantics are the syntax.
Every binary JSON-like format (MessagePack, BSON, etc.) is a
different model with different tradeoffs.

XML separates these concerns properly. The Information Set is the
model. Text, binary, compressed binary are all just serializations of
that model. You can choose the serialization appropriate to your
constraints without changing what the data means. This is correct
layering. This is how systems should be designed.

But correct layering is not convenient when you're writing a quick
API endpoint, so we chose the conflated mess and called it progress.

What We Lost

When we discarded XML, we lost:

  * First-class validation through schemas
  * Namespacing and composition
  * Comments and self-documentation
  * A separation between structure and content
  * Tooling that could verify correctness before runtime
  * A format that could evolve without breaking existing consumers

What we gained:

  * Fewer characters
  * Easier hand-writing for trivial cases
  * Native parsing in JavaScript

Fantastic trade.

The Binary Answer

One of the common complaints about XML is its verbosity, particularly
for network transmission. "All those closing tags waste bandwidth".
But even accepting this concern at face value (we shouldn't), XML
addressed it years ago.

Fast Infoset, standardized as ITU-T Rec. X.891 and ISO/IEC 24824-1,
is a binary encoding of the XML Information Set. It provides the same
logical structure, the same schema validation, the same semantic
richness, but with dramatically reduced size and parsing overhead. An
XML document can be serialized to Fast Infoset for transmission, then
deserialized back to standard XML at the receiving end. The schema
remains the same. The tooling remains the same. Only the wire format
changes.

EXI (Efficient XML Interchange), another W3C standard, goes further.
It uses schema-informed compression to achieve sizes competitive with
hand-tuned binary formats, while maintaining XML's semantic model.
You get type safety, validation, and self-description, with none of
the supposed bandwidth penalty.

These formats exist. They are standardized. They have implementations
in multiple languages. And yet the industry collectively ignores them
in favor of JSON, then invents Protocol Buffers and other binary
formats to solve the performance problems that binary XML already
solved.

The pattern is instructive: we abandoned XML for being verbose, then
when dealing JSON proved too painful, we created new binary formats
that lack XML's semantic richness, but with a confused grasp that "we
need something, but what is it!?". We could have simply used the
binary XML encodings that already existed. But that would require
admitting that XML was right all along.

On Practicality

I am not arguing that XML should be used everywhere. There are cases
where other formats are appropriate: small data transfers between
cooperating services and scenarios where schema validation would be
overkill. But these are the exceptions, not the rule.

For anything requiring durability, for anything that will be consumed
by multiple systems, for anything where correctness matters more than
convenience; XML remains the superior choice. The fact that we
collectively pretend otherwise is a testament to our capacity for
self-deception.

We chose the format that was easier to type over the format that was
harder to misuse. We chose developer convenience over system
reliability. And now we act surprised when our JSON APIs drift, when
our configurations break silently, when our data lacks the structure
we assumed it had.

A Final Point

Microsoft, for all their faults, understood this. MSBuild uses XML.
WPF uses XML. .NET's configuration system was XML until they caved to
JSON pressure in .NET Core. These were not arbitrary choices; they
were recognition that complex systems require complex
representations, and that formality in data representation prevents
entire classes of errors.

The fact that we now consider this "old-fashioned" says more about
our current priorities than about XML's utility. We value keystroke
economy over semantic precision. We value familiarity over rigor. We
value the appearance of simplicity over actual simplicity, which is
the simplicity that comes from clear rules and consistent structure.

XML is not perfect. XPath is baroque; XSLT is its own circle of hell;
the various XML-based "standards" spawned by enterprise committees
are monuments to over-engineering. But the core format (elements,
attributes, schemas, namespaces) remains sound. We threw out the
mechanism along with its abuses.

I am tired of lobotomized formats like JSON being treated as the
default, as the modern choice, as the obviously correct solution.
They are none of these things. They are the result of path dependence
and fashion, not considered engineering judgment.

Sometimes the old way was the right way. This is one of those times.

---------------------------------------------------------------------

  * << mmagueta
  * RSS / Atom

Powered by capivaras.dev.