Re: Next YAML: drop equality definition

Hi Zenaan,

> Could both of these, the "may reject" option, and the "constrain ...
> and must reject" option, be part of the schema, or specified by
> command line option/ side-channel specification of at the appropriate
> layer?
>
> "Implementation dependent" doesn't feel like enough control.

It should be stated that YAML spec do not specify node equality
at all, so as any YAML libraries. The equality should be evaluated
by the native object's == operator. In some system, the equality
of the class instances, which is usually stored as a mapping
node in YAML, are evaluated by identity (pointer address).
In other systems, it is by the value of properties. In some
systems, the equality operator can be overridden to suit the
specific purpose of the object type. In any cases, how to
evaluate equality belongs to the definition of the data type.
It should not be determined by the serialization language.

It seems that the statement should not have been
"Implementation dependent" but something like "schema
dependent" or "data type dependent". I need some better
words...

Best,
Osamu



On 2016/03/04 23:44, Zenaan Harkness wrote:
> Hi Osamu, excellent post with lots of links and all! Thank you. One
> question below.
>
> On 3/4/16, Osamu TAKEUCHI <[email protected]> wrote:
>> There were long arguments how we should treat equality of nodes in YAML.
>>
>> https://sourceforge.net/p/yaml/mailman/search/?q=%22%5BYAML-core%5D+equality%22&mail_list=all&sort=posted_date%20desc
>>
>> Currently, equality of nodes is used in two purposes. One is to
>> reject a mapping with duplicate keys in the YAML 1.2 spec.
>> The spec says a mapping with duplicate keys should be rejected
>> by a YAML parser. The other is for allowing a library to represent
>> some equal scalar nodes by an single identical node to save memory
>> consumption.
>>
>>    https://sourceforge.net/p/yaml/mailman/message/23572250/
>>
>> It sounds straightforward at first but not in the reality.
>> The equality of nodes involves issues when anchor/alias and
>> implicit tag resolution are involved.
>>
>> To solve the problems, Oren proposed the following.
>>
>>    https://sourceforge.net/p/yaml/mailman/message/24061658/
>>
>>> Do not specify YAML equality rules. Eliminate most of the discussion
>>> of equality, canonical formats etc. and replace it by a stating that
>>> implementations "may" reject mappings that have "equal" keys,
>>> according to their own *implementation-specific* definition of equality.
>>> Constrain this
>>> to say that nodes with equal tags and equal content are always
>>> equal and hence "must" be rejected as duplicates.
>
> Could both of these, the "may reject" option, and the "constrain ...
> and must reject" option, be part of the schema, or specified by
> command line option/ side-channel specification of at the appropriate
> layer?
>
> "Implementation dependent" doesn't feel like enough control.
>
> Thanks again,
> Zenaan
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140