Re: proposal for faults

+1

Should we consider the case in which a fault may associate with several
messages?  There is no such case in the current patterns set, because
all use fault-replaces-message and have zero or one replaceable
messages.  In message-triggers-fault, two messages in a pattern means
two possible references.  Hypothetical patterns with
message-replaces-fault and number of messages > 2 would have the same
issue.  Allow a list of ncname in @messageReference or just ask users to
specify multiply?  I think it is probably more straightforward to have a
single ncname.

Amy!
On Wed, 01 Oct 2003 01:34:55 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:

> 
> The current draft [1] has fault reference components [2] as unfinished
> 
> business. The status quo is:
> 
> <definitions>
>   <interface>
>     <operation>
>       <infault
>             name="xs:NCName" 
>             messages="list of xs:QName" >
>         <documentation />?
>       </infault>
>       <outfault
>             name="xs:NCName" 
>             messages="list of xs:QName" >
>         <documentation />?
>       </outfault>
>     </operation>
>   </interface>
> </definitions>
> 
> I propose we use the following instead:
> 
> <definitions>
>   <interface>
>     <operation>
>       <input ../>*
>       <output ../>*
>       <fault messageReference="xs:NCName" details="xs:QName"/>
>     </operation>
>   </interface>
> </definitions>
> 
> where @messageReference indicate the message in the pattern 
> that this fault element is declaring concrete detail information
> for, and @details indicates the XML element which represents 
> all the data that is available if/when this fault occurs. The
> direction of the fault (inbound vs. outbound) is implied by
> the value of @messageReference (see my messages about how 
> operation/input and operation/output are redundant for further
> details). 
> 
> In component model-speak, I propose that a fault reference
> component have two properties:
>     - a {message reference} property, ala that of message references
>     - a {details} property indicating an element defining the contents
>       of the fault message
> 
> The binding message reference components [3] for referring to faults
> from inside a binding would also need to change to be consistent with
> this approach. Basically, instead of:
> 
> <definitions>
>   <binding>
>     <operation>
>       ...
>       <infault
>             name="xs:NCName" >
>         <documentation />?
>       </infault>
>       <outfault
>             name="xs:NCName" >
>         <documentation />?
>       </outfault>
>     </operation>
>   </binding>
> </definitions>
> 
> I propose:
> 
> <definitions>
>   <binding>
>     <operation>
>       ...
>       <fault messageReference="xs:NCName">
>         <documentation />?
>       </fault>
>     </operation>
>   </binding>
> </definitions>
> 
> Faults defined as above would have a natural default SOAP 
> binding: the details element goes inside the <details>
> element of a SOAP fault. Other bindings can define suitable
> binding rules. 
> 
> Sanjiva.
> 
> [1] http://tinyurl.com/p7m5
> [2] http://tinyurl.com/p3dg
> [3] http://tinyurl.com/p7t4
> 
> 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 30 September 2003 15:45:46 UTC