Re: Next YAML: drop equality definition

Thanks Oren,

I'll try to make all of this clear in the YAML Developers Guide. I can
start by making a document that declares the layers and what properties
apply and such. Then we can have more precise and targeted arguments. :)

My main addition is that the reader/writer transforms between your layer 0
and 1 are responsible for transforming between a unicode encoding and a
stream of unicode code point integers. Do you agree?

Ingy

On Mon, Mar 7, 2016 at 10:54 AM, Oren Ben-Kiki <[email protected]> wrote:

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

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