Re: Issue 292: Analysis and proposal

I think this is ok, would suggest a few truly minor tweaks:

<original>
A message may contain or cause multiple errors during processing. 
Except where the order of detection is specifically indicated (as for 
mustUnderstand faults above), a SOAP node is at liberty to select any 
single fault from the list of possible faults prescribed for the errors 
encountered. The selection of a fault is not predicated on the 
application of the "MUST", "SHOULD" or "MAY" keywords to the generation 
of the fault with the exception that if one or more of the prescribed 
faults is qualified with the "MUST" keyword then any one fault from the 
list of possible faults MUST be generated.
</original>

<proposed>
A message may contain or result in multiple errors 
during processing. Except where the order of detection is 
specifically indicated (as for mustUnderstand faults above), 
a SOAP node is at liberty to reflect any  single fault from the 
set of possible faults prescribed for the errors encountered. The 
selection of a fault need not be predicated on the application of the 
"MUST", "SHOULD" or "MAY" keywords to the generation of the fault,
with the exception that if one or more of the prescribed 
faults is qualified with the "MUST" keyword, then any one fault from the 
set of possible faults MUST be generated.
</proposed>

Reasons:

* select -> reflect (I think we need to indicate this is the fault you 
actually trigger)

* list -> set (it's not ordered, I think)

* is not predicated -> need not be predicated (I think a node should be 
free to
  consider MUST, SHOULD, MAY if desired)

* inserted commas around parenthetical phrase in last sentence.

Agreed?  Thanks.

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







Marc Hadley <marc.hadley@sun.com>
Sent by: xml-dist-app-request@w3.org
09/17/2002 04:54 PM

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



In the interests of brevity I propose that we shorten this proposal as 
follows:

(i) Leave section 1.1 as is.

(ii) Add the following variation on Noah's proposed paragraph for 2.6.

A message may contain or cause multiple errors during processing. 
Except where the order of detection is specifically indicated (as for 
mustUnderstand faults above), a SOAP node is at liberty to select any 
single fault from the list of possible faults prescribed for the errors 
encountered. The selection of a fault is not predicated on the 
application of the "MUST", "SHOULD" or "MAY" keywords to the generation 
of the fault with the exception that if one or more of the prescribed 
faults is qualified with the "MUST" keyword then any one fault from the 
list of possible faults MUST be generated.

Regards,
Marc.

On Monday, Sep 16, 2002, at 22:39 US/Eastern, 
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
> ------------------------------------------------------------------
>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.

Received on Tuesday, 17 September 2002 17:34:03 UTC