RE: Action 270

>1. What is a policy vocabulary?

Last Wednesday, the Working Group began clarifying the definition of the term Policy Vocabulary<http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_vocabulary> and Policy Alternative Vocabulary<http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative_vocabulary>. Let's try and clarify these definitions (yellow highlights new text) ...

"A policy vocabulary is the set of all policy assertion types of the assertions contained within a policy. The assertion types of the assertions that are contained within nested policy expressions (if any) in the assertions contained within the policy are not part of the policy vocabulary."

"A policy alternative vocabulary is the set of all policy assertion types of the assertions that are contained within the policy alternative. The assertion types of the assertions that are contained within nested policy expressions (if any) in the assertions contained within the policy alternative are not part of the policy alternative vocabulary."

>2. What is the role of a policy vocabulary in intersection?

The policy intersection does not rely on the policy vocabulary or policy alternative vocabulary. The policy vocabulary of the intersection (resulting policy) can be useful to apply the negation semantics outlined in Section 3.2, WS-Policy Framework<http://www.w3.org/TR/2007/CR-ws-policy-20070330/#rPolicy_Alternative>. Let's try and clarify this in Section 4.5, Policy Intersection<http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Policy_Intersection> (yellow highlights new text) ...

"If two policies are compatible, their intersection is the set of the intersections between all pairs of compatible alternatives, choosing one alternative from each policy. The vocabulary of the intersection is the union of the policy vocabularies of the two compatible policies."

>3. What is a policy alternative vocabulary?

See Q1.

The attached document highlights the above suggested clarifications to the Framework spec. We hope this helps.

Regards,

Asir S Vedamuthu
Microsoft Corporation



From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Maryann Hondo
Sent: Tuesday, April 10, 2007 12:10 PM
To: public-ws-policy@w3.org
Subject: 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)