RE: Proposal: abstract faults

Tom

I cut and pasted the examples straight out of the Working Drafts. I notice the Editors' copy only mentions encodingStyle for headerfaults, so i think your example is more correct given the latest Status Quo. 

So sorry for the confusion. 

Paul

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: 18 December 2003 17:48
To: Downey,PS,Paul,XSJ67A C; 'www-ws-desc@w3.org'
Subject: RE: Proposal: abstract faults



This looks really great.

I am a bit confused about the binding faults you show in your example. You
have namespace and encodingStyle attributes in there and I didn't think we
had them anymore.  If we do, what are they for?  The current editor's copy
doesn't say anything about faults in Part 3.

My memory also seems to be failing me on what the @message attribute is for
in the binding fault.  Is this the same message that is specified in the
interface?

Ideally, I would like to keep the binding 'mostly empty' in the same manner
that we managed to do for operations.  That is, I shouldn't have to say
anything about the faults, particularly SOAP faults, unless I want to
override the defaults.  We could then specify various SOAP fault specific
values that would override the default.  I don't know what those could be;
perhaps faultCode is the only interesting thing for SOAP faults.

Like this:

  <binding>
      <fault>
        <wssoap:fault name="xs:NCName"
                      faultcode="mntoken"? />
      </fault>
  </binding>*

What do you think?

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of paul.downey@bt.com
Sent: Thursday, December 18, 2003 4:26 AM
To: www-ws-desc@w3.org
Subject: Proposal: abstract faults



In fulfilment of my Action point, here is a proposal to hoist faults into
the interface alongside operations.


Status Quo
----------

<definitions>

  <interface>
    <operation>
      <infault
            name="xs:NCName"
            messageReference="xs:NCName"?
            message="xs:QName"?
        <documentation />?
      </infault>*
      <outfault
            name="xs:NCName"
            messageReference="xs:NCName"?
            message="xs:QName"?
        <documentation />?
      </outfault>*
    </operation>*
  </interface>

  <binding>
    <operation>
      <fault>
        <wssoap:fault message="nmtoken"
                namespace="uri"?
                encodingStyle="uri"? >
          ....
        </wssoap:fault>*
      </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 are defined under each operation, possibly 
   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 of operations.

2) each fault is to be given a abstract name, unique within the interface.

3) the fault details are defined under the interface/fault.

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="xs:NCName"
            messageReference="xs:NCName"?
            message="xs:QName"?
        <documentation />?
    </fault>*

    <operation>
      <infault name="xs:NCName"/>*
      <outfault name="xs:NCName"/>*
    </operation>*
  </interface>

  <binding>
      <fault>
        <wssoap:fault name="xs:NCName"
            message="nmtoken"
            namespace="uri"?
            encodingStyle="uri"? />
           ....
        </wssoap:fault>*
      </fault>*

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


Thanks to Glen for his input!
Paul

--
Paul Sumner Downey
Web Services Integration
BT Exact

Received on Friday, 19 December 2003 05:33:52 UTC