Hi Caroline,
Could you also provide us a patch with the same fix for the actual SDO code
(https://svn.apache.org/repos/asf/tuscany/cpp/sdo/) ?
Thanks in advance,
Adriano Crestani
On Tue, Jun 24, 2008 at 1:29 PM, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> Simon Laws wrote:
>
> On Fri, Jun 20, 2008 at 12:32 AM, Caroline Maynard <
>> [EMAIL PROTECTED]> wrote:
>>
>> A PHP SCA/SDO user has observed a problem when working with a schema that
>>> uses floating point types.
>>>
>>> Everything is fine when we read the data from Tuscany as a floating point
>>> type. But when Tuscany converts the data to a string, then it loses
>>> precision, and in particular this happens when the data is written to an
>>> XML
>>> document.
>>>
>>> When Tuscany does this conversion, it uses a format string of "%.3Le" for
>>> a
>>> double, or "%.3e" for a float. This means that it will always use
>>> scientific
>>> notation, with only 3 decimal places, resulting in significant loss of
>>> precision.
>>>
>>> I did check this against the SDO 2.1 spec, and that expects doubles and
>>> floats to be printed as [0-9]*('.'[0-9])?('E'|'e'). So I don't know why
>>> Tuscany chose its format. Certainly not from the XML schema spec:
>>> http://www.w3.org/TR/xmlschema-2/#float.
>>>
>>> Is there anyone still around who can shed any light on why Tuscany does
>>> this? Do you agree it's a problem? I'm guessing that that raising a JIRA
>>> isn't going to get me a fix, but if I develop a patch myself, would
>>> someone
>>> volunteer to apply it?
>>>
>>> (You'll recall that in PHP we are using the sdo-cpp-pre2.1 branch, but
>>> the
>>> same format string is used in trunk, so the problem applies there too.)
>>>
>>>
>>>
>>> Hi Caroline
>>
>> I've no idea why Tuscany chose this format but it doesn't sounds right to
>> me. If you make the change as a patch I can go ahead and apply it.
>>
>
> Thanks Simon. I've attached the patch to Tuscany 2439:
> http://issues.apache.org/jira/browse/TUSCANY-2439
>
> You'll see that the patch was created from the sdo-cpp-pre2.1 branch. The
> same issue does exist in the cpp trunk, which uses the same format strings
> when doing a double/float to string conversion. However I haven't created a
> patch for trunk because I don't have an environment where I can test it.
> I'll gladly work one up if someone is willing to work with me on it.
>
>
