Re: Quoting strings of digits

--===============3362572291085944864==
Content-Type: multipart/alternative; boundary="94eb2c1464b4bab159055e8ba102"

--94eb2c1464b4bab159055e8ba102
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for that analysis. The YAML spec is somewhat different to other
specifications that I've worked with in the past, since it is, as you point
out, reticent about constraining behaviour.

On 22 November 2017 at 13:10, flyx <[email protected]> wrote:

> My answer is based on the fact that both SnakeYaml and PyYaml are YAML
> 1.1. However, the answer would not be substantially different for YAML 1.=
2
> since implicit tag resolutions introduced in YAML 1.2 are only suggestion=
s
> and not required to be supported by a conforming implementation.
>
> On 20. Nov 2017, at 02:10, Thomas Conway <[email protected]> wrote:
>
>>
>> [snip]
>>
>> Note in particular that the string value for the key 'sampleName' is a
>> sequence of digits with a leading zero, and is not quoted.
>>
>
> When we read it in to our java system (using snakeyaml), the unquoted
>> sequence of digits is turned into an integer, which means that subsequen=
t
>> steps drop the leading zero.
>>
>> I've tried reading the specification, but I can't see that it defines th=
e
>> conversion.
>>
>
> Nor does it disallow it. Unquoted scalars get the non-specific =E2=80=9E?=
=E2=80=9C whose
> resolution is not defined by the specification. This means that an
> implementation has complete freedom over how it interprets a scalar like
> =E2=80=9E08063075=E2=80=9C. Some regexes have been given in the type regi=
stry for YAML 1.1,
> including the !!int tag [1]; however, supporting them is not required and
> implicitly resolving them based on the given regexes is not either and
> actually never even suggested anywhere (although it is commonly implement=
ed
> in YAML 1.1 implementations).
>
> Is the serialisation valid?
>>
>> Is the conversion of the string of digits to an integer valid?
>>
>
> Let=E2=80=99s look up the definition of validity in the YAML 1.1 spec:
>
> To be valid, a node must have a tag which is recognized by the YAML
>> processor and its content must satisfy the constraints imposed by this t=
ag.
>>
>
> Note that the YAML specification nowhere gives any details about how
> native types must be (de)serialised to/from YAML tags =E2=80=93 with good=
 reason.
> Therefore, it is hard to tell what to base an answer to your question on.=
 I
> would say that serialising the string to an unquoted scalar is definitely
> valid, since a YAML !!str tag allows its content. Note that concerning th=
e
> serialisation, rendering a string as unquoted scalar is *always* valid
> since the definition of validity only concerns the relation between a
> node=E2=80=99s content and its tag, and if we assume that the implementat=
ion knows
> the !!str tag and chooses to render all nodes that have been given the
> !!str tag when creating them from the native object as unquoted scalars i=
f
> possible. The choice of giving the !!str tag to a native string object
> =E2=80=9E08063075=E2=80=9C (or even =E2=80=9E42=E2=80=9C or =E2=80=9Efals=
e=E2=80=9C) is not covered by the specification
> and therefore cannot be invalid.
>
> On the loading side, things are a bit different. If, for example, we
> assume that the scalar =E2=80=9E08063075=E2=80=9C is given the !!int tag =
based on the
> knowledge that it is afterwards transformed into a Java Integer, this is
> invalid since the scalar=E2=80=99s content does not satisfy the constrain=
ts imposed
> by the !!int tag [1] (i.e. the regex). However, since !!int is mentioned,
> but not defined, in the YAML 1.1 specification, you could also say that
> even in doing this, SnakeYaml does conform to the specification since
> conforming to the !!int regex is not required by the spec.
>
> On the practical side, it is a bad thing for SnakeYaml not to comply to
> the !!int regex since this harms interoperability. But you asked for
> specification conformance, and as I said, one can argue that this behavio=
r
> *is* conformant.
>
> A word of advice: SnakeYaml does allow you to specify the target type you
> want to deserialise to. If you define a POJO that contains all the fields
> which are properly typed, you can just tell SnakeYaml to load the YAML in=
to
> that POJO, and chances are that when it sees that the target type is a
> String, it will load the scalar as String no matter how its content looks=
.
> I do not know SnakeYaml internals, so I cannot guarantee that it will wor=
k,
> but I've never seen it fail.
>
> Regards,
> Felix
>
>
>  [1]: http://yaml.org/type/int.html
>
>


--=20
Thomas Conway
[email protected]
My friends, love is better than anger. Hope is better than fear. Optimism
is better than despair. So let us be loving, hopeful and optimistic. And
we'll change the world. - Jack Layton

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

<div dir=3D"ltr">Thank you for that analysis. The YAML spec is somewhat dif=
ferent to other specifications that I&#39;ve worked with in the past, since=
 it is, as you point out, reticent about constraining behaviour.</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 22 November 2017 at=
 13:10, flyx <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">My answer is based on the fact that both SnakeYaml and PyYaml are YA=
