Fwd: Review of WSDL 2.0 Pt 3 Last Call WD

Forwarding on behalf of the XML Protocol WG.

regards,
Marc.

Begin forwarded message:

> Resent-From: w3c-xml-protocol-wg@w3.org
> From: Marc Hadley <Marc.Hadley@Sun.COM>
> Date: September 6, 2004 10:30:24 PM EDT
> To: "'w3c-xml-protocol-wg@w3.org'" <w3c-xml-protocol-wg@w3.org>
> Subject: Review of WSDL 2.0 Pt 3 Last Call WD
>
>
> I have an action to review WSDL 2.0 Part 3[1]. Here are my comments.
>
> Marc.
>
> [1] http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/
>
> - Section 2 WSDL SOAP Binding
>
> "Notice that there are no default binding rules defined for Interface 
> Fault components by this binding. Thus, if a given Interface component 
> has any Fault components, then such Interface components MUST be bound 
> via Binding components which indicate a specific interface and contain 
> as many Binding Fault components as there are Fault components in the 
> Interface Fault component."
>
> Comment: It's unclear why default binding rules are not defined for 
> fault components. The additional information that would be required is 
> minimal and this feature would be useful.
>
> - Section 2.6 Declaring SOAP Modules
>
> Comment: The relationship between SOAP Modules declared in the binding 
> and features declared in the interface is unclear. From the SOAP 1.2 
> Rec (section 3.3): "A  SOAP module realizes zero or more SOAP 
> features". I would expect a similar relationship in WSDL such that a 
> SOAP module in a binding would reference one or more features in the 
> interface, a module being the binding of those features to the 
> protocol.
>
> - Section 3 WSDL HTTP Binding
>
> "Notice that there are no default binding rules defined for Fault 
> components by this binding."
>
> Comment: Similar to the case for the SOAP binding, it's unclear why 
> the extra step was not taken to define such default binding rules.
>
> - Section 3.3 Default Binding Rules
>
> "Mechanisms that are outside the scope of this specification MAY 
> modify the serialization format of the instance data corresponding to 
> the output message. An example of such modification is the combination 
> of the serialization as application/x-www-form-urlencoded and the 
> SOAP-Response Message Exchange Pattern ([SOAP 1.2 Part 2: Adjuncts], 
> Section 6.3)."
>
> Comment: More detail required here, it's not clear what the example is 
> trying to illustrate.
>
> - Section 3.8.1.1 Case of elements cited in whttp:location attribute
>
> "When constructing the request URI, each pair of curly braces (and 
> enclosed element name) is replaced by the corresponding content of the 
> element."
>
> Comment: What is the expected behavior when the element is not present 
> in the instance data or is nil. The rules in section 3.9.1 appear to 
> allow both things to happen.
>
> - Section 3.8.3 Serialization as "multipart/form-data"
>
> Comment: What is the expected serialization of an element that is nil 
> in the instance data ? An empty part, an omitted part ?
>
> - Section 3.9 Operation Styles
>
> Comment: The relationship between the operation styles defined in this 
> section to the serializations defined in section 3.8 would be 
> clarified by listing the permitted serializations for each style. 
> Currently the serializations list the allowed style but not the other 
> way round. Consider switching the order of 3.8 and 3.9.
>
> Comment: Should there be a style defined to match the serialization 
> defined in 3.8.2 ?
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.

Received on Thursday, 9 September 2004 14:19:10 UTC