RE: [XSLT 2.0] Question about decimal arithmetic

I would prefer to treat this as a comment on Functions and Operators rather
than as an XSLT comment.

I entirely share your concerns: I would much prefer decimal arithmetic to be
fully interoperable. However, we are starting with the position that (a) XML
Schema does not defined the maximum precision supported by an xs:decimal,
and (b) XML Schema doesn't even say what should happen if your source
document contains more decimal digits than the implementation allows.

Generally speaking (and without wishing to speak for any individual
companies) my perception is that XQuery vendors are willing to sacrifice a
bit of interoperability in this area in return for extra run-time
efficiency.

It would be possible in principle for XSLT to impose stricter rules than
XQuery does, though I'm not sure this would be a popular option among WG
members, and it's difficult because the schema rules themselves are so open.

Michael Kay


> 
> Divison of decimal numbers is not well specified.  There are 
> two aspects of the problem:
> 
>    1. How many fraction digits should be kept? For example, 
> what is the result of 1.0 div 3.0?
> 
>    2. Should the answer be rounded or truncated?
> 
> I have been told previously that the answer is 
> "implementation defined", but it's hard for me to accept 
> arithmetic that is "implementation defined".  Since I am 
> chairman of the OASIS XSLT Conformance committee, I would 
> like to be able to produce a test suite that expects known 
> answers to numerical operations.
> 
> I have a suggestion:
> 
> For XSLT processors which are schema-aware, it is possible to 
> specify the number of fraction digits in the result from any 
> operation.  In this case, my first question has a clear 
> answer.  I propose that some mechanism be added to XSLT so 
> that, even without schemas, the number of fraction digits can 
> be specified.  I believe that this would solve my problem, 
> and that, along with a statement in the spec about rounding, 
> it would make decimal arithmetic precise, as it should be.
> 
> jeff kenton
> 
> 
> 
>