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

Re: Issue 292: Analysis and proposal

From: Marc Hadley <marc.hadley@sun.com>
Date: Wed, 18 Sep 2002 08:18:29 -0400
Cc: xml-dist-app@w3.org
To: noah_mendelsohn@us.ibm.com
Message-Id: <BD5830AA-CB00-11D6-86A9-0003937568DC@sun.com>

On Tuesday, Sep 17, 2002, at 17:32 US/Eastern, 
noah_mendelsohn@us.ibm.com wrote:

> I think this is ok, would suggest a few truly minor tweaks:
>
> <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)
>
OK.

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

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

> * inserted commas around parenthetical phrase in last sentence.
>
OK.

> Agreed?  Thanks.
>
Yes, thanks.

Marc.

>
> 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.
>
>
>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.
Received on Wednesday, 18 September 2002 08:18:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT