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

RE: xp requirement document specifies headers

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Wed, 24 Jan 2001 13:46:09 -0800
Message-ID: <00b401c0864f$10491fe0$308f3b9d@redmond.corp.microsoft.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: <xml-dist-app@w3.org>, "Mark Nottingham" <mnot@akamai.com>
> While I agree that an end-of-non-default-agent-blocks marker allows
> for optimization of intermediaries, I think it could just as easily go
> into an extension. This would simplify the object model, keeping a one
> to one mapping between object symantic and XML tag. It would also
> allow for more complicated extensions should the need arise.

I would think that treating *all* blocks as "extensions" would provide
the simplest model. Note that we have no notion of "object semantic" and
therefore no idea how an XML Protocol module maps its parameters into an
XML Protocol block. As all blocks are extensions then they can of course
be as complex as they like without clogging up the base structure.

> For instance, with a SOAP-like encoding:
> <SOAP-ENV:Block
>  SOAP-ENV:mustUnderstand="sureWhyNot"
>  SOAP-ENV:actor="...actor1">
>    <joez:Extension joez:importData="pi" />
> </SOAP-ENV:Block>
> <SOAP-ENV:Block>
>    <opt:endOfActors />
> </SOAP-ENV:Block>
> <SOAP-ENV:Block>
>    <!-- end to end data here -->
> </SOAP-ENV:Block>
> <SOAP-ENV:Block>
>    <opt:endOfData />
> </SOAP-ENV:Block>
> <SOAP-ENV:Block>
>    <!-- MD5Sum and other transport assurances -->
> </SOAP-ENV:Block>

It seems strange not to use the XML element construct for providing this sort
of containment. If you look carefully at the SOAP envelope then it uses the
Header element for containing "actor enabled" data and the Body element as a
special case of a Header.

It actually also allows you to stick stuff in after the Body but as has been
mentioned in this thread, it is not as clear as could be what to do with it.
Without some encoding in the Header that stuff is following at the end then it
becomes very hard to deal with. We had the same problem in HTTP which is the
reason for the "Trailer" header field:


There is no reason why this can't be done in the same way in SOAP.

Received on Wednesday, 24 January 2001 16:47:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC