Matthew Peters wrote:
> OK, this testcase is enough to demonstrate the problem (using
> Sample.wsdl from the defect that Silvano raised). The problem is not
> that the sdo does not have the precision; it's in the serialisation to
> xml which treats the value like 'print' does and not 'print_r'. Still
> needs further investigation.
> 
> <?php
> $xmldas = SDO_DAS_XML::create('./Sample.wsdl');
> $sdo = $xmldas->createDataObject('http://Sample','getDoubleResponse');
> $sdo->getDoubleReturn = 1.23456789;
> 
> print_r($sdo);
> print "\n";
> 
> print $sdo;
> print "\n";
> print "\n";
> 
> $xdoc   = $xmldas->createDocument('', 'BOGUS', $sdo);
> $xmlstr = $xmldas->saveString($xdoc, 0);
> print $xmlstr;
> ?>
> 
> 
> this gives:
> 
> 
> SDO_DataObjectImpl Object
> (
>     [getDoubleReturn] => 1.23456789
> )
> 
> object(SDO_DataObject)#3 (1) {getDoubleReturn=>"1.235e+000"}
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <BOGUS xsi:type="tns2:getDoubleResponse" xmlns:tns2="http://Sample";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <tns2:getDoubleReturn>1.235e+000</tns2:getDoubleReturn>
> </BOGUS>
> 

I did at first stop reading this thread at its first line, which was 
really not a good way to get my attention. But I have relented, and 
tried running Matthew's testcase above, though substituting the first 
two lines with some straight SDO using Silvano's original schema:

   $xmldas = SDO_DAS_XML::create('./Samples.xsd');
   $sdo = $xmldas->createDataObject('http://Samples','Sample');

I observe that there doesn't seem to be a problem with the data itself, 
only with the way it is printed. The difference is that in the "good" 
cases, the data (PHP Double type) is handed to the PHP engine to print, 
but in the "bad" cases, it is Tuscany which is doing the conversion to a 
string before PHP gets a look in.

(Note that PHP has a single type which is used for floats and doubles, 
whereas Tuscany, C++ and XML treat them as different types.)

When PHP prints a double, it uses a printf format string of "%.nG", 
where the precision (n) is configurable (see 
http://php.net/manual/ini.core.php#ini.precision). %G says use %E 
(scientific) or %f, whichever is the shorter.

When Tuscany does the same thing, it uses "%.3Le" for a double, or 
"%.3e" for a float. This means that it will always use scientific 
notation, with only 3 decimal places, as we have observed.

It's possible to avoid using the Tuscany conversion code by adding a 
chunk more code to handle it ourselves, as we do when returning data as 
values, rather than just printing it. I'll have a go at this.

I think this accounts for the behaviour of Matthew's testcase. But we're 
going through similar Tuscany code when converting between SDOs and XML, 
and this will really need a Tuscany change.

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 
where Tuscany got its format. Certainly not from the XML schema spec: 
http://www.w3.org/TR/xmlschema-2/#float.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to