From: Jos de Bruijn <debruijn@inf.unibz.it>

Date: Mon, 04 May 2009 18:05:15 +0200

Message-ID: <49FF123B.5070608@inf.unibz.it>

To: RIF <public-rif-wg@w3.org>

Received on Monday, 4 May 2009 16:06:08 GMT

Date: Mon, 04 May 2009 18:05:15 +0200

Message-ID: <49FF123B.5070608@inf.unibz.it>

To: RIF <public-rif-wg@w3.org>

XPath functions and operators essentially says that each implementation can decide for itself which length for decimals it supports. For example, implementation A could support decimals of length 16, while implementation B supports decimals of length 20. In addition, each implementation can use its own rounding algorithm for representing numbers that need larger decimals. For example, implementation A could truncate numbers, while implementation B rounds them. this poses problems for us when defining things like casting functions and arithmetic operations. for example, according to XPath casting a string "0.1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" to a decimal results either in an error or a decimal of some length (given by the implementation) that is obtained from the number corresponding to the string by some arbitrary rounding algorithm. It is not possible for us to define this kind of behavior in DTB, because functions are defined as functions: you have some input values that define an output value. In addition, it is really bad for interchange, since some implementations do something, while other implementations do something else, and you get no warning. So, for casting, I propose to define the xs:decimal casting function such that the result of casting a string to a decimal is simply the number with the input string as lexical representation, and so we have no exception behavior. We might define conformance such that implementations only need to support decimals of a particular length. The problem with numeric functions are similar. With addition, subtraction, and multiplication we run into the same problem. Again, I propose to define the functions such that the output values are simply the decimals which are the result of the arithmetic operations and not from some implementation-dependent modification. With division it gets a bit more complicated. For example, there is no decimal that can represent the result of dividing 1 by 3, because there are no infinite-length decimals. If we had owl:real we could still properly defined the division function, although there is no syntactical representation for the result. I have two possible solutions for you: (1) We reintroduce owl:real and use it for the definition of numeric-divide (I think we need it only there). (2) We define the domain of numeric-divide such that only pairs of numbers a,b (if they are decimals) are included if a/b can be represented using a decimal. This means that if 1,3 are the arguments, the value of the function is not specified by DTB and is left up to the implementation. I think these are crucial issues and we need to have at least an idea of where we want to go before DTB can go to last call. Otherwise, it will not be possible to make any RIF implementations. Best, Jos

- application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 2 June 2009 18:34:08 GMT
*