WS Definition WG Issues List

<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: 

<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?

• What is the standard way to describe an array?
• How many other valid ways are there to describe an array?
• How do i define more complex types?
• Does the new WSDL 1.1 approach to arrays support all the different array types in SOAP?

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).

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.

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.

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.

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>

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?

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.