xsl:if test fails for comma separated number
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.
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).
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 < '0.00'"> DR </xsl:if>
<xsl:if test="@balance >= '0.00'"> CR </xsl:if>
...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).
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
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.Registry
(For application on OC4J server, that works)
Version: 1
Vendor: Oracle Corporation.
Vendor URL: http://www.oracle.com
[TransformerFactory here is oracle.xml.jaxp.JXSAXTrans
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.
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.Registry
(For application on OC4J server, that works)
Version: 1
Vendor: Oracle Corporation.
Vendor URL: http://www.oracle.com
[TransformerFactory here is oracle.xml.jaxp.JXSAXTrans
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.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
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.
BTW :
<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 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.
BTW :
<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.
ASKER
One more observation :
<xsl:if test="'10,000.00' >= '0.00' "> fails but
<xsl:if test="'@balance' >= '0.00' "> works when @balance = 10,000.00.
Now that's funny.
<xsl:if test="'10,000.00' >= '0.00' "> fails but
<xsl:if test="'@balance' >= '0.00' "> works when @balance = 10,000.00.
Now that's funny.
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?
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?
ASKER
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.
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.
welcome, good luck with this
ASKER
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.