Web developers may be surprised to hear this, but, for what it was designed to do, there is no better tool than XML and the XML stack, and never has been. XML was designed for complex documents, especially documents with one or more of these properties: 1. creating, storing, exchanging, processing complex and long documents. Example: a 30,000-page telephone exhcnage manual. Quarter to half a million pages of operating system documentation. Manuals for nuclear submarines, for power plants, that have to remain usable for 100 years or more. 2. working with historical transcriptions - everything from scratchings on fragments of broken pottery from ancient Greece to Old High German manuscripts to critical (comparative) editions of Mary SHelley’s novel Frankenstein. 3. interchanging and processing tens of thousands, or tens of millions, of academic journal articles a day, where the authors are often not available to make changes. 4. working with automatically generated documents that need redundancy and frequent testing (e.g. the messages fuel pumps send to the cash register computer inside the office at a filling station). 5. working with documents that will be updated over a long period of time, especially by multiple generations of people. 6. Processing texts that will be produced in many different output formats. There are more use cases, but that’s enough. For each of them tehre are formats that go part-way. You could use JSON and custom validation code for the financial messages. You could use HTML for journals. But if you do, you have to reinvent some things along the way that XML already has, and you tend to lose the long-term benefits of declarative processing - a level beyond the level of declarative markup in HTML. Heck, HTML does not even have a standard way to identify a poem within a chapter of a book, and to say who wrote it - people do not agree about what to put in a cite element, and yet this is really basic metadata. HTML is fabulous for its intended purpose, just as XML is for its own purpose. There is no inherent advantage or disadvantage to Mary Shelley compared to Mary SHelley but you need a tool to check that the markup doesn’t say by mistake, or have a typo. Oops, you are reinventing Schematron or relaxNG or DTDs or XML Schema, and writing software that will rot over time & need maintenance but is not standards-based. You could use JSON schema for some of it, but defining your own types, inheritance, and using those types to distinguish a poem author from a memo author are beyond its remit. What’s important is saying what information is present, so that it can be processed, and then having tools to act on that. XML, and modern tools such as XSLT 3, XQuery 3, and the whole stack, is perfect for hte job at hand. Which is why i teach XSLT 3 courses. #markupmonday #xmlIsUseful #xml #xslt