wsa:Action: too much flexibility for our own good?

The draft of the WS-Addressing spec submitted to the W3C defines a new wsa:Action attribute. It is used to decorate the messages that make up an operation in a WSDL portType with the URI that should appear in the wsa:Action header when a message is sent on the wire. Here's an example from that document:

<definitions targetNamespace="http://example.com/stockquote" ...>
  ...
  <portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
      <input message="tns:GetTradePricesInput"
            wsa:Action="http://example.com/GetQuote"/>
      <output message="tns:GetTradePricesOutput"
            wsa:Action="http://example.com/Quote"/>
    </operation>
  </portType>
  ...
</definitions>

In cases where no wsa:Action attribute is present, the value is computed using a well-known algorithm that builds an action URI out of the following pieces of information:

1. the WSDL's targetNamespace
2. the local name of the portType
3. the value of the name attribute of the input and output elements if present or the name of the operation with "Request" or "Response" appended if not

In deciding on an action URI, there are three obvious choices. One is to apply the algorithm above, which means your action URI encodes information about your WSDL portType and operation. Another is to explicitly specify an action URI that's related to your message structure. Specs like WS-Eventing use this approach. For instance, the action URI for the WS-Eventing subscribe message is http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe, which matches the expanded name of the message element, {http://schemas.xmlsoap.org/ws/2004/08/eventing}Subscribe. Finally, if you wanted to you coudl come up with an action URI that had no relationship whatsoever to the message your are sending or the portType/operation you are defining. It's a third thing that's completely separate.

Okay, clearly the protocols provide a ton of flexibility here. So what should you do in practice? This is where things get gnarly, becuase different tools are likely to favor different models. In WSE, the action URI is used to figure out what policy to apply to a message and how to dispatch to code (if you are using the low-level messaging API). In some tools, the action URI is not used for dispatching; they favor the name of the element in the message body instead. It could just be me, but it seems like coming to some concensus on what the action header is for, how it impacts policy decisions, and how it relates to the things we believe have semantics in our Web services is a necessary step if we want to continue to interoperate across toolkits in the future.