Re: yaml-cpp and YAML 1.2

Ingy dot Net <[email protected]> Fri, 4 Mar 2016 12:45:39 -0800
Newsgroups gmane.text.yaml.general
Message-ID <CAHJtQJ6G8PK2hHTePHXy1eZTYaP=oNew3Cw9+W+U3inDira59Q@mail.gmail.com>
Andrey,

I'll make sure that your test work gets incorporated into the dev kit test
suite.

Cheers, Ingy

On Fri, Mar 4, 2016 at 8:51 AM, Oren Ben-Kiki <[email protected]> wrote:

> 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