You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The YAML 1.1 spec allows to use booleans as keys of maps and performs auto-conversion, which most of the time is not what you want. The YAML 1.2 spec actually changes this and reduces the number of strings that can be interpreted as booleans.
I have just encountered this with one of our specs, using a construct like this:
Coord:
description: A 3D coordinatetype: objectrequired:
- x
- yproperties:
system:
description: The coordinate systemtype: stringx:
description: The X coordinatetype: numbery:
description: The Y coordinatetype: numberz:
description: The Z coordinatetype: numberaccuracy:
description: The accuracy of the coordinatetype: number
It happened because we are performing some processing using go-yaml and they implement YAML spec 1.1: go-yaml/yaml#214
The y parameter in the previous sample is actually interpreted by go-yaml as a true value, instead of the string "y".
Although speccy itself properly handles this case, I think it would make sense to warn users that they are using an error-prone construct.
The text was updated successfully, but these errors were encountered:
Yeah I think this one can be closed, seeing as OpenAPI is telling users to use YAML 1.2 it's not up to Speccy to worry about it. @djtarazona could you close this one?
The YAML 1.1 spec allows to use booleans as keys of maps and performs auto-conversion, which most of the time is not what you want. The YAML 1.2 spec actually changes this and reduces the number of strings that can be interpreted as booleans.
I have just encountered this with one of our specs, using a construct like this:
It happened because we are performing some processing using go-yaml and they implement YAML spec 1.1:
go-yaml/yaml#214
The
y
parameter in the previous sample is actually interpreted by go-yaml as atrue
value, instead of the string"y"
.Although speccy itself properly handles this case, I think it would make sense to warn users that they are using an error-prone construct.
The text was updated successfully, but these errors were encountered: