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 Wednesday, 13 June 2001 17:35:59 UTC