- From: <jones@research.att.com>
- Date: Wed, 13 Jun 2001 17:35:53 -0400 (EDT)
- To: jacek@idoox.com, moreau@crf.canon.fr
- Cc: ruellan@crf.canon.fr, xml-dist-app@w3.org
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