W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

RE: Issue 25 Proposal

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 11 Jun 2001 18:32:05 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192484@0-mail-1.hpl.hp.com>
To: "'christopher ferris'" <chris.ferris@east.sun.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>
Cc: David Clay <david.clay@oracle.com>, xml-dist-app@w3.org
Hi Chris,

One of the issues that arises is around the targetting of blocks and the use
of the actor and mustUnderstand attributes (which I think are currently
defined for use only by immediate children of the <SOAP-ENV:Header/>
element. The first child element of the <SOAP-ENV:Body/> is implictly
targetted at the "ultimate" recipient and implicitly has mustUnderstand="1".
The situation is less clear for subsequent children of the Body element -
some may be multiref parameters. The situation is even less clear for
elements between the end-tag of the Body and the end-tag of the Envelope.

So questions arose particularly about the use of mU in conjuction with
trailers, and if trailers were contained within the Body, whether mU is
implicitly set on the trailer. If the live in a <SOAP-ENV:Trailer/>
container after the Body, do they get the same actor/mU treatment as



> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 11 June 2001 17:04
> To: Jean-Jacques Moreau
> Cc: David Clay; xml-dist-app@w3.org
> Subject: Re: Issue 25 Proposal
> I'm curious as to what manner of discomfort? Header blocks
> could be considered "pre-processing" for the Body and Trailer
> blocks "post-processing" of the Body. 
> For instance, if I wanted to have the message signed
> after processing of the Body, a Trailer might be much
> more appropriate than a Header block which needed to
> be deferred until after the Body (and/or other Headers)
> were processed.
> I think that we should strive for simplification. Adding
> in (or simply clarifying in) the ability to stick
> "stuff" in the Envelope after the Body element without
> providing any processing guidance as has been provided
> for Headers seems to me to be arbitrary and would lead to
> confusion not increased clarity.
> Cheers,
> Chris
> Jean-Jacques Moreau wrote:
> > 
> > christopher ferris wrote:
> > 
> > > I am curious as to why the trailers aren't
> > > XMLP Blocks?
> > 
> > Making trailers ordinary blocks (and hence having a unified 
> processing
> > model) would indeed simplify the spec, remove a number of 
> ambiguities, and
> > enable us to build simpler (and more maintainable) 
> implementations. However,
> > this option does seem to cause some incomfort...
> > 
> > Jean-Jacques.
Received on Monday, 11 June 2001 13:32:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC