3 ms·

I find this claim misleading. First, the article starts off by picking examples from YAML 1.1. But the YAML 1.2 spec officially made YAML a superset of JSON. I

I find this claim misleading. First, the article starts off by picking examples from YAML 1.1. But the YAML 1.2 spec officially made YAML a superset of JSON. It was published in 2009, more than a decade ago. The article later does mention YAML 1.2, but it claims that it isn't compatible with JSON either because YAML 1.2 documents are required to have a %YAML directive stating its version. Except, that's not what the spec says. The actual spec states that documents without a %YAML directive should be treated as YAML 1.2 [1]. [1]: https://yaml.org/spec/1.2.1/#id2781553 https://yaml.org/spec/1.2.1/#id2781553

jmillikin 4y ago
That part of the YAML 1.2 spec is in conflict with reality, though. The base of YAML 1.1 documents is large enough that a backwards-incompatible change to default behavior is for practical purposes impossible. YAML 1.1 was released in 2005, and 1.2 in 2009 -- only four years later. But here we are, in 2022, and YAML 1.1 is still the default (in many cases, only) version supported. That's why the "Norway problem" persists -- it's not possible for the parser to know whether the author of an un-versioned YAML document containing "a: no" intended it to parse the same as {"a": false} or {"a": "no"}. Python (PyYAML) doesn't support 1.2 yet: https://github.com/yaml/pyyaml/issues/116 https://github.com/yaml/pyyaml/issues/116 Ruby (Psych) ditto -- I can't even find a tracking issue to enable it. Go (go-yaml) is a mixture of YAML 1.1 and 1.2, depending on the author's preferences. Also, as a rough guideline, you can't have a backwards-incompatible revision of a versioned spec declare that it's the new default version, because that breaks all existing users.