xsl:if test fails for comma separated number

calboronster used Ask the Experts™
Hi guys,

My application has an XML transformation over XSL which then is displayed to the end user.
The entire application is existing over Oracle 9i appserver (JDK1.4) and is presently ported to Weblogic 11G.(JDK1.6)

Now there is behavior which seems quite weird between the two version above.
As a part of display logic we have done something like this (to show whether the amount is debit or credit based on it being positive or negative) where numbalance is the users balance and DR/CR is a simple text.
<xsl:value-of select="@balance"/>
<xsl:if test="@balance &lt; '0.00'"> DR </xsl:if>
<xsl:if test="@balance &gt;= '0.00'"> CR </xsl:if>

Open in new window

The funny part is if the amount is more that 3 digits we put a comma in it (10,123.45) through our service code. This comma causes the test function (to consider the number as text?) and not work; hence neither CR nor DR is displayed after the balance.

This same functionality works in Oracle 9i appserver (OC4J) even with negative balance.
For example (-19,456.00) DR will be displayed.
I am pretty sure that issue is with THE COMMA in number as the stuff works correctly with 3 digits and below on both JVMs.

[Does XSL allow comparison of numbers with legit commas in it]
Please do not suggest me the 'correct' way to do the comparison (we already know and are screwed by a developer who has left); only why it is different in different places (as we need to find why and not how).
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Gertone (Geert Bormans)Information Architect
Top Expert 2006
XSLT input numbers have to be of the form
do like this
number(translate($your-num, ',', '')) to do the compare
the translate will drop the ','


Hi Gertone,

I know it should have been done as you say, but (unfortunately) it was not.
My question is how could  xsl:if test work properly with nn,nnn.nn (comma included) in one of the earlier versions (and treat it as a number).

Is there some change in XSLT transformation logic over the time or am I missing something.
Mind you that the XSLT transformation happens in java code on the application server in both cases.
Gertone (Geert Bormans)Information Architect
Top Expert 2006
I did not see your last line in the question, sorry
I thought you just needed a fix and jumped in too fast

There is much too little information in your question to know for sure what is going on, it is not simply a JVM thing
To what processor is the transformer bound, to what parser is the parsing bound.
So there is a lot in your javacode that could be different between oracle and weblogic
and depending on what is on the classpath...

I know for instance that starting 1.5 or 1.6 it is highly recommended to chunk out the native java xml parser and replace it with xerces or something since the xml parser is no good
maybe weblogic fixed that one way or another

If you are absorbing a service call using soap and the type of the attribute is known by the schema (or WSDL) to be a float,
you have no guarantuee on how it is progressed in the XML object that serves as the input for your XSLT

There are a number of things you can do

1. In the XSLT make a copy of the attribute in a random node and see how it serialises without testing.
It is likely different between versions

2 In the XSLT add some calls to system-property() to figure out things like xsl:version, xsl:vendor... and maybe a bunch of others if you find out you are using XSLT2
Starting with Angular 5

Learn the essential features and functions of the popular JavaScript framework for building mobile, desktop and web applications.


Thanks Gertone,

There is no soap call in picture, we have a simple logic of java creating a generic XML response and a transformer that transforms this xml over site specific xsls to create html response.

(I could not understand the first to-do you mentioned, let me try that and update you..)
For second part, here is something I found on using your directions (is something obvious that you see here):

1. Output of XSL system properties :
(For application on Weblogic 11G server, that fails at xsl:if)

Version: 1.0
Vendor: Apache Software Foundation (Xalan XSLTC)
Vendor URL: http://xml.apache.org/xalan-j
[TransformerFactory here is weblogic.xml.jaxp.RegistrySAXTransformerFactory]

(For application on OC4J server, that works)

Version: 1
Vendor: Oracle Corporation.
Vendor URL: http://www.oracle.com
[TransformerFactory here is oracle.xml.jaxp.JXSAXTransformerFactory]

Mind you that in both places I have Xalan (and Xerces) of same version (in classpath).
I guess (and see in the code) that we are not using any native java XML transform etc.

I hope this answers most of your questions.
Information Architect
Top Expert 2006
So, You have your difference allready.

It seems as if the Oracle XSLT processor was buggy, allowing the ',' in the numbers
(at least if the next test fails)
You might have Xalan on the ClassPath, you are aparently not using it in the Oracle setting,
I bet you are also using the Oracle parser
oraxsl (the Oracle XSLT) was known to have a bunch of bugs (last time I checked was around 2006 or so, but I believe 9i is that old isn't it?)
and inconsistencies and the DOM was quirky.

You may want to test were the "bug" is, parser or XSLT
by adding a <xsl:copy-of select="@balance"/>
you could copy the balance attribute and see how it originally was (by looking at the raw result of the transform)
It might be that the parser does some normalisation based on a schema

But you also might just be happy with the fact that you now know that you have two different XSLT processors in place and they behave differently
(they always do :-)
The original XSLT was designed for the ora XSLT and has a flaw.
From this, fix the XSLT and move on. If you need help fixing, let me know


Hi Gertone,

One man's bug is another man's feature. This is an ancient application which we are trying to upgrade from OC4J to Weblogic and faced this issue out of expected.

(Let me ask you this though I can already guess the answer).
Is it possible somehow through any configuration to make Xalan simulate 'the bug', namely ignore the ,(commas) in number in xsl:if. No tough code changes.
(This cr*p is all over the place and would require a hell of effort to get it good).

To let you know one more thing, I tried to remove Xalan/Xerces from my server JVM classpath and the application still works as-is. It means the XSLT implementation libraries are internally present in Weblogic and used thus. Classpath makes no difference. Does that look good to you?

I have a fix ready for this issue already where I use translate and format-number etcetera, but was trying to avoid that. But this now looks inevitable. Before that I test the 'bug' with randomly placed commas.

<xsl:value-of select="@numbalance"/> --> -10,504.45 as csv numerical output
(or did you mean copy-of? I am sure about that comma that is passing through our java code)

Thanks again Gertone.


One more observation :

<xsl:if test="'10,000.00' &gt;= '0.00' "> fails but
<xsl:if test="'@balance' &gt;= '0.00' "> works when @balance = 10,000.00.

Now that's funny.
Gertone (Geert Bormans)Information Architect
Top Expert 2006

I don't know of a configuration for Xalan that would fix that
It could be that Xerxes can serialise differently (or pass on differently) when it is aware that those are numbered types. This is all very fuzzy since an XSLT1 processor should not be type aware on that level

I can understand that you don't want to change the stylesheet at all different places.
I think I would just slip in a different stylesheet that does an identity copy but "normalizes" the numbers in all numeric fields

From your next observation.
It seems it is not a bug in oraxsl then but it is due to something that the parser does in this case. Weird, is there a schema involved?


I forgot to mention that my last observation IS on Oracle 9i app server.
It could be that the feature/bug in OraXSL that works only in case of elements/attributes.
Not with direct value (?). Maybe maybe.

On WebLogic, neither works as expected.
Also there is no schema involved in these logics.

Lets call it quits and give the corpse a bad name.

From what I come to know from our discussion and the observations is that there used to be some feature in OraXSL which didn't translate into Xalan standards. And now that Weblogic inherently uses Xalan the feature went missing ( like : identifying comma separated number as a number and not text). Just scared what else might have gone.

Better way I am taking is to use translate for all the number as you mentioned in very first post.

Thanks Gertone for suggesting the analyses.
Gertone (Geert Bormans)Information Architect
Top Expert 2006

welcome, good luck with this

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial