[DTB] issues with numeric casting/built-in functions

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