6 ms·

I changed my opinion of XML after I had to deal with yaml. Whoever thought it is a good idea for complex configs (kubernetes) was wrong

dathinab 6y ago
> 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 ;=)
- barefootliam 6y ago
  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 6y ago
    > 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.
- bawolff 6y ago
  So... JSON? Honestly if json had comments and allowed trailing commas it would be perfect.
  - dathinab 6y ago
    It also would at least need a first class base64 type IMHO. Oh and NaN,-Inf,+Inf.
ljm 6y ago
XML isn't the most enjoyable thing to write (although we don't seem to have a problem when it comes to HTML and JSX). There's the whole debate around when to use attributes or children, and all that, which I can see would be a problem if the schema is poorly defined. 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.
merb 6y ago
kubernetes mostly uses json internally, yaml is only the "cli" side of things. kubectl converts the yaml files to json. (https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#describing-a-kubernetes-object https://kubernetes.io/docs/concepts/overview/working-with-ob...)

dathinab 6y ago

> 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 ;=)

barefootliam 6y ago
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 6y ago
  > 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.
bawolff 6y ago
So... JSON? Honestly if json had comments and allowed trailing commas it would be perfect.
- dathinab 6y ago
  It also would at least need a first class base64 type IMHO. Oh and NaN,-Inf,+Inf.

ljm 6y ago

XML isn't the most enjoyable thing to write (although we don't seem to have a problem when it comes to HTML and JSX). There's the whole debate around when to use attributes or children, and all that, which I can see would be a problem if the schema is poorly defined. 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.

merb 6y ago

kubernetes mostly uses json internally, yaml is only the "cli" side of things. kubectl converts the yaml files to json. (https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#describing-a-kubernetes-object https://kubernetes.io/docs/concepts/overview/working-with-ob...)