Re: YAML spec inconsistencies + Question on marshalling

Ingy dot Net <[email protected]> Sun, 4 Feb 2018 19:33:10 -0700
Newsgroups gmane.text.yaml.general
Message-ID <CAHJtQJ7xHKLpAf+iLAPhmd78QXP0M5ADqUeHnpVehRf2_mW1zg@mail.gmail.com>
--===============6586057617170486670==
Content-Type: multipart/alternative; boundary="001a113ba57a17926505646de288"

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

Hi Eemeli,

You might be interested in these repositories:

   - https://github.com/yaml/yaml-spec
   - https://github.com/yaml/yaml-test-suite

I mention these primarily because that is a better place to bring these
concerns up as issues (and possibly pull requests).

I look forward to discussing these as github issues.

Cheers, Ingy

On Wed, Jan 31, 2018 at 6:19 PM, Eemeli Aro <[email protected]> wrote:

> I think there's also a mistake in example 8.2, where the last folded
> value is parsed to be "\t=C2=B7detected\n", while it should be
> "\t\ndetected\n" -- the tab prefix means that the line is more folded,
> i.e. an s-nb-spaced-text(n) production, and therefore its subsequent
> newline should not be folded into a space. Admittedly it's a bit weird
> to have a first line in a block be "more folded", but I'm pretty sure
> that's what the spec maps it to.
>
> On 31 January 2018 at 21:53, Eemeli Aro <[email protected]> wrote:
> > Hi all,
> >
> > I'm working on a new JavaScript YAML 1.2 library, and while testing my
> > code against the examples given in the spec, I've come across a couple
> > of inconsistencies. I trust this might be a good place to ask about
> > them?
> >
> > When a non-strip block scalar appears as the last entry in a file that
> > is not terminated by a newline, should the value of that scalar still
> > include a terminating newline? In the spec, example 6.4 appears to do
> > so, while example 8.21 does not. My own preference here would be to
> > always include a newline, as otherwise it's very easy to alter the
> > value while processing, especially when reordering documents in a
> > stream.
> >
> > Is there a mistake in the parsing of the "keep" value of example 8.5?
> > Specifically, should its value be "# text\n\n" rather than "# text\n"?
> > It's followed by dedented comment lines, and the second newline is
> > highlighted in the source as being a part of the l-keep-empty(n)
> > production. The following example 8.6 similarly highlights the (only)
> > line of its "keep" value with the same production, but shows that
> > newline to be a part of the resulting value.
> >
> > On a different note, would anyone have good pointers for
> > implementations of marshalling YAML scalars? For instance, when a map
> > includes multiple different numerical values, and some of them are (or
> > should be) stored as hexadecimal while others as decimal, how do other
> > implementations control this and/or guarantee that a load/modify/dump
> > cycle won't normalise all of these numbers to a single style of
> > representation?
> >
> > My code so far is at https://github.com/eemeli/yaml and
> > https://github.com/eemeli/raw-yaml; only the latter lower-level
> > interface is published so far on npm.
> >
> > eemeli
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>

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

<div dir=3D"ltr">Hi Eemeli,<div><br></div><div>You might be interested in t=
hese repositories:</div><div><ul><li><a href=3D"https://github.com/yaml/yam=
l-spec">https://github.com/yaml/yaml-spec</a><br></li><li><a href=3D"https:=
//github.com/yaml/yaml-test-suite">https://github.com/yaml/yaml-test-suite<=
/a></li></ul><div>I mention these primarily because that is a better place =
to bring these concerns up as issues (and possibly pull requests).</div></d=
iv><div><br></div><div>I look forward to discussing these as github issues.=
</div><div><br></div><div>Cheers, Ingy</div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Wed, Jan 31, 2018 at 6:19 PM, Eemeli Ar=
o <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I think there&#39;s also a mistake in example 8.2, where the last folded<b=
r>
value is parsed to be &quot;\t=C2=B7detected\n&quot;, while it should be<br=
>
&quot;\t\ndetected\n&quot; -- the tab prefix means that the line is more fo=
lded,<br>
i.e. an s-nb-spaced-text(n) production, and therefore its subsequent<br>
newline should not be folded into a space. Admittedly it&#39;s a bit weird<=
br>
to have a first line in a block be &quot;more folded&quot;, but I&#39;m pre=
tty sure<br>
that&#39;s what the spec maps it to.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 31 January 2018 at 21:53, Eemeli Aro &lt;<a href=3D"mailto:eemeli@gmail.=
com">[email protected]</a>&gt; wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I&#39;m working on a new JavaScript YAML 1.2 library, and while testin=
g my<br>
&gt; code against the examples given in the spec, I&#39;ve come across a co=
uple<br>
&gt; of inconsistencies. I trust this might be a good place to ask about<br=
>
&gt; them?<br>
&gt;<br>
&gt; When a non-strip block scalar appears as the last entry in a file that=
<br>
&gt; is not terminated by a newline, should the value of that scalar still<=
br>
&gt; include a terminating newline? In the spec, example 6.4 appears to do<=
br>
&gt; so, while example 8.21 does not. My own preference here would be to<br=
>
&gt; always include a newline, as otherwise it&#39;s very easy to alter the=
<br>
&gt; value while processing, especially when reordering documents in a<br>
&gt; stream.<br>
&gt;<br>
&gt; Is there a mistake in the parsing of the &quot;keep&quot; value of exa=
mple 8.5?<br>
&gt; Specifically, should its value be &quot;# text\n\n&quot; rather than &=
quot;# text\n&quot;?<br>
&gt; It&#39;s followed by dedented comment lines, and the second newline is=
<br>
&gt; highlighted in the source as being a part of the l-keep-empty(n)<br>
&gt; production. The following example 8.6 similarly highlights the (only)<=
br>
&gt; line of its &quot;keep&quot; value with the same production, but shows=
 that<br>
&gt; newline to be a part of the resulting value.<br>
&gt;<br>
&gt; On a different note, would anyone have good pointers for<br>
&gt; implementations of marshalling YAML scalars? For instance, when a map<=
br>
&gt; includes multiple different numerical values, and some of them are (or=
<br>
&gt; should be) stored as hexadecimal while others as decimal, how do other=
<br>
&gt; implementations control this and/or guarantee that a load/modify/dump<=
br>
&gt; cycle won&#39;t normalise all of these numbers to a single style of<br=
>
&gt; representation?<br>
&gt;<br>
&gt; My code so far is at <a href=3D"https://github.com/eemeli/yaml" rel=3D=
"noreferrer" target=3D"_blank">https://github.com/eemeli/yaml</a> and<br>
&gt; <a href=3D"https://github.com/eemeli/raw-yaml" rel=3D"noreferrer" targ=
et=3D"_blank">https://github.com/eemeli/raw-<wbr>yaml</a>; only the latter =
lower-level<br>
&gt; interface is published so far on npm.<br>
&gt;<br>
&gt; eemeli<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----=
-------------<br>
Check out the vibrant tech community on one of the world&#39;s most<br>
engaging tech sites, Slashdot.org! <a href=3D"http://sdm.link/slashdot" rel=
=3D"noreferrer" target=3D"_blank">http://sdm.link/slashdot</a><br>
______________________________<wbr>_________________<br>
Yaml-core mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]=
rge.<wbr>net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/yaml-core" rel=3D"n=
oreferrer" target=3D"_blank">https://lists.sourceforge.net/<wbr>lists/listi=
nfo/yaml-core</a><br>
</div></div></blockquote></div><br></div>

--001a113ba57a17926505646de288--


--===============6586057617170486670==
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
--===============6586057617170486670==
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

--===============6586057617170486670==--