Example of a message defined to be used with a document style web service. Note that a <part>
element inside a <message> element declares an element attribute.
Thus, a <part> element inside a <message> may declare a type attribute or an element attribute.
- When the <message> is to be used with an RPC web service, use the type attribute.
- When the <message> is to be used with a document style web service, use the element
With document style web services, the BP mandates that each message have zero or one part.
I'm not clear why we can't use type instead of element in this case.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
A quick recap of what the WS-I BP 1.1 has to say about message definitions in Document/Literal and RPC/Literal bindings:
R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the type attribute.
R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.
The WS-I BP 1.1, section 4.4.1, also contains a motivation for the above rules.
Briefly, the reason is because of a part defined using the type attribute cannot be nillable and must occur exactly once. This makes sense with RPC-type operations - the usually have a fixed number of parameters that always need to be present. Admitted, object references in method calls can be null, but it feels like an exception to me more than a rule.
Hope this sheds some light!