4 ms·

At least I've never had production errors because of malformed xml. Yaml, though.. A misplaced dash and your list of a single item is suddenly two distinct item

At least I've never had production errors because of malformed xml. Yaml, though.. A misplaced dash and your list of a single item is suddenly two distinct items instead.

nikanj 3y ago
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
Groxx 3y ago
While 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.
- kaba0 3y ago
  But one of them has schema descriptions to prevent these errors as soon as possible.
  - Groxx 3y ago
    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.
    - matsemann 3y ago
      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.
  - throwawaymaths 3y ago
    > But one of them has schema descriptions JSONSchema? It's pretty standardized and well accepted.
    - NBJack 3y ago
      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).
      - meepmorp 3y ago
        XML schema is a separate spec.
    - kaba0 3y ago
      Read the title - just because YAML is a superset of JSON, doesn’t mean you can check every YAML file with JSOnSchema.
deleted 3y ago
[deleted]
EddTheSDET 3y ago
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…
- dragonwriter 3y ago
  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.
gilcot 3y ago
You're one of those few lucky whose malformed xml cause no issue.
kstrauser 3y ago
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.
- marcosdumay 3y ago
  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.
throw__away7391 3y ago
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.
KronisLV 3y ago
> At least I've never had production errors because of malformed xml. Oh hey, I had some while making https://hn-blogs.kronis.dev/ https://hn-blogs.kronis.dev/ I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousands-of-tech-blogs-now-you-can 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.

At least I've never had production errors because of malformed xml. Yaml, though.. A misplaced dash and your list of a single item is suddenly two distinct items instead.

nikanj 3y ago

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

Groxx 3y ago

While 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.

kaba0 3y ago
But one of them has schema descriptions to prevent these errors as soon as possible.
- Groxx 3y ago
  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.
  - matsemann 3y ago
    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.
- throwawaymaths 3y ago
  > But one of them has schema descriptions JSONSchema? It's pretty standardized and well accepted.
  - NBJack 3y ago
    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).
    - meepmorp 3y ago
      XML schema is a separate spec.
  - kaba0 3y ago
    Read the title - just because YAML is a superset of JSON, doesn’t mean you can check every YAML file with JSOnSchema.

deleted 3y ago

[deleted]

EddTheSDET 3y ago

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…

dragonwriter 3y ago
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.

gilcot 3y ago

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

kstrauser 3y ago

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.

marcosdumay 3y ago
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.

throw__away7391 3y ago

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.

KronisLV 3y ago

> At least I've never had production errors because of malformed xml. Oh hey, I had some while making https://hn-blogs.kronis.dev/ https://hn-blogs.kronis.dev/ I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousands-of-tech-blogs-now-you-can 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.