Re: Equality of YAML nodes

Thanks for your comments, BlueG.

In this email, I want to talk mainly about the equality 
evaluation scheme for !!map and !!seq. Namely, I do not 
want to talk about that of the nodes with non standard 
Tags, because the latter does not seem to be incompatible 
with the portability of YAML.


>       1. YAML is easily readable by humans.
>       2. YAML matches the native data structures of agile languages.
>       3. YAML data is portable between programming languages.

In general, the importance is 1 > 3 > 2, for me, surprised? 
But, all of them should be for the primary purpose.

        0. YAML is useful for people.

So, if portablity maximization or definition cleanness
maximization becomes incompatible to this primary purpose, 
I think we should seek some work around. In addition,
if a part of the specification is always neglected by 
users, I think the description should be reconsidered.


I now feel that the definition of equality I gave the other 
day was not a real definition but more like the description 
of the current situation of YAML. So, in order to make it 
better, I reconsidered it.

The information model of PHP's Hash is incompatible to 
that of !!map as Oren pointed out. So, we have to distinguish 
them in the YAML's specification. I agree with Oren at this 
point.

Hash and Array of many languages have the same information 
model to that of !!map or !!seq, except for the definition 
of euqality. For example, an array of object (object[]) in 
C# has same information model as that of !!seq. However, 
equality of C# arrays are evaluated by their identity while
!!seq compares the child objects one by one. So, they are
incompatible in the definition of equality. For some cases, 
the difference is much less obvious, as the case of the ruby's 
Array and Hash. However, strictly speaking, the equality 
definition of !!map and !!seq is incompatible to that of 
Hash and Array in almost all languages.

If we represent such a native data object with a !!map or 
!!seq node, the difference of equality definition can cause 
a problem. 

But, in reality, it is very rare cases where the problem
appears obviously. The reason is that it is very rare to have 
!!map or !!seq as the key of a mapping node and even if we 
might use !!map or !!seq as the mapping key, it is further 
rare to have duplicated keys in a mapping. Note that this 
is different from my President-Party example because the 
keys were not !!map but !President, there.

Since it is rare, almost all existing libraries neglect
the difference in the definition of equality. But if we 
really want to go strict with YAML's specification, we 
can never use !!map and !!seq to represent our Hash and 
Array objects.


I think the best way to work around this problem is 
giving up to fully define the behavior of a mapping node 
that have duplicated keys with !!map or !!seq Tag. 
Then, we do not have to define the equality of !!map 
and !!seq too strictly.

I revise my proposal for the equality definition of !!map, 
!!seq and other YAML's standard collection nodes to be:

    If two nodes are identical, they are equal.
    If they are of different content, they are not equal.
    If they are of equal content, the result is *undefined*.
      They might be judged as equal but they might not.

This definition is useful enough for most of application 
and weakens the portability of YAML very little because 
it is different from the current definition only for the 
cases where a mapping node is rejected due to the duplicated 
keys. I think this is also the way most of the libraries
implement YAML, now and in the future. It fills the gap
between the ideal and the real worlds.

At the same time, it is less strict enough to allow users 
to represent their Hash and Array by !!map and !!seq nodes. 
Note that the above definition is even compatible to the 
definition of equality just by the identity.


If we should think of cleanness of the definition, instead
of the portability of YAML, I'm willing to change the 
subject.

Best,
Osamu TAKEUCHI

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf