RE: executing Cindy's proposed change - two questions

Philippe asked me to look at this issue from the WSDL 2.0 perspective, and I
confess that I'm unable to quickly reach a conclusion on whether the
operation name and direction are integral to the fault action pattern.
Cindy's objection rests on the cornerstone statement that "a fault message
has no meaning when considered outside the context of the targeted
operation."  I don't find anything in WSDL 2.0 that would conclusively
either affirm nor deny that statement.

 

Given a fault such as "unknown user", and two operations such as "getEmail"
and "changePassword", both of which could return the "unknown user" fault,
it seems to me to be a matter of interpretation as to whether the semantics
of the fault are the same for each operation (focusing on the "unknown user"
aspect), or whether the semantics differ slightly ("can't get email address
for unknown user" separate from "can't change password for unknown user.")

 

The WSDL 2.0 component model is suggestive of the status quo, as it defines
the structure of fault messages at the interface level, where they can be
referred to (and thus reused) by various operations.  Section 4.4.3 of the
WS-A Metadata spec defines the {action} property is defined for Interface
Fault components and not on Interface Fault Reference Components, but I
guess that's also part of Cindy's suggested change.

 

My conclusion is that the status quo is not obviously broken, and that the
opposite semantic of a per-operation fault action could be supported by
defining faults that are not reused between operations.  On the other hand,
the proposal is also not obviously broken, and that a per-fault action could
be supported by explicitly setting the same action on each fault reference
that refers to a particular fault.

 

My intuition tells me that developers will consider faults semantically
equivalent regardless of which operation provokes them, based on the long
but ultimately non-unanimous deliberations on faults in the WSDL WG.  But I
also acknowledge that WSDL 1.1 has set up the opposite expectation.

 

I have not been tracking the WG's deliberations so far, but it appears that
there is consensus that moving forward without objections is more
expeditious then moving forward without document churn.  I trust you to make
a wise decision in that regard.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
Sent: Monday, June 18, 2007 5:24 PM
To: [WS-A]
Subject: executing Cindy's proposed change - two questions

 

I have modified Cindy's proposed default WSDL 2.0 Action pattern for faults
slightly, by dropping the delimiter between the operation name and the
direction token - this matches the pattern for non-faults.

 

Her proposal:

 

[tns] [delimiter] [interface name] [delimiter] [operation name] [delimiter]
[direction] [delimiter] [fault name] 

 

My version:

 

[tns] [delimiter] [interface name] [delimiter] [operation name] [direction]
[delimiter] [fault name] 

 

An example following my pattern could be:

 

http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvail
abilityResponse/AvailabilityNotAvailableFault

 

(Let me know if you object to my choice of fault name...)

 

- - - -

 

Second problem: should the direction token be that of the message to which
the fault is reponding, rather than the direction of the fault? In other
words, should the example above, presuming that the message which triggered
the fault had an action of
http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvail
abilityRequest , be 

 

http://greath.example.com/2004/wsdl/resSvc/reservationInterface/opCheckAvail
abilityRequest/AvailabilityNotAvailableFault

 

?

 

I will assume, for now, that this is not the case, but what I put above may
be what people expect.

 

Tony Rogers

CA, Inc

Senior Architect, Development

tony.rogers@ca.com

co-chair UDDI TC at OASIS

co-chair WS-Desc WG at W3C

 

  _____  

From: public-ws-addressing-request@w3.org on behalf of Rogers, Tony
Sent: Tue 19-Jun-07 9:58
To: Bob Freund; [WS-A]
Subject: executing Monica's proposed change

Looking at the words to resolve Monica's issue, I find myself stumbling over
the repetition of "to indicate that the subject supports WS-Addressing but
does not require its use, " in successive sentences. Would anyone be
perturbed if I exercised my editorial licence, and elided the second copy of
this clause to a semicolon? What I'm suggesting is that we convert:

 

 In order to indicate that the subject supports WS-Addressing but does not
require its use, an additional policy alternative should be provided which
does not contain this assertion.  To indicate that the subject supports
WS-Addressing but does not require its use, the compact authoring style for
an optional policy assertion provided by WS-Policy V1.5 [link] may be used.


 

into:

 

 In order to indicate that the subject supports WS-Addressing but does not
require its use, an additional policy alternative should be provided which
does not contain this assertion; the compact authoring style for an optional
policy assertion provided by WS-Policy V1.5 [link] may be used.  

 

I believe this is as explicit, but somewhat easier to read.

 

If people (especially Monica) object, I'll use the former version.

 

 

Tony Rogers

CA, Inc

Senior Architect, Development

tony.rogers@ca.com

co-chair UDDI TC at OASIS

co-chair WS-Desc WG at W3C