- From: Marc Hadley <marc.hadley@sun.com>
- Date: Wed, 18 Sep 2002 08:18:29 -0400
- To: noah_mendelsohn@us.ibm.com
- Cc: xml-dist-app@w3.org
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 UTC