- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 14 Jan 2005 12:15:10 -0800
- 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 "%2F". 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