RE: xslt and math

I assume this is intended as a comment on the XPath 2.0 specification,
however the correct address for comments on that spec is
The XPath 2.0 specification is currently a Proposed Recommendation and the
time for considering new requirements on the spec is long past. It's true
that the spec was a very long time in gestation, and that the use of XSLT in
applications such as SVG generation, where trigonometric function support is
needed, has grown during that time. The process of gathering requirements
for future versions of XQuery and XPath has started, and it might therefore
be a good idea to raise this requirement on the public-qt-comments list.
Please supply more evidence of the requirement: it's not good enough just to
say that math support is non-existent, you need to explain what mathematical
functions you require, and what the applications are that require these
functions. The same goes for rounding; if you want a different rounding
algorithm from those currently available, you need to explain what algorithm
you need, and why the existing algorithms are unsuited to your application.
Ideally, please provide evidence of the requirement, for example references
to national or international accounting standards.
The WGs have always taken the view that not all functions need to be in the
core language. There's plenty of scope for function libraries (either
specifications or implementations) to be made available by third parties.
The EXSLT initiative ( is one example of this, and you are
welcome to contribute to it. EXSLT already includes a selection of
mathematical functions, which are available in a number of XSLT 1.0 and XSLT
2.0 implementations, and it would be useful to know to what extent those
functions meet your application needs.
Michael Kay
(personal response)


From: [] On
Behalf Of Peter Rushforth
Sent: 19 December 2006 11:33
Subject: xslt and math

My first comment is that math support is poor to non-existent
in XSLT and should be incorporated directly in the
language rather than forcing the user to use java
or other extension functions.
Another comment I have is that the support for rounding
provides only the limited and un-common default mode
of round-half-to-even.  While this may be theoretically 
sound, it isn't practical and forces us to use java extension
Apart from this, everything is great.

Received on Wednesday, 20 December 2006 13:51:32 UTC