RE: FW: Proposals to address SOAPAction header

The downside to making it a module is that you run into
the same old problem of which module comes first (ie.
the ordering issue).  Also, some processors will need
to know which list of handlers to use before processing
can begin so having to go thru the headers (even the
first one) might be too late.  I would imagine that this
would be true for the people who are currently using
SOAPAction for dispatching.
-Dug

"Henrik Frystyk Nielsen" <henrikn@microsoft.com>@w3.org on 06/09/2001
07:16:03 AM

Sent by:  xml-dist-app-request@w3.org


To:   Doug Davis/Raleigh/IBM@IBMUS, "Matt Long" <mlong@phalanxsys.com>
cc:   <xml-dist-app@w3.org>
Subject:  RE: FW: Proposals to address SOAPAction header




I think we should differentiate between information which is part of the
HTTP protocol binding and information we would like to carry within the
SOAP envelope.

If we are discussing the latter then carrying the value as an attribute
would mean that we consider this to be different from all other
extensions to SOAP which are dealt with through the normal SOAP
extensibility model based on elements (blocks).

If we wanted to carry such information within the envelope then I think
a much more consistent mechanism would be like the SOAP-RP proposal that
provides an "action" element which is part of the SOAP-RP module [1] and
hence follows the normal extensibility model.

>a 'target' attribute on the soap-env is just one.

Henrik

[1] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html#N0511

Received on Saturday, 9 June 2001 07:42:13 UTC