Re: Next YAML: drop equality definition

Ingy, Oren,

Thank you very much for the comments.
But sorry, I am not interested in the layer structure
very much at least in this thread.

It only matters when you want to detect key duplication
as early stage as you can. The only problem for me
was misusage of the word "YAML parser."  From the
beginning, I was trying to say the detection should
be done after or during construction using native
methods as it is currently done in the real world.
At least YAML spec should allow it. If a YAML processor
has no construction stage, it must not do it because
it can not do it correctly. This will not hurt users
too muchas YamlReference does not.

Actually, very few people put importance on the
layered structure. I evaluate it very well designed
consistently, safely and efficiently. But the users
are almost only interested in the application level.
Most of the library maintainers do not, neither.

I ask: How many YAML documents are checked for key
duplication by tools without construction stage but
aware of application-defined tags per day? How many YAML
conjectures are working with non-terminating YAML stream?
How many YAML systems actually implemented canonical
form based comparison of nodes with application-defined
tags? I'm afraid they are almost all imagination.

In contrast, if we have YAML library that can serialize/
deserialize complex native object tree containing full
of different classes into/from YAML file, it will be
widely used. YAML's tag system is very well designed to
suit to build such library. Equality and identity
definitions of YAML spec forbid a part of such use cases
and distort data semantics in such use cases for little
benefit.

I am more interested in talking what kind of portability
we need and what kind of readability wee need.

We should put more importance on realistic use cases.

Osamu Takeuchi



On 2016/03/08 3:54, Oren Ben-Kiki 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