Strings that parse as floats: is there a canonical serialization for strings?

--===============5898023146637938896==
Content-Type: multipart/alternative; boundary="000000000000b56af6059625907d"

--000000000000b56af6059625907d
Content-Type: text/plain; charset="UTF-8"

The `[+-]` of a float is optional in YAML 1.2's JSON schema tag resolution
https://yaml.org/spec/1.2/spec.html#id2804356 and in YAML 1.2s core schema
tag resolution https://yaml.org/spec/1.2/spec.html#id2805071. In YAML 1.1
it appeared to be required.

This means that YAML 1.2 parses certain unquoted hex strings (git commits,
hashes, etc.) as floats, for example: 504e199 would be parsed as a float
instead of a string. This might be surprising if the YAML serialization
library is not explicitly quoting strings or tagging them.

I feel like this may be a weakness in the YAML 1.2 spec under 10.1.1.3
Generic String https://yaml.org/spec/1.2/spec.html#id2802842 where it
describes the Canonical Form of strings glibly as "The obvious." I am not
very familiar with how the spec works, but it seems to me that if there is
no clearly described canonical form for strings, serialization tools are
liable to produce output (like the example above) which does not produce
accurate round-trip (reversible) serialization/deserialization.

Is this an area which could be improved in the spec, so that YAML
serializers are directed to serialize strings in a way which guarantees
that it will deserialize back to the same thing? Barring that, is there any
general advice for library authors or bug reporters about how serialization
of such YAML strings should be performed, such as always quoting strings?

Thanks!
Shannon

--000000000000b56af6059625907d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The `[+-]` of a float is optional in YAML 1.2&#39;s JSON s=
chema tag resolution <a href=3D"https://yaml.org/spec/1.2/spec.html#id28043=
56">https://yaml.org/spec/1.2/spec.html#id2804356</a> and in YAML 1.2s core=
 schema tag resolution <a href=3D"https://yaml.org/spec/1.2/spec.html#id280=
5071">https://yaml.org/spec/1.2/spec.html#id2805071</a>. In YAML 1.1 it app=
eared to be required.<br><br>This means that YAML 1.2 parses certain unquot=
ed hex strings (git commits, hashes, etc.) as floats, for example: 504e199 =
would be parsed as a float instead of a string. This might be surprising if=
 the YAML serialization library is not explicitly quoting strings or taggin=
g them.<br><br>I feel like this may be a weakness in the YAML 1.2 spec unde=
r 10.1.1.3 Generic String <a href=3D"https://yaml.org/spec/1.2/spec.html#id=
2802842">https://yaml.org/spec/1.2/spec.html#id2802842</a> where it describ=
es the Canonical Form of strings glibly as &quot;The obvious.&quot; I am no=
t very familiar with how the spec works, but it seems to me that if there i=
s no clearly described canonical form for strings, serialization tools are =
liable to produce output (like the example above) which does not produce ac=
curate round-trip (reversible) serialization/deserialization.<br><div><br><=
/div><div>Is this an area which could be improved in the spec, so that YAML=
 serializers are directed to serialize strings in a way which guarantees th=
at it will deserialize back to the same thing? Barring that, is there any g=
eneral advice for library authors or bug reporters about how serialization =
of such YAML strings should be performed, such as always quoting strings?</=
div><div><br></div><div>Thanks!</div><div>Shannon</div></div>

--000000000000b56af6059625907d--


--===============5898023146637938896==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5898023146637938896==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core

--===============5898023146637938896==--