Re: Equality

William Spitzak <[email protected]>
Newsgroups gmane.text.yaml.general
Message-ID <[email protected]>
In the majority of systems that would consider a key of 1 and a key of 
1.0 equal, they will also have the limit that a key of "blah" is not 
allowed. But I don't see YAML being designed to somehow define the set 
of legal keys, so it seems defining this equality is also outside YAML's 
scope. Also there are far more complex problems than int vs float: a 
system using 32-bit floats will consider a lot of numeric keys equal 
that a 64-bit float system will consider unequal. I think it would be 
impossible for YAML to define this and nobody would obey any such 
defined rules.

I would vote for rule 4.

To make a YAML processor practical, we do need something to hash to 
build a table. Therefore I agree with the rule that equal tags and equal 
content are guaranteed to be equal. It is not clear when two literals 
are equal however, I certainly consider "false" and false to be unequal. 
Rather than requiring all YAML processors to understand all possible 
automatic tagging rules I would add "is it quoted" to the data that says 
literals are unequal. I'm unclear on whether this is already how you are 
defining it.

In addition I would agree with the majority here that the order of keys 
should not make maps unequal, and multiple equal keys are considered 
equal to a map where all except the last one have been deleted. Without 
this it is probably impossible to do any complex yaml processing.

> 4. 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. The problem here is 
> that { 1: "int", "1" : "string" } would work in Python and not in 
> Javascript. Arguably, anyone defining a cross-platform schema would be 
> able to "easily" avoid such issues (e.g., by requiring all keys of the 
> mapping to have the same tag, which is pretty trivial). But there's no 
> longer a universal cross-platform validity guarantee.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.