Accommodating Java-library bugs reflected in processor conformance

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Hi folks,

One of the issues I wanted to raise before our next meeting was what I 
called "bug emulation mode" in our last meeting.  I've come across a 
situation where Java-based tools are relying on an implementation of a Java 
library that I'm sure must have a bug in it.

The simple stylesheet to illustrate this is as follows and can be run with 
any input:

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 version="1.0">

<xsl:template match="/">
   <xsl:value-of select="format-number(-12345,'#,###;(#)')"/>
</xsl:template>

</xsl:stylesheet>

According to one of my students (thank you Edmund), the non-Java-based 
4XSLT program runs as I would anticipate:

[ejm@linux2 ejm]$ 4xslt xmlFN.xml xslFN.xsl
<?xml version='1.0' encoding='UTF-8'?>
(12345)
[ejm@linux2 ejm]$

Note that there is no formatting of the negative number within the 
parentheses because that portion of the input grammar defining the display 
of negative numbers is an unpunctuated sequence of digits.

However, the following are the results, in order, of XT, Saxon and Xalan(Java):

T:\ftemp>xt test.xsl test.xsl
<?xml version="1.0" encoding="utf-8"?>
(12,345)
T:\ftemp>saxon test.xsl test.xsl
<?xml version="1.0" encoding="utf-8"?>(12,345)
T:\ftemp>x:xsljavaxalan test.xsl test.xsl test.out
Invoking Xalan jar....
========= Parsing file:/T:\ftemp\test.xsl ==========
Parse of file:/T:\ftemp\test.xsl took 1582 milliseconds
========= Parsing file:/T:\ftemp\test.xsl ==========
Parse of file:/T:\ftemp\test.xsl took 250 milliseconds
=============================
Transforming...
transform took 170 milliseconds
XSLProcessor: done

T:\ftemp>type test.out
<?xml version="1.0" encoding="UTF-8"?>
(12,345
T:\ftemp>

Note that these Java implementations are all punctuating the digits of the 
negative number.

Other tests reveal that while the negative number prefix and suffix are 
correctly being respected, any pattern describing the digits of negative 
number formatting is being ignored in favour of the pattern describing the 
digits of positive number formatting.

I think it is obvious that all three are not conformant, but I'm sure we 
will need to address the above situation explicitly to explain to many of 
the readers who I suspect will be confused by what appears to be "the 
majority interpretation" when I suspect it is just a bug in the Java 
runtime library.

.............. Ken

--
G. Ken Holman                      mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.               http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0     +1(613)489-0999   (Fax:-0995)
Web site:     XSL/XML/DSSSL/SGML/OmniMark services, training, products.
Book:   Practical Transformation Using XSLT and XPath ISBN1-894049-05-5
Article: What is XSLT? http://www.xml.com/pub/2000/08/holman/index.html
Next public instructor-led training:             2001-01-27,2001-02-21,
-                            2001-02-27/03-01,2001-03-05/07,2001-03-21,
-                                   2001-04-06/07,2001-05-01,2001-09-19