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 YAML 1.1 the bool type is defined as following: A Boolean represents a true/false value. Booleans are formatted as English words (“true”/“false”, “yes”/“no” or “on”/“off”) for readability and may be abbreviated as a single character “y”/“n” or “Y”/“N”.
The following basic data types are supported by YAML : Boolean.
A Boolean represents a true/false value. Booleans are formatted as English words (“ true ”/“ false ”, “ yes ”/“ no ” or “ on ”/“ off ”) for readability and may be abbreviated as a single character “ y ”/“ n ” or “ Y ”/“ N ”.
YAML indicates boolean values with the keywords True, On and Yes for true. False is indicated with False, Off, or No.
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:
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
).
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With