Hi Everett,
I feel I lucked into a great reference with Michael Kay's XSLT Programmer's
Reference. He explains there that when one of the entities being compared
is a node it takes the type of the other, so making one node a number was
sufficient. Cute huh?
According to him, and as Gary verified, strings are always supposed to be
converted to numbers in comparisons, and if both entities in a comparison
are nodes, then apparently the proper behavior is to attempt to convert the
text of both to numbers and then compare.
-Dave
-----Original Message-----
From: everett stauffer [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 10:28 PM
To: [EMAIL PROTECTED]
Subject: Re: RelationalExpr doing alpha comparisons?
What is the exact format of the "numeric" data as text?
I've found that "1000.00" will be treated as a number,
but "1,000.00" will not. However, number() always seems
to work, though I've not experimented with the effects of
mixing formats. (Say, "1.000,00" in the XML, but "1,000.00"
in the JVM environment.)
I chalked the behavior up to a rationalization that runs like:
"Any inclusion of locale specific formatting shall result in
the interpretation of the data as string, not number, unless
explicitly converted."
Performance differences could come into play, I suppose.
If an 'implicit' conversion doesn't do a locale format check,
but the use of number() does, one would want the data to
be in the locale format of your JVM, and not use number()?
So if only one of XPath statements has to be qualified (use of
number()), are we seeing that one of your fields has 'extra'
formatting and the other doesn't?
Or, that the use of number() once in a test statement forces the
type checking/conversion for all other statements in that logical
portion of the test statement?
(I was expecting to hear that
number(//Number) < number(//HighestNumber)
would be needed for a 'working' test statement.)
Everett
