php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57827 Don't remove xsi:type when saving to xml
Submitted: 2007-09-06 10:09 UTC Modified: 2017-01-10 08:10 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: mattsch at gmail dot com Assigned:
Status: Suspended Package: SCA_SDO (PECL)
PHP Version: 5.2.1 OS: Gentoo Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mattsch at gmail dot com
New email:
PHP Version: OS:

 

 [2007-09-06 10:09 UTC] mattsch at gmail dot com 
Description:
------------
This is somewhat related to the tuscany bug early about xsi:type.  There are schemas that rely on the xsi:type and without it, the xml request/response will be unintelligible.  Don't remove the xsi:type.

Reproduce code:
---------------
        public function toXML($sdo)
        {
            SCA::$logger->log('Entering');
            SCA::$logger->log("sdo = $sdo");

           try
            {
                $xdoc   = $this->xmldas->createDocument('', 'BOGUS', $sdo);
                $xmlstr = $this->xmldas->saveString($xdoc, 0);

                // remove the xsi:type="<type of the top level element>" and its preceding blank

#Don't remove the xsi:type
#                $xmlstr = preg_replace('/ xsi:type=".*"/','',$xmlstr);

                SCA::$logger->log("xml = $xmlstr");
                return         $xmlstr;
            }
            catch( Exception $e )
            {
                $problem = $e->getMessage();
                if ( $e instanceof SDO_Exception )
                $problem = "SDO_Exception in toXML : " . $problem ;

                /**
                 * Depending on whether the function is being used on the client side
                 * or the server side either report the problem to the client, or
                 * record the problem in the error.log
                 */
                trigger_error($problem);

                /* When the 'TypeHandler is being used by the Soap Server          */
                if ( strcmp($this->association, self::SERVER) === 0)
                SoapServer::fault("Client", "Unable to encode to XML");

            }/* End trap problem

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-09-06 18:30 UTC] mfp@php.net 
I am very happy for us to remove this line of code since I don't think it is achieving very much but I just want to check that I have understood the problem. What is confusing me is that the xsi:type should now never be generated as part of the xml. It should not have been generated in the past, in fact, so all we are doing is using preg to remove something that is never going to be there. 

The reason it is never going to be there is that the wsdl we generate has the request and response structures as elements, not as types, so xsi:type is never needed. xsi:type was being generated in the past, in error by the code that serialised the SDO to XML.

So, although I am very happy to remove the line, I don't see that it can ever cause a problem to have it there. Hence I want to check that I understand...

...so, please would you sketch out a test case that shows the line actually causing a problem?

I would feel more
 [2007-09-06 18:33 UTC] mfp@php.net 
"I would feel more" is of course a bit of left over text from an uncompleted sentence, and not some vague yearning :-)
 [2007-09-06 18:41 UTC] mattsch at gmail dot com 
Bug 11774 should outline the problem.  When you have an abstract complex type, it is imperative that you show xsi:type.  Otherwise you won't be able to identify what type of element it is.
 [2007-09-17 10:42 UTC] mfp@php.net 
My point in my last posting was that actually we do not have an abstract complex type in this example. The wsdl that we generate defines the messages and responses as elements, not  complex types e.g.:

<xs:element name="reverseResponse">
  <xs:complexType>
     <xs:sequence>
         <xs:element name="reverseReturn" type="xs:string"/>
     </xs:sequence>
  </xs:complexType>
</xs:element>

... here it is an error to have an xsi:type. If you use XERCES to try to parse xml with an xsi:type like the following you will get an error.

<tns2:reverseResponse 
  xsi:type="tns2:reverseResponse"  <!-- error !!! ->
  xmlns:tns2="http://SoapHandlerTestComponent" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns2:reverseReturn>MBI</tns2:reverseReturn>
</tns2:reverseResponse>

So my point was that because the wsdl defines elements not types, there should never be an xsi:type for the top-level message or response in the generated xml. The preg that you suggested taking out was there to stop us generating it, a left-over from a time when we were generating when we shouldn't. As I said I am happy to take it out, and will do so, but I don't believe it was doing any harm.
 [2007-09-17 11:36 UTC] mfp@php.net 
I just looked at this and the underlying Tuscany SDO code is still generating these xsi:types after all. So I believe the preg to remove these is still needed if we are to generate valid xml. 

In fact it does not matter one bit when we are both the generators and comsumers of the xml since the underlying Tuscany code likes the xsi:types. It is because we insist on the element name being BOGUS (because that is how to trigger the right behaviour from the soap extension) I think - the xml won't validate to start with so I don't think we can complain about the Tuscany behaviour.
 [2007-09-17 13:30 UTC] mattsch at gmail dot com 
The preg was removing _all_ xsi:types from the document and not just the first one and yes it was breaking as a result of that.
 [2007-09-18 08:52 UTC] mfp@php.net 
Ah, of course, thank you, I see now. We don't have a unit test that does that so I had not realised. I have changed the preg so it only removes the xsi:type from the top level element - the message or response - and leaves any other xsi:type's alone. 

That is checked back into FULMAR and will be in the next release.
 [2017-01-10 08:10 UTC] kalle@php.net
-Status: Assigned +Status: Suspended -Assigned To: fulmar +Assigned To:
 [2017-01-10 08:10 UTC] kalle@php.net 
Suspending this report as the extension have not had a release for almost 9 years.  Please revive this if the extension once again shows life
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 11:01:30 2024 UTC