[ Apologies if you see this twice -- the last message
I sent doesn't seem to have gone through yet ]
Miloslav Nic wrote:
> BTW: Are there more functions causing problems for non Java
> implementators?
The requirement that numbers are represented as per IEEE 754
is troublesome. There's no portable way to deal with NaNs
and infinities in C, C++, or most other languages (C9X makes
things a little easier, but implementations aren't widely available
yet.)
The 'string()' function is astonishingly difficult to implement
correctly without native language support, specifically clause 2,
subclause 7, XPATH section 4.2: "there must be as many, but only
as many, more digits as are needed to uniquely distinguish the
number from all other IEEE 754 numeric values."
I can't think of any document transformation tasks that actually
require floating-point calculations; IMHO a much better choice would
have been pointed infinite-precision rationals.
Or -- to make things easier for languages other than Scheme, Haskell, ML,
Lisp, etc. -- fixed-precision rationals with the numerator and denominator
limited to 32 bits. C and Java programmers could use a pair of longs
with 0/0 as the exceptional "NaN" value. (An exceptional value is
needed to represent the result of number("...") where "..." isn't
a valid number). Mandating IEEE 754 doubles seems gratuitously
Java-centric to me.
--Joe English
jenglish@xxxxxxxxxxxxx
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list