Re: proposal for faults

Sanjiva Weerawarana 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"/>

"detail" (singular), rather.

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

Our disagreement in that thread carries over to this one.

Plus, for consistency I think we should either keep input/output and
infault/outfault or get rid of both and go with message/fault. (This
keeping in mind that I'm not in favor of defaulting the "pattern"
attribute on an operation.)

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

I still don't see why you're arguing in favor of

  <fault messageReference="xs:NCName" details="xs:QName"/>

over

  <fault messageReference="xs:NCName" details="list of xs:QName"/>

Can you please explain? As I said in an earlier email, I can declare
an arbitrary number of faults as replacements for a given message.
With your syntax, I'd be forced to write:

<definitions>
   <interface name="if">
     <operation name="op">
       <input body="ns:foo"/>
       <output body="ns:bar"/>*
       <fault messageReference="response" details="ns:fault1"/>
       <fault messageReference="response" details="ns:fault2"/>
       <fault messageReference="response" details="ns:fault3"/>
       <fault messageReference="response" details="ns:fault4"/>
     </operation>
   </interface>
   <binding name="bind" interface="tns:if">
     <operation name="tns:op">
       <input/>
       <output/>
       <fault messageReference="response"/>
       <fault messageReference="response"/>
       <fault messageReference="response"/>
       <fault messageReference="response"/>
     </operation>
   </binding>
</definitions>

How would I then know which binding fault corresponds to which abstract 
fault? And what does the ability to bind each fault separately buy you
when they're all meant to replace the same message?

With the old syntax, we'd have this instead:

<definitions>
   <interface name="if">
     <operation name="op">
       <input body="ns:foo"/>
       <output body="ns:bar"/>*
       <outfault messageReference="response" details="ns:fault1 
ns:fault2 ns:fault3 ns:fault4"/>
     </operation>
   </interface>
   <binding name="bind" interface="tns:if">
     <operation name="tns:op">
       <input/>
       <output/>
       <outfault messageReference="response"/>
     </operation>
   </binding>
</definitions>

As you can see, at the binding level everything is clear.

Roberto

Received on Tuesday, 30 September 2003 17:28:18 UTC