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

I am feeling somewhat incomfortable with point b), especially if the next step is to disallow multiple
body blocks. Unless there is strong evidence that this is a necessary restriction, I would suggest
that we remove b) from the proposal.

On a related note, I am have been wondering recently about the processing model and mU blocks. Am I
correct in thinking that, today, we allow body blocks to reference hearder blocks, and vice-versa?
Does it make sense for an mU header block to be targetted at none? Does it make sense for a body block
to reference an mU header block? Is an intermediary supposed to abort processing if it finds a non-mU
header block that references an mU header block it does not understand (i.e. is section 2.5 meant to
be recursive?)?

Jean-Jacques.


Noah_Mendelsohn@lotus.com wrote:

> 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 understand
> the 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)
>
>   -----------------------------------------------------------------
>                    Name: pic28703.pcx
>    pic28703.pcx    Type: PCX Image Document (application/x-unknown-content-type-PCXImage.Document)
>                Encoding: base64

Received on Wednesday, 14 November 2001 12:40:01 UTC