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 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)