[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ws-tx 5/30/2006: WS-AT Semantics, wsp:Optional, and WS-Policy
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]