Re: Issue 25 Proposal

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 Thursday, 14 June 2001 17:04:53 UTC