WSDL 1.1 Issues The following loose ends and errors have been found in WSDL1.1, and should be fixed in future versions of WSDL. 1 Error in schema: "parameterOrder" attribute of "operation" not defined in WSDL schema Section 2.4.6 Parameter Order within an Operation states "a request-response or solicit-response operation MAY specify a list of parameter names via the parameterOrder attribute (of type nmtokens) while in the schema there is no parameterOrder optional attribute defined for operation References: Section 2.4.6 Parameter Order within an Operation A 4.1 WSDL Schema 2 Inconsistency: Shall "element" attribute of "part" only refer to elements defined in schema? In section 2.3 Messages, it states: " WSDL defines several such message-typing attributes for use with XSD: *element. Refers to an XSD element using a Qname. *type. Refers to an XSD simpleType or complexType using a Qname." While in the section 3.1 example 4 and example 5, element is used as follow: References: Section 2.3 Message Section 3.1 SOAP Examples 3 Error in examples: Does order matter for the child elements of "definitions"? Section 3.1 SOAP Examples, example 3 lists as the last element under . This is inconsistent with the schema where is defined as the second of the sequenced elements of the "definitionsType"; similar issue with section 4.1 HTTP GET & POST Binding example 6 where is put after References: Section 3.1 SOAP Examples, example 3 Section 4.1 HTTP GET & POST Binding example 6 A 4.1 WSDL Schema 4 Error in schema: "name" attribute of "soap:fault" is not defined in schema Section 3.6 sopa:fault grammar indicates that fault has a required name attribute while in the schema no such attribute defined for faultType References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema 5 Error in grammar: "name" attribute of "part" should be "optional" name attribute of part element is shown as required in the grammar while in the schema it's optional. The definition of partType complextype states References: Section 2.1 WSDL Document Structure Section 2.3 Messages A 4.1 WSDL Schema 6 Error in grammar: "use" attribute of "fault" should be optional Section 3.6 soap:fault grammar indicates that the use attribute of fault is required while in the schema use is defined as optional References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema 7 Error in text: "transport" attribute of "soap:binding" should be optional Section 3.3 sopa:binding grammar and the SOAP binding schema both indicate that the transport attribute of binding is optional while in the text, it is "required" References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema 8 Error in schema: "soap:operation" should be optional Section 3.4 sopa:operation grammar indicates that the operation is optional. In the text of the same section, it also states that "For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted." However, in the SOAP Binding schema, no value is specified for minOccur/maxOccur. It implies that this element is required. References: Section 3.4 soap:operation A 4.2 SOAP Binding Schema 9 Error in text: "use" attribute of "soap:body" should be optional Section 3.5 sopa:body grammar and the SOAP binding schema both indicate that the use attribute of soap:body is optional while in the text, it is "required" References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema 10 Inconsistency in "soap:header" specification Section 3.7 sopa:header and soap:headfault grammar indicates that there can be 0 or more element while in the schema no minOccur/maxOccur specified for which means there can be exactly one occurrence References: Section 3.7 sopa:header and soap:headfault A 4.2 SOAP Binding Schema 11 Array Declaration Issues Inheritance rules have been changed since 2000/10 version XML schema. It requires that everything must be re-stated to be inherited. In section 3.1 SOAP Examples (example 5) and section 5.11 MIME Binding example (example 7), array declaration still follows old rules. See Appendix A for more details. References: Section 3.1 SOAP Examples (example 5) Section 5.11 MIME Binding example (example 7) 12 Asymmetry between soap:body and soap:header This issue can be viewed as an example our observation that the binding extension specification is not clearly documented and not sufficient. Section 3.5 states that "The soap:body element specifies how the message parts appears inside the SOAP Body element. ... provides information on how to assemble the different message parts inside the Body element if the SOAP message ". Section 3.7 states that "the soap:header and soap:headerfault elements allows header to be defined that are transmitted inside the Header element of the SOAP Envelope. It is patterned after the soap:body element ". These statements imply that it should be similar to assemble different message parts inside SOAP message body and message header. However, the attributes of these two elements are quite different and the usage of the word "part(s)" and "message" is very confusing to many readers. The grammar section lists these elements as below: * * The text about parts attribute of soap:body reads as " The optional parts attribute of type nmtokens indicates which parts appear somewhere within the SOAP Body portion of the message (other parts of a message may appear in other portions of the message such as when SOAP is used in conjunction with the multipart/related MIME binding). If the parts attribute is omitted, then all parts defined by the message are assumed to be included in the SOAP Body portion". Here it's very hard to understand if "part" refer to the WSDL message part or the SOAP message part, also it's hard to understand if it's talking about WSDL message or SOAP message. There is no explanation about: * Why does soap:header need to have the "message" and "part" attributes while soap:body can be bound to a particular input/output message? * Is it intended to allow part from other messages to be incorporated into the SOAP header? Then what is the meaning of grouping parts into a message? * Why does not soap:header allow more than one part per message while in soap:body "parts" attribute can be a list of WSDL message parts? 13 Typo in Section 3 SOAP Binding "This binding grammar it is not an exhaustive specification since the set of SOAP bindings is evolving. Nothing precludes additional SOAP bindings to be derived from portions of this grammar." References: Section 3 SOAP Binding 14 Typo in Section 3.6 soap:fault "The soap:fault element specifies the contents of the contents of the SOAP Fault Details element. It is patterned after the soap:body element." References: Section 3.6 soap:fault 15 Typo in Section 3.4 soap:operation "...For the HTTP protocol binding of SOAP, this is value required (it has no default value)." References: Section 3.4 soap:operation