Re: Issue 25 Proposal

Stuart,

Right, and hence my question, why wouldn't that be a good
idea? It would simplify the processing model considerably
if the content of the Body element (and Trailer if that
is adopted) were all treated equally.

Having the first child element of the Body element treated
"as if it had" an mU attribute==1 and an actor attribute==default
(or something which implied the "ultimate" recipient) means
that a SOAP processor needs to have separate logic for the
processing of the Body than it has for the Header (and/or
Trailer if we were to add that).

One could achieve semantically the same result with:

<SOAP:Envelope ...>
	<SOAP:Block mU='1' actor='http://foo' 
		intent='header'>...</SOAP:Block>
	<SOAP:Block mU='1' actor='http://myultimatedest'
		intent='body'>...</SOAP:Block>
	<SOAP:Block mU='1' actor='http://bar'
		intent='trailer'>...</SOAP:Block>
</SOAP:Envelope>

This has certain advantages because:
	- one peice of code handles all cases equally
	- one can use actor to handle dispatching
	of the Body (and Trailer) to handlers in the same manner
	that is used for Headers is handled today

This last point may be important in cases where there may
be specialized handling of the same set of elements within
the Body depending upon some external factors. In an RPC-centric
usage model, this might not be seen as important. However, in a
messaging environment, I think that it might prove quite
valuable. 

As for handling of streaming, I can see where this becomes
problematic without some accounting for rollback if intent=trailer
were permitted at an "ultimate" destination.

What isn't clear to me is how treating stuff which appears
after the Body within the Envelope without a clear set
of semantics is perferable. True, a mU Fault might not
muck-up the works, but theoretically, in the advent of
a parser error an equally undesireable Fault might 
be generated, leaving us with the problem of how to handle
the rollback of the Body in any event.

I'm not suggesting that I have the answer, I'm just pointing
out that at present, I don't believe that the SOAP spec or our
draft accounts effectively for this either. 

Cheers,

Chris

"Williams, Stuart" wrote:
> 
> 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
> headers?
> 
> Regards
> 
> Stuart
> 
> > -----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.
> >