RE: Issue 182: Fault Code restriction: "At Most One Fault Proposa l"

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: 21 February 2002 18:35
> 
> I read Stuart's email, and I just don't see that he's
> suggesting that a node might silently fail w/r/t the
> SOAP processing model. What he points out is that
> the spec is already quite clear on when a SOAP node MUST
> generate a Fault (see his table) but that there were also
> cases where the semantics were "MAY" or "SHOULD" and
> that the semantics of header blocks externally specified
> seemed to be perfectly within their prerogative to
> choose the terms MAY and/or SHOULD in addition to MUST.
> 
> Hence, a generalized "if processing is unsuccessful..."
> really has no business saying that a Fault MUST be generated,
> especially as this would conflict with other sections of
> the specification.

Exactly.

> My understanding of our discussion yesterday was that
> this issue was all about the cardinality (exactly one Fault)
> and not about whether or not a fault would be generated.

Sort-of-maybe! I think there would be concensus that the cardinality is
no-more than one fault generated as a consequence of processing a given
message. The question I have raised is *in general* whether *if* message
processing is unsuccesful whether "exactly one fault MUST be generated" or
"at most one fault MAY be generated". The later case does allow for a
specification that descibes the semantics of a block to deem processing of
that block to have failed without requiring that it generate a fault.

But my main question is... what catastrophe befalls us if in a given
circumstance a fault is *not* generated. If we cannot answer that question,
then by RFC 2116 I don't think we should be using MUSTs. (In fact I would
say that is1 a question that we should be able to answer with respect to
every MUST in the spec and I think that is the point of Larry Masinter's
comments in [1] that are an aspect of Issue 11 [2] that I don't believe we
have actually addressed - the resolution text does not seem to speak of it).

From [1]:

"SOAP 1.1 specification issues (these may be protocol issues, but the
specification is unclear enough to tell):

*  including implementation details as "MUST"-level requirements:

   Some of the protocol requirements labeled as "MUST" in the SOAP 1.1
   specification seem to require implementation details that have no
   explicit interoperability requirements. These requirements are likely
   'sound implementation advice' which are miscast.

   In general, the "MUST" and "SHOULD" requirements in the SOAP 1.1 document
   are unjustified (that is, the document gives no justification)."

[1]
http://discuss.develop.com/archives/wa.exe?A2=ind0006&L=soap&F=&S=&P=29507
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x11

> Orthogonal to the above is the point Noah raises below. The
> SOAP spec goes out of its way to say nothing whatsoever
> about what a SOAP node *does* with a "generated" Fault.
> Hence, I don't believe that there is, at present, any
> need for the phrase under consideration to address "being
> able to tell whether a request is proceeding successfully...".
> 
> Cheers,
> 
> Chris

Regards

Stuart

Received on Friday, 22 February 2002 05:29:53 UTC