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

Prasad, 
 
I am not clear on the issue, but let me give it a shot. 
 
Are you saying that the we should always indicate that alternatives are meaningful only after normalization and somehow this is not clear in the specification? 
 
In the end, one would always need to account for normalization prior to testing compatibility with alternatives. Any discussion of compatibility needs to account for normalization as the normalization basically distributes the alternatives in a nested assertion to the parent by affecting the alternatives of the parent. For example, in Policy 2 the nested assertion may appear to be identical to Policy 1, but after normalization the alternatives would not be compatible with Policy 1 as there would be additional conjunctions with Assertion1 OR Assertion 2 that would be added. Thus the alternatives in a normalized parent would end up removing alternatives in the nested children although the nesting of the assertions would be preserved. I believe this is the spirit of the example in Section 4.3.2 as well. 
 
I am wondering actually starting the example in Section 4.3.2 with a compact form may also contribute to some confusion in this regard because we need to show that one adds to the number of alternatives due to normalization by taking the alternatives in the children into account. 
 
Therefore, I am asking whether that the perceived problem is probably not in the definitions but illustrating WHEN it is appropriate to use alternatives in matching and compatibility. 
 
Cheers, 
 
--umit
 


________________________________

	From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
	Sent: Wednesday, Aug 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