GNOME Bugzilla – Bug 72236
format-number - negative pattern does not work correctly
Last modified: 2009-08-15 18:40:50 UTC
Daniel, I guess I keep stressing you out with numbers.. (sorry :( The following test case (libxslt 1.0.12): <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:value-of select="format-number(-1,'###,###;###,###')"/>| <xsl:value-of select="format-number(-1,'###,###;###,### ')"/>| </xsl:template> </xsl:stylesheet> gives: -1| 1 | I would expect: 1| 1 | as a result. It looks like the pattern for negative numbers is not used if there is not a non-special character in it (in the example I put a space, but the classical examples are with "()" to indicate that it is negative, or with CR to indicate a credit, etc. TIA. Jon Zaid
Seems Igor the maintainer of the Windows port objects modifying those files which are generated by Visual Studio. I can't help on this bug which is not GNOME related. You should subscribe to the mailing list and discuss with Igor about this. http://mail.gnome.org/archives/xml/2002-March/msg00058.html Daniel
Oops ... this was actually intended for another bug ... Daniel
Okay, apparently, according to the comment in the code, if the patterns for positive and negative numbers are the same, then Java seems to keep the default sign handling. It is actually a specific case in the code flagged as such for Java compatibility: ---- libxslt/number.c , xsltFormatNumberConversion() , line 1050 ---- /* Here's another Java peculiarity: * if -ve prefix/suffix == +ve ones, discard & use default */ if ((nprefix_length != prefix_length) || (nsuffix_length != suffix_length) || ((nprefix_length > 0) && (xmlStrncmp(nprefix, prefix, prefix_length) !=0 )) || ((nsuffix_length > 0) && (xmlStrncmp(nsuffix, suffix, suffix_length) !=0 ))) { prefix = nprefix; prefix_length = nprefix_length; suffix = nsuffix; suffix_length = nsuffix_length; } else { default_sign = 1; } ---------------- My take on this is that referencing the Java online doc for specifying the format-number() behaviour was a gross mistake, actually making a reference implementation part of the spec and I hope it gets fixed in future version of XSLT. Now if Bjorn who wrote that code went through the work of debugging this there is probably a good reason and that behaviour should probably be kept. Are other XSLT processor handling this in a simialr way ? Daniel
I tried with Sablot .71 and MSXSL 4.0 (Napa couldn't handle format- number period!) I had to modify the Sablot to do <xsl:value-of select="format-number(-1,'0;0')"/> as it didn't like the other number format that I used in the previous example; but both Sablot and MSXSL did not put the "-" sign, i.e. they respected the "0;0" as written instead of using the default +/- notation. I did read something curious in Micheal Kay's book XSLT 2nd Edition book. He says "If there is an explicit negative subpattern, it serves only to specify the negative prefix and suffix; the number of digits, minimal digits and other characteristics are all the same as the positive pattern." So, if we are actually ignoring the pattern, then I can see some sort of strange logic behind the java code. On the other hand, two of the widely used (no offense to libxslt) engines, Microsoft and Sablot do not follow the java rule. Another curiosity.. After reading that section of the book, I made the following test. <xsl:value-of select="format-number(-1,'0;0,0')"/>| <xsl:value-of select="format-number(-2,'0,0;0')"/>| I would expect 1| 0,2| (MSXLT returns this), instead I get -1| -0,2| from libxslt, even if the formats are different in this case. I guess this is since the actual number format is ignored and only the sign is used, the two compare the same. In the end, its your call.. Thanks. jon
Well both Saxon and Xalan are Java implementations and both implement the same behaviour as libxslt on this specific issue: http://mail.gnome.org/archives/xslt/2002-March/msg00018.html http://mail.gnome.org/archives/xslt/2002-March/msg00019.html (sorry sablotron is really not in the same league when it comes to conformance to the standard I'm afraid, it seems they are actually taking number code from libxslt to improve their implementation, and MSXML is also not Java based, since the spec dictate that the behaviour is defined by Java -- which I really hate -- then it seems to me that MS implementation may just not have caught that specific behaviour). thanks for the report, it's a murky area, I hate this part... Daniel
I think we can close the bug at this point, there is no new evidence that the current behaviour is actually incorrect, thanks ! Daniel
ok.. thanks Daniel. I agree with your call.