Re: Issue 25 Proposal

 Hi, please see my post re: 'Issue 25 Proposals from the f2f'
first.

 Christopher, there has been agreement on first checking for mU
faults and only when every header is known to be known to the
processor can the processing begin.

 I agree that your approach would be a simplification, but only
for those who don't mind mathematical abstractions. Sometimes a
little bit of additional complexity adds a lot to clarity of the
purpose. That's one point for keeping Body separate.

 Your simpler approach also completely kills the possibility of
streaming, which is arguably a useful optimization. Why can't you
stream any more? Because you have to see the end tag
(</SOAP:Envelope> in your case) before being sure that you will
understand all the headers - that's because only the ending
SOAP:Envelope tag tells you there is no more SOAP:Block.

 If we had SOAP:Header, SOAP:Body and SOAP:Trailer (the last
with the same handling rules as the first) with sequential mU
checking and processing, we could encounter a situation where the
body has been processed successfully but then you don't
understand one of the mU trailers.

 As for why streaming only the Body seems sufficient to me: I
have an opinion and a feeling that headers are going to be used
for relatively small metadata only. Then the body can bear the
bulk of the data and streaming can be more important to you than
knowing beforehand the data is proper XML. If encountering a
parser error mid-stream would cause you a head-ache, you wouldn't
even consider streaming. On the other hand when memory is limited
and where rollback is either simple or unnecessary altogether,
you'll be glad if you know "from now on I can stream if I will".

 Even in messaging environments, where you argue your simpler
approach "might prove quite valuable", I think I have reasons why
Body is special:

 I'd naturally map one SOAP message to one application-level
message. This application-level message would live in the Body,
possibly decorated with headers.

 If you kept your simple model with only Blocks, you could easily
start putting more application-level messages into one SOAP
message, then the next simple step is to address these to
different endpoints, and what you end up with is a bus structure
with complex semantics due to its immense flexibility. I wouldn't
like to go there.

 Best regards

                            Jacek Kopecky
                               Idoox



On Mon, 11 Jun 2001, christopher ferris wrote:

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

Received on Monday, 11 June 2001 15:35:37 UTC