You're one of those few lucky whose malformed xml cause no issue.

Whole I definitely agree yaml is pointlessly prone to this ("NO" lol), I've had plenty of xml issues. Bad manual attribute encoding, duplicate attributes (pretty easy when there are lots) that vary in behavior depending on your xml reader, using text content instead of attributes, using lists of text nodes as a map that then gets deduplicated inconsistently instead of attributes (to work around needing to manually encode complex or multi-line text into an attribute)...

Humans can screw up anything. And more text often allows it to hide for longer.

But one of them has schema descriptions to prevent these errors as soon as possible.

Sure, if you define and use it. Same as yaml schemas (they exist!).

XML has them sorta built in (basically all (notable) libraries support them), but it's not like it's required or somehow innately protected because of that. It's just a bit easier to adopt.

But my case was with a yaml validated to a schema. A kube ingress file with a list of rules. My additional dash made it a new entry, in practice allowing everything. With xml it would have been very explicit that I now accidentally had made two rules.

> But one of them has schema descriptions

JSONSchema? It's pretty standardized and well accepted.

I believe XML has it baked directly into the official spec. JSONSchema is great, but I wouldn't call it a standard yet, and anecdotally I haven't seen it as often as I'd like in use (i.e. I either need to run kubectl --dry-run or use a separate third party solution to validate my changed yaml).

XML schema is a separate spec.

Read the title - just because YAML is a superset of JSON, doesn’t mean you can check every YAML file with JSOnSchema.

I once had an issue where something failed in prod but not in test, it was because a MAC address was dynamic and in prod only consisted of numbers so whatever tool we used parsed the Yaml value as a sexagesimal number and threw a type error. Yaml can be interesting…

Note that the behavior you describe (like the “NO” problem) was part of the YAML 1.1 excessive-effort-at-DWIM insanity (in this case, intended to make time entry “just work”) that was removed in YAML 1.2.

Malformed xml sneaks through the kitchen window and poisons you in your sleep. Someone puts naively escaped umlauts (ä -> ä ) into the surname field and your entire xml parser borks with unknown entity errors

Pro tip: remember that all JSON is valid YAML. You can put JSON in a .yaml file and be just fine. I find that handy when the explicitness makes it easier to read the file.

As long as you remove all the indenting.

All JSON evaluates to some value in YAML. But it's not always the value you want it to.

I have. A ton of vendors and APIs generate XML with interpolation or some other form of hand-rolled code that’s incorrectly escaped, which compliant parsers can’t parse and they can’t fix.

> At least I've never had production errors because of malformed xml.

Oh hey, I had some while making https://hn-blogs.kronis.dev/

I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousan... but the gist of it is that I had to parse thousands of blog feeds and some article from 2009 included a SOH control sequence inside of otherwise valid XML and this broke everything, until I added additional error handling.