Re: Issue 25 Proposal

 Mark, Gudge,
 I think the con of going this route would be in putting too much
ordering burden on the client.
 The pro of this route would be the clear streaming point. But
then if we call it StuffYouMustUnderstand everybody would put the
request body in this part and out goes streaming again.
 If we want to keep the possibility of streaming (which I'm not
so convinced about any more) I think we only need to drop the
remark that Body is semantically equivalent to a header with
mustUnderstand="1" - we should disallow mustUnderstand on Body
blocks (if there can be more then one*) at all. Then we say
"processing of Body is done _after_ checks and processing on
Header" and we're set.

 * - I haven't seen any resolution on whether the Body contains
blocks or is a block yet. I always understood SOAP as though Body
is a (one) block.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/

P.S: I'm starting to prefer the way of disallowing streaming
altogether and saying "put the bloody huge data in an attachment
as that's where streaming errors won't affect the validity of
the whole message".




On Thu, 14 Jun 2001, Mark Jones wrote:

 >
 > Gudge,
 >
 > Your (first) proposal:
 >         <env:Envelope xmlns:env='http://www.w3.org/2001/06/soap-envelope' >
 >           <env:StuffYouMUstUnderstand>
 >             <!-- Stuff the end point must understand goes here -->
 >           </env:StuffYouMustUnderstand>
 >           <!-- streaming point is now here -->
 >           <env:Stuff>
 >             <!-- Stuff you don't have to understand (including stuff referenced from
 >         above) goes here -->
 >           </env:Stuff>
 >         </env:Envelope>
 >
 > was pretty much exactly what I had in mind:
 >
 >         > We seem to flirt from time-to-time with eliminating the
 >         > header/body/trailer distinction.  Another possibility is to make a
 >         > break with SOAP 1.1 syntax and simply have a set of blocks in which we
 >         > syntactically distinguish a streaming point if so desired.  This point
 >         > is the point after which we guarantee not to place/find any additional
 >         > mU=1 blocks.
 >
 >
 > So the question is -- what are the pros and cons of going this route?
 >
 >   What does it break?
 >
 >   What are the advantages (apart from unification of header/body/trailer
 >   and establishing a streaming point)?
 >
 > --mark
 >

Received on Sunday, 17 June 2001 12:09:36 UTC