This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have a number of functions whose signature includes the pseudo-type "numeric", and explain this by saying that there are actually multiple function signatures with different types (decimal, double, float, numeric). We say in section 1.4 that fn:abs(numeric) is actually four different functions with different signatures, but in XQuery ยง3.1.6 we say "fn:abs#1 references the fn:abs function" as if there were only one. This is a fudge and a mess, and it is quite unnecessary now that we support union types. We should define these functions with a signature that expects a supplied type of union(decimal, float, double), and returns the same as its result type, and all the problems go away. In addition, if we do it using a union type, then user-defined functions on numeric values can adopt the same approach (well, actually, they already can). The only complications are how to introduce a new built-in union type. Rather than make all the effort to decide what name and namespace such a type should have, I propose that we make it anonymous, and allow anonymous plain union types to be declared using ItemType syntax at the point of use: "union" "(" QName ("," QName)* ")" We then not only solve the "numeric" problem, but also provide a powerful capability for users at the same time, being able to declare union types and use them freely without pre-declaration in a schema, e.g. <xsl:variable name="d" select="@timestamp cast as union(xs:gYearMonth, xs:date)"/>
I am a user of XPath 3.0, XSLT 3.0 and XQuery 3.0. One of my activities is writing function libraries. In the past this was the FXSL library, version 1.x and 2.x. Now, having the function data-type in XPath 3.0 and the ability to define anonymous functions and have them called dynamically, it becomes possible to provide a function library consisting entirely of XPath 3.0-defined functions, so that these functions are immediately available to XQuery, XSLT, and pure XPath and to any host language of XPath. The only remaining problem is that a function that accepts numeric arguments and/or returns a numeric result, has to be implemented in different overloads -- one for each possible combination of the concrete numeric types of its arguments. Unfortunately, even this is beyond the reach of a mere mortal programmer. While having overloads with the same arity is allowed for XPath system functions, it is forbidden for user-defined functions. Thus, the only remaining solution is to use the "least-common denominator" type -- that is roughly xs:double (because value conversion is still required) -- as the type of the arguments and the result of the function. This compromises correctness (such as loss of precision) and efficiency. Fortunately, XPath 3.0 gives us hope for a solution using a pure union type of xs:decimal, xs:double and xs:float. However, the programmer has to declare and use a user-defined numeric type. The schema definition needs to be imported into every module that needs to use the numeric type. Not all host languages of XPath support importing a schema, and even the majority of existing XSLT and XQuery implementations are not schema-aware, so they cannot import a schema and the user-type it defines. Taking into account these facts, the best solution would be to create a new predefined XPath 3.1 data-type and name it conveniently as "xs:numeric". This type is the pure union mentioned above. The xs:numeric data-type would be available in all (not only schema-aware) implementations of XPath 3.1 and any of its host languages. On the surface, adding the xs:numeric data-type is easy and would not cost any specification, or implementation-related effort. On the contrary, the specification and implementation of the various system functions that have numeric parameters would be simplified. Deep inside, having the xs:numeric type would be a huge step forward that would boost the precision and efficiency of every XQuery, XSLT, XPath, or XPath-host-language programmer. Regards, Dimitre Novatchev
The WG expressed was broadly in favour of introducing xs:numeric as a named built-in union type with member types xs:decimal, xs:double, and xs:float; it now awaits a detailed technical proposal, as well as liaison with the owners of the XML Schema namespace. Introduction of SequenceType syntax for anonymous union types will be explored as a separate proposal.
*** This bug has been marked as a duplicate of bug 20631 ***
(In reply to Michael Kay from comment #3) > > *** This bug has been marked as a duplicate of bug 20631 *** But the status of 20631 is "New" while this bug (25444) was already resolved as "assigned". This is a loss of very important information! Please, kindly update the status of this bug to assigned, so that its treatment can continue normally from the point where it was interrupted. Or has there been a decision to reverse the status of this bug and the decisions of the WG?
The XSLT and XML Query WGs discussed this bug (and the technically equivalent one, bug 20631) in our joint call today. Please note that there is no significant difference, for purposes of these two WGs, between the statuses of New and Assigned. Closing this bug as a duplicate of bug 20631 is not an indication that the WG has changed its mind about anything; it is at most an indication that bug 20631 was here first. Since each bug points to the other, any discussion of bug 20631 will be informed by the discussion here. The upshot of our discussion today was to establish that no one seems to have any objections to the solution as outlined in [1], which proposes xs:integer, xs:decimal, xs:double, xs:float as the order of members (noting that it replicates the priorities used in casting numeric literals, and noting also that xs:integer is redundant for use of xs:numeric as a sequence type, and xs:float is redundant when it comes to casting behavior). So -- no worries, the xs:numeric type is coming, as soon as we get through the coordination issues with the custodians of the XSD spec and namespace. [1] https://lists.w3.org/Archives/Member/w3c-xsl-query/2014May/0053.html (member-only link)