Re: Equality

Oren,

>     I do not find very much importance to keep an arbitrary YAML file to
>     be acceptable to every implementation. Each YAML file must have its
>     own purpose. So, I expect no chance where one would like to feed the
>     YAML file in my example to any YAML implimentation that do not have
>     reference-based object model.
> 
> 
> Well, that's where we differ.
> 
> YAML's goal 2 (portability) has higher priority than goal 3 (matching 
> native data structures). That is, wo do see the point in being able to 
> create generic "schema-blind" YAML tools, having a well-defined 
> consistent YAML data model, and so on. I can see why someone only 
> interested in a particular application (or implementation) may disagree; 
> someone interested in generic tools and portability would agree. It is a 
> matter of priorities; had we flipped the order of the goals, we would 
> have had a different set of rules.

Yes, cross-platform portability is very important. But the 
portability is not for the "generic schema-blind YAML tools" 
but for real cross-platform applications. I do not think the 
schema-blind tools are so important. I rather want YAML to
be more useful to the real applications.

In addition, you are still talking about an ideal portability.
I give an example, where a schema-blind tool can not evaluate 
nodes' equality correctly.

- !People
  - &A { name: Mike }
  (snip)
- !Cats
  - &a { name: Mike }
  (snip)
- !Favorites
  *A: beaf steak
  *a: canned tuna
  (snip)

Schema-blind tool will think *A and *a are equal objects.
However, it is allowed in the YAML spec to give different 
tags to the two nodes implicitly. Here, I assume !Person tag 
to *A and !Cat tag to *a. So, these two nodes are not equal
to each other. The !Favorites mapping is valid, containing
no duplicated keys.

* "Mike" is a popular cat's name in Japan. It means three-color 
  hair. The pronunciation is something like "meekwe".


>     IMO, the main purpose of defining the semantics in YAML spec is to
>     make the YAML file readable by human eyes. If we can believe the
>     order of mapping keys is always neglected by the YAML processor, it
>     becomes easier to understand the meaning of the data model and to
>     hand-write a YAML file.
> 
> 
> I think you are biased here; PHP developers would disagree :-)

No, I don't think so.

  1. Specifying the data model in this case clarifies the meaning
     of the document: "the key order does not matter."

  2. In the majority of applications, the order of the a hash object
     is meaningless, even in PHP applications.

I don't think PHP people disagree with me at these points. At the 
same time, I don't think it is a bad idea for PHP people to store 
their ordered-hash objects in YAML mapping nodes, unless the key 
order is indeed the concern of the specific application. Only when 
the key order really matters, they should store the data in a !!omap 
node to clarify the meaning of the data.


On the other hand, I do not think people will be too much confused by 
seeing looks-like-duplicated keys in a mapping node. At first, when 
such a YAML file is really meaningful in an application, people will
understand the right meaning of the data from the schema implicitly or
explicitly. Secondly, many real applications are making use of hash 
objects that can contain multiple objects with same property values.
Thirdly, nobody will regret to see such a data file can not be
processed correctly in some platform that has nothing to do with the 
specific application.


>     So, I do not like to define the must-be-rejected mapping as you
>     proposed because it does not seem to make YAML files much more
>     readable. I think it is more benefitial to remov the constraint and
>     to increase the adaptablity of YAML language to more applications.
> 
> 
> Readability is YAML's first and foremost goal. However, I don't see how 
> saying that { a: 1, a: 2 } may be legal in some applications and illegal 
> in some other applications increases readability. I find it to be 
> confusing and that it decreases readability; that is, I can no longer 
> tell just by looking at a YAML file whether it is valid or not, or what 
> it means if it is valid.

I think the required "readability" to YAML is not for distinguishing 
validity of a file but for understanding the meaning of the data. 

Regarding the equality of collection nodes, I think people can easily
see the meaning of the YAML documents in my two examples. 
Looks-like-duplicated keys do not prevent our understanding,
unless we worry if it is allowed in YAML spec or not.

Regarding the mapping node with really duplicated keys, I have not 
reached my conclusion. I just wanted to remind a related issue that 
might affect the discussion. Note that JSON does not forbid duplicated 
keys in a mapping node. Note that if we allow duplicated keys, the equality 
of nodes loose all its meaning in YAML spec. We will not have to discuss 
anything about it.


> 1. Expand the definition of scalar tags to specify a list of other 
> "potentially equal" tags. Values of the defined tag are considered equal 
> to values of the listed tags, if and only if their canonical form is 
> identical. This would cover the !!int 1 and !!float 1.0 case.
>
> It would even cover the case of !!int 1 == !!str 1 if we list !!str as 
> potentially equal to !!int, to accomodate Javascript and any other 
> feebly-typed language out there. I think this is something we can live 
> with (we'll definitely blame Javascript for it in the spec :-).

For me, this seems too much. A short warning will be enough.
"Note that some languages have unique definitions for equality. 
For example, !!int 1 and !!str "1" are equal mapping keys in 
JavaScript."

BTW, this issue might be the reason why JSON does not forbid 
duplicated keys in a mapping node.


> 2. For collection tags - a mapping tag could specify its values are 
> "potentially equal" to values of another mapping tag, if the values 
> associated with some set of keys are equal. Thus, for example, an !!omap 
> would be equal to a !!map if all the values for all the keys are equal 
> between the two. An value of an Employee tag could be equal to a value 
> of a Supervisor if their FirstName and LastName keys are equal, and so on.

I did not see what was the point in this description. 
Did you want to say that collection nodes with different tags may be 
equal to each other when they have the same child nodes?

I do not see why you suddenly says this. Could you please give some 
use cases to see the meaning? I could not imagine anyone wants to 
evaluate !!omap node and !!map node are equal *as mapping keys*. 
The !Employee and !Supervisor example did not seem natural, neither.


> This does not address Osamu's identity vs. value based equality issue 
> for collections. I view this as a completely orthogonal issue. It is one 
> we discussed at length at the time (years back); in a nutshell, since 
> YAML is a data serialization language, and since value-based semantics 
> are a subset of identity based semantics (that is, value-based data 
> works in identity based systems, but not the other way around), I feel 
> that we made the right call. Changing this would be a much deeper 
> modification than the above suggested tweak to the equality rules. That 
> is, IMO changing this would be a YAML 1.3 or even a YAML 2.0 issue.

Our difference is that you want to keep an arbitrary YAML file to
be acceptable to every implementation but I don't. Repeatedly,
I will not regret to see a valid YAML file can not be processed 
correctly in some platform that has nothing to do with the 
specific application. I guess not a few people think so.

BTW, I wonder if value-based platforms can process self-containing 
collection nodes in a *valid* YAML document.

- &A [ *A ]
- &B [ *A ]
- { *A: 1, *B: 2 }

Identity-based platform will accept this input because *A and *B
can be evaluated unequal. Can any value-based platform process 
this correctly?

Best,
Osamu Takeuchi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july