[Bug 28319] New: [FO30] (and [FO31]) Text on least common type and conversion in fn:min and fn:max ambiguous

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28319

            Bug ID: 28319
           Summary: [FO30] (and [FO31]) Text on least common type and
                    conversion in fn:min and fn:max ambiguous
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

Under 14.5.3 fn:max we say:

<quote>
Numeric and xs:anyURI values are converted to the least common type reachable
by a combination of type promotion and subtype substitution. See Section B.1
Type Promotion XP30 and Section B.2 Operator Mapping XP30.
</quote>

It is unclear to me what "least common type" refers to, which is not defined in
either XP30 or FO30. Section B.1 does not use this term. It talks about
promotion. One way to read "least common" is to say that it must be deeper in
the type hierarchy, but we do not have a strict type hierarchy (see also LCT
discussion for XSLT in bug 24569), xs:double does not 'inherit' from xs:float.

The term "least common" is easily misunderstood, should it mean something
similar to the lowest common ancestor concept
(http://en.wikipedia.org/wiki/Lowest_common_ancestor)? But we do not have a
clear graph relationship between the numeric types.

Another way to read "least common" is to write it as "most specific", which
means for me that xs:byte is more specific than xs:short, which is clearly not
its intention.

It is also ambiguous to me what "is converted" means here. It suggests that the
type is converted and the original type is lost, as with type promotion
(section B.1) but section B.2 suggests the opposite, with substitution, where
the original type is retained. Tests with Saxon give ambiguous results (or I
miss something).

I.e.:
max((xs:byte(10), xs:short(9)))
>> is result of type xs:byte, xs:short, or xs:integer (the LCT)? Assumed: byte

max((xs:integer(12), xs:decimal(10)))
>> Assumed: result of type xs:integer expected (type substitution), but unclear (and Saxon returns xs:decimal)

max((xs:float(1), xs:decimal(2)))
>> result should be xs:float, but the LCT relation is vague

In layman's words, I think the common rule for numeric and xs:anyAtomicType is:
- substitute the type for any of xs:integer, xs:decimal, xs:float, xs:double
- substitute xs:integer for xs:decimal
- the first that applies:
  - if seq contains xs:double or xs:anyAtomicType, promote all to xs:double
  - if seq contains xs:float, promote all to xs:float
- compare using op:numeric-greater-than.
- return promoted (changed) or substituted (unchanged) type and value

---------------

Also note that in FO30, Section 4.3 Comparison operators on numeric values, the
text reads:

    one argument is promoted to the type of the other as described 
    above in 4.2 Arithmetic operators on numeric values.

which should probably be "promoted or substituted", though the result is
boolean here, so it is of minor significance.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 23 March 2015 18:11:00 UTC