Re: Next YAML: drop equality definition

On 3/7/16, Oren Ben-Kiki <[email protected]> wrote:
> Using the layered approach to describe YAML processing, then:

... lots of Acks...

> Layer 3 is the application native data structures. They _must not_ depend
> on scalar identity. They _must not_ depend on key order in a mapping. They
> _must not_ depend on duplicate keys in a mapping. You can have key order
> and duplicate keys in an !!omap or something like that.

Ack. This Layer 3 makes perfect sense. Default "application native
YAML map" ("default" schema) does not allow duplicates and must not
depend on key order.

I think of application as perhaps a level above even layer 3? Is this
right? Because at the highest level (e.g. statistics graphing
application), it can save/load as per its own needs, with its own
"default schema", yes?

Or would it still "officially be violating YAML spec" to redefine !map
to be !omap in its "default schema for save files"?

My assumption:
Layer 4 - the user of YAML layer - that code which makes use of a YAML
library, which library provides anything up to and including "YAML
Layer 3".

Layer model is the best thing for clarity of YAML in recent times.
Thank you all!

...
> The above rules allow _control_ over the interoperability of YAML data
> between systems. Note - "control", not "guarantee". Nothing can "guarantee"
> interoperability between the native data types of completely unrelated
> platforms.

Massively important distinction. This should be in a spec :D

> The rules also try to minimize the "surprise" people may feel when learning
> on how the application actually interprets the data.
>
> Sometimes this means that less-common data needs to be serialized with a
> bit more syntax (e.g., !!omap notation vs. !!map notation). Note the fact
> we _require_ the use of a less-streamlined syntax (1) does not _prevent_ us
> from being able to serialize "anything at all" into YAML and (2) does not
> necessarily reduce legibility - in fact, it arguably increases.

I think this might answer my question above, but I'm not sure.

> Now, you can break any of the above rules, with the understanding that by
> doing so you are stepping outside of what YAML provides. In this case your

"Provides by default schema" vs suggests, vs recommends vs allows etc.

With the layer spec, YAML feels to me "mature" and "flexible".
Which = powerful. Great stuff.

> system may produce unexpected results if valid YAML processors are applied
> to the data, and will "surprise" people who expect YAML behavior. So, while
> we can't prevent people from doing whatever they want - this is a free
> universe - we can require that people doing such such things will not say
> "this is a valid YAML system".

And a streaming schema validating YAML parser could do certain checks
to notify re well formedness etc.

> BTW: The reason that tags can't apply to different kinds of nodes is due to
> the identity issue. Collection identity is guaranteed by YAML. Scalar
> identity is not. Applying the same tag to both raises some sticky issues.
> That said, we may be able to relax this by using careful wording
> (especially given the gap Osamu has found). I'm not certain it is a problem
> in practice, though.
>
> So... "it is what it is". I hope the above helps explain why.

Thank you.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval