Re: yaml-cpp and YAML 1.2

Oren Ben-Kiki <[email protected]> Fri, 4 Mar 2016 14:00:25 +0200
Newsgroups gmane.text.yaml.general
Message-ID <CADJiDhvkvJALth=cf2YW-RS=jemN85KfrasSuVgBxDK+vtAzzQ@mail.gmail.com>
The main change from 11 to 1.2 was JSON compatibility and very few other
very minor syntax simplifications. All the schema flexibility , the layered
processing model, and the data models were there from from YAML1.0 - this
is the essence of YAML, IMO, even more than the syntax.

As for the specific recommended schemas, we made more explicit what was
inherent in the system. We put 3 schemas directly in the spec, because
these schemas are "important", not because they are "all encompassing". The
failsafe schema allows you to process _any_ YAML document, regardless of
who generated it. That is "good". The JSON-compatible schema is important
for obvious reasons. The "Core" schema is intended to be a, well, "core"
for more specific schemas that step beyond JSON compatibility.

As Ingy correctly pointed out, we made a big mistake by not updating the
type repository to match. Still, the fact the above 3 schemas are directly
in the spec serves to say (1) "there is more then one", and at the same
time (2) "here is how to maximize interoperability".

Obviously, different applications use different schemas. Consider the
schema used by Ruby's yaml module (which I use a lot). It supports
ruby-specific tags that are obviously not supported by SnakeYAML, and
vice-versa. There's no expectation that I'll dump my Ruby data into YAML
and load it into some random Java application and that my Ruby classes will
just magically migrate as a result.

Instead what we can do is run a Java YAML composer, which will give me a
(complete or partial) representation as abstract YAML nodes - basically,
what yaml-cpp does. Then I can load YAML generated by anyone at all, and do
_some_ stuff with it. Obviously not as much stuff as the Ruby application
that generated this YAML. And that's OK, and it demonstrates why YAML tools
that do not go "all the way" play an important role in the ecosystem.

This is why I talked about "controlling" interoperability, which is doable,
rather than "ensuring" it, which is not possible in general.

If SnakeYAML correctly parses all the examples, and in general follows the
1.2 spec, syntax-wise, and doesn't violate the 1.* specs,
information-model-wise (e.g., it must not use keys order, it must ignore
the node style when doing tag resolution, etc.), then as far as I'm
concerned, it is 1.2 compliant.

Note that the examples were not meant to be a comprehensive set of unit
tests for testing compliance. So I don't have a set of "YAML certification
tests" to point you at. Sorry :-(

I did set up ypaste (which is up and running again) to serve as a dynamic
reference in case there are edge cases one wants to investigate. But that
only covers the _syntax_. It won't help you with testing the tag resolution
rules.

Creating a YAML certification test suite is an interesting project. It
would be great if someone picked that one up. I don't have the time :-(

I greatly appreciate you putting the time and effort into SnakeYAML and
updating it to YAML1.2. The more implementations the merrier, and the more
they stick with the spec, the better.

Thanks,

Oren.

On Fri, Mar 4, 2016 at 12:44 PM, Andrey Somov <[email protected]>
wrote:

> Dear Oren,
> thank you for the time and patience.
>
> 1. I am sorry, I messed the terminology. I was saying "parser", but was
> meaning "processor". I have already fixed the terminology on SnakeYAML's
> page to avoid confusion. SnakeYAML is a complete processor, not merely a
> parser.
> But PyYAML still says "PyYAML - The next generation YAML parser and
> emitter for Python.", while in fact it is also composer and constructor.
> Which means PyYAML is a processor.
>
> 2. I completely misunderstood the recommended schemas. I must admit I
> still do not understand them. Especially I do not get what is changed in
> 1.2 from 1.1. Flexible tag resolution was already there in 1.1.
>
> 3. At the moment SnakeYAML implements 1.1 and there is no single bug
> related to the spec compliance.
> Users ask to implement 1.2. If SnakeYAML can parse all the examples of
> YAML 1.2 without failures, is it  1.2 compliant ?
> If yes, then why the spec contains the schemas definitions ?
> What is the indication that SnakeYAML processor implements recommended
> schemas as it should ?
>
> Cheers,
> Andrey
>

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

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