JSON is not a good data-interchange format.

Authored by Mark Seemann, a software architect and consultant, this blog focuses on software design, object-oriented programming, and functional programming principles. Readers can explore articles and discussions on topics such as dependency injection, domain-driven design, and test-driven development. Additionally, they can learn about architectural patterns, design patterns, and best practices for building robust, maintainable software systems.

ploeh blog

Mark Seemann argues that XML is technically superior to JSON as a data-interchange format, despite JSON's widespread adoption. He contends that XML's bad reputation stems from overengineered standards like SOAP, not from XML itself. XML offers a rich ecosystem of mature standards including schema languages (XSD), query languages (XQuery), streaming parsers, and native comment support — features JSON lacks or has had to reinvent via third-party tools like JSON Schema. Seemann acknowledges JSON's practical dominance and its natural fit for JavaScript-heavy SPAs and BFF services, but maintains that for interoperability and formal data exchange, XML's built-in tooling and schema support make it the stronger choice. He also notes that neither format is ideal for configuration files.

Worse is better: JSON versus XML

I recently had to process XML files for the first time to parse German legislative texts. I found it hard to wrap my head around it, mostly because the XML object (lxml library in Python) was so opaque. If I read JSON, I get a Python dictionary that I can inspect in the debugger. With lxml I get an Element object which shows next to nothing.
For example, I struggled to read the content of an XML node. The <code>element.text</code> method gives me the text between the opening and closing tag. But if there is a nested node, the method gives you only the text up to the nested node. Then you need to get the nested node and call <code>element.tail</code> to get the text coming after. If I want all the text recursively, I need to call <code>element.iter()</code> and concatenate the results. So leaf and non-leaf modes behave differently but the class of the object I am seeing in the debugger is the same. I get that this is how the format works, but it’s unintuitive if you come from JSON.
What is much nicer is the query language, which saves you a lot of tree iteration and if-else statements.

this is probably an obtuse take but i hope i never have to work with XML again. ive only had to work with XML once, fixing Python logic in an accounting system invoicing pipeline. and like <a href="https://daily.dev/tilman151" data-mention-id="KrtluvEScPXJXrnrc3w7w" data-mention-username="tilman151" translate="no">@tilman151</a> mentioned, the interface provided by these libraries were very unintuitive and clunky

The reason VHS won out against betamax, as mentioned in the linked <a href="https://en.wikipedia.org/wiki/Videotape_format_war" target="_blank" rel="noopener nofollow">wiki article</a>, is hilarious 😂
Reminded me that sometimes older can be better despite the modern demand for things. Tube amps vs solid state amps, records vs digital music platforms, books vs audiobooks…

This is a refreshingly nuanced defense of XML. Separating the format itself from the baggage of SOAP makes the comparison fairer, and the mature schema, query, and streaming ecosystem is still a real advantage when interoperability matters more than developer convenience.