RE: [Yaml-core] yaml++ (@: *data #inheritance)

[Oren Ben-K. <or...@ri...>]

Clark C . Evans wrote:
>  //: # list of options
>   - &true !bool 1
>   - &false !bool 0
>   - &mabye ~
>  selection: *true
> 
> Certainly, I could do it using a "list" key instead
> of using //, however, the // signifies to a YAML++ 
> process that the data contained is a comment and 
> will not generally be used by the application.  At 
> lower levels, our YAML path expression may have options
> to skip such keys in recursive queries, etc.  Or an
> YAML++ aware editor may show the commented areas 
> as collapsed or in grey or some other color indicating
> that they are "comments".

I was toying with the idea that any key starting with '// ' (note the space)
would be a comment key. This way one could easily do:

options:
   // one: foo
   two: bar
   // three: baz

Thoughts?

> With this example in mind, I'd like to propose another "special"
> key used for what is called "data inheritance" in XML circles.
> Since data inheritance is a common application level requirement,
> this special key can be valueable.

I've used "data inheritance" heavily in data formats (this was before the
days of XML). It is a great notion, but does require application support.
Note that it only applies to maps. I'm not certain about using '@' for it. I
think '^' would be more intuitive.

While I think such a key is a great idea, I have mixed feelings about
placing it in the core spec. I guess that there's no harm in including it...

> Combined, the \\ comment and @ inheritance special keys can
> be used to build "template" data values.

That's exactly what we did in my old application... With different notation,
of course.

> So, I was thinking about calling YAML plus full support for the
> semantics of the special keys as YAML++.  Yes?

No. There is but one YAML. Each application decides on the schema it
supports. If this schema supports //, ^, binary data and dates, fine. If
not, also fine.

I'd encourage generic tools to support as much of the core spec as possible,
but most of the relevant stuff (comments, inheritance, types) can (and
should) be implemented as "plug-ins" to a generic framework. I don't think
there's sense in defining "levels" of implementation etc. You just use what
you need, period. That's simpler all around.

Have fun,

    Oren Ben-Kiki