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