ws-tx 5/30/2006: WS-AT Semantics, wsp:Optional, and WS-Policy

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

Everyone,
After the meeting 18 May and subsequently, we've worked on several 
options seen as optimal for Issue 45: Use of wsp:Optional. Of all the 
possible approaches, it appears the simplest one is the use of 
SHOULD/SHOULD NOT that allows **exactly two** equivalent behaviors 
(SHOULD/SHOULD NOT), is consistent with WS-Policy and wsp:Optional, and 
doesn't require a new local attribute. In WS-AT, this effectively 
changes the MUST to SHOULD [1], and simplifies our original proposal. [2]
In tandem, Joe has also proposed an alternative that achieves the same 
result in a slightly different fashion (MUST/MUST IGNORE rather than 
SHOULD/SHOULD NOT). [3] They are two sides of the same coin and achieve 
the same goal.

In WS-Policy, "A policy assertion represents an individual requirement, 
capability, or other property of a behavior." For example, that 
"requirement" or "property" can be "expected, but not required". And 
absence could be defined as "not expected, but will not generate an 
error". Using the concept of **exactly two** equivalent behaviors, we 
can define our own semantics and specify the behavior (flow, ignore, 
etc).[4] Anything more would require a new multi-valued attribute.

If we consider supporting MUST and NO CLAIMS or UNDEFINED as has 
alternatively been proposed, we may:

1. Create a condition whereby there is no way to differentiate if the 
assertion doesn't exist anywhere in the policy (absence of a policy 
assertion means "no claims" if there is no instance of the assertion in 
the entire policy) or the assertion is present in at least one 
alternative (MUST NOT). [5]

2. Leave the client in a difficult state - if a client attempts to 
attach to that service, the client doesn't know what the service will do 
(error, ignore or flow transaction).

We're particularly concerned when we see composition with other 
assertions such as security, and the complicated after-effects of any 
decision we make in isolation. Our goal is to support rather than 
compromise the utility and certainty that transactions are envisioned to 
provide, and the behavior we expect (whether transactional or not). Thanks.

[1] Section 5.2:
Change from: "A policy assertion that specifies that an atomic 
transaction MUST be flowed inside a requester’s message."
Change to: "A policy assertion that specifies that an atomic transaction 
SHOULD be flowed inside a requester’s message."

    Note: We can discuss other possible revisions to this section after
    we concentrate on acceptance of this concept itself first.

[2] Original proposal: 
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00168.html
[3] For Joe's equivalent alternative, see: 
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200605/msg00229.html. 

[4] The key is to remain consistent between normalized and compact 
policies.
[5] This has implications on policy engines and the need for a complex 
client interface.