Re: comparators and "error"

[Dave Cridland <[e-mail]>]

On Wed May 10 20:09:17 2006, Arnt Gulbrandsen wrote:
> 
> Dave Cridland writes:
>> I'm really not so sure. On the face of it, it sounds like bad 
>> design, but I think there's at least two cases here - an attempt 
>> to compare "fish" and "bicycle", and an attempt to compare "fish" 
>> and "2". I have a feeling this is an important distinction.
> 
> It is precisely the distinction between "neither input is valid" 
> and "one input is valid, the other not".
> 
>> Arguably, "fish" is equal in numeric value to "bicycle" - they 
>> both have no numeric value, so it's the same as comparing NIL and 
>> NIL with "i;octet".
> 
> Or as comparing null with null in SQL.
> 
>> Equally, "2" has a numeric value of 2, whereas "fish" does not, so 
>> they are unequal - like comparing NIL and an existing string with 
>> "i;octet".
> 
> Or as comparing 2 with null in SQL. And wouldn't you know, SQL is 
> different from ACAP in this respect.

Good for SQL... ACAP's definitions regarding this are a lot less 
clear.


> I'd rather not venture into this dark and confusing maze of 
> null/nil semantics. These are choices for the protocol to make, say 
> I.
> 
> 
I think - but I'm not absolutely sure - that the question has already 
been settled.

In RFC2244, section 3.4, which is the authoritative definition of 
comparators:

1) "i;octet" specifically states that NIL is equal only to itself. 
(Second paragraph in its definition, last sentence)

2) "i;ascii-casemap" specifically states that it applies a mapping 
then does "i;octet". So NIL==NIL again.

3) "i;ascii-numeric" then complicates my argument, because "All 
values which do not begin with a US-ASCII digit are considered equal 
with an ordinal value higher than all non-NIL single-valued 
attributes" - that certainly seems to mean "fish" == "bicycle", but 
I'm not sure if it means "fish" != NIL or "fish" == NIL. It says 
nothing to me about whether NIL == NIL.


> Instead, I think I'll add a fourth operator, valid, which indicates 
> whether a given string is valid input for the collation. It's not 
> really necessary. indomain(a) is true if and only if a=a. But it 
> sounds sensible. Permits protocols to differentiate between one and 
> two invalid inputs if they want to, without resorting to hacks like 
> a=a.

I'm entirely happy to have an additional operator, however, I'd 
prefer to standardize the behaviour somewhat. In particular, I'd 
quite like it settled as to whether NIL==NIL in general, and whether 
invalid input is equal to NIL - at the very least as a default.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw