Bug 20631 - [XQ31] The "numeric" pseudo-type
Summary: [XQ31] The "numeric" pseudo-type
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.1 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
: 25444 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-10 12:13 UTC by Michael Kay
Modified: 2015-07-06 09:02 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2013-01-10 12:13:43 UTC
A number of functions, such as abs(), have signatures that declare the expected type and result type as "numeric". In 4.2 we explain "The word " numeric " in function signatures signifies these four types [that is, integer, decimal, float, and double]."

This informal description was fine in the past, but it falls apart once we have higher-order functions. What is the type of fn:abs#1? What happens when we supply fn:abs#1 to a function that expects function(xs:integer) as xs:double? We don't say.

With the work that we have done on unions, we can do better than this. We should say that where we use "numeric" in a function signature, we mean an anonymous type whose definition is union(xs:decimal, xs:double, xs:float). With this definition, there is no change in functionality for callers of these functions, but the semantics become clear for higher-order operations where the type of the function is significant.
Comment 1 Michael Kay 2013-01-10 12:22:22 UTC
Actually, it should be union(xs:double, xs:float, xs:decimal) in that order.

The current rule in the function calling rules that says

<quote>For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double.</quote>

can then be removed; this will happen automatically by virtue of the existing rules applying to all union types. Because xs:double is the first type listed in the union, and because the lexical space of xs:double is a superset of the lexical space of xs:float and xs:decimal, the cast will always either return an xs:double, or will fail. So there is no change from the existing behaviour.
Comment 2 Andrew Eisenberg 2013-01-14 15:19:06 UTC
This issue is addressed in 3.1.6 Named Function References:

Certain functions in the [XQuery and XPath Functions and Operators 3.0] specification are defined to be polymorphic. These are denoted as accepting parameters of "numeric" type, or returning "numeric" type. Here "numeric" is a pseudonym for the four primitive numeric types xs:decimal, xs:integer, xs:float, and xs:double. For the purposes of named function references, these functions are regarded as taking arguments and producing results of type xs:anyAtomicType, with a type error raised at runtime if the argument value provided is not of the correct numeric type.

Note:

The above way of modeling polymorphic functions is semantically backwards compatible with XQuery 1.0. An implementation that supports static typing can choose to model the types of these functions more accurately if desired.
Comment 3 Michael Kay 2013-01-22 16:22:09 UTC
Decided to put this on the 3.1 agenda and make no change for 3.0.
Comment 4 Michael Kay 2014-05-25 13:10:25 UTC
*** Bug 25444 has been marked as a duplicate of this bug. ***
Comment 5 Jonathan Robie 2014-10-28 20:07:12 UTC
I suggest that we replace this definition as follows:

[Definition: When referring to a type, the term numeric denotes the types xs:integer, xs:decimal, xs:float, and xs:double<add>, which are each derived from xs:numeric</add>.]
Comment 6 Jonathan Robie 2014-10-28 20:07:48 UTC
(In reply to Jonathan Robie from comment #5)
> I suggest that we replace this definition as follows:
> 
> [Definition: When referring to a type, the term numeric denotes the types
> xs:integer, xs:decimal, xs:float, and xs:double<add>, which are each derived
> from xs:numeric</add>.]

I will also have to look at all uses of numeric in XQuery 3.1 / XPath 3.1.
Comment 7 Michael Kay 2014-10-28 20:22:19 UTC
(In reply to Jonathan Robie from comment #6)
> (In reply to Jonathan Robie from comment #5)
> > I suggest that we replace this definition as follows:
> > 
> > [Definition: When referring to a type, the term numeric denotes the types
> > xs:integer, xs:decimal, xs:float, and xs:double<add>, which are each derived
> > from xs:numeric</add>.]
> 
> I will also have to look at all uses of numeric in XQuery 3.1 / XPath 3.1.

xs:double etc are not "derived from" xs:numeric, at least not in the sense of XSD 1.1 part 2 where "A is derived from B" means "The base type of A is B or is a type derived from B". xs:double is substitutable for xs:numeric, which is not the same thing.
Comment 8 C. M. Sperberg-McQueen 2014-10-28 21:10:27 UTC
It makes me nervous to say that xs:integer et al. are "derived from" xs:numeric, since that would set up a direct conflict with the use of the term "derive" in XSD (in which xs:numeric, like all unions, is "derived from" xs:anySimpleType).  I think we would do better to follow the wording used to introduce the type in F and O, and say something like:

    [Definition: When referring to a type, the term xs:numeric denotes the built-in type xs:numeric, which is a union of (in order) the types xs:double, xs:float, and xs:decimal.]

I am aware that there are parts of the XSD spec that use "derived" in precisely the way I am here cautioning against; experience with the utility of those usages is one reason I am expressing my concern about this.
Comment 9 Jonathan Robie 2014-11-11 16:25:27 UTC
The definition now reads as follows:

[Definition: When referring to a type, the term numeric denotes the types xs:integer, xs:decimal, xs:float, and xs:double which are all member types of the built-in union type xs:numeric .]
Comment 10 Michael Kay 2015-07-06 09:02:27 UTC
Confirmed that this is fixed in the current draft specifications.