Before XML, you either had completely plain text-files, like INIs, or even JSON today. That's great for humanly editable files, but defining complex types in su

Before XML, you either had completely plain text-files, like INIs, or even JSON today. That's great for humanly editable files, but defining complex types in such files is a bit arbitrary, and there's room for lots of ambiguity. What are the valid fields and values? On the other hand, binary file-types usually mapped to C structs. This results in files that are near impossible to read or write if you don't have access to those structs. It was also vulnerable to encoding issues like bit-order. XML bridged those extremes. When using XSD etc. correctly it's possible (in theory) to validate locally if a given file will be read and understood by any and all other software implementing the same standard. It removes (in theory) the ambiguity of the plain-text formats, while still resulting in an output that's (in theory) immediately readable and editable by a human with no external references. The promise of XML is to replace the big, proprietary binary files, not to be the end-all be-all of textually encoded data. Small, simple RESTful webservices has no need for XML. Big, complicated ones might not, but once you've coded up against an advanced WSDL API, and the generated stubs just worked, complete with types and pre-wire validation, it's not hard to see the value.