Re: Proposal: abstract faults (amended)

Paul,

I should have sent out email about the amendment I proposed, sorry.

Indeed, I think that @messageReference should be defined on 
interface/operation/infault
and interface/operation/outfault rather than on interface/fault.

The rationale for that, as you correctly stated, is that the value
of this attribute depends on the MEP in use by the operation that
uses the fault.

But @message definitely belongs on interface/fault, because its
value won't vary across operations, and in particular it does
not depend on any MEP.

Also, I have to say that after thinking about it a bit more, I'm not
so sure that the interface/fault/@name attribute should be of type
xs:QName. I think your original (pre-amendments, that is) proposal
got it right in using xs:NCName. I'd hate to have to explain to people
why the name of an operation is an NCName while the name of a fault is
a QName given that they are defined in the same scope (an interface).

On the other hand, Amy was right in pointing out that *references* to
a fault should use xs:QName.

So my proposal is to revert interface/fault/@name back to a xs:NCName
all while keeping references to faults as xs:QName(s). This is entirely
consistent with the use of xs:QName for the binding/operation/@name attribute
(a reference to an operation).

Here's the updated pseudo-schema:

<definitions>

   <interface>
     <fault name="ncname"
            message="qname"?>
        <documentation />?
     </fault>*

     <operation>
       <(in|out)fault name="qname"
                      messageReference="ncname"?
       </(in|out)fault>*
     </operation>*
   </interface>

   <binding>
     <operation>
       <(in|out)fault name="qname">
         <wssoap:fault>*
           ....
         </wssoap:fault>*
       </(in|out)fault>*
     </operation>*
   </binding>*

</definitions>

Thanks,
Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com


paul.downey@bt.com wrote:
> In fulfilment of my Action point, here is an amended proposal to hoist
> faults into the interface alongside operations.
> 
> Changes
> -------
> 
> Original Proposal (Paul):
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0046.html
> 
> Made fault name a qname (Amy):
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0058.html
> 
> Moved fault name to /binding/fault (Sanjiva):
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0068.html
> 
> Status Quo from latest Editor's copies (Tom):
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0061.html
> I haven't added Tom's further simplification to hoist the fault/code 
> into a faultcode attribute on the soap binding. I like this 
> simplification very much, but think we should discuss this separately 
> as it is soap binding specific change and may confuse this discussion.
> 
> On last week's teleconference, Roberto pointed out a problem
> with messageReference attribute following the abstract fault 
> definition: it refers to something defined inside a MEP. 
> I've therefore moved both messageReference and message attributes
> back into the operation/(in|out)fault element. 
> 
> 
> 
> 
> Status Quo
> ----------
> 
> <definitions>
> 
>   <interface>
>     <operation>
>       <(in|out)fault name="ncname"
>             messageReference="ncname"?
>             message="qname"?
>         <documentation />?
>       </(in|out)fault>*
>     </operation>*
>   </interface>
> 
>   <binding>
>     <operation>
>       <(in|out)fault> name="ncname"
> 	    messageReferences="ncname">
>         <wssoap:fault>*
>           ....
>         </wssoap:fault>*
>       </(in|out)fault>*
>     </operation>*
>   </binding>*
> 
> </definitions>
> 
> 
> 
> Problems with Status Quo
> ------------------------
> 
> 1) how a binding/operation/fault is linked to an 
>    interface/operation/fault is unclear.
> 
> 2) it is not obvious how several different binding faults may map
>    to a single interface fault.
> 
> 3) duplication: many operations across the interface may return the 
>    same fault, but the details such as documentation are defined under
>    each operation, possibly duplicated again for infault and 
>    an outfault.
> 
> 4) there is no certain way to ensure that two operations return 
>    the "same" fault.
> 
> 
> Proposal
> --------
> 
> 1) each fault is defined in the interface at the same level 
>    as operations.
> 
> 2) each fault is to be given a abstract name, unique within the 
>    interface.
> 
> 4) each interface/operation identifies the interface faults returned 
>    using the abstract name.
> 
> 5) each fault in the binding is linked to an interface fault 
>    by the abstract name
> 
> 
> The following is an illustration of how this new structure could be
> represented in XML:
> 
> 
> <definitions>
> 
>   <interface>
>     <fault name="qname>
>        <documentation />?
>     </fault>*
> 
>     <operation>
>       <(in|out)fault name="qname"
>             messageReference="ncname"?
>             message="qname"?
>       </(in|out)fault>*
>     </operation>*
>   </interface>
> 
>   <binding>
>     <operation>
>       <(in|out)fault> name="qname">
>         <wssoap:fault>*
>           ....
>         </wssoap:fault>*
>       </(in|out)fault>*
>     </operation>*
>   </binding>*
> 
> </definitions>
> 
> 
> Conclusion
> ----------
> 
> Abstracting faults has the following benefits:
> 
> - inference: identifying a fault using an abstract name, explicitly.
> 
> - This supports a common way of working: an implementer may identify
>   all the exceptions and an action to be taken.
> 
> - a binding does not have to actually describe all of the interface
>   faults
> 
> - several different <binding> section faults may map to a single
>   interface fault e.g. both 'HTTP 404' and 'SOAP fault code: notfound'
>   may result in the same interface fault 'missing' being generated.
> 
> 
> Paul
> 
> --
> Paul Sumner Downey
> Web Services Integration
> BT Exact
>

Received on Monday, 19 January 2004 22:18:21 UTC