I tried running Java2WSDL to generate a WSDL for a
document-style/literal-encoded Web service. I added the arguments:
--style DOCUMENT --use LITERAL

The result contains a multitude of same-named elements representing input
parameters. Including:
  <element name="in0" type="xsd:string" /> 
  <element name="in0" type="xsd:string" /> 
  <element name="in0" type="xsd:string" /> 
  <element name="in0" type="impl:Foo" /> 
  <element name="in0" type="xsd:string" /> 
  <element name="in0" type="xsd:string" /> 
And so on...

You can see this is bound to create problems when the duplicates have
different types. For example, the following message needs an in0 part of type
Foo, but there’s nothing to specify that in0 is a Foo and not a string.
<wsdl:message name="addNoteRequest">
   <wsdl:part element="in0" name="in0" /> 
</wsdl:message>
********************************************
The other funny thing about this WSDL involves the element that the above
<element> elements appear inside:
<schema targetNamespace="" xmlns="http://www.w3.org/2001/XMLSchema";>

Meanwhile, my complex types’ definitions appear in the parent element:
<schema targetNamespace="urn:bar.foo"
xmlns="http://www.w3.org/2001/XMLSchema";>

I expected all this stuff (including the <element> elements) would just appear
in something like the latter <schema> element, the one with my own target
namespace. I didn’t expect the <schema> with the empty target namespace.

If everything were in the same namespace, then the entire contents of the
<soap:Body> element could use the same namespace -- no? Like:
<soap:Body>
    <f:Foo xmlns:f="urn:bar.foo">
      <f:arrayOfBars>
        <f:Bar>
          <f:ID>000001</f:ID>
        </f:Bar>
        <f:Bar>
          <f:ID>000004</f:ID>
        </f:Bar>
      </f:arrayOfBars>
    </f:Foo>
</soap:Body>

Reply via email to