[XSCH] My thoughts on XPath eq and current document

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
Disadvantages : none
__

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