RE: 3554: "Policy Alternatives" and "Policy" need proper definiti on

Hi,

>Prasad, do you think we should describe these concepts with illustrative
>examples in the Primer?

Asir, Dan and I had an offline discussion on this and I am happy to close
this issue and issue 3553 with the resolution to explain / clarify these
aspects in the primer.

Thanks.

Prasad

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Friday, August 04, 2006 5:45 PM
To: Prasad Yendluri; Anthony Nadalin
Cc: Daniel Roth; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: 3554: "Policy Alternatives" and "Policy" need proper def
inition

Hi Prasad,

Thank you for your clarification.

> The point is that the nested policy in 
> “Example Policy 2” has policy alternatives
> that are identical to the policy 
> alternatives in “Example Policy 1”.

Agreed

Let us construct the policy alternatives from your example Policy 2.
Constructing the alternatives from the XML Information Set representation
involves multiple steps including normalization. Your example Policy 2 in
the policy normal form is:


01 <Policy>
02   <ExactlyOne>

== Policy Alternative 1

03    <All>
04      <Assertion1/>
05      <Assertion4>
06        <Policy>
07          <ExactlyOne>
08            <All>
09              <Assertion5/>
10              <Assertion6/>
11            </All>
12          </ExactlyOne>
13        </Policy>
14      </Assertion4>
15    </All>

== Policy Alternative 2

16   <All>
17     <Assertion1/>
18     <Assertion4>
19       <Policy>
20         <ExactlyOne>
21           <All>
22             <Assertion5/>
23             <Assertion7/>
24           </All>
25         </ExactlyOne>
26       </Policy>
27    </Assertion4>
28   </All>

== Policy Alternative 3

29   <All>
30     <Assertion2/>
31     <Assertion4>
32       <Policy>
33          <ExactlyOne>
34            <All>
35              <Assertion5/>
36              <Assertion6/>
37            </All>
38          </ExactlyOne>
39       </Policy>
40     </Assertion4>
41   </All>

== Policy Alternative 4

42   <All>
43     <Assertion2/>
44     <Assertion4>
45       <Policy>
46         <ExactlyOne>
47           <All>
48             <Assertion5/>
49             <Assertion7/>
50           </All>
51         </ExactlyOne>
52       </Policy>
53     </Assertion4>
54   </All>

39  </ExactlyOne>
40 </Policy>   

WS-Policy describes the algorithm for converting a policy expression in the
compact form to the normal form [1].

The above policy expression in the normal form maps to the following policy:

Alternative 1 = {Assertion 1, 
                 Assertion 4 w Nested Policy (5,6)}
Alternative 2 = {Assertion 1, 
                 Assertion 4 w Nested Policy (5,7)}
Alternative 3 = {Assertion 2, 
                 Assertion 4 w Nested Policy (5,6)}
Alternative 4 = {Assertion 2,
                 Assertion 4 w Nested Policy (5,7)}

WS-Policy describes the mapping from the normal form to the policy data
model [2][3].

Policy implementers use the normative text to construct a policy from the
XML Information Set representation and do not rely on the terminology used
in the drafts. The definitions of ‘Policy’ and ‘Policy Alternative’ are at
the policy data model level. As you can see, a policy is a collection of
policy alternatives.

I looked through the interop archive [1] to see if there are any test cases
that represent your example Policy 2. I found three test cases:
Policy23.xml, Policy24.xml and Policy 25.xml. These test cases use
WS-SecurityPolicy assertions. Their intersection results are in the
‘/intersected’ directory of the interop archive. I am not aware of any
related interop issues.

Prasad, do you think we should describe these concepts with illustrative
examples in the Primer?

[1]
http://www.w3.org/TR/2006/WD-ws-policy-20060731/#Compact_Policy_Expression 
[2]
http://www.w3.org/TR/2006/WD-ws-policy-20060731/#Normal_Form_Policy_Expressi
on 
[3]
http://www.w3.org/TR/2006/WD-ws-policy-20060731/#Policy_Assertion_Nesting
[4]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Jun/att-0010/WS-Pol
icy-Interop-Artifacts-04-11-2006.zip 

Regards,

Asir S Vedamuthu
Microsoft Corporation

________________________________________
From: Prasad Yendluri [mailto:prasad.yendluri@webmethods.com] 
Sent: Wednesday, August 02, 2006 8:18 PM
To: Anthony Nadalin; Asir Vedamuthu
Cc: Asir Vedamuthu; Daniel Roth; Prasad Yendluri; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

Hi Asir,

Yes the example below does have a nested policy.  I used … around the
<wsp:policy> elements  on purpose, to skip some unnecessary detail, that are
not needed to illustrate the issue at hand.

