untrue statement on https://hitchdev.com/strictyaml/why/implicit-typing-removed/

[qyanu]

Hi there hitchdev!

I found no better place to send in the following pedantry, so here it goes:

As of today (2023-02-25), the webpage https://hitchdev.com/strictyaml/why/implicit-typing-removed/ demonstrates the "The Norway Problem", where the YAML specification directs the parsing of values (without surrounding quotes) like GB, IE, FR, and DE into strings, but to the surprise of many users mandates parsing the value (again without surrounding quotes) NO, the two letter code for Norway, as boolean false.
Further down, also the following statement is made:

The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification.

Where the last part of the sentence is a hyperlink to https://yaml.org/spec/1.2.2/

However,

1. for the 1.2.2 specification, i could not find the paragraph where the string "NO" is a valid format of the boolean true.

2. The 1.2.2 changelog of the specification (link here: https://yaml.org/spec/1.2.2/ext/changes/ ) explicitely lists the change, that starting with the revision 1.2.0 (2009-07-21):

   Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings.

Notwithstanding all the other aspects of YAML that justify StrictYaml to refuse to parse certain features of YAML, this particular statement on the homepage, that NO (without quotes) shall be parsed into a boolean false when pedanticly following the 1.2.2 revision of the YAML-Spec is not true.

I would suggest that

• The last part of the above quoted sentence on the homepage is changed to "YAML 1.1 specification";
• the hyperlink points to the YAML 1.1.0 revision;
• a note is added to the sentence that this particular problem is not present in the YAML 1.2 specification any longer [*].

best regards,

Max

[*] which means that some valid yaml documents are parsed differently with a yaml-1.1 parser and a yaml-1.2 parser, and this demonstrates another aspect of the YAML spec to be on the lookout for.