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

 Noah,
 I like the general direction of this, I appreciate it's finally
been explored. 8-)
 I don't think we need to say anything about the actor and
mustUnderstand attributes on body blocks because an application
may want to transport in SOAP messages some elements which might
contain those attributes (for their names are pretty generic
ones).
 Maybe we might say that these attributes on body blocks are to
be ignored by the SOAP processing (as per SOAP processing model)
because they belong to the application and not to SOAP.
 Anyway, how about namespacing these attributes? 8-)
 I'm interested in those 6 issues, too. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 7 Nov 2001 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.
 >
 > (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 Thursday, 8 November 2001 12:12:24 UTC