SOAP WSDLs - Document/Literal
Example of the SOAP message
Here are the strengths and weaknesses of this approach:
There is no type encoding info.
You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
Document/literal is WS-I compliant, but with restrictions (see weaknesses).
The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans.
The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
WS-I only allows one child of the soap:body in a SOAP message. As you can see in Listing 7, this example's soap:body has two children.
The document/literal style seems to have merely rearranged the strengths and weaknesses from the RPC/literal model. You can validate the message, but you lose the operation name.