- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Tue, 19 Jun 2001 16:28:09 -0700
- To: "Marc Hadley" <marc.hadley@sun.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>
- Cc: "christopher ferris" <chris.ferris@east.sun.com>, "David Clay" <david.clay@oracle.com>, <xml-dist-app@w3.org>
I agree with Marc -- I would also point to the requirement that we have for helping intermediaries [1]. Simplicity is always in the eye of the beholder and there are a lot of use cases where a message has a "main-purpose" in which case it is a lot simpler to say: "stick it in the body". What I think is the main point is that we have a clear processing model for the whole message including headers, body, and trailers. Because there is no direct processing impact of trailers I can't see any reason for creating a special SOAP envelope construct (trailer element) for holding them - they can just be listed under the body. The existence of the Body element already makes it unambiguous that these are trailers. Henrik Frystyk Nielsen mailto:henrikn@microsoft.com [1] http://www.w3.org/TR/xp-reqs/#z802 >Jean-Jacques Moreau wrote: >> >> Talking about simplification, do you think it would be a further >> simplification to have Bodies be just ordinary blocks, as has been >> suggested earlier several times? >> >This has a bearing on streaming processors. With the >clarification on mustUnderstand that we reached during the F2F >it is now clear that streaming cannot start until the Body >element is reached since all headers must be examined for mU >before processing can commence. If we lose the concept of Body >and don't add something to tell streaming processors that all >the mU have been seen then the whole message must be examined >before processing can start. This may not be possible for >memory constrained devices...
Received on Tuesday, 19 June 2001 19:35:05 UTC