W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Issue 182: Fault Code restriction: "At Most One Fault Proposal"

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Sat, 23 Feb 2002 11:00:49 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D05A540D8@red-msg-07.redmond.corp.microsoft.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>, <noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>

I agree with you analysis that a fault may not be sent anywhere, but it
seems that there are many ways in which one can detect a failure in
addition to receiving a concrete SOAP fault message. Regardless of how a
fault is detected from the outside, I think it is important that we
provide a deterministic state machine for a SOAP processor. Currently we
provide two final states: "failure" and "non-failure" and as part of
this I think we have to indicate how one gets to these states in all
cases. Otherwise we end up with a funny third "don't know" state.


>So, I don't think I regard a mechanism that merely generates faults, or

>even is we go so far as to say (in accordance with the resolution of 
>Issue 102) that an MEP spec. MUST detail the disposition of faults 
>generated during the operation of the MEP, provides us with a reliable 
>mechanism to indicate failure.
>Even, if in all cases of failure we mandate the generation of a fault, 
>I think it would be a little unwise to *rely* on that as an "indication

>of failure"... because there are no guarantees that it will be brought 
>to the attention of anyone/thing.
Received on Saturday, 23 February 2002 14:02:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC