Re: [xsl] format-number() causing problems to non-java implementators

[ 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