The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed m

The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads. That does not point to a particular excellence of XML. XML was designed as a markup language and thus people came up with XML-based domain specific languages with which they could define trees of data and metadata for storage and payloads. So, in effect, what these people are sending back and forth is trees with metadata. You can encode the same information in JSON or S-expressions, and people have already done all that. You just need to agree on conventions for the semantics but that holds even for XML. XML has the benefit of wide support across platforms, good reference implementations originally, various standard schemas for different data, but technically it has nothing revolutionary: rather, as people who do know XML inside out it's overly complex as a base format for data encoding. Writing a parser compliant to the spce is not trivial. XML's best feature is probably the fact that the complexity in the structure and syntax of the language is not enforced and you can easily keep your XML simple. That is what most people actually do. The fact that you can define an office suite in XML is not particularly a merit to XML: Microsoft just decided to use XML to encode their previously binary documents in plaintext. It's not as if they couldn't have done it without XML but some other format, or, defining their formats in XML would somehow make the documents available for anyone to interpret who has an XML parser. The meat is still in the semantics which you have to implement in your export and import code. Whether those semantics are then applied in the form of JSON or XML or pickled Python dicts or whatever is the trivial part.