DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14497>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14497

String to double conversion does not respect "XMLSchema" standard

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From [EMAIL PROTECTED]  2002-11-22 08:20 -------
Sorry for the delay...

I did not try your fix because I guess it's ok acording to your understanding 
of the problem BUT I'm not sure this is the correct way to deal with it..

I explain, the XMLSchema specification tell that a float IS IN AMERICAN FORMAT:

>From XMLSchema Datatypes:

3.2.4.1 Lexical representation
   float values have a lexical representation consisting of a mantissa followed,
   optionally, by the character "E" or "e", followed by an exponent. The 
exponent
   �must� be an integer. The mantissa must be a decimal number. The 
representations
   for exponent and mantissa must follow the lexical rules for integer and 
decimal.
   If the "E" or "e" and the following exponent are omitted, an exponent value 
of 0 is assumed. 

   The special values positive and negative zero, positive and negative
   infinity and not-a-number have lexical representations 0, -0, INF, -INF and 
NaN, respectively. 

   For example, -1E4, 1267.43233E12, 12.78e-2, 12 and INF are all legal 
literals for float

And the DECIMAL lexical representation, referenced above is:
3.2.3.1 Lexical representation
   decimal has a lexical representation consisting of a finite-length sequence 
of decimal
   digits (#x30-#x39) separated by a period as a decimal indicator.
   
   
A period is REQUIRED as separator. There is no country / language consideration 
in this specification. I guess it's to allow all over the world usage of the 
same schema.

According to the specification, guys like me, in France, have to use the 
English/American "wrong ":-) decimal format....or maybe our is the wrong ;-) !!

Stop joking, I believe that we have to conform exactly to the XMLSchema 
specification and treat number like the W3C says. So the fix is not to use the 
local decimal separator but to force the standard library to treat the number 
in the IEEE format.

The user of an XSLT transformation for example will have to use the 
formatNumber method to obtain a localized representation.

What do you think about it??

Reply via email to