There's lots of comments here on XML as a file format, but that's not precisely correct (even the opening of the wikipedia article on it has the same conceptual

There's lots of comments here on XML as a file format, but that's not precisely correct (even the opening of the wikipedia article on it has the same conceptual flaw in the opening description). I think understanding what it actually is, and why it exists can really offer a lot of perspective. As somebody who lived through the emergence of XML (and HTML) from SGML, and remembers SGML actually in use in some settings, I think it's important. XML is a specification for how to create data interchange formats using a semantic, hierarchical, organizational scheme -- it's not a file format. You create data formats that follow XML, but every different schema is a different data format. What XML did, and the reason it was important, was that it made it much easier to design and specify data formats that had standard tooling for writing, validating, and reading, than pretty much any other earlier conceptualization. Before then, pretty much every piece of software, and even every different version of the same software, had a custom, usually binary, undocumented, and proprietary data format that it used to serialize data (usually as a file format on disk) or to transmit data across a network. Today, it's more or less assumed that when you serialize data to disk, or build up some data object to send over a network, it'll probably be in some kind of human readable format, figuring out how to encode your data into bits, or dump out serialized C structs or whatever isn't the common practice anymore. Even using binary serialization format like Cap'n_Proto or BSON is considered kind of unusual outside of some large organizations. Developers back in those days were dealing with a variety of CPU and memory architectures, endianness, word size, and other things that made cross-platform movement of data a total nightmare. And almost nobody documented their formats in any way, reverse engineering formats was a valuable skill in some contexts. There was some precedent for XML-like approaches. A very common one was CSV, which was often used to move tabular data between systems (and is useful to view as another "specification" for making data formats). But again, it lacks a standard specification, lacks validation, and has other flaws that make it frustrating to use for data interchange. When XML hit, it was kind of like the enlightenment happened. Developers suddenly had tooling and standards that let them not only pump out data formats in a self describing way, but schemas that also let them know they were writing the data correctly and let readers know how to parse it. Even better, a human can usually just open up a data format created to the XML specification in a text editor and just read-off the data fields and values. Long-term archival became easier, networking systems became easier, RPC and API development became almost trivial, and so on. SOAP was created because XML was created. Most of Java's built in data format stuff and RPC functionality assumes XML. Thousand page books written by a dozen authors showed up in stores trying to explain to developers all of the weird edge bits and use-cases. Then the ugly parts of XML started to settle in. The verbosity, the overengineered bits, the lack of clarity over fields and attributes, stylistic disagreements over how to organize data using it. Turns out most developers don't want to go through the hassle of writing out the validation schemas so that was usually left unused, and then most of the tooling actually wasn't very good -- for a long time good implementations of readers/writers/validators just didn't even exist for many languages. It also turns out just handling and parsing through XML, even with decent tooling, is kind of an arcane chore. Since the early 2000s then, there's been an explosion of approaches that all have learned the lessons of XML, the good and the bad, and seek to tackle various perceived shortcomings: size, ease of use, etc. XML is an exquisite crystal castle, built using the purest most elegant thinking, over decades. It turns out most people just want good enough to get it done. So most developers it seems just serialize to JSON or JSONL, gzip it, and send it over the wire or write it to disk. If you're lucky somebody will write down the fields and expected data values in a team wiki somewhere, and off everybody goes. Gone are validators, carefully crafted hierarchical data values, schemas with carefully considered semantics. As somebody who lived through the dregs of binary formats and the heights of XML, I think this is okay. But it's good to know that XML exists if extreme formalism is still needed, and binary formats are relegated to highly niche use-cases.