The point is that the nested policy in  “Example Policy 2” has policy
alternatives that are identical to the policy alternatives in “Example
Policy 1”.
With the current (somewhat loose) specification of a policy to be a
collection of policy alternatives, one can deduce that the alternatives in
the nested Policy specification are alternatives of the parent policy also,
which match the alternatives in “Example Policy 1” (and hence the two
policies are compatible etc.).  

It would be helpful to have more concrete definitions.

Regards,
Prasad

________________________________________
From: Anthony Nadalin [mailto:drsecure@us.ibm.com] 
Sent: Wednesday, August 02, 2006 6:56 PM
To: Asir Vedamuthu
Cc: Asir Vedamuthu; Daniel Roth; Prasad Yendluri; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

The example below does have nesting, as there is TransportBinding assertion
that has an AlgorithmSuite assertion and so on and so on

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Asir Vedamuthu" <asirveda@microsoft.com>
"Asir Vedamuthu" <asirveda@microsoft.com> 
Sent by: public-ws-policy-request@w3.org 
08/02/2006 04:09 PM

To

"Asir Vedamuthu" <asirveda@microsoft.com>, "Prasad Yendluri"
<prasad.yendluri@webmethods.com>, "Daniel Roth" <daniel.roth@microsoft.com>,
<public-ws-policy@w3.org>

cc


Subject

RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def inition





In the example below, it is not clear to me where assertions start and end.
As described in Section 4.3.2 [1], a nested policy expression is a policy
expression that is a child element of a policy assertion element:

"Any policy assertion MAY contain a nested policy expression. The schema
outline for a nested policy expression is:

<Assertion …>
 …
 ( <wsp:Policy …> … </wsp:Policy> )?
 …
</Assertion>"

In the example below, it does not look like any of these assertions have
nested policy expressions. Was this intentional? The normative text in
Section 4.3.2 seems to be clear that this must be the case.

[1]
http://www.w3.org/TR/2006/WD-ws-policy-20060731/#Policy_Assertion_Nesting

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

________________________________________
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Wednesday, August 02, 2006 7:12 AM
To: Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

RE the text of the specification is not explicit enough for this

A full worked out example that demonstrates how the current definitions are
ambiguous or not explicit enough is the best way to move forward on this.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

________________________________________
From: Prasad Yendluri [mailto:prasad.yendluri@webmethods.com] 
Sent: Tuesday, August 01, 2006 5:36 PM
To: Asir Vedamuthu; Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

Hi Asir,

> I noticed that your example policies do not use any nested policy
expression.

Section 4.3.3 defines:

Equivalence 
wsp:Policy is equivalent to wsp:All 

So, for readability, I have not explicitly put wsp:policy brackets around
things and used wsp:All.

If my  examples have been, 

 Example Policy 1:

 <wsp:All> 
   <!-- assertion 5 --> 
   <wsp:ExactlyOne>     
          <!-- assertion 6 --> 
          <!-- assertion 7 -->
   </wsp:ExactlyOne>
  </wsp:All>

Example Policy 2:

<wsp:All>
  <wsp:ExactlyOne>  
    <!-- assertion 1 -->
    <!-- assertion 2 -->
  </wsp:ExactlyOne>
  <wsp:ExactlyOne>  
    <!-- assertion 4 -->
     . . . .
     <wsp:policy> 
        <!-- assertion 5 -->  
        <wsp:ExactlyOne>   
          <!-- assertion 6 --> 
          <!-- assertion 7 -->
       </wsp:ExactlyOne>
    </wsp:policy>
    . .  .  .
  </wsp:ExactlyOne>
</wsp:All>

Would you not then have the same policy alternates for Policy 1 and the
nested policy in policy 2?
I understand the way you came up with the production of the alternatives for
each policy and agree that is the correct way to arrive at them.  The point
of the issue however is that, the text of the specification is not explicit
enough for this. What makes a nested alternative in a Policy specification
not an alternative of the parent policy, when policy is only defined to be
“a collection of policy alternatives”? The nested policy and hence the
embedded alternative is part of the same “collection” is it not?

Regards,
Prasad

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Tuesday, August 01, 2006 5:05 PM
To: Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

Hi Prasad,

Thank you for writing down these examples. Let us look at the two policy
expressions in your e-mail below.

Policy 1 has two alternatives:
A1 = {assertion 6, assertion 8}
A2 = {assertion 7, assertion 8} 

Policy 2 has six alternatives:
A3 = {assertion 1, assertion 4}
A4 = {assertion 2, assertion 4}
A5 = {assertion 1, assertion 5, assertion 6}
A6 = {assertion 1, assertion 5, assertion 7}
A7 = {assertion 2, assertion 5, assertion 6}
A8 = {assertion 2, assertion 5, assertion 7}
 
