RE: F&O comments on distinct-values function

Thanks for your comments.  I think we need to say that the 'eq' operator
is used to determine whether two values are distinct or not.  We do not
need the total order requirement.  

All the best, Ashok

-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com] 
Sent: Thursday, November 21, 2002 7:01 AM
To: Priscilla Walmsley; public-qt-comments@w3.org
Cc: w3c-query-operators@w3.org
Subject: RE: F&O comments on distinct-values function


> A few comments on the distinct-values function:
> 
> 1. Why does it matter if two values of the same type have a 
> total order, as long as they can be compared using eq?  For 
> example, QNames do not have total order but you should be 
> able to pick out distinct ones using the eq/ne operators.  It 
> seems like only duration would be a problem here.

I agree. (And I personally think that we should define equality over
durations, based on reducing the duration to a (months, seconds) tuple).
> 
> 2. I'm assuming that xs:integer(1) and xs:decimal(1.0) are 
> not distinct values (or are they?) Should the rec specify 
> which type the returned value should have?  If not, maybe 
> there should be a note about that being implementation dependent.

Yes, we should add a note that if several values are eq to each other,
it is
implementation-dependent which of them is returned. 
> 
> 3. How should anySimpleType values be handled?  Using the eq 
> operator results in an anySimpleType value being cast to the 
> type of the other operand.  It seems logical that if the 
> sequence is (xs:integer("3"), <x>3</x>), distinct-values 
> should only return one value (3), but what if it is 
> (xs:integer("3"), <x>3.0</x>, <x>3</x>).  Should that return 
> one, two, or three values?  This should be clarified.

We have been doing a lot of work in the last week or two to redefine
"eq" so
that it is transitive. This should remove this problem.
> 
> 4. NaN is not equal to itself using the eq operator, so 
> should it really be equal to itself for the purposes of this function?

This function is consistent with the decision we made in XSLT that NaN
is
equal to itself for the purpose of grouping, sorting, and key lookup. I
think it's the right way to go. (Java does it this way too).
> 
> 5. There is no need to make a special point about 0.0 being 
> equal to -0.0, since this is the behavior of the 
> numeric-equal function.

True (but it doesn't do any harm either).
> 
> 6. In the last sentence of the first paragraph, the comma 
> appears to be in the wrong place and "a implicit" should say 
> "an implicit"  Also, the sentence starting with "Equality of 
> string values are..." should be "Equality of string values is..."

Yes.

Thanks for the comments!

Michael Kay

Received on Thursday, 21 November 2002 10:52:41 UTC