Re: yaml-cpp and YAML 1.2

Oren Ben-Kiki <[email protected]> Fri, 4 Mar 2016 11:29:28 +0200
Newsgroups gmane.text.yaml.general
Message-ID <CADJiDhvgwFjPyB+2AuWNOSH9enJ_ELproKOoWEi72GBuR8uTEw@mail.gmail.com>
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