Re: Issue 25 Proposal

 Gudge,
 I think that in order to keep the idea of the streaming point
the second approach would need one more rule like:

 If you have
   <Envelope>
     <Stuff mU="1" id="x1">...</Stuff>
     <Stuff mU="1" id="x2">...</Stuff>
   </Envelope>
 mustUnderstand check of the blocks in #x2 is performed _after_
processing blocks in #x1, which is _after_ performing mU check on
blocks in #x1.

 But then the use of the Stuff blocks would have to be described
well in the narrative. And again, your approaches may put too
much ordering burder on the client.
 Regards

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Thu, 14 Jun 2001, Martin Gudgin wrote:

 > How about;
 >
 > <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>
 >
 >
 > or
 >
 > <env:Envelope xmlns:env='http://www.w3.org/2001/06/soap-envelope' >
 >   <env:Stuff mustUnderstand='1' >
 >     <!-- Stuff the end point must understand goes here -->
 >   </env:Stuff>
 >   <!-- 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>
 >
 >
 > Gudge
 >
 > ----- Original Message -----
 > From: <jones@research.att.com>
 > To: <jacek@idoox.com>; <moreau@crf.canon.fr>
 > Cc: <ruellan@crf.canon.fr>; <xml-dist-app@w3.org>
 > Sent: Wednesday, June 13, 2001 5:35 PM
 > Subject: Re: Issue 25 Proposal
 >
 >
 > > As I pointed out at Dinard, the decision to require doing all mU
 > > checks without side-effect effectively moved the "streaming point" to
 > > the body (possibly also including the start element of the body at the
 > > final destination in order to verify that it can also be understood).
 > > [Yes, I know that a "clever" implementation can go ahead and stream
 > > through the headers as long as it can roll back results, but
 > > practically speaking, the streaming point is now at the body.]
 > >
 > > If we decide to permit blocks containing mU semantics after the body,
 > > then Jacek correctly points out that we will have moved the practical
 > > streaming point to the end of the message.
 > >
 > > It seems to me that the options are:
 > > 1) trailers are not blocks but are referenceable elements
 > >    (keep in mind that header blocks can also function simply
 > >     as referenced blocks)
 > > 2) trailers are targettable blocks but must have mU=0
 > > 3) trailers are just like header blocks (targettable and can have mU=1)
 > >
 > > Options 1) and 2) keep the practical streaming point at the body.  As
 > > Jacek points out, 2) leaves you with the possibility of faulting after
 > > you have successfully processed the body, but it also may be valuable
 > > to cuase additional processing after the body in some cases.  Option
 > > 3) requires checking the entire message, practically eliminating
 > > streaming any part of the message.
 > >
 > > I'm not sure whether I prefer 1) or 2), but I think it would be a
 > > mistake to adopt 3).
 > >
 > >
 > > 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.
 > >
 > >
 > > --mark
 > >
 > >
 > > Mark A. Jones
 > > AT&T Labs - Research
 > > Shannon Laboratory
 > > Room A201
 > > 180 Park Ave.
 > > Florham Park, NJ  07932-0971
 > >
 > > email: jones@research.att.com
 > > phone: (973) 360-8326
 > >   fax: (973) 360-8970
 > >
 >

Received on Sunday, 17 June 2001 11:33:35 UTC