No offense to the creator of YAML, but: The fact that it became one of the de-facto standards for cloud tooling is an absolutely damning statement about the state of the industry.
I get that XML is about as sexy as mainframes, and that a lot of folks here probably have PTSD from working with Java/Spring web apps, but YAML is about the worst of all worlds.
Though I think the real problem is that real-world configuration files are way too complicated for a simple/dumb/logic-less representation like a .ini/.conf file, so someone thinks to add some logic to is - which is just config-as-code. In a terrible programming language.
If you want config-as-code (and you want to!), just do it properly and use a proper programming language for it. Don't care which one, be it JavaScript, Python, Go, PDP-11 Assembly, or Rust. But please stop with these half-measure DSLs that just don't cut it.
XML does not, in a single line of code with no preknowledge of the document, deserialize into a map or array (of nested maps/arrays as needed). It cannot be mapped easily into domain objects/datastructs without extensive mapping info.
Instead, you need to describe the structure of the XML, have preknowledge of prefixes and meanings for namespaces, have to deal with CDATA crap, have directives, config-in-comments, and hosts of other annoyances.
XML sucks. I programmed from 1995 to the present. XML sucks. YAML is far far far far far superior.
The ONLY good thing about XML is XPath. That's it! XSLT? awful. schemas and other validations? horrid.
XStream (java library) was the only thing that made XML usable, and the second JSON (and later YAML) came out, I dropped it immediately.
That’s called “schema.” It’s a pretty out there concept, I know, the idea that you should be burdened to document the structure and intent of your data for both human and mechanical consumption. I realize I’m being forceful here, but keep in mind, you are compensated incredibly well. If it takes you another hour to save ten down the road, earn the pay. I don’t understand this aversion to tough stuff - which seems to be pretty popular here - and I’m starting to think I should interview for it a bit harder than I already do.
The problem with this thinking is that you, personally, are then forbidden from arguing for the use of a strictly typed language for development because it’s the opposite position to the one you’re holding here. The exact reasons we use languages like those are the same reasons we should be explicit with our schemas. It’s unfortunate that many people try to argue both sides due to the convenience, as you say, of a single line parse, when years of experience has taught that duck anything is a bug fountain. (Not saying you are arguing both, by the way, it’s just common.)
Try reading back your gripe with the following in mind: do I have a stronger complaint than “it’s difficult” here? I think you’ll find that you don’t convey one effectively.
There's this kind of stuff but it's niche and more convention than actual schema.
https://www.xml.com/pub/a/2006/05/31/converting-between-xml-...