Resolve evaluates node 'y' to true. Is this always required ?

[arjunbhandage]

There is map created to resolve values which resolves y as below to true:
{true, yaml_BOOL_TAG, []string{"y", "Y", "yes", "Yes", "YES"}},

If the value of node is 'y' should it be resolved to 'true' always ?
I faced issue while generating go code from openAPI yaml --> oapi-codegen/oapi-codegen#362

Not sure if it is bug or I should never use the tags from the resolveMapList ?

yaml/resolve.go

Line 37 in 7649d45

{true, yaml_BOOL_TAG, []string{"y", "Y", "yes", "Yes", "YES"}},

[perlpunk]

In YAML 1.1, scalars like y and Y are resolved as booleans. I guess go-yaml implements YAML 1.1.

OpenAPI however documents this:
https://swagger.io/specification/#format

• Tags MUST be limited to those allowed by the JSON Schema ruleset.
• Keys used in YAML maps MUST be limited to a scalar string, as defined by the YAML Failsafe schema ruleset.

If go-yaml wants to implement the YAML 1.2 schemas, here is official test data:
https://github.com/perlpunk/yaml-test-schema

Note that the YAML JSON schema definition is a bit ambiguous in the YAML spec. Strictly speaking, all strings not being booleans or numbers would have to be quoted. The OpenAPI documentation is quite unclear regarding that.

[arjunbhandage]

Thank you very much for the clarification @perlpunk. Quoting around the strings solved the issue for me.

[arjunbhandage]

I see in the compatibility section that go-yaml supports YAML 1.2 and 1.1
And according to YAML spec 1.2 schema, y is not interpreted as bool, where as in 1.1 y is interpreted as bool.
https://yaml.org/spec/1.2/spec.html#id2804923
I think this is a bug in go-yaml.

[niemeyer]

We support a useful mix of the two: v2 handles them as booleans, while v3 tries to move us forward by only considering them as bool if you explicitly attempt to unmarshal the value onto a boolean.