ML 1.1. However, the answer would not be substantially different for YAML 1=
.2 since implicit tag resolutions introduced in YAML 1.2 are only suggestio=
ns and not required to be supported by a conforming implementation.<br>
<br>
On 20. Nov 2017, at 02:10, Thomas Conway &lt;<a href=3D"mailto:drtomc@gmail=
.com" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
[snip]<span class=3D""><br>
<br>
Note in particular that the string value for the key &#39;sampleName&#39; i=
s a sequence of digits with a leading zero, and is not quoted.<br>
</span></blockquote><span class=3D"">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
When we read it in to our java system (using snakeyaml), the unquoted seque=
nce of digits is turned into an integer, which means that subsequent steps =
drop the leading zero.<br>
<br>
I&#39;ve tried reading the specification, but I can&#39;t see that it defin=
es the conversion.<br>
</blockquote>
<br></span>
Nor does it disallow it. Unquoted scalars get the non-specific =E2=80=9E?=
=E2=80=9C whose resolution is not defined by the specification. This means =
that an implementation has complete freedom over how it interprets a scalar=
 like =E2=80=9E08063075=E2=80=9C. Some regexes have been given in the type =
registry for YAML 1.1, including the !!int tag [1]; however, supporting the=
m is not required and implicitly resolving them based on the given regexes =
is not either and actually never even suggested anywhere (although it is co=
mmonly implemented in YAML 1.1 implementations).<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Is the serialisation valid?<br>
<br>
Is the conversion of the string of digits to an integer valid?<br>
</blockquote>
<br></span>
Let=E2=80=99s look up the definition of validity in the YAML 1.1 spec:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
To be valid, a node must have a tag which is recognized by the YAML process=
or and its content must satisfy the constraints imposed by this tag.<br>
</blockquote>
<br>
Note that the YAML specification nowhere gives any details about how native=
 types must be (de)serialised to/from YAML tags =E2=80=93 with good reason.=
 Therefore, it is hard to tell what to base an answer to your question on. =
I would say that serialising the string to an unquoted scalar is definitely=
 valid, since a YAML !!str tag allows its content. Note that concerning the=
 serialisation, rendering a string as unquoted scalar is *always* valid sin=
ce the definition of validity only concerns the relation between a node=E2=
=80=99s content and its tag, and if we assume that the implementation knows=
 the !!str tag and chooses to render all nodes that have been given the !!s=
tr tag when creating them from the native object as unquoted scalars if pos=
sible. The choice of giving the !!str tag to a native string object =E2=80=
=9E08063075=E2=80=9C (or even =E2=80=9E42=E2=80=9C or =E2=80=9Efalse=E2=80=
=9C) is not covered by the specification and therefore cannot be invalid.<b=
r>
<br>
On the loading side, things are a bit different. If, for example, we assume=
 that the scalar =E2=80=9E08063075=E2=80=9C is given the !!int tag based on=
 the knowledge that it is afterwards transformed into a Java Integer, this =
is invalid since the scalar=E2=80=99s content does not satisfy the constrai=
nts imposed by the !!int tag [1] (i.e. the regex). However, since !!int is =
mentioned, but not defined, in the YAML 1.1 specification, you could also s=
ay that even in doing this, SnakeYaml does conform to the specification sin=
ce conforming to the !!int regex is not required by the spec.<br>
<br>
On the practical side, it is a bad thing for SnakeYaml not to comply to the=
 !!int regex since this harms interoperability. But you asked for specifica=
tion conformance, and as I said, one can argue that this behavior *is* conf=
ormant.<br>
<br>
A word of advice: SnakeYaml does allow you to specify the target type you w=
ant to deserialise to. If you define a POJO that contains all the fields wh=
ich are properly typed, you can just tell SnakeYaml to load the YAML into t=
hat POJO, and chances are that when it sees that the target type is a Strin=
g, it will load the scalar as String no matter how its content looks. I do =
not know SnakeYaml internals, so I cannot guarantee that it will work, but =
I&#39;ve never seen it fail.<br>
<br>
Regards,<br>
Felix<br>
<br>
<br>
=C2=A0[1]: <a href=3D"http://yaml.org/type/int.html" rel=3D"noreferrer" tar=
get=3D"_blank">http://yaml.org/type/int.html</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Thomas Conway<br><a=
 href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br=
>My friends, love is better than anger. Hope is better than fear. Optimism =
is better than despair. So let us be loving, hopeful and optimistic. And we=
&#39;ll change the world. - Jack Layton</div>
</div>

--94eb2c1464b4bab159055e8ba102--


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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============3362572291085944864==
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

--===============3362572291085944864==--