Re: Review. Section 11.1.1 Error in promotion/type pecification?

On Thu, Jun 09, 2005 at 03:31:34PM +0100, Steve Harris wrote:
> Lines: 50
> 
> 
> Review of http://www.w3.org/2001/sw/DataAccess/rq23/ v1.379
> 
> This is a critical issue. I raised it on IRC when reviewing section 11 as
> per last weeks action, but neglected to mail the list and so forgot.
> Apologies.

Yeah, ditto.

> Promotion order is given as:
> 
>     * xs:double
>     * xs:float
>     * xs:decimal

I have no particular attachment to the above scheme beyond that XPath
does it and I want to be cool like XPath.
  <http://www.w3.org/TR/xpath20/#promotion>
A lot of the functions we use (like numeric-add) are defined in terms
of those types. Given an absurd just-in-time implementation and the
following query:

  WHERE { ?who age ?age ; shoeSize ?shoeSize
          FILTER (?age + ?shoeSize = 84) }

the query engine sees the plus and pages the on-call query researcher.
He is woken from his slumber to see a page like:

    numeric-add("42"^^xs:float, "42"^^xs:integer)

He whips out his trusty web browser to check out the semantics of add.
  <http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping>
points to
  <http://www.w3.org/TR/xpath-functions/#func-numeric-add>
which defines the opperation in terms of two identically-types
operands. In XPath-land, those two operands were normalized to the
same type by applying XPath's Numeric Type Promotion.

Given that, I guess we could supply our own promotion rules. But I
wonder what wisdom guided their decisions. Until someone from XQuery
can say "we did it for X" and we can confidently decide that Steve's
comments are more important than X, I am

  -0

on changing this.

> with types being promoted to the one obove in the list. However xs:float
> does not subsume xs:decimal - according to
> http://www.w3.org/TR/xmlschema-2/#decimal The value space of decimal is
> the set of numbers that can be obtained by multiplying an integer by a
> non-positive power of ten and all minimally conforming processors must
> support decimal numbers with a minimum of 18 decimal digits. This exceeds
> the precision* of xs:float and xs:double in some cases, so the type
> "promotion" may well be lossy.
> 
> *	Type     Epsilon
> 	integer	 1.0
> 	float    1.0e-5
> 	double   1.0e-9
> 	decimal  1.0e-17
> 
> My recollection is that we agreed to start with double, dateTime and
> integer (c.f. http://www.w3.org/2001/sw/DataAccess/ftf4.html RESOLVED: to
> address valueTesting by choosing datetime, date, time; date less-than,
> date-greater-than, date-equal; string ops per 1.171; numeric double,
> integer, 9 numeric ops above, per xquery f&o with EricP, KendallC, SteveH
> abstaining), since then we have aquired xs:decimal, which complicates
> matters greatly.
> 
> Suggested replacement text:
> 
>     * xs:double
>     * xs:float
>     * xs:integer
> 
> And replace all occurances of xs:decimal in the text with xs:integer. Drop
> note in A / B entry of Table 11.1.
> 
> N.B. xs:float does not subsume xs:integer either, but the overlap is much
> bigger, and this kind of conversion is common in programming laguages so
> will hopefully be less supprising

But integer is lexically derived from decimal:
  <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#decimal-derived-types>
(I don't claim to contradict you, just relaying my confusion.)
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.