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