Headers as first class citizens

I think in the various discussions regarding support for headers some of the
basic motivations behind supporting header syntax may have been lost.

Versioning - As explained in detail at
http://www.pacificspirit.com/Authoring/Compatibility/ it is all but
impossible to design a Schema element that can be robustly extended across
multiple versions. As such one's only realistic option to extend an existing
message in a backwards compatible way is to add in a new header. Because the
header processing model explicitly allows for ignoring unrecognized content
it is always safe to add in new headers with optional content confident that
the header will be ignored by systems that do not understand it.

Application Level Data - In front of my mail client is a mail relay which
runs spam assassin. Spam Assassin puts in headers like X-Spam-Probability
that provide additional information about the mail message the relay is
forwarding. The information is not part of the mail message itself. Rather,
it is a header. My mail application could read in this header and use it to
do things like mark mail with a color I have designated to mark 'spam' based
on the value in the X-Spam-Probability header.

	My mail client's support for X-Spam-Probability has nothing to do
with my SOAP stack or my WSDL stack. It is purely an application level
functionality. It shouldn't be necessary to introduce a brand new WSDL
feature if the only feature WSDL is to provide is schema validation.

The suggestion of creating a single WSDL feature that gives a list of
abstract headers with their schema definitions could work but only if the
abstract headers can be individually mapped to individual SOAP headers/HTTP
headers/Mail Headers/etc. at the binding level. If the abstract headers MUST
be mapped into a single binding header then the function and versioning
separation that made headers useful in the first place is lost.

Given that the type of headers that are being discussed are not related to
the functionality of the SOAP or WSDL stacks and given that they really have
nothing to do with WSDL features why can't we just put in support for the
proposal in
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0069.html with
appropriate warning text telling implementers that if their header is really
an extension to the SOAP/WSDL stack then it would be more appropriate to use
a WSDL feature?

		Yaron

P.S. An example of the scenario in the second to last paragraph above may be
useful. 

Let's say I have a WSDL feature that lets me define abstract headers as a
series of elements. But the feature, when mapped to SOAP, requires that all
the elements be stored in a single SOAP header. 

Now lets say that I have a client that supports the foo and bar headers
talking to a server that only supports the foo header. When the client sends
a message the SOAP serialization/binding will have a single SOAP header
which will contain two elements, foo and bar. When the server receives this
SOAP header how should it read the contents of the single SOAP header? Does
the order of the foo and bar elements listed in the SOAP header matter? How
does the server know to dig through the foo and bar elements, recognize them
as the bindings of abstract headers and then determine that it can ignore
bar and just pay attention to foo?

SOAP itself has already answered all of these questions in its header
design. But by forcing all the abstract headers into a single physical
header we rob the user of the ability to use SOAP's design. Instead we will
be forced to re-invent the answer to these questions ourselves. In other
words, if we don't just use SOAP/HTTP/SMTP/etc. headers then we will, in
effect, have to re-invent the functions provided by these headers ourselves
within WSDL.