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>