Paul Downey writes:

> I raised this very issue in my position paper [1] to the W3C Workshop
> on Enterprise computing, and see it as a fundamental consequence
> of SOAP not having a "stack", but a "bag" (actually a graph with WSS)
> which requires meta-data such as the much trumpeted WS-Policy to
> unravel.

One of my great regrets about the SOAP Recommendation is that it does not
make crystal clear an aspect of the design that I considered to be very
important. Still, the crucial function is there IMO:

First of all, it's not true that what SOAP has is a "bag"; the header
elements are siblings in an envelope Infoset, and the Infoset is ordered.
Also, headers may have interacting semantics [1] :

"Mandatory SOAP header blocks are presumed to somehow modify the semantics
of other SOAP header blocks or SOAP body elements."

Furthermore, and this is crucial, while SOAP itself mandates no fixed
order when processing, headers can be defined to control the order [1]:

"The processing of one or more SOAP header blocks MAY control or determine
the order of processing for other SOAP header blocks and/or the SOAP body.
For example, one could create a SOAP header block to force processing of
other SOAP header blocks in lexical order. In the absence of such a
controlling SOAP header block, the order of header and body processing is
at the discretion of the SOAP node. Header blocks MAY be processed in
arbitrary order. Header block processing MAY precede, MAY be interleaved
with, or MAY follow processing of the SOAP body. For example, processing
of a "begin transaction" header block would typically precede body
processing, a "logging" function might run concurrently with body
processing and a "commit transaction" header block might be honored
following completion of all other work."

This is not an accident. It's why we require that all mustUnderstand
checking be done before any other work. That's what ensures you that if
you have an mU header that says "do the headers in reverse order" or
"alphabetical order" or more likely "do signatures first" then that
header or those headers will necessarily be checked in time to determine
an order.

Furthermore, and this is the part I really wish had been highlighted a bit
more, nothing says these must be separate headers. So, IMO, if you want
to say >in the specification for wsa:To< "if there are multiple wsa:To
headers, here's the rule for how to process them all in the presence of
the others", you can do so. If they are marked mU then you can be sure
that, at least per the SOAP spec, their specifications can conspire to
determine an order.

In fact, what I really wanted to see in the recommendation would be a
statement along the lines of: "The specifications for headers that may
coexist in a SOAP message must collectively describe the correct
interpretation of the headers in combination as well as in isolation.
Thus, specifications may be written for families of headers designed to be
used together, to determine operation in the case where multiple instances
of the same header appear etc. Such specifications may call for a given
header to be "understood" only when accompanied or only if not accompanied
by certain other headers. etc."

I think that is in fact implicit in what is there, but obviously many
users have missed it. Whether the typical stacks out there provide much
help in supporting such combined interpretation and ordering is a
different question, but the spec definitely anticipates it IMO.

Noah

[1] http://www.w3.org/TR/soap12-part1/#muprocessing
[2] http://www.w3.org/TR/soap12-part1/#procsoapmsgs
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------