- From: christopher ferris <chris.ferris@east.sun.com>
- Date: Sat, 02 Jun 2001 08:49:26 -0400
- To: David Clay <david.clay@oracle.com>
- CC: fallside@us.ibm.com, xml-dist-app@w3.org
- Message-ID: <3B18E0D6.1A27B1FC@east.sun.com>
David, I am curious as to why the trailers aren't XMLP Blocks? In addition, I don't understand the relationship of the processing rules. Why is it that the XMLP processor must (or should as the case may be) *store* the body? Is this the XMLP Body? What has storage to do with the processing? Cheers, Chris > David Clay wrote: > > --------------------------------------------------------------- > > Issue 25 Proposal > > Background > > > Issue 25 [1] deals with SOAP 1.1 "trailers" which are sub > elements of the SOAP envelope following the body. The only > wording in the SOAP 1.1 specification [2] which talks about > headers is point number 3 under the definition of envelope > (my italics): > > 1. Envelope > > o The element name is "Envelope". > o The element MUST be present in a SOAP message > o The element MAY contain namespace declarations as > well as additional attributes. If present, such > additional attributes MUST be namespace-qualified. > Similarly, the element MAY contain additional sub > elements. If present these elements MUST be > namespace-qualified and MUST follow the SOAP Body > element. > > Proposed Usage Scenario > > > A sender wishes to include a checksum of body contents, but > the sending device does not have enough storage capacity to > buffer the body before sending. Hence the checksum must be > sent physically after the body, and cannot be included in a > header element. > > Proposed Glossary [3] Changes > > > I would suggest that the definitions of header and body > include their location within the envelope (new text in > italics): > > XMLP header > > A collection or zero or more XMLP blocks which may > be targeted at any XMLP receiver within the XMLP > message path. An XMLP header is the first element > within an XMLP envelope. > > XMLP body > > A collection or zero, or more XMLP blocks targeted > at the ultimate XMLP receiver within the XMLP > message path. An XMLP body follows the XMLP > header within an XMLP envelope. > > And the following new definition: > > XMLP trailer element > > A sub element of an XMLP envelope which follows > the XMLP body. Trailer elements are NOT comprised > of XMLP blocks. However, references to trailer > elements may be contained in XMLP blocks. > > Processing Rules > > > Blocks within an XMLP header may refer to trailer elements. > Whenever such a block is targeted at an XMLP processor and > the block contains the MUST UNDERSTAND attribute, the XMLP > processor must store the body in order to process the header > block before the body. If the block does NOT contain the > MUST UNDERSTAND attribute, the XMLP processor should store > the body if it is capable of doing so. > > Blocks within an XMLP body may also refer to trailer > elements. The XMLP processor makes these elements available > to ultimate receiver of the body. > > > Notes > > > * This assumes that XMLP will contain a facility for specifying the > order in which blocks should be processed unrelated to the > physical ordering within the envelope. Therefore, the only > reason to physically order data is that it is not possible to > construct and store the entire message before sending. > * This only helps storage constrained senders. Storage constrained > receivers will do better if blocks refer to data located in the > header. > * This proposal does not allow a sender to decide to add an XMLP > block after the header has been sent. > > [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x25 > [2] http://www.w3.org/TR/SOAP/#_Toc478383494 > [3] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082
Received on Saturday, 2 June 2001 09:03:17 UTC