RE: Proposed resolution of issue 101: relationship between header and body blocks

Noah,

This is the bit of the proposal on Issue 101 that I was trying to find
during yesterday's discussion.

> 2. Process SOAP blocks targeted at the SOAP node, generating SOAP faults
> (see 4.4 SOAP Fault) if necessary. A SOAP node MUST process SOAP >>header
> << blocks identified as mandatory >>and MUST process the SOAP body
block<<.

The last insert ">>and MUST process the SOAP body block<<" presumably only
applies at the anonymous actor/ultimate recipient. However, at this point is
speaking more generally of the require behaviour of a SOAP Node.

Could be I missed something, but I didn't read right to me.

Best regards

Stuart

> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: 09 November 2001 20:29
> To: dug@us.ibm.com; frystyk@microsoft.com
> Cc: xml-dist-app@w3.org
> Subject: Proposed resolution of issue 101: relationship between header
> and body blocks
> 
> 
> [Here's an updated version with the 6 issue list form Oisin, and bit of
> proofing.   Also, I changed 2.5 subsection 1 below to account for 
> Jackek's concerns about mustUnderstand attrs in the body, and I 
> further clarified header/body distinctions in 2.5 subsection 2.
> Please use this version as
> the basis for future discussion.  Thank you.  Noah.]
> 
> I'm not 100% sure I like this, but here is a cut at what I think we are
> aiming at for the solution to issue 101 [1], per our discussion on the
call
> today.  I've actually got to run before proofreading this.  Doug and
> Henrik:  please help me tune this up for discussion by the group.  Thank
> you
> 
> Problems to be solved
> ---------------------------
> 
> Generally, there is ambiguity in the current spec as to whether body and
> header are really symmetric.  For example, if you send a purchaseOrder in
> the body to a stock quote service, is that a mustUnderstand fault?  Is it
> reasonable to put the purchase order in a header and some transaction
> control in the body?  If they're symmetric, the answer would be yes.  Is
> the chapter 2 processing model clear enough on dealing with bodies?   This
> proposal attempts to capture the resolution to these issues as proposed on
> the call.
> 
> Here are the issues as we identified them on the call (from Oisin):
> 
> 1.  4.3.1 is the section with the relationship between header/body
>     block, once we settle all the other things we have to go back and
>     make sure that this reflects what we mean
> 
> 2. There are different opinions on what can be processed as a block and
>    how  many things can be processed in the body - some say one unit,
>    other say multiple. combination of  this and mustunderstand may
>    make streaming more difficult
> 
> 3. If I have body and as children I have A and B, does this mean two
>    units of work, or A is the unit of work and B is support, or vice
>    versa?
> 
> 4. Indicate that a subpart of body is not understand - whether to use mU
or
>    otherwise
> 
> 5. If body parts are separate, not normal headers blocks, then we have
>    to look at the processing model and unify that.
> 
> 6. If headers are the extension mechanism, but technically extensions can
>    be placed in the body , then what is to stop people putting
>    extensions in the body?
> 
> 
> Proposed resolution
> -------------------
> 
> Overview:  the body block will be viewed as different from header entries
> in intent and processing details (e.g. fault generation)
> 
> Details of proposed resolution (very rough cut):
> 
> a) We delete section 4.3.1 which implies that header and body blocks are
> more or less the same thing.
> b) We introduce text, probably in 4.3, to indicate that the body is
> intended to carry what is essentially the "main purpose"  of the msg (by
> contrast, headers are intended to carry extension function, metadata, and
> other data in support of processing the body.)  (Ed Note:  this is to
> discourage the use of header entries to carry, for example, purchase
> orders, while the body has some control information like "begin
> transaction").
> c) The body does not participate directly in the mustUnderstand mechanisms
> of chapter 2.  Body entries SHOULD NOT carry mustUnderstand attributes
> (maybe that should be MUST NOT, but there might be a backwards
> compatibility issue with SOAP 1.1 if we care.)  Specifically, 
> we change Section 2.5. to read (changes bracketed in >> <<):
> 
> 2.5 Processing SOAP Messages
> This section sets out the rules by which SOAP messages are processed.
> Unless otherwise stated, processing must be semantically equivalent to
> performing the following steps separately, and in the order given. Note
> however that nothing in this specification should be taken to prevent the
> use of optimistic concurrency, roll back, or other techniques that might
> provide increased flexibility in processing order as long as all SOAP
> messages, SOAP faults and application-level side effects are equivalent to
> those that would be obtained by direct implementation of the following
> rules.
> 
> 1. Generate a single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand
> Faults) if one or more SOAP >>header<<blocks targeted at the SOAP node are
> mandatory and are not understood by that node. If such a fault is
> generated, any further processing MUST NOT be done.  >>Note that SOAP body
> blocks SHOULD NOT carry mustUnderstand attributes; if present such
attributes
> are ignored.  Faults, if any, resulting from failure to recognize the
> contents of the body are not not mustUnderstand faults, are not mandated
> by this specification, and MUST NOT be generated in this step.<<
> 
> 2. Process SOAP blocks targeted at the SOAP node, generating SOAP faults
> (see 4.4 SOAP Fault) if necessary. A SOAP node MUST process SOAP >>header
> << blocks identified as mandatory >>and MUST process the SOAP body
block<<.
> A SOAP node MAY process or ignore >>non-mandatory header blocks targeted
> at the SOAP node.<<   In all cases where a SOAP >>header<< block is 
> processed, the SOAP node must understandthe SOAP block and must do such 
> processing in a manner fully conformant with the specification for that 
> SOAP block. Faults, if any, must also conform to the specification for 
> the processed >>header<< block. It is possible that the processing of 
> particular >>header<< block would control or  determine the
> order of processing for other SOAP blocks. For example, one could create a
> SOAP header block to force processing of other SOAP header blocks in
> lexical order. In the absence of such a SOAP block, the order of
processing
> for >>header and body blocks<< is at the discretion of the SOAP node. SOAP
> nodes can make reference to any information in the SOAP envelope when
> processing a SOAP block. For example, a caching function can cache the
> entire SOAP message, if desired.
> 
> If the SOAP node is a SOAP intermediary, the SOAP message pattern and
> results of processing (e.g. no fault generated) MAY require 
> that the SOAP
> message be sent further along the SOAP message path. Such relayed SOAP
> messages MUST contain all SOAP header blocks and the SOAP 
> body blocks from
> the original SOAP message, in the original order, except that 
> SOAP header
> blocks targeted at the SOAP intermediary MUST be removed 
> (such SOAP blocks
> are removed regardless of whether they were processed or ignored).
> Additional SOAP header blocks MAY be inserted at any point in the SOAP
> message, and such inserted SOAP header blocks MAY be 
> indistinguishable from
> one or more just removed (effectively leaving them in place, but
> emphasizing the need to reinterpret at each SOAP node along the SOAP
> message path.)
> 
> d)  I'm still unclear on whether we say anything about the 
> contents of the
> SOAP body:  do we want to indicate that dispatch can always 
> be done based
> on the first child of <Body>?  I think we're indicating that 
> there is at
> most one abstract operation in the body, but I'm not sure how 
> to relate
> this to lexical representations.
> 
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x101
> 
> --------------------------------------------------------------
> ----------
> Noah Mendelsohn                                    Voice: 
> 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> --------------------------------------------------------------
> ----------
> 
> 
> 
> 
> 
> (Embedded image moved to file: pic28703.pcx)
>

Received on Wednesday, 28 November 2001 07:21:28 UTC