- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Wed, 14 Nov 2001 10:59:06 -0800
- To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, <Noah_Mendelsohn@lotus.com>
- Cc: <dug@us.ibm.com>, <xml-dist-app@w3.org>, <ruellan@crf.canon.fr>
IMO, a simple way of putting it is to say that the <body> is defined as a well-known block. Just as any other block, it has an open content model and can contain as many immediate child elements as it wants. The body is always mustUnderstand and targeted at the default/anonymous actor. As it is well-known, it can't ever generate a mU fault. As for any other block, if there is content in the block that causes a fault then that fault should be based on a client fault. Given that we have been discussing multiple fault codes, more specific codes can be introduced as well. As part of the guidelines for how to *use* the body we indicate that this is where the "main purpose" of the message goes. Henrik Frystyk Nielsen mailto:henrikn@microsoft.com >-----Original Message----- >From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr] >Sent: Wednesday, November 14, 2001 09:01 >To: Noah_Mendelsohn@lotus.com >Cc: dug@us.ibm.com; Frystyk; xml-dist-app@w3.org; ruellan@crf.canon.fr >Subject: Re: Proposed resolution of issue 101: relationship >between header and body blocks > > >I am feeling somewhat incomfortable with point b), especially >if the next step is to disallow multiple body blocks. Unless >there is strong evidence that this is a necessary restriction, >I would suggest that we remove b) from the proposal. > >On a related note, I am have been wondering recently about the >processing model and mU blocks. Am I correct in thinking that, >today, we allow body blocks to reference hearder blocks, and >vice-versa? Does it make sense for an mU header block to be >targetted at none? Does it make sense for a body block to >reference an mU header block? Is an intermediary supposed to >abort processing if it finds a non-mU header block that >references an mU header block it does not understand (i.e. is >section 2.5 meant to be recursive?)? > >Jean-Jacques. > > >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. >> >> 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) >> >> ----------------------------------------------------------------- >> Name: pic28703.pcx >> pic28703.pcx Type: PCX Image Document >(application/x-unknown-content-type-PCXImage.Document) >> Encoding: base64 > >
Received on Wednesday, 14 November 2001 13:59:58 UTC