RE: Issue 25 Proposal

Hi Chris,

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 11 June 2001 19:21
> To: Williams, Stuart
> Cc: Jean-Jacques Moreau; David Clay; xml-dist-app@w3.org
> Subject: 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.

Firstly Iwas only trying to shed a little (probably a very little) insight
into the nature of the discussion in answer to your question:

> > > I'm curious as to what manner of discomfort? 

> 
> 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. 

Basically there are a number of ideas floating around and i don't think
we've explored all the corners. The question of whether all blocks are
really the same and the body is just syntactic sugar for a header targeted
at the 'default' actor with mU=1 or whether the is something 'special' about
the body has been lingering around for some time (see Issue 101 [1]). As you
suggest, I think if we only have blocks we get 'trailers' for free and
things do indeed look simpler to me too.

> 
> 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.

I think streaming entered the discussion elsewhere... don't think I brought
it up.

> 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.

So I'd agree with that, but it admits at several approaches to a solution:
One is to clarify the semantics of those things that are not clear (siblings
of the first body entry, elements between the closing body tag and the
closing envelope tag); define and legitimise the concept of trailers, their
syntax and semantics; more radically regards the envelope content as a bag
of blocks possibly overlayed with a processing dependency graph - but this
would be a larger departure from SOAP 1.1.

> 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. 

Likewise...

> 
> Cheers,
> 
> Chris

Best regards

Stuart

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x101
--
> 
> "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.
> > >
>

Received on Tuesday, 12 June 2001 05:58:19 UTC