revised fault proposal

This is a revised proposal based on the discussion on the mailing
list the last few days. I would appreciate if you say +1 if you
are ok with this etc. and give concrete suggestions rather than 
general comments. I'd like to get this written up ASAP so that
we can close on much of part1 functionality.

==================

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 fault/@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). Note that we allow multiple <fault> elements with the
same @messageReference value - this is the mechanism to indicate
the multiple faults that may occur in the same message role played
by @messageReference.

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 constraints on {message reference} would have to be written
up as per the above paragraph.

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" details="xs:QName"?>
        <code>...</code>
        <subcode>...</subcode>
        <documentation />?
      </fault>
    </operation>
  </binding>
</definitions>

Note that the optional fault/@details attribute would allow one
to disambiguate between mutiple occrurences of 
interface/operation/fault with the same @messageReference value.

Faults defined as above would have a natural default SOAP 
binding: the details element goes inside the <details>
element of a SOAP fault and Other bindings can define suitable
binding rules. 

ISSUES:
------
    - Roberto & Tom have expressed a preference to using <infault>/
      <outfault> instead of what I wrote above. Can you guys live with
      my writing this up with an issue for this?

Sanjiva.

[1] http://tinyurl.com/p7m5
[2] http://tinyurl.com/p3dg
[3] http://tinyurl.com/p7t4

Received on Friday, 3 October 2003 12:52:57 UTC