Comments - WSDL 2.0 Message Exchange Patterns

Please find below my comments on the WSDL 2.0 Message Exchange Patterns  
document [1] (dated 2004/02/24).

* The draft uses "patterns" and "WSDL patterns" often; suggest either  
normalising to "WSDL Message Exchange Patterns" or beginning the  
introduction with "Web Services Description Language (WSDL) message  
exchange patterns (hereafter, 'patterns')..."

* It might be advisable to differentiate the MEPs described here from  
the messages in underlying protocols (to use SOAP terminology); perhaps  
"Interface Message Exchange Patterns"? (I don't feel strongly about  
this, just a suggestion)

* A short, formal definition of what a Fault is, in WSDL terms, may be  
useful (not necessarily in this document, but somewhere).

* Section 2 uses "generation" in reference to Faults, which seems to  
have a different meaning than in SOAP. When A SOAP Fault is generated,  
it is not necessarily transmitted on the wire; here, the implication  
seems to be that it is. Suggest using "Fault transmission," "Fault  
delivery," or "Fault destination" throughout instead. This would make  
the first sentences in the section something like: "WSDL patterns  
specify the destination and transmission of any Faults generated in a  
message exchange using standard rules. The most common such rules are  
defined here and referenced by patterns later in this document. A  
Fault, regardless of the rule in effect, terminates the message  
exchange it occurs in."

* Can the destination or occurrence of a Fault be overridden  
dynamically? E.g., can I specify a SOAP header that says "send any  
faults over there" or "keep that fault to yourself"?) If so, the  
mechanisms in section 2 should be couched as "Default Fault Generation  
Rules," or "Default Fault Transmission Rules", with appropriate  
explanatory text, if the previous suggestion is accepted.


1.  
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20- 
patterns.html


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 15 June 2004 18:41:08 UTC