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
orfalse
.
Does this mean all the alternate forms in 1.1 should be interpreted in 1.2 as strings (rather than boolean values) in deserialization?
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 ;-).You've asked two different questions, so I'll answer them in turn:
No, the scalars
on
andoff
should be interpreted as strings (tag:yaml.org,2002:str
).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:
And indeed, when using the JSON schema, only the scalars
true
andfalse
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
, andFALSE
are all booleans.