Re: Issue 25 Proposal

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