Re: some new info/issues on lists

Michael Kifer wrote:

>> 2.  We got rid of deep-equal because you can just check for list
>>     identity.  But it seems to me there will often be lists of data
>>     values, and data values generally need to be compared with the
>>     appropriate equality predicate for their type (numeric-equal,
>>     datetime-equal, duration-equal, XMLLiteral-equal,
>>     compare+numeric-equal 0, text-compare+numeric-equal 0, etc).  I
>>     suggest bringing back deep-equal for when you want comparison on
>>     data values to be done using datatype equality instead of identity.
>>     (This does suggest having a literal-equal or data-value-equal
>>     predicate; literal-equal(x,y) is the same as deep-equal(list(x),
>>     list(y))).
> 
> Data type constants that are equal will compare as equal. That is, 
> List(1.0 2.0) = List(1.00 2.00).
> 
> We don't have identity, by the way. Identity is not logically definable.

We have previously used "identity" in the XSD sense of "same value in 
the value space", which is exactly how our equality is defined.

I believe what Sandro is pointing out is that for several of our 
datatypes "same value in the value space" is less useful than the XSD/ 
XPath notion of equality. For example:

       "2000-03-04T23:00:00+03:00"^^xsd:dateTime
and
       "2000-03-04T20:00:00Z"^^xsd:dateTime

are not identical under XSD 1.1, not equal in terms of our equality 
semantics (they represent different values in the value space), but they 
are equal in terms of real world time instants[*] and in terms of the 
xsd equality algorithm which is exposed through our builtin 
pred:dateTime-equal.

So when comparing ground lists then the datatype-specific equality 
predicates rather than the RIF "same value in value space" equality 
semantics would probably be desirable.

Dave

[*] At least under the common sense, but technically false, notion of 
absolute time.