Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>> jeyaraman: It is possible for a client to infer MAY behavior based on 
>> the
>> normalized policy alternatives (MUST and SHOULD NOT).
>>
>> For example, an operation may advertise a compact form of the AT policy
>> assertion, such as:
>>
>> 1 <wsdl:operation name="TransferFunds" >
>> 2 <wsp:Policy>
>> 3 <wsat:ATAssertion wsp:optional="true" />
>> 4 </wsp:Policy>
>> 5 </wsdl:operation>
>>
>> A consumer may normalize the above policy expression (in compact form)
>> into two policy alternatives: one with AT assertion (MUST) and another
>> without it (SHOULD NOT). These two alternatives indicate that the AT
>> behavior MAY be engaged.
>>
>> Hence, there is no need for a new attribute.
>
mm1: Ram, let's separate Issue 45 [reference 1] concerns here:

    (1) Composition with WS-Policy and the use of the compact form
    (shortcut for expressing multiple alternatives)
    (2) WS-AT intended use of this optional attribute

Clearly, choices made where wsat:ATAssertion wsp:Optional="true" is used 
or not, and if the policy is normalized, have impacts to implementation 
and interoperability.

(1) In Section 3.2 of WS-Policy [reference 2]:

"An assertion whose type is part of the policy's vocabulary but is
not included in an alternative is explicitly prohibited by the
alternative."

Interpretation of the above WS-Policy text indicates that the WS-AT 
description of the compact shortcut, wsp:Optional="true", has to be the 
policy alternatives "MUST" and "MUST NOT" rather than the current 
specified alternatives of "MUST" and "SHOULD NOT". Otherwise, WS-AT is 
misusing WS-Policy.

(2) WS-Policy does not prohibit postponing the selection of a final 
policy alternative, and this could be done with normalized forms, at the 
expense of a complex client interface. But, your simple example contains 
only a single assertion. In actual applications, a policy alternative 
can and likely will contain multiple types of policy assertions 
[reference 3].
According to WS-Policy, a wsdl:binding/wsdl:operation can have a set of 
policy alternatives, one of which MUST be chosen. The final selection of 
one alternative could be delayed so long as they are acceptable to both 
client and service.
However, it is unlikely that all types of assertions can support 
postponing the selection of a final policy alternative.

In Section 5.2, WS-AT:

    "The absence of the assertion is interpreted to mean that a
    transaction SHOULD NOT be flowed inside a requester’s message."

There are two points of view to the above stated behavior. If a 
requestor's message does flow a transaction that SHOULD NOT have been 
flowed, the current WS-AT specification leaves undefined how the service 
would handle such an unexpected transaction.

The WS-AT specification does not state what happens when a policy 
assertion is not met. We should define that a service interpretation of 
the policy assertion takes precedence when the requestor flows a 
transaction context it should not have flowed. The service can either 
silently ignore the non-requested transaction context or it can fault on 
the mismatch between client and service interpretation of the wsat 
policy assertion.

Thanks.


==========
[1] Issue 45: 
http://lists.oasis-open.org/archives/ws-tx/200603/msg00168.html (on 
public site)

[2] Reference: http://www.w3.org/Submission/WS-Policy/, see some of the 
sections important to this discussion:
[start]
p. 6, 3.1 Policy Assertion
"A policy assertion identifies a behavior that is a requirement (or 
capability) of a policy subject."

p. 6, 3.2 Policy Alternative
"A policy alternative is a logical construct which represents a 
potentially empty collection of policy assertions. An alternative with 
zero assertions indicates no behaviors. An alternative with one or more 
assertions indicates behaviors implied by those, and only those 
assertions."...

"An assertion whose type is part of the policy's vocabulary but is not 
included in an alternative is explicitly prohibited by the alternative."

p. 7, 3.4 Web services
"A requester may choose any alternative since each is a valid 
configuration for interaction with a service, but a requester MUST 
choose only a single alternative for an interaction with a service since 
each represents an alternative configuration."

"A policy assertion is supported by a requester if and only if the 
requester satisfies the requirement (or accommodates the capability) 
corresponding to the assertion."

p. 10, 4.3.1 Optional Policy Assertions
"To indicate that a policy assertion is optional, this specification 
defines an attribute that is a syntactic shortcut for expressing policy 
alternatives with and without the assertion." [schema for Optional follows]
"/Assertion/@wsp:Optional
If true, the expression of the assertion is semantically equivalent to 
the following:
<wsp:ExactlyOne>
<wsp:All><Assertion ...> ... </Assertion> </wsp:All>
<wsp:All />
</wsp:ExactlyOne>

If false, the expression of the assertion is semantically equivalent to 
the following:
<wsp:ExactlyOne>
<wsp:All><Assertion ...> ...</Assertion></wsp:All>

Omitting this attribute is semantically equivalent to including it with 
a value of false." [an example follows with an actual assertion]
[end]

[3] According to WS-Policy, an alternative is a set of options (assertions).