W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

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

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 7 Nov 2001 16:53:52 -0500
To: dug@us.ibm.com, frystyk@MICROSOFT.COM
Cc: xml-dist-app@w3.org
Message-ID: <OF534E672C.1FC5723A-ON85256AFD.0075D03A@lotus.com>
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.

(put list of 6 issues from the call here)

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"  purpose (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 MUST NOT carry mustUnderstand attributes;  faults, if any, resulting
from failure to recognize the contents of the body are not not
mustUnderstand faults and 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 SOAP blocks not so identified. 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 SOAP block. It is possible
that the processing of particular SOAP 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
------------------------------------------------------------------------
Received on Wednesday, 7 November 2001 17:03:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT