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 Summary: String to double conversion does not respect "XMLSchema" standard Product: XalanC Version: 1.4.x Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: XalanC AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If, in XMLSchema, you defined a float or double attribute, you have to specified it's value using the english way of formatting number, I mean the "." a sdecimal separator. But during an XSLT processing, each string needing to be used as a number is converted to Double using the "inline double DoubleSupportconvertHelper(const XalanDOMChar* theString, bool fGotDecimalPoint)" (file PlatformSupport\DoubleSupport.cpp line 637). This function uses the atof conversion "instruction" but this one is, under Windows, localized. So the conversion from "6.25" for example give "6" because my "user code" use setlocale to put the locale parameter to french (with a "," as separator). I guess this problem may be encouter on other platform. To reproduce the "bug" just write an xml file with numerical attribute in some element like this: <elt value="6.25"/> Then use a simple XLST file trying to multiply the value by 100 and see the result. example: <xsl:template match="elt"> <xsl:value-of select="@value * 100"/> </xsl:template> If you use the XalanTransform example, no problem. but if you add a setlocale (LC_NUMERIC, "French_France") before calling ::tranform....oops you optain 600 and not 625... For what I know, XMLSchema force us to write numbers in English form for the data to be validated (in my XMLSpy version, "french" float are refused...). So I guess that the Xalan code should treat number as English ones, even if this is anoying in some other situations. The path I submit is to simply wrap the atof call with setlocale calls like this: char* locale = setlocale(LC_NUMERIC, "English_USA"); double result = atof(theBuffer); setLocale(LC_NUMERIC, locale); return result; Or the users should be inform that Xalan converts EACH string to number using locale parameter and that if they wrap their xalan transformation in code like the one I give the problem is "solved". What do you think?
