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

>So we're defining failure as anything which generates a fault, 
>otherwise apparent success?
>
>Or equally, all failures cause a fault to be generated (by definition 
>of what failure is)?

I completely agree with you that there in general are many levels of
status information including what in some situations can be considered
to be fault cases. However, for the particular case of SOAP, I think it
is useful to have a somewhat simpler situation where, as you state,
failure is anything which generates a fault.

In issue 68 [1] we discussed the possibility of being able to support
"status" information in general. We closed that particular issue by
saying that while it is fully possible for SOAP applications to define
such information, we only define two levels in SOAP: faults and
everything else. I think makes sense given that we have the rather
simplistic level of understanding user-defined data carried in a SOAP
message.

>Well the current wording, which is also retained in Marc's propoals 
>against 182 record in the issues list, is,
>
>	"If processing is unsuccessful, exactly one fault MUST
>be generated by the node."
>
>It think that would require pretty subtle interpretation say that it 
>allowed case b) ie. failure, unsucessful processing and 0 *generated* 
>faults.

FWIW, I am fine with Marc's proposal. I understood that by b) you meant
"being able to fail in an application-defined manner without necessarily
telling anybody" which I think is covered by the notion on generating a
fault but not requiring it to be sent anywhere.

>So... I think I see "unsuccessful processing" and "failed processing" 
>as synonymous, but I see the generation of a fault as a consequence of 
>failed processing to be optional in general. In a particular case fault

>generation is inaccordance with the semantics and rules associated with

>the block being processed. ie. the specification of the block being 
>processed may insist on the generation of a fault under particular 
>circumstances.

I agree that there is no distinction between unsuccessful and failed
processing.

One can of course describe failure in many ways but it is useful to have
a common manner in which failure can be represented. In the case of SOAP
we provide a SOAP fault which we encourage people to use. However, we
cannot possibly force people to use it - they can always invent their
own mechanisms if they so desire.

As we are providing a common fault mechanism, I think it is important
that we are clear on when we expect a SOAP processor to use it, not just
in the form of specific fault codes but in general terms matching the
processing model described in the rest of section 2. My proposal is that
we express this in terms of the SOAP processing model concept of
understanding a SOAP block or body.

Henrik

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x68

Received on Saturday, 23 February 2002 14:02:23 UTC