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.

Right, that's what I meant, thanks for the more-clear wording.

     -- Sandro

Received on Thursday, 23 April 2009 15:02:42 UTC