[barefootliam]

When we invented XML we did not have configuration files as a major use case- although the possibility of ubiquity had been hinted at in a speech by Michael Sperberg-McQueen earlier that year, comparing the potential of SGML to the infrastructure in tunnels beneath the city of Chicago.

There's an XPath from 2016 (3.1) but it didn't have any significant input from browser people - so the primary audience represented were people with large, complex, or multitudinous documents.

There's also microxml, although its traction is limited because of a (relatively minor) backward compatibility issue around whitespace in attribute values.

The use case of people editing small simple documents by hand, documents that did not contain mixed content (rich text if you like, with markup inside running text) wasn't major; in creating XML we did discuss having a syntax that distinguished elements that could contain text directly from those that could only contain other elements, but none of the suggestions were compatible with HTML, of course, or any other existing SGML vocabulary, and all of the proposals (including mine) were ugly and had flaws.

The primary advantages of using XML are

* you can use the XML stack - XPath, XSLT, XQuery, RelaxNG, XML Schema, XForms, EXI, etc etc - on your documents (including conf files)

* people who don't think of themselves as programmers can do sane powerful & useful things - the languages are declarative;

* XML documents can be in the problem domain - elements named after things they represent, not "div" and "span" for example

* you can write a custom grammar-based validation check that both gives some rudimentary QA and also helps to drive syntax-directed editors, hierarchical database schemas and so forth;

* syntax errors are fatal, and there's some redundancy in close tags, which help catch errors that often can't be caught easily by checking the data (e.g. for metadata)

For sure there are things we'd do differently with hindsight, but remember also that XML predates the success of JavaScript and CSS. There are things that would be different in JavaScript and CSS today, too, if done again.

[bawolff]

> you can use the XML stack - XPath, XSLT, XQuery, RelaxNG, XML Schema, XForms, EXI, etc etc - on your documents (including conf files)

A super complex stack with questionable security properties and composes in a way that is the opposite of simple.

> people who don't think of themselves as programmers can do sane powerful & useful things - the languages are declarative;

Not sure how that distinguishes it from other markup languages. What are we comparing to that is imperative? TeX?

> XML documents can be in the problem domain - elements named after things they represent, not "div" and "span" for example

I mean i guess xml works better for data serialization than a soup of html. That is not exactly a high bar.

> you can write a custom grammar-based validation check that both gives some rudimentary QA and also helps to drive syntax-directed editors, hierarchical database schemas and so forth;

You can do that with any format you can parse into to an abstract syntax tree. I suppose xml is convinent compared to writing your own custom format in so much as you already have an off the shelf parser, but we're comparing different serialization formats, not having no serialization format.

> syntax errors are fatal, and there's some redundancy in close tags, which help catch errors that often can't be caught easily by checking the data (e.g. for metadata)

That's pretty standard for all data serialization formats. If instead of data serialization you are instead talking about mark-up languages, that's almost always considered a bad thing.

> For sure there are things we'd do differently with hindsight, but remember also that XML predates the success of JavaScript...

I think that's pretty debatable when it comes to javascript. Regardless though, hindsight may be 20:20, but there is still room to look at fundamental design decisions. People may quibble about aspects of css and js, but the fundamental design choices turned out to be pretty solid to this day. XML on the other hand comes off as a weird compromise that tries to do too many things, doesn't do any of them all that well, resulting in an ecosystem of over the top complexity.