Re: yaml-cpp and YAML 1.2

Cool stuff.

The loader implementation guide is a good idea. An explicit resolver stage
(picking which native type to construct, tag resolution, etc.) may be
useful between the deserializer and the constructor stages.



On Fri, Mar 4, 2016 at 6:44 PM, Ingy dot Net <[email protected]> wrote:

> Very well stated, Oren. A couple points of possible current interest:
>
>    - I have recently started what I call the yaml-dev-kit
>    <https://github.com/ingydotnet/yaml-dev-kit#readme>
>    - See YAML Loader Guide
>    <https://github.com/ingydotnet/yaml-dev-kit/blob/guide/yaml-loader-guide.pod#readme>
>    - https://github.com/ingydotnet/yaml-pegex-pm/ is a new project
>    currently using the dev kit for tests
>    - Also https://github.com/flyx/NimYAML
>    - Catch flyx, ingy (always) and obk, andrey-snakeyaml (sometimes) on
>    irc.freenode.net#yaml to discuss
>
>
> On Fri, Mar 4, 2016 at 4:00 AM, Oren Ben-Kiki <[email protected]> wrote:
>
>> 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
>>
>>
>

------------------------------------------------------------------------------

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