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

Sounds like what we discussedon the chat - comments in <dug>.
-Dug


Noah_Mendelsohn@lotus.com on 11/09/2001 03:29:03 PM

To:   Doug Davis/Raleigh/IBM@IBMUS, 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 >> <<):
   <dug> I would leave it as SHOULD NOT, but perhaps make it clear that if
   they do appear it is outside the scope of the spec as to what that
means.
   </dug>

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

<dug>
s/not not/not/
I don't think we should say ", are not mandated by this specifictiona, and
MUST NOT be generated in this step".  I agree they are not MU faults, but
the rest of it is an implementaton detail - some may want to verify
whether the Body is a known service at this point in their processing, some
may want to do it later.  I don't think we need to tell them when to do it
and more importantly tell them when NOT to do it.
Since they are not MU faults, we should say what they CAN be - for example,
Client faults:
  Faults, if any, resulting from failure to recognize the contents of the
  body are not mustUnderstand faults, but instead Client faults.
</dug>

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 <dug>if it is the ultimate recipient</dug><<. 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.

<dug>
I would prefer if we didn't say anything about dispatching on the 1st
body block - that would preclude someone from supporting boxcarring
(if they wanted).  I'd like to leave it as is: just a block of XML
that is up to the SOAP node to decide how to process.
</dug>

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

Received on Monday, 12 November 2001 07:31:29 UTC