Are “on” and “off” supposed to be interpreted as t

问题:

YAML 1.1 says

Canonical:

y|n

Regexp:

y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF

YAML 1.2 says

Definition:

Represents a true/false value. In languages without a native Boolean type (such as C), is usually bound to a native integer type, using one for true and zero for false.

Canonical Form:

Either true or false.

Does this mean all the alternate forms in 1.1 should be interpreted in 1.2 as strings (rather than boolean values) in deserialization?

回答1:

You've asked two different questions, so I'll answer them in turn:

1. Are “on” and “off” supposed to be interpreted as true or false in YAML 1.2?

   No, the scalars on and off should be interpreted as strings (tag:yaml.org,2002:str).

2. Does this mean all the alternate forms in 1.1 should be interpreted in 1.2 as strings (rather than boolean values) in deserialization?

   Some of them, yes, but others only sometimes.

   It's important to note that the portion of the YAML 1.2 spec you quoted is from the section 10.2 JSON Schema. Per its introduction:

   The JSON schema is the lowest common denominator of most modern computer languages, and allows parsing JSON files. A YAML processor should therefore support this schema, at least as an option. It is also strongly recommended that other schemas should be based on it.

   And indeed, when using the JSON schema, only the scalars true and false are implicit boolean (tag:yaml.org,2002:bool) values.

   However, the spec recommends that YAML parsers use the Core schema, not the JSON schema, by default. The Core schema is "an extension of the JSON schema, allowing for more human-readable presentation of the same types."

   When using the Core schema, the scalars true, True, TRUE, false, False, and FALSE are all booleans.

回答2:

In the YAML 1.2 specification they are no longer mentioned, but I don't recall it says anywhere why they were removed and that they are. However in practical situations these extra "booleans" caused confusion, and that is guess why they probably were removed from the spec.

In ruamel.yaml , my upgrade of PyYAML (which is mostly YAML 1.1 and supports Yes/No/On/Off ) I only represent these values as booleans if the YAML file is specified to be YAML 1.1 (using a loading parameter, or a starting line %YAML 1.1. And these scalars are then interpreted as strings. I haven't heard anyone complain yet, so I assume I am doing the right (i.e. what everyone expects based on the 1.2 spec) thing ;-).