W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Re: Comments - WSDL 2.0 Message Exchange Patterns

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 16 Jun 2004 11:49:33 -0400
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: www-ws-desc@w3.org
Message-id: <20040616114933.4dc82a4d.alewis@tibco.com>

On Tue, 15 Jun 2004 15:35:53 -0700
Mark Nottingham <mark.nottingham@bea.com> wrote:

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

I'd like to take the latter suggestion as an editorial, if that suits
others.  It means fewer changes, and qualifies as editorial, I think.

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

See archives of the task force for discussion of this.  I'm loath to
reopen it (David Booth, can you comment?).

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

Hmm.  Probably part one, where the syntax is.  Relate that syntax to the
semantic of application fault.

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

Err.  Not fault destination.  "Transmission" seems sorta okay.  It's
really about generation, though, and the *attempt* to transmit, whereas
"transmission" implies that it actually gets successfully sent.

The rulesets specify: when faults may occur, how the destination for the
fault is chosen (replace a message, return the fault to the source of the
message that triggered it).  Fault creation and targeting ruleset? 

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

Awkward.  There's an implication that external rules govern the
generation.  Which may be true in the sense that they govern what *causes*
a fault, but is not true in the sense that faults may only "occur" at
certain points in any given exchange (a fault is never the first message
in an exchange, as an example).

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

The specification is silent on this issue.

Since it is not forbidden, it would be trivial to add a fault-to-address
feature/property, and state in the specification of the feature that the
property MAY (if it is optional) or MUST (if it is required) be the target
for faults triggered by the message.

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

Does "default" carry the implication that they are used unless something
else is specified?  I'm concerned that the word would confuse readers. 
Would it work to mention that features or bindings might override the
ruleset in some fashion?

(responding primarily as part two ed)
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Wednesday, 16 June 2004 11:57:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC