- From: <bugzilla@jessica.w3.org>
- Date: Sun, 04 May 2014 21:25:01 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25444 dnovatchev@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dnovatchev@gmail.com --- Comment #1 from dnovatchev@gmail.com --- 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 -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 4 May 2014 21:25:02 UTC