Two policy alternatives are compatible if each policy assertion in one
alternative is compatible with a policy assertion in the other and
vice-versa. None of the above policy alternatives are compatible. 

Two policies are compatible if a policy alternative in one is compatible
with a policy alternative in the other. Policy 1 and Policy 2 are
incompatible because none of the policy alternatives in Policy 1 is
compatible with a policy alternative in Policy 2.

Just as expected, these two policies are incompatible. I noticed that your
example policies do not use any nested policy expression.

I hope this helps.

PS: I’ll update your entry in Bugzilla.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

________________________________________
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
Sent: Monday, July 31, 2006 5:32 PM
To: Daniel Roth; Prasad Yendluri; public-ws-policy@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper def
inition

Dan,

Policy is defined to be a “collection of policy alternatives” only. Since an
assertion in policy alternative can embed another policy (as defined below),
a policy can end-up with policy alternatives in the policy embedded (in an
assertion of an alternative).

   <Assertion …>
  …
  ( <wsp:Policy …> … </wsp:Policy> )?
  …
</Assertion>

There is generally no ambiguity until we run into further specifications
that state things like “Two policies are compatible if an alternative in one
is compatible with an alternative in the other.”

Suppose you have the following two Policy specifications:

            Example Policy 1:

 <wsp:All> 
   <wsp:ExactlyOne>      <!—Alternative A →
          <!-- assertion 6 --> 
          <!-- assertion 7 -->
   </wsp:ExactlyOne>
   <!-- assertion 8 -->  <!—Alternative B →
</wsp:All>

               Example Policy 2:

<wsp:All>
  <wsp:ExactlyOne>  <!—Alternative 1 Top level →
    <!-- assertion 1 -->
    <!-- assertion 2 -->
  </wsp:ExactlyOne>
  <wsp:ExactlyOne>  <!—Alternative 2 Top level →
    <!-- assertion 4 -->
    <wsp:All> 
        <!-- assertion 5 -->  <!—Alternative 3 Nested →
        <wsp:ExactlyOne>      <!—Alternative 4 Nested →
          <!-- assertion 6 --> 
          <!-- assertion 7 -->
       </wsp:ExactlyOne>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:All>


Turns out <!—Alternative A → in Example Policy 1 is compatible with (same
definition as) the “nested” policy alternative marked 
<!—Alternative 4 Nested → in Example Policy 2.

Then using the definition, “Two policies are compatible if an alternative in
one is compatible with an alternative in the other.”, one can conclude that
Example Policy 1 and Example Policy 2 are compatible, without further
qualification of “alternative in a policy”. In reality, the policies are not
compatible of course even though, based purely on the current definition of
policy (and other related entities), one can arrive at that conclusion.

Hope that clarifies the issue.

Regards,
Prasad

________________________________________
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
Sent: Monday, July 31, 2006 4:24 PM
To: Prasad Yendluri; public-ws-policy@w3.org
Subject: RE: NEW ISSUE: "Policy Alternatives" and "Policy" need proper
definit ion

I’m having difficulty understanding this issue.  Some examples that
demonstrate how the current definitions are ambiguous would be helpful.

Thanks.

Daniel Roth

________________________________________
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
Sent: Wednesday, July 26, 2006 4:15 PM
To: public-ws-policy@w3.org
Subject: NEW ISSUE: "Policy Alternatives" and "Policy" need proper definit
ion

Title: "Policy Alternatives" and "Policy" need proper definition
 
Description: Section 2.3 terminology defines a “policy” to be, “a collection
of policy alternatives”
No further constraints on how these alternatives are grouped, i.e. on the
origin of alternatives in the collection.

Similarly section 3.2 (Policy) defines a “policy” to be: “a policy is a
potentially empty collection of policy alternatives.”

This “collection” does not account for level of nesting of a specific policy
alternative. 

Section 2.3 terminology defines a “Policy Alternative” to be “a collection
of policy assertions” only. 
No further restriction on how these assertions are grouped (or) the origin
of the assertions in the collection.


Similarly section 3.2 (Policy Alternative) defines a policy alternative to
be: 
“A policy alternative is a logical construct which represents a potentially
empty collection of policy assertions. An alternative with zero assertions
indicates no behaviors.”

This “collection” again does not account for level of nesting of a policy
assertion included.

Justification:
There is scope for interpretation that needs to be eliminated. “policy
assertion” and “policy” definitions need to account for level of nesting of
the collection they define. 
 
Target: WS-Policy 1.5 - Framework
 
Proposal – Tighten up the definitions of “policy” and “policy assertion”.
Sorry I have not come up suggestion for a specific replacement text at this
point.
Hope to follow-up later.


Regards,
Prasad Yendluri

Received on Tuesday, 8 August 2006 23:03:36 UTC