Re: Issue 292: Analysis and proposal

Good catch.  I had sort of thought of this issue, but didn't manage to do 
a good job of resolving it.  Indeed, one could make the case that even 
"MUST generate a fault"  is too strong, because it really means "MUST 
generate either this fault or another."  I considered that, but with some 
hesitation, decided it was too clumsy to sprinkle through the text.

I agree that text introducing faults throughout the text must be 
consistent with whatever phrases are used in my newly proposed text. 
Again, thanks for catching that.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jacek Kopecky <jacek@systinet.com>
09/17/2002 04:17 AM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     XMLP Dist App <xml-dist-app@w3.org>
        Subject:        Re: Issue 292:  Analysis and proposal


 Noah, group,
 this proposal uses the terms "MUST fault", "SHOULD fault" and "MAY
fault" as though they were consistently used in the spec to indicate
that a fault must/should/may be generated. I don't believe this is the
case, the spec usually says that a fault MUST/SHOULD/MAY be generated,
or some language like this.
 I propose (as a friendly amendment) that the text below says "MUST
generate a fault", "SHOULD generate a fault" and "MAY generate a fault".
 Also, if we accept this (even with my amendment) it would be necessary
that all the mentions of generating a fault be rephrased to match the
three double-quoted versions above - e.g. instead of "a fault MUST be
generated" it would say "the processor MUST generate a fault".
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


 
On Tue, 2002-09-17 at 04:39, noah_mendelsohn@us.ibm.com wrote:
> 
> This note is in fulfillment of the action assigned to me on last week's 
> telcon to propose a formal resolution of issue 292 [1].   On Sept. 6, I 
> proposed a general direction for the solution [2], which was adopted on 
> the telcon.  The wording in [2] was known to be impractically clumsy, 
and 
> there are some traps that one can fall into in trying to present this in 
a 
> manner that is architecturally rigorous and unambiguous.  Here is a cut 
at 
> specific text that I propose we use to resolve this issue:
> 
> ***************************************************************
> >From Section 1.1 (all references are to editors' copy) [3]:
> 
> <original>
> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
> "MAY", and "OPTIONAL" in this document are to be
> interpreted as described in [RFC 2119]. 
> </original>
> 
> <proposed>
> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC 2119].  See 2.6
> Processing SOAP Messages for clarification of the terms "MAY fault",
> "SHOULD fault", and "MUST fault" in situations where a single SOAP
> message contains or results in more than one error.
> </proposed>
> 
> --------------------------------------------------------------
> 
> >From Section 2.6 (all references are to editors' copy) [4]:
> 
> <original>
> Failure is indicated by the generation of a fault (see 5.4 SOAP
> Fault). SOAP message processing MAY result in the generation of
> at-most one fault. Header-related faults other than those related to
> understanding SOAP header blocks (see 2.4 Understanding SOAP Header
> Blocks) MUST conform to the specification for the corresponding SOAP
> header block.
> </original>
> 
> (note: there are no changes in the first paragraph...I just include
> it here for context.)
> 
> <proposed>
> Failure is indicated by the generation of a fault (see 5.4 SOAP
> Fault). SOAP message processing MAY result in the generation of
> at-most one fault. Header-related faults other than those related to
> understanding SOAP header blocks (see 2.4 Understanding SOAP Header
> Blocks) MUST conform to the specification for the corresponding SOAP
> header block.
> 
> Except where order of detection is specifically indicated (as for
> mustUnderstand faults above), a SOAP node MAY choose to generate any
> one of the faults that would result from the processing of a message
> that contains or results in more than one error.  This lattitude
> applies independent of whether the errors are separately specified as
> "MAY fault", "SHOULD fault", or "MUST fault".  It also applies, except
> as specifically indicated, to any mixture of faults from violations of
> this specification ([SOAP Part 1] and [SOAP Part 2]), violations of
> the specifications of SOAP features, and/or to faults detected by a
> SOAP binding.  For example, a node encountering a situation in which
> it "MAY fault" due to misuse of a SOAP feature: (a) MAY reflect that
> fault and terminate processing without further checking the message
> for other errors; (b) MAY continue and select a different fault to be
> generated; or (c) if none of the errors is indicated as "MUST fault",
> MAY decline to fault at all, and instead continue with successful 
> processing of the message.
> </proposed>
> 
> ***************************************************************
> 
> I propose that we vote to adopt the above on during the Wed. call. 
> Thank you.
> 
> Noah
> 
> 
> [1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x292
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0057.html
> [3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#notation
> [4] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#procsoapmsgs
> 
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>

Received on Tuesday, 17 September 2002 09:18:35 UTC