XML was designed for documents; JSON for data structures. The 'lost art' framing implies we forgot something valuable, but what actually happened is we stopped using a document format for data serialization. That's not forgetting - that's learning. XML is still the right choice for its original domain (markup, documents with mixed content). It was never the right choice for API payloads and config files.
> XML was designed for documents; JSON for data structures.
JSON wasn't even designed for anything. It's literally the necessary and sufficient part of JavaScript that you could pass to an eval() to get a data structure out. It required zero tooling and even third-party module to hit the ground running.
> It was never the right choice for API payloads and config files
Partially agree about API payloads; when I design my APIs I typically use binary formats.
However, IME XML is actually great for config files.
Comments are crucial for config files. Once the complexity of the config grows, a hierarchy of nested nodes becomes handy, two fixed levels of hierarchy found in old Windows ini files, and modern Linux config files, is less than ideal, too many sections. Attributes make documents easier to work with due to better use of horizontal screen space: auto-formatted JSON only has single key=value per line, XML with attributes have multiple which reduces vertical scrolling.
XML is still the implementation tool for Microsoft Office and Open Office docs. I wouldn't hold those up as the gold standard or anything, but it's hard to see how Markdown could capture everything that XML does for, say, powerpoint or excel.
> XML is still the implementation tool for Microsoft Office and Open Office docs.
It is and that is a good thing. I can't tell you the number of times that an application storing it's data in XML has made it possible for me to do things that would otherwise be impossible.
But nobody authors these documents in XML. It's just an application storage format. It could just as easily be Sqlite.
