Re: Issue 25 Proposal

 Mark, just quick replies inside your message.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Wed, 13 Jun 2001 jones@research.att.com wrote:

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

What I meant with faulting after the successful processing by of
the Body was not the normal "something-went-wrong" faulting, it
was mU faults.
 I assumed mU would be checked on trailers _after_ all previous
processing. It would be very awkward in such case if we had an mU
fault (meaning "I-don't-know-what-you-want-from-me")  after
successfully processing the application payload.
 I would really have no problem with the "normal" (non-mU) faults
after the body even though somebody could shoot themselves in the
foot by not understanding that there could be a fault there.

 > 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

This, too, would be cool, but it might be a little confusing to
learn. In SOAP you first have the natural distinction of metadata
and data (headers and body), then you add the streaming point in
there for the advanced ones. In your proposal the distinction
would disappear (that's OK) and the advanced streaming-point
thing would be sent into the core that has to be understood by
SOAPers.

Let's keep SOAP simple - and that not in the mathematical sense
of small and flexible, rather in the sense of easy to grasp and
flexible.

Jacek

Received on Wednesday, 13 June 2001 17:50:08 UTC