Re: Next YAML: drop equality definition

On 3/7/16, Osamu TAKEUCHI <[email protected]> wrote:
> 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.

You understood precisely what was in my mind - thank you so much for
putting it into words that YAML people can understand :)


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

Another good example of the way I was thinking.

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

Possibly - if the spec is simplified, this may have positive but also
negative consequences - must think through such things.

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

YAML spec must still be layered, and support lower layer processors though...

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

Or have both - like Java's LinkedHashMap or LinkedHashSet - if
Javascript cannot do such a thing "natively", then perhaps Javascript
needs a LinkedHashMap implementation? Or just return a Pair of
(Array,HashMap) - but only in those situations where an application
layer requires this of course.

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

This makes intuitive sense to me. Even when there's no schema, there
is (in my mind) an implicit "YAML data model schema" anyway...

> It will be said that such a document will be not portable
> enough.

This assertion has never properly made sense to me - "contextless
document" means "schema-less document" which means a YAML document
which no application really knows about. This just does not exist in
the real world, except theoretical.

For example, if we consider certain YAML spec test documents to be
"contextless", there is always some implicit schema, and the context
is the YAML spec itself.

So although there may be a default or implicit schema, "schema less
document" just does not make sense to me, and --therefore--:

  talking of "such a document will not be portable enough",
  also just does not even make sense

Every real document, has an actual context. That actual context, at
the very least -implies- some schema.


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

"Native object" say from Java, and exporting to YAML, and importing
into Javascript, for example?

Is this merely an implementers problem, not a spec problem? If a
particular programming language is so deficient that it is not
possible to have one set of values accessible by, alternately, both
map and by array or linked list, then that programming language has
some serious limitations...

> All the well-designed
> YAML libraries must be able to build the representation
> graph from such a YAML document with the proper schema given.

Ack.

> Then, this representation graph itself can be manipulated
> by the application to deal with the data. In this sense,
> the document is still portable.

Ack.

> Anyway, no more portability
> can be expected unless all the document model defined in the
> schema is natively implemented in the platform.

"Just a platform issue."

> This is also the case for the current spec if a
> document is full of custom tags.

Ack.

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

Is "recommended schema" same as "default" schema?

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

Interesting discussion. Thank's all for persisting...
Zenaan

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