Re: Next YAML: drop equality definition

Hi,

On 2016/03/07 18:44, Zenaan Harkness wrote:
> On 3/6/16, Osamu TAKEUCHI <[email protected]> wrote:
>> I agree duplicate key should be detected by
>> YAML processors because we do not want users
>> to use duplicate keys for overwriting the
>> values of predefined keys.
>
> By "predefined key" do you mean "a key previously defined in this map"?

Yes.

I see what you mean.
I myself is actually very close to your side,
while I understand the way YAML currently goes, too.


Let's imagine how we can go your way. Then, we should stop
defining the data models for the three kinds of data nodes:
scalar, mapping, and sequence in the core spec completely.
The spec will just define the syntax of a YAML document and
the data model is solely determined by tags. The data models
for standard tags are given in the schema section so that,
for example, a mapping node with !!map tag will keep
flagging errors for duplicate keys and not being aware of
the key order, while nodes with user defined tags can adopt
any data models as you want.

It allows you to build LinkedHashMap from a mapping node with
duplicate keys if the tag is resolved to !LinkedHashMap.
You can also build a Hash from a mapping node with duplicated
keys with overwriting previously defined keys if the tag is
resolved to !HashOverwriting.


To do so, the YAML library provides API to allow you to build
a native object from the content of the node, with preserving
the key order in mapping nodes and identities of all nodes.

     To build an object from a scalar node, your builder function
     is callbacked with the formatted content itself as the
     arguments.

     To build an object from a sequence node, your builder function
     is callbacked with a list of already built native objects as
     the arguments.

     To build an object from a mapping node, your builder function
     is callbacked with the list of key-value pairs as nature
     objects in the right order as the arguments

You are not restricted to build static value, array or hash
from scalar, sequence and mapping. You can do whatever you want
using the information given from the library. For example, a
sequence node with !sum_of_int may generate an int value with
calculating sum of the child nodes with discarding the child
nodes after the calculation.

This gives much more freedom to us.
It makes the core spec simpler.
It may make YAML more popular.


Actually, this is almost what I did when I wrote a YAML
library with C#. To allow an application to build customized
object from customized tags, the library must have such API.
The difference is, I myself tried not to build any native
object that is too far from YAML's data model. If the spec
do not define the data model, people can do whatever they
want.


Technically speaking, keeping the key order and identity of
nodes in the representation graph is not difficult with any
practical languages. The key-value pairs for a mapping node
can be stored in an array-like structure in the representation
graph, instead of in a hash like structure. Unless the library
try to detect key duplication, it will not need quick key
search for the collection. Scalar nodes will be represented
by some class object in the graph. If we create one instance
for one scalar node, the identity will be preserved automatically.


The remaining concern is, people with less knowledge on the
schema can hardly understand the semantics of the data. But
this is natural. If one do not know the schema, they can not
even know the data type of a scalar node. The information
lost from the document due to the freedom should be gained
from the schema.


It will be said that such a document will be not portable
enough. IMO, portability does not matter unless one try to
construct native objects from nodes with tags that can not
be properly handled in the platform. All the well-designed
YAML libraries must be able to build the representation
graph from such a YAML document with the proper schema given.
Then, this representation graph itself can be manipulated
by the application to deal with the data. In this sense,
the document is still portable. Anyway, no more portability
can be expected unless all the document model defined in the
schemais natively implemented in the platform. This is also
the case for the current spec if a document is full of custom
tags.


Note that, portability of a YAML document without any custom
tags are not affected at all, because the data model of the
standard tags are fully specified in the recommended schema.


It seems consistent for me for now.
I think we can go this way if we decide.

Best,
Osamu Takeuchi


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