- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 12 Nov 2001 07:31:19 -0500
- To: Noah_Mendelsohn@lotus.com
- Cc: frystyk@microsoft.com, xml-dist-app@w3.org
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