Action 270

This action item was to formulate a proposal against the Guidelines 
document, but there may be a need to 
change other documents as well. In our effort to propose changes to the 
Guidelines, we (Monica, Ashok, Dale and Maryann) had a fairly detailed 
discussion and we now put forward a set of topics that we identified might 
be of interest for discussion by the WG.

In ongoing discussions (prompted by WS-Addrssing issues), questions have 
arisen about Framework 
definitions; we should be detailed and clear on these.

1.    What is a policy vocabulary?
2.    What is the role of a policy vocabulary in intersection?
3.    What is a policy alternative vocabulary?
4.    What is the role of a policy alternative vocabulary in intersection?

   Asir's note seems to indicate that every Policy Alternative has its own
   policy vocabulary [1]. Yet, Section 3.2 Framework uses "Policy
   Vocabulary" (note singular) which implies a single vocabulary for
   the entire policy. Also, if each alternative has its own vocabulary
   then the sentence - "When an assertion whose type is part of the
   policy's vocabulary is not included in a policy alternative, the
   policy alternative without the assertion type indicates that the
   assertion will not be applied in the context of the attached policy
   subject" - has little or no meaning because there could conceivably
   never be a policy assertion that is not in the policy vocabulary.

And, further questions apply.
5.  What is a nested policy alternative vocabulary?
6.  What is the role of a nested policy alternative vocabulary in 
intersection?

There seems to be general agreement that nested policy assertions are 
part of the policy vocabulary.  If so, this needs to be spelled out 
carefully and explicitly.

In line with these core definitions and these open questions, three 
ideas do not currently cohere smoothly in the WS-Policy Framework. 
Within our work group and in other domains defining policy assertions, 
different assumptions appear to be applied and used. Examples include 
note from Asir Vedamuthu, efforts in WS-Addressing, and within WS-Policy 
WG. They are:


 1. Policy assertion authors should be allowed to specify that a set
    of policy assertions are mutually exclusive.
 2. Policy assertion authors should be allowed to use an empty policy
    alternative to indicate "neutrality" on a set of policy assertions.
 3. An absent policy assertion (from the relevant vocabulary) is
    equivalent to the presence of the negation of that assertion. (a
    "closed world" assumption).[2]

When any two of these are applied, it could lead to inconsistency or 
conflict with the other. We've seen, for example:

  * Use of 1 and 2 conflicts with 3.
  * Use of 2 and 3 conflicts with 1.

This crops up for WS-Addressing with their wsam:Addressing, and various 
response types. This issue, not limited to WS-Addressing. could lead to 
the development of self-conflicting policies. As has been indicated, 
conformance may also apply - see WS-Addressing case where its core 
functionality actually sets the baseline. More on this comes later as an 
additional discussion related to this issue, specific to the 
WS-Addressing case. [3]

Using an example for 3-way mutual exclusion only, let's conceptualize the 
challenge that exists.

Mutually exclusive policy assertions A, B, and C are constrained so that:

  A <--> -(B or C)
...

  B <--> -(A or C)
...

  C <--> -(A or B)
...

Suppose that policy assertion E has a nested policy domain defined with 
mutually exclusive policy assertions A, B, and C. Then the vocabulary of a 
nested 
alternative is {A, B, C}.

An empty alternative will then, by the absent assertion implies negation 
principle, imply:

  -A and -B and -C

Consider that, for example, -(B or C) is equivalent to (-B and -C), 
which implies A. But we already have -A, and therefore a contradiction.

As a result, we have the following options to avoid this inconsistency:

  Option 1: Policy assertion authors may not be allowed to constrain
  policy assertions to be mutually exclusive.

Note: This is an unacceptable limitation in general, looking at 
WS-Addressing and others as possible examples.

  Option 2: Policy assertion authors must not be allowed to use an
  empty alternative to indicate neutrality.

Note: This is an unexpected limitation that seems like it should be 
avoided.  This would necessitate that authors define define assertions 
that consist of mutally exculive alternatives and in any given policy 
instance enforce that one must be specified(default).

  Option 3: The absence of an assertion  is illegal or means it is
  negated.

Note: The consensus of our group was that "absence means negation" 
convention should be abandoned. 
[Relates to CWA - see 2] Need to explore to see if this could affect 
wsp:Optional and may 
require that policy assertions are explicitly stated. Doing away with 
this assumption may result in the least change needed.  This would 
necessitate that 
authors define what empty means if empty is allowed. Eliminating this 
assumption  implies
that authors define that any policy instance must consist either of 
mutually 
exclusive alternatives or an empty alternative and they explain the 
semantics of the empty 
assertion.

Another example shows this as well, where a policy exists with the 
following policy assertions (not assertion parameters - pseudo code):

Policy A
<wsp:Policy>
   <wsp:ExactlyOne>
        <xx:Assertion A>
             <wsp:Policy>[first match]
                  <wsp:ExactlyOne> 
                       <
                       xx:Assertion B>
                       <xx:Assertion C>
                  </wsp:ExactlyOne>
             </wsp:Policy>
        <xx:Assertion E>
             <wsp:Policy>[first match]
                  <wsp:ExactlyOne>
                       <xx:Assertion B>
                       <xx:Assertion C>
                  <wsp:ExactlyOne>
             </wsp:Policy>
    </wsp:ExactlyOne>
</wsp:Policy>

intersected with a policy like this:

Policy B
<wsp:Policy>
  <xx:Assertion A>
     <wsp:Policy>[first match]
             <xx:Assertion B>
     </wsp:Policy>
</wsp:Policy>

The processing of nested policy assertions occurs in 'depth first' order 
whereby:

  * Assertion B would match in each descent of the policy alternatives.
  * However the AssertionB under AssertionE would be rejected because
    the higher level QNames did not match.

The primary impact occurs with the CWA.  An advantage of removing CWA is 
that the Policy Vocabulary idea can be replaced by the definition of 
processing rules of the 
(immediate) policy assertion scope of a nested policy assertion in 
explaining intersection. Policy vocabulary was mainly needed to explain 
how to apply CWA consistently (so that the range of the underlying 
assertion domain scope was defined). Policy scoping now allows empty to be 
neutral, in that
the framework matches on the high level Qname, but says nothing about a 
match for nested assertions
that do not match. It also might necessitate changes to the assumptions 
WS-Addressing found.

Note: This email provides some basis for a proof for change.  A next 
step may be to address the intersection algorithm and its scope. 


=========
[1] Action 271 response: 
http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0017.html
[2] CWA = Closed World Assumption

  http://en.wikipedia.org/wiki/Closed_world_assumption
  http://moonbase.wwc.edu/~aabyan/Logic/CWA.html

[3] To resolve a key question from the WS-Addressing group that 
underlies many questions we pose the question:

Can  authors represent mutually exclusive behavior and use empty to 
indicate 'both/all' behaviors?

One answer might be:
When an assertion whose semantic when empty, is to indicate neutrality to 
the "both/all" behavior
is scoped to an endpoint level (in which multiple exchanges of messages 
are covered) it may still result in 
failures since it is unclear from that policy which behavior applies to 
any given message. To ensure the correct characterization of all message 
exchange patterns, the authors ( like WS-Addressing) may need to define an 
additional set of assertions which when scoped to a message level could 
indicate the exact set of patterns that the endpoint supports. In addition 
the client would need to reverse its own requirements and match on the 
characteristics that it desires in a service not on its own capabilities.



(note to Monica, Ashok, Dale....hope I captured it all correctly in this 
last round)