https://bugs.chromium.org/p/chromium/issues/detail?id=514995
which was already nuts, so they are clearly not interested in anything related to XML. XML is a fantastic tool, it's just that a whole generation of developers refused to even touch it and are biased against it.
And since Chrome is now basically the web... wait til there is only Chrome and Safari left and see what happens to web "standards"...
Whoever thought it is a good idea for complex configs (kubernetes) was wrong
Kinda agree, YAML is a mess wrt. many aspects.
> I changed my opinion of XML after I had to deal with yaml.
I still didn't change my opinion about XML, it is similar a mess wr. many aspects.
For both there is a sane sub-set which isn't a mess and which looks reasonable fine. Sadly this subset has not necessary clear borders.
So I guess a sub-set of XML, i.e. XML reinvented in 2020 would probably be better then YAML. But then you could also do a YAML reinvented in 2020 ;=)
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.
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.
Honestly if json had comments and allowed trailing commas it would be perfect.
Oh and NaN,-Inf,+Inf.
But then, it's not like YAML is any better with how confusing its whitespace rules can be, and all the short-hand ways of avoiding explicit syntax (see: do you indent arrays in a hash or not? What's up with having to double-indent in some cases but not another?). And given the length of many yaml-based configs, it becomes pretty much useless once you're a thousand lines in, which you'll easily approach with a CI config.
At least with XML, you could actually attach a stylesheet to it (even just CSS) and you'd automatically have a human readable version of the file, without having to bother with converting YAML or JSON or whatever. That'd simplify the generation of a lot of internal dashboards.