php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57663 WSDL Generated Does Not Validate
Submitted: 2007-05-10 15:34 UTC Modified: 2007-06-29 09:00 UTC
From: michael dot caplan at henryschein dot com Assigned: tuscany 1297 (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5.2.1 OS: CentOS 4
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: michael dot caplan at henryschein dot com
New email:
PHP Version: OS:

 

 [2007-05-10 15:34 UTC] michael dot caplan at henryschein dot com
Description:
------------
My WSDL generated does not validate (ran against the oXygen editor and Mindreef SOAPscope).  The bindings elements appears to be adding bogus child elements (operation contains a child of operation & binding contains a child of binding).


The following diff fixed these issues:


Index: Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php
===================================================================
--- Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php	(revision 195)
+++ Z:/michael/labnet_online/api/lib/SCA/Bindings/soap/ServiceDescriptionGenerator.php	(working copy)
@@ -120,18 +120,10 @@
             $binding                     = $wsdl->createDataObject('binding');
             $binding->name                 = "{$class_name}Binding";
             $binding->type                 = "{$wsdl->targetNamespace}#{$class_name}PortType";
-            $soap_binding                 = $xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBinding');
-            $soap_binding->style         = 'document';
-            $soap_binding->transport     = 'http://schemas.xmlsoap.org/soap/http';
-            $binding->binding             = $soap_binding;
             foreach ($service_desc->operations as $op_name => $params) {
                 $binding_operation             = $binding->createDataObject('operation');
                 $binding_operation->name     = $op_name;
 
-                $soap_operation             = $xmldas->createDataObject(self::SOAP_NAMESPACE, 'tOperation');
-                $soap_operation->soapAction = "";
-                $binding_operation->operation    = $soap_operation;
-
                 $bo_input                     = $binding_operation->createDataObject('input');
                 $soap_body                     = $xmldas->createDataObject(self::SOAP_NAMESPACE, 'tBody');
                 $bo_input->body             = $soap_body;


Expected result:
----------------
  <binding name="Labnet_API_LabnetOnline_001_ImplementationBinding" type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">
    <operation name="getRestorations">
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>
    </operation>
  </binding>

Actual result:
--------------
<binding name="Labnet_API_LabnetOnline_001_ImplementationBinding" type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">
    <operation name="getRestorations">
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>

      <tns3:operation xsi:type="tns3:tOperation" soapAction=""/>
    </operation>
<tns3:binding xsi:type="tns3:tBinding" transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
  </binding>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-17 08:32 UTC] mfp@php.net
Mike, this is overkill. We think that the second binding element (the one in the tns3 namespace, which is really the soap namespace) is required (we see lots of examples of this for web services on www.xmethods.net) and we are even more sure that we must have the second binding element. 

Are you able to get any more information about why the wsdl does not validate? I suspect that it might be to do with the xsi:type elements. Could you try just taking out those elements? If that is the problem we could do a quick fix where we suppress them. In fact we do not want SDO to generate them at all, and it would be useful for us to know that they cause validation errors for you. After a quick fix, I could raise a defect report on the SDO code.
 [2007-05-17 09:03 UTC] mfp@php.net
I just realised that when I said 'the second binding element (the one in the tns3 namespace...' I meant the second _operation_ element (i.e. the one with the soapAction). Sorry about that.
 [2007-05-23 11:47 UTC] mfp@php.net
Can you say why the wsdl does not validate? Is it the xsi:type  attributes?
 [2007-05-23 12:17 UTC] mfp@php.net
I just raised a defect report against the underlying C++ code that is in the sdo extension. 

https://issues.apache.org/jira/browse/TUSCANY-1297
 [2007-05-23 13:09 UTC] michael dot caplan at henryschein dot com
Sorry for not being more responsive to this ticket.  The issue I'm reporting here is not the xsi:type attibute, although that is an issue that I reported in #11012.

What I'm seeing is that the element <tns3:operation> is not a valid child of <operation>.  Also, <tns3:binding> is not a valid child of <binding>.  

I validated my WSDL using both oXygen and SOAPScope, and both complained about those elements.  

I and also spent some time trying to understand the WSDL XML schema, and I don't see how these elements could be validly placed were they are in the binding section.  But, I certainly don't feel confident with my understanding of these XML grammars and there is a good chance my alalysis is wrong.  Even so, I don't understand why the to above mentioned products both fail my generated WSDL because of these elements.
 [2007-06-11 12:20 UTC] mfp@php.net
I just tried loading some SCA-generated WSDL using XERXES and got some useful messages:

Error: URI=file:///C:/Documents%20and%20Settings/Administrator/workspace/XML/Greeting.wsdl Line=48: cvc-complex-type.2.4.a: Invalid content was found starting with element 'tns3:operation'. One of '{"http://schemas.xmlsoap.org/wsdl/":fault}' is expected.
Error: URI=file:///C:/Documents%20and%20Settings/Administrator/workspace/XML/Greeting.wsdl Line=50: cvc-complex-type.2.4.a: Invalid content was found starting with element 'tns3:binding'. One of '{"http://schemas.xmlsoap.org/wsdl/":operation}' is expected.


It dawned on me that this is to do with the order of the elements in the WSDL. Because tOperation and so on inherit from tExtensibleDocumented, it is allowable for them to have elements from other namespaces e.g. from the soap namespace as we do, but the order is wrong. We are generating: 
  <binding name="GreetingBinding" type="tns2:GreetingPortType">
    <operation name="greet">
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>

      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>
      <tns3:operation xsi:type="tns3:tOperation" soapAction=""/>
    </operation>
    <tns3:binding xsi:type="tns3:tBinding" transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
  </binding>

which fails. The XML passes though if the elements from the soap namespace come first:
  <binding name="GreetingBinding" type="tns2:GreetingPortType">
    <tns3:binding xsi:type="tns3:tBinding" transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
    <operation name="greet">
      <tns3:operation xsi:type="tns3:tOperation" soapAction=""/>
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>

      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>
    </operation>
  </binding>

OK, that's the source of the problem. Now how we are going to fix it I don't know, as this is the order in which it comes out from SDO. Pass to Tuscany I suppose.
 [2007-06-11 12:28 UTC] mfp@php.net
I just added this new information to Tuscany JIRA 1297
 [2007-06-29 09:00 UTC] mfp@php.net
I believe the order of the elements is now different and this is fixed in 1.2.2, so I am closing. Please feel free to reopen if you find the problem is still there.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Dec 01 01:03:34 2021 UTC