Re: yaml-cpp and YAML 1.2

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


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

> On Fri, Mar 4, 2016 at 10:17 AM, Andrey Somov <[email protected]>
> wrote:
>
>> I am also confused now.
>>
>
> Let's try...
>
>
>> (I think it better to clarify what is "tag resolution schema" outside of
>> this thread, because it is important for everyone, not only yaml-cpp.)
>>
>
> It is spelled pretty clearly in the spec. Associate a tag with each node,
> based only on the "allowed" data (you can't cheat and use, for example, key
> order etc.).
>
>
>> 1. At the moment PyYAML and SnakeYAML give users a possibility to use a
>> custom Resolver for the tag resolution.
>>
>
> Yes. Good.
>
>
>> Does it mean that they are YAML 1.2 compliant ?
>>
>
> Depends on how they handle % directives and blocks and scalars and so on.
> If they are doing it by the spec, then yes.
>
> But it seems you are missing the point. Processing YAML is a multi-stage
> thing. It is OK for a "valid legal compliant YAML" tool to implement only
> _some_ of these stages. "Parsing" is just the first stage.
>
>
>> - the schema must be still implemented by users (regular expressions must
>> match the YAML 1.2 expectations)
>>
>
> That's one way to do tag resolution for scalars. In general tag resolution
> also applies to non-scalar nodes. But applying a regexp to scalars is a
> popular, effective method.
>
>
>> - if users of the same parser want to exchange documents they have to
>> send _code_ , otherwise the same configurations will be parsed differently.
>>
>
> Actually, a list of [ regexp, tag ] is hardly "code". It is "data", and
> can be wrapped in some schema language in a completely platform independent
> way.
>
> Yes, the tags need something to map into in your native code - if my
> Haskell "Foo" type has code with no equivalent in your Julia code, then
> there is only so much you can do with a node with the "Foo" tag, right?
>
> This is why the spec goes at length at defining the data model*s* -
> *plural*. You can process the YAML document at different levels,
> "depending". You can even apply different schemas to the same document and
> that's *also* fine.
>
> Which means that tools that work at different levels are all useful. E.g.,
> a YAML pretty printer cares *nothing* about schemas. And it is useful.
>
>
>> The spec says that 3 schemas should be implemented as an option which
>> would mean that a user may give a YAML file to another user and simply say
>> "please parse with this schema" (all the required code is already inside
>> the parser).
>>
>
> "Should". "Recommended". Yes.
>
>
>> 2.
>> >Providing a YAML::Node load_complete_representation("foo.yaml",
>> tag_resolution_schema) would be nice of course ;-)
>>
>
> Again, this is *if* the tool chooses to go up one level in the processing
> pipeline. There is no requirement that it does. YamlReference certainly
> doesn't! It is a reference *parser*. Not a composer, not a constructor.
>
>
>> >But this can be done as a layer on top of yaml-cpp and that's perfectly
>> fine.
>> Well, the whole point for me (when I read the spec) that it must be in
>> the parser (how it is done in js-yaml).
>>
>
> It is not done in the "parser". What a "parser" is is well-defined in the
> spec. It takes text, emits a stream of events. It doesn't construct a graph
> in-memory. It doesn't do tag resolution. It does not construct native
> application data structures.
>
> It is done in a "YAML processor" which happens to include both a parser
> and a composer and a constructor. Again, it is OK to provide just the
> parser. That's what YamlReference does. It is OK to provide just a
> partial-representation composer. That's what yaml-cpp does. It is OK to
> provide a full end-to-end processor returning native data. That's what, for
> example, the Ruby's yaml module does. That's all OK.
>
>
>> What is a layer on top of yaml-cpp ?  What is the layer on top of PyYAML
>> or js-yaml ?
>> Where can read about layers ?
>>
>
> Chapter 3 of the spec.
>
> A layer on top of yaml-cpp would be a hypothetical yaml-cpp-plus-schema
> library that takes the YAML::Node from yaml-cpp and go over all the nodes
> and ensure each one is associated with a tag based on regexps and other
> allowed methods for tag resolution.
>
> A layer on top of _that_ would be a hypothetical
> yaml-cpp-plus-schema-plus-magic library that takes the nodes (each one with
> a tag) and magically converts them to arbitrary C++ data types. Given C++
> has no reflection capabilities, this would be extremely difficult to do.
> You'd probably only be able to convert to specific C++ data types that
> implemented some user-provided hooks and so on. In a language with managed
> run-time (Java included) you can actually construct "any" arbitrary data
> type by simply associating the right tag with each node.
>
> There is absolutely no requirement from yaml-cpp to provide these
> additional two layers of functionality. In fact yaml-cpp already goes
> beyond what YamlReference does, which is the bare minimum - just converting
> the text to a stream of "events" (tokens, call them what you will). It is
> definitely a valid YAML1.2 parser, ignoring bugs :-) It doesn't construct
> nodes. It doesn't do tag resolution. It doesn't construct native data
> structures. It is a YAML1.2 *parser*.
>
> You might say this is much nit-picking. But being *precise* about these
> things in YAML came from bitter lessons learned in XML, where there is no
> such precision, leading to global misery all around. So YAML defines the
> levels of processing and what the data model in each stage and so on - to
> allow for great freedom of implementation and *control* over
> interoperability. Nothing on earth will *ensure* interoperability between
> the data of an arbitrary Haskell program and the data of another arbitrary
> Julia program. "Control" is all we can achieve.
>
> Oren.
>

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