- From: Jacek Kopecky <jacek@idoox.com>
- Date: Wed, 13 Jun 2001 23:49:59 +0200 (CEST)
- To: <jones@research.att.com>
- cc: <xml-dist-app@w3.org>
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