Re: Next YAML: drop equality definition

This has been a long thread...

The way I see it: The spec is what it is :-)

Using the layered approach to describe YAML processing, then:

Layer 0 is the text file (Unicode encoding etc.). It doesn't do anything.

Layer 1 is the parser/scanner/grammer/etc. It doesn't do duplicate key
detection. It does provide key order. It provides indentation levels, and
the way strings are wrapped in lines, and how characters are quoted, and
lots of other "presentation" details. It can be streaming. YamlReference is
an example.

Layer 2 is building an abstract node graph (with either some or all of the
nodes having resolved tags). It _need not_ preserve key order. It _need
not_ preserve identity of scalars. It _may_ do duplicate key detection, but
if it does it _must_ do so in a way that ensures "no false positives", that
is, it may _only_ flag keys as duplicate if the application _must_ consider
them equal, given the YAML data model (thanks to Osamu for finding a gap in
the definition of this data model).

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.

A concrete system can work at level 0 only (e.g., re-encode a YAML file
from utf-8 to utf-32be). Or level 0/1 only (e.g., a YAML pretty-printer).
Or level 0/1/2 only (e.g., a ypath tool for extracting specific fragments
from a document). Or level /0/1/2/3 (a full application). All are valid.
Each one uses a different (related) data model.

Much of the confusion in this very long thread is due to people applying
the restrictions or data model of a level X to another level Y where they
do not apply. Also, confusing between what is _allowed_ and what is
_required_ in each level.

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.

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.

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

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.

Oren.

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

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core