W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

RE: Issue 25 Proposal

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Tue, 19 Jun 2001 16:28:09 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CCFA@red-msg-07.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT