SOAP encoding is basically a lost cause which has been abandoned by current SOAP stacks.
Avoid it at all cost.
Also you imported the namespace but you didn't specify a location for the schema (the namespace identifier is a URI and in this case it looks like a URL but it doesn't have be an addressable URL - which is why you have to specify a schema location).
Usually it is more efficient and reliable to access a local rather than a remote copy of the schema.
Jaspreet Singh Puri
Joined: Jul 15, 2007
You are absolutely right. We should avoid using schema definition from http://schemas.xmlsoap.org/soap/encoding/. In my case, I have to migrate a axis 1.2 wsdl that uses these schema definitions so am forced to use it.
Originally posted by Jaspreet Singh Puri: You are absolutely right. We should avoid using schema definition from http://schemas.xmlsoap.org/soap/encoding/. In my case, I have to migrate a axis 1.2 wsdl that uses these schema definitions so am forced to use it.
The WSDL fragment indicates that you do not realize that you shouldn't be basing any new XML types on that schema even if you have to use it. SOAP encoding is not XML Schema driven. It is simply a loose set of rules of how data structures are transformed to semi-structured XML data and back. These rules are out-lined in Section 5 SOAP Encoding. The soap encoding schema was created as an afterthought. Its heavy use of the xs:any type (which accepts any well formed XML without any further definition of structure) highlights XML Schema's inability to capture the rules of how SOAP encoding structures its XML data. Even though WSDL is XML Schema based it side steps the issue because the "encoded" message mode moves the definition of the payload format outside of the scope of the WSDL.
RPC/Encoded may generate well formed XML, but it isn't a useful XML document in the XML Schema sense - so the use of XML Schema driven tools will be at best not very useful (you are still going to have to deal with those <xs:any> manually during marshalling and unmarshalling), at worse a serious risk to your project.