[XSCH] My thoughts on XPath eq and current document

From: Benjamin Nguyen <Benjamin.Nguyen@inria.fr>
Date: Thu, 10 Nov 2005 18:24:39 +0100 (CET)
To: SWBPD <public-swbp-wg@w3.org>
```

Hi all,

first of all I took some time to read up in detail on XPath 2.0 [1], Nov.
3rd version, looking for precise info on the eq function and type
promotion. From what I understand in the recommandation, there are two
sorts of numeric type promotion autorized :

a) xsd:double to xsd:float
b) xsd:decimal to xsd:float

and therefore all other that could be obtained through the use of subtype
substitution, such as xsd:integer to xsd:decimal to xsd:float.

I suppose that type promotion is transitive, however given the ruleset,
this is irrelevant.

To my point :

during the F2F it was not clear to me the behaviour of the operator eq and
type promotion, I thought that eq was not transitive therefore :

1.3^^xsd:decimal eq 1.3^^xsd:float would convert the decimal to float and
compare, then return TRUE (pardon my lapse of inverted commas here, and
in what follows)

whereas

1.3^^xsd:float eq 1.3^^xsd:decimal would be unable to convert, therefore
return FALSE.

I was wrong on that point (my bad), which is why I voted "does not
entail". In fact, type promotion looks for  the first type to which all
types can be promoted to, and does the  comparison, my understanding is
now that the xs:decimal would be promoted to float, then compared,
whatever the order.

Now :

this means in fact that comparisons in bewteen types are in reality made
within the xsd:float space, since xsd:decimal (xsd:integer) and xsd:double
can all be promoted to xs:float

Example :

1.3^^xsd:decimal eq? 1.3^^xsd:float is evaluated in the following way :

a) 1.3^^xsd:decimal is an exact value
b) 1.3^^xsd:decimal is promoted to 1.3^^xsd:float
c) 1.3^^xsd:float is evaluated to 1.2999999523^^xsd:float
d) both compare equal -> return TRUE

Same with 1.3^^xsd:double eq? 1.3^^xsd:float

a) 1.3^^xsd:double is evaluated to 1.299999999999999822^^xsd:double
b) 1.299999999999999822^^xsd:double is promoted to
1.299999999999999822^^xsd:float
c) 1.299999999999999822^^xsd:float is evaluated to 1.2999999523^^xsd:float
d) 1.3^^xsd:float is evaluated to 1.2999999523^^xsd:float
e) both compare equal -> return TRUE

Therefore :

with this insight, I feel it compelling to adopt the XPath 2.0 eq
(pink in document) approach.

However :

I disagree with some phrasing in the current [2] document, which I find
misleading such as claiming that "eq is non-transitive"

The example given to support the non-transitive claim is :

3.2^^xsd:float eq 3.20000000000000000001^^xsd:decimal

but not

3.2^^xsd:decimal eq 3.20000000000000000001^^xsd:decimal

I do not understand why this is "non-transitive", if one adopts the vision
(which I think is correct) of xsd:float = an interval and xsd:decimal = a
point. With such an interpretation, eq can be seen as a polymorphic
operator meaning "equals"  in the xsd:float (interval) world (see Allen
[3]), meaning "=" in the xsd:decimal (point) world, and meaning "during"
if one compares xsd:decimal eq xsd:float or "contains" if one compares
xsd:float eq xsd:decimal.

I suggest adopting these semantics for RDF and OWL eq. This means that the
ENTAILMENT is non-transitive, since :

eg:car eg:engineSizeInLitres "1.3"^^xs:double

ENTAILS

eg:car eg:engineSizeInLitres "1.3"^^xsd:float

But

eg:car eg:engineSizeInLitres "1.3"^^xsd:float

DOES NOT ENTAIL

eg:car eg:engineSizeInLitres "1.3"^^xsd:double

Seems to me pretty straightforward and logical.

So after some thought, I'd like to change my vote to _entails_ making it
clear that 1.3^^xsd:float IN REALITY means "any float within 2^-24 of
the decimal 1.2999999523", and 1.3^^xsd:double means : "any float within
2^-53 of the decimal 1.299999999999999822".

Easy to understand xsd:float does not entail xsd:double

__
In brief :

Advantages : clear interval semantics, full XPath 2.0 compatibility,
better entailment
__

Regards,

BN

[1] http://www.w3.org/TR/xpath20/
[2] http://www.w3.org/TR/swbp-xsch-datatypes/
[3] http://www.cert.fr/dcsd/THESES/fabiani/manuscrit_fabiani/img173.gif

--
------------------------------------
| Dr. BENJAMIN NGUYEN              |
| Université de Versailles         |
| et St-Quentin-en-Yvelines        |
| Eq. Systèmes de Bases de Données |
| 45, av des Etats-Unis            |
| 78035 Versailles CEDEX           |
|----------------------------------|
| INRIA-Futurs                     |
| Projet Gemo                      |
| 4, rue Jacques Monod             |
| ZAC des Vignes                   |
| 91893 Orsay CEDEX                |
| FRANCE                           |
------------------------------------

Tel. INRIA : (33) (0) 1 72 92 59 31
Tel. UVSQ  : (33) (0) 1 39 25 40 49
```
Received on Thursday, 10 November 2005 17:24:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:45 UTC