The spec does not say much about how values of abstract types are to be stringified when the type is something else xsd:string. Should it just be stringified as XML (and then URLencoded)? If it is xsd:string, then it is unclear how chars outside the ASCII range are to be handled. UTLencoded UTF8 perhaps? Is it legal for the part referenced to reference a schema element instead of a type? For http:urlReplacement it not not clear what URL escaping should be done on the replacement text. - Is an embedded "?" to be expanded into "?" or "%3f". - Is an embedded "%3f" to be expanded into "%3f" or "%253f" For http:urlReplacement it is not clear what should happen for "search patterns" where there is no correspondingly named part in the message.
The _transport_ attribute of <soap:binding> is optional, but it is not clear to me what the default is. Is "http://schemas.xmlsoap.org/soap/http" the default? If so, shouldn't the schema in section A-4.1 declare this value as the default?
According to the schema in section A-4.1 the 'name' attribute of <part> is optional. This is not indicated in the grammar in section 2.1 and section 2.3. Section 2.3 also states that "The part _name_ attribute provides a unique name among all the parts of the enclosing message". I believe the schema is wrong and that the definition of "partType" should be changed to: <complexType name="partType"> <complexContent> <extension base="wsdl:openAtts"> <attribute name="name" type="NMTOKEN" use="required"/> <attribute name="type" type="QName" use="optional"/> <attribute name="element" type="QName" use="optional"/> </extension> </complexContent> </complexType>
According to the schema in section A-4.1 the <import> element might take an subordinate documentation element. The grammar in section 2.1 ought to be changed to say: <wsdl:import namespace="uri" location="uri"> * <wsdl:documentation .... />? </wsdl:import> In WSDL 1.1 (2001-03-15) it simply says. <import namespace="uri" location="uri"/>* The namespace qualifier for <import> is also missing in the current text.
In example 1 of WSDL 1.1 (2001-03-15) the binding reference from the port does not resolve because of a typo. The binding name should be: tns:StockQuoteSoapBinding The example is missing "Soap" in there. Simon Fell also notes that examples 2,4 and 5 have the same problem.
The spec does not say much about how values of abstract types are to be stringified when the type is something else xsd:string. Should it just be stringified as XML (and then URLencoded)? If it is xsd:string, then it is unclear how chars outside the ASCII range are to be handled. UTLencoded UTF8 perhaps? Is it legal for the part referenced to reference a schema element instead of a type? For http:urlReplacement it not not clear what URL escaping should be done on the replacement text. - Is an embedded "?" to be expanded into "?" or "%3f". - Is an embedded "%3f" to be expanded into "%3f" or "%253f" For http:urlReplacement it is not clear what should happen for "search patterns" where there is no correspondingly named part in the message.
I ran across this example at http://www.w3.org/2001/03/14-annotated-WSDL-examples The example is correct but does emphasize a concern. 1) when a part is typed "element" and referenced to schema 2) and the binding's soap:body "namespace" attribute is used Spec reads Section 3.5 ...although the namespace attribute only applies to content not explicitly defined by the abstract types. ... A case becomes present where the namespace attribute can be declared and the element's namespace *is* explicitly declared by the targetNamespace of the schema (assuming XSD) which is the namespace to be used and *NOT* the text of the soap:body namespace attribute. However, if the schema was non-XSD *and* no targetNamespace (or such) could be isolated, the value of the namespace would default to the "namespace" attribute. This seems confusing and it would seem in the interests of best practices to either 1) declare the namespace attribute of the soap:body element equal to the intended namespace or 2) omit the namespace attribute *if* the element is explictly declared in schema. (I would think (1) would clear any garbled confusion in either case).
<quote section="3.4 soap:operation"> The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted. <quote> It's my opinion that WSDL should not specify the absolute exclusion of the SOAPAction for non-HTTP bindings. What if an SMTP binding wants to use exactly the same URI, but encapsulate it in an "X-SOAPAction" header?
<quote section="3.4 soap:operation"> The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted. <quote> Does this mean the SOAPAction value should include the quotes needed ?, i.e. if you're expecting a SOAP request POST .... SOAPAction: "/foo/bar" do you include the quotes in the soap:operation ?, e.g. <soap:operation soapAction="/foo/bar" /> or not?, if not and the soapAction is mandatory for HTTP bindings, how do you specify that you want an empty SOAPAction header ? e.g. POST .... SOAPAction: