W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2005

i035: unique action values for faults

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 14 Jan 2005 12:15:10 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A50633B2EA@RED-MSG-30.redmond.corp.microsoft.com>
To: <public-ws-addressing@w3.org>

I volunteered to come up with a proposal for unique action values for
each fault.  It was a little nastier than I thought, and a couple of
days of reflection haven't brought any simplifying insights.  So here
'tis at last.  Amendments welcomed!

For WSDL 1.1 the pattern for messages is

  [target namespace]/[port type name]/[input|output name]

and for faults could be something like:

  [target namespace]/[port type name]/[operation name]Fault:[fault name]

I try to keep the number of slashes the same (hence the ':' as the
second delimiter), and a similarity between the
OpNameRequest/OpNameResponse name defaulting convention.

For WSDL 2.0 it's not clear which level of fault the Action should be
more closely related to.  If one wants to correspond to the type of
fault, which may be generated by more than one operation, the pattern
could extend

  [target namespace]/[interface name]/[operation name][direction token]

to allow faults like this:

  [target namespace]/[interface name]/[fault name]Fault

Or, if matching faults up to a specific operation is necessary, one
could come up with a convention like:

  [target namespace]/[interface name]/[operation name]Fault:[fault name]

But there's one catch.  In WSDL 2.0 the fault name is a QName, so the
targetNamespace needs to be encoded in some fashion.  No clean way to
this is apparent (even WSDL 2.0 component designators are pretty messy,
e.g. not canonically comparable, in this case).  Here I add the
targetNamespace appropriately escaped:

  [target namespace]/[interface name]/[operation name]Fault:[fault local
name][escaped fault namespace]

Where the escaped fault namespace is the URI with "/" replaced with

My 2 cents:

First of all, it's not clear to me which would be the most common usage
case for Action on faults - that a fixed Action would be used with all
faults, that the Action would correspond to the type of fault, or that
the Action would correspond to a fault participating in a particular
operation's message exchange pattern (or some other grouping
altogether).  None of these seem to be obviously in the 80% case.  It
seems to me that no matter which default we choose, the majority of the
time the default will need to be overridden by an explicit wsa:Action
value.  The fixed default doesn't seem much less usable than the
alternatives, and certainly is a lot simpler.

The question is, what will we gain in the 80% case by a more complex
fault Action algorithm?
Received on Friday, 14 January 2005 20:16:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC