Re: Equality

Oren Ben-Kiki wrote:
> On Sat, Nov 28, 2009 at 8:55 PM, Osamu TAKEUCHI <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     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.

I don't think schema-blind tools have any chance to determine whether 
two nodes are equal or not.  This is very schema-specific.  Not only two 
nodes with different tags could be equal, but also a scalar node could 
be equal to a collection node.  Consider, for instance, that in

x: 1.0i
y: { re: 0.0, im: 1.0 }
z: { rho: 1.0, phi: 1.5707963267948966 }

the three nodes 'x', 'y', and 'z' are probably equal.  You don't know 
unless you know the schema.  Another example is from my own application, 
where nodes

db1: postgres://localhost:5432/mydb
db2: mydb
db3: { engine: postgres, host: localhost, port: 5432, database: mydb }
db4: { database: mydb }

will generate the same object.

Anyway, what kind of schema-blind generic tools you have in mind?  I'm 
not aware of any.  And I also don't understand how lack of equality 
rules could affect them: a schema-blind generic tool cannot convert a 
YAML node to a native object anyway.  A document of the form:

a: 1
a: 2

will be represented by a generic schema-blind tool as a mapping:

ScalarNode("a", tag="?"): ScalarNode("1", tag="?")
ScalarNode("a", tag="?"): ScalarNode("2", tag="?")

where ScalarNode objects use identity-based equality.

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

It's not clear what you mean by valid.  Is it well-formed or not?  In 
this case, it is valid.  Is this document adheres some schema (for 
instance, the standard JSON schema)?  In this case, probably not.
The thing is that equality rules are schema-specific.

> At any rate:
> 
> I think I have an alternative everyone could live with, though, based on 
> my original option 3. The following suggestion is to codify the current 
> behavior of existing implementations, but on a per-tag rather than 
> per-platform basis. This preserve portability (which, like it or not, 
> YAML views as an important goal, second only to readability).

Could you explain what you mean by portability?  That any document could 
be converted to a native object?  But that is hardly possible since 
capabilities of mapping objects in different languages differ 
considerably.  Some of them could only support string keys, others 
support arbitrary scalar keys, some of them accept immutable collection 
keys, and some could have arbitrary keys.

> 1. Expand the definition of scalar tags to specify a list of other 
[...]
> 
> 2. For collection tags - a mapping tag could specify its values are 
[...]

You still insist on structural value-based comparison.  See my example 
above where a scalar node is equal to a mapping node.

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

I definitely don't agree with that.  The fact that you cannot represent 
a native structure in YAML naturally because of value-based equality 
means that value-based equality is a wrong choice.


Thanks,
Kirill

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