The lost art of XML

Summary

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 passé. "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 ...