xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope

• Key: TUSCANY-1297
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Matthew Peters
• Component/s: C++ SDO
• Affects Version/s: Cpp-Next
• Fix Version/s: Cpp-Next

Description

We use SDO to build and generate WSDL. We use the standard WSDL and SOAP schemas (schemata?) to build the model then add port, operation, binding etc. elements, then serialise the lot to XML. There are occasional xsi:type attributes in the serialised XML which cause the WSDL not to validate or load in visual studio. Here is a snippet from WSDL that we have generated in this way:

<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>

These xsi:type attributes cause this WSDL to fail to load. I quote one of our users:

> MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will
> not import a SCA generated WSDL. It complains that it does not validate
> because of the following element attributes:

> xsi:type="tns3:tBody" of <tns3:body>
> xsi:type="tns3:tAddress" of <tns3:address>

> Stripping out these attributes resolved the VS WSDL import problem.

and a different bug report but the same problem:

> WSDL generated does not validate (ran against the oXygen editor and
Mindreef SOAPscope).

Comments

[Pete Robbins]

Is it possible to post the complete document rather than the snippet? I assume tns3 is the wsdl/soap namespace? Is the xsi namespace defined in the document?

[Matthew Peters]

I can post one that shows the same problem that I just generated from one of our own components. You'll see that tns3 is the soap namespace and yes xsi is defined. If you want them you'll find the wsdl and soap xsd documents that we use at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd and http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns2="http://Greeting" xmlns:tns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns3="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://Greeting">
  <types>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="http://Greeting"
      elementFormDefault="qualified">
      <xs:element name="greet">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="name" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>

      </xs:element>
      <xs:element name="greetResponse">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="greetReturn" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:schema>

  </types>

  <message name="greetRequest">
    <part name="greetRequest" element="tns2:greet"/>
  </message>
  <message name="greetResponse">
    <part name="return" element="tns2:greetResponse"/>
  </message>
  <portType name="GreetingPortType">

    <operation name="greet">
      <input message="tns2:greetRequest"/>
      <output message="tns2:greetResponse"/>
    </operation>
  </portType>
  <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>
  <service name="GreetingService">

    <port name="GreetingPort" binding="tns2:GreetingBinding">
      <tns3:address xsi:type="tns3:tAddress" location="http://localhost/examples/SCA/helloworldscawsservice/Greeting.php"/>
    </port>
  </service>
</definitions>

<!-- this line identifies this file as WSDL generated by SCA for PHP. Do not remove -->

[Matthew Peters]

Actually I just found that the xsi:type is not the problem. Sorry to mislead you. It is the order in which the elements in the binding and operation elements come out: .

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/Gr
eeting.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/Gr
eeting.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>

[Matthew Peters]

I realise I have got a problem here - I raised the original JIRA with a title that presupposed what the problem was. Really the problem is that the WSDL will not validate with visual studio, soapscope, oXygen, or, I now discover, XERCES. There appear to be at least two problems:

xsi:type upsets visual studio

the order of the <tns3:xxxx elements upsets XERCES

I assume, though can't be sure, because I have not tried them, that soapscope and oXygten are upset by the second problem.

So there are two problems with the given WSDL. Are you okay with having them both in one JIRA or do you want it split into two?

[Pete Robbins]

I have fixed the element ordering problem.

The writing of xsi:type is actually valid but unnecessary. I will look at another fix o try and prevent these being written

[Matthew Peters]

I concur this is fixed. Thank you!