RE: NEW ISSUE: 4142 Contradictory recommendation for nesting and intersection

I am waiting to see whether the other working group members all agree on
the semantics that you are supposing. 
 
As I said, once we have agreement in the semantics, the fix is easy. 
 
Regards, 
 
--umit
 


________________________________

	From: Asir Vedamuthu [mailto:asirveda@microsoft.com] 
	Sent: Saturday, Jan 13, 2007 2:02 AM
	To: Yalcinalp, Umit
	Cc: public-ws-policy@w3.org
	Subject: RE: NEW ISSUE: 4142 Contradictory recommendation for
nesting and intersection
	
	

	Answer is NO - as per the policy intersection algorithm in
Section 4.5 [1]. We agree that the quoted sentence [2] in Section 4.3.2
is misleading. There is an easy fix - drop the sentence.

	 

	Regarding ACTION-181 [3], when should we expect your amended
proposal?

	 

	 

	[1] 
http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection>  

	 

	[2] "The reason for requiring at least an empty <wsp:Policy/>
Element above is to ensure that two assertions of the same type will
always be compatible and an intersection would not fail (see Section 4.5
Policy Intersection)"

	 

	[3] http://www.w3.org/2005/06/tracker/wspolicy/actions/181 

	 

	Regards,

	 

	Asir S Vedamuthu

	Microsoft Corporation

	 

	 

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
	Sent: Wednesday, January 10, 2007 12:11 PM
	To: Sergey Beryozkin; Anthony Nadalin
	Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org
	Subject: RE: NEW ISSUE: Contradictory recommendation for nesting
and intersection

	 

	The question is about the semantics. In the example, ex:Foo is
NOT a policy parameter. It is a nested assertion. Let me paraphrase for
more clarity. 

	 

	Is 

	 

	<ex:MyAssertion>

	     <wsp:Policy>

	           <ex:NestedAssertion>

	    </wsp:Policy>

	</ex:MyAssertion>

	 

	compatible with 

	 

	<ex:MyAssertion>

	     <wsp:Policy/>

	</ex:MyAssertion>

	 

	?

	 

	(a) No

	(b) Yes

	 

	Depending on your answer, the fix in the document is different.
Fix is secondary to what the wg members think the semantics is. 

	 

	Given that our WGs, such as WS-Addressing have been looking into
using nested assertions as well, this needs to be well aligned, agreed. 

	 

	--umit

	 

	 

		 

________________________________

		From: Sergey Beryozkin
[mailto:sergey.beryozkin@iona.com] 
		Sent: Wednesday, Jan 10, 2007 3:34 AM
		To: Anthony Nadalin
		Cc: public-ws-policy@w3.org;
public-ws-policy-request@w3.org; Yalcinalp, Umit
		Subject: Re: NEW ISSUE: Contradictory recommendation for
nesting and intersection

		Hi

		 

		Thanks for the explanation about the parameters. I think
I just got it wrong. In the Umit's example I thought ex:Foo was a
parameter, but it's actually a policy assertion in that example...so I
reckon option1 would still be the right approach to follow....

		 

		Cheers, Sergey

			----- Original Message ----- 

			From: Anthony Nadalin
<mailto:drsecure@us.ibm.com>  

			To: Sergey Beryozkin
<mailto:sergey.beryozkin@iona.com>  

			Cc: public-ws-policy@w3.org ; 
public-ws-policy-request@w3.org ; Yalcinalp, Umit
<mailto:umit.yalcinalp@sap.com>  

			Sent: Tuesday, January 09, 2007 5:07 PM

			Subject: Re: NEW ISSUE: Contradictory
recommendation for nesting and intersection

			 

			The ex:Foo parameter is a domain specific
processing item, not evaluated at the framework level, thus I would
consider the assertions in your example the same. This is the
understanding we have with Security Policy assertions. 
			
			Anthony Nadalin | Work 512.838.0085 | Cell
512.289.4122
			 "Sergey Beryozkin" <sergey.beryozkin@iona.com>

"Sergey Beryozkin" <sergey.beryozkin@iona.com> 
Sent by: public-ws-policy-request@w3.org 

01/03/2007 12:28 PM

 

To

 
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-policy@w3.org>



cc





Subject


Re: NEW ISSUE: Contradictory recommendation for nesting and intersection

 





			
			Hi
			
			" 

			(a) The statement in 4.3.2 quoted is in error.
Including a nested empty policy expression allows the compatibility
testing to occur, but does NOT guarantee the same types to be compatible
for intersection (which is implied by the intersection algorithm). Using
this logic, expressions 1 and 2 are not compatible as the intersection
algorithm suggests. " 

			seems like the right solution, as in 

			"The alternative in (1) is <wsp:Policy>
<ex:Foo/></wsp:Policy>. The alternative in (2) is <wsp:Policy/>." 

			(1) is more specialized than (2), has ex:Foo
policy parameter, hence they're different 

			Cheers, Sergey 

			----- Original Message ----- 
			From: Yalcinalp, Umit
<mailto:umit.yalcinalp@sap.com>  
			To: public-ws-policy@w3.org
<mailto:public-ws-policy@w3.org>  
			Sent: Wednesday, January 03, 2007 1:56 AM
			Subject: NEW ISSUE: Contradictory recommendation
for nesting and intersection

			Title: Contradictory recommendation for nesting
and intersection 

			Description: The specification provides some
guidance about when to include an empty policy element. Section 4.3.2,
Assertion/Policy element states: 

			{Note: if the schema outline for an assertion
type requires a nested policy expression but the assertion does not
further qualify one or more aspects of the behavior indicated by the
assertion type (i.e., no assertions are needed in the nested policy
expression), the assertion MUST include an empty <wsp:Policy/> Element
Information Item in its [children] property; as explained in Section
4.3.3 Policy Operators, this is equivalent to a nested policy expression
with a single alternative that has zero assertions. The reason for
requiring at least an empty <wsp:Policy/> Element above is to ensure
that two assertions of the same type will always be compatible and an
intersection would not fail (see Section 4.5 Policy Intersection). 

			} 
			The paragraph stated imply two different and
somewhat contradictory advice. 
			(a) A nested assertion by definition (via
schema) should always expressed using nesting, even if the nesting
yields zero assertions in a single alternative. (This is per the first
statement) 

			(b) Two assertions that have the same nesting
will always be compatible REGARDLESS of whether they have different
nested elements inside. (This is inferred from the last statement). 

			While the first statement is intuitive, the
second recommendation (b) is counter indicative per the intersection
algorithm and thus requires either changing or clarification. This is
due to the unclarity of the intersection algorithm. Consider the
following two policy expressions: 

			(1) 
			<wsp:Policy> 
			<wsp:ExactlyOne> 
			<wsp:All> 
			<ex:NestedAssertion> 
			<wsp:Policy> 
			<ex:Foo/> 
			</wsp:Policy> 
			</ex:NestedAssertion> 
			</wsp:All> 
			</wsp:ExactlyOne> 
			</wsp:Policy> 
			(2) 
			<wsp:Policy> 
			<wsp:ExactlyOne> 
			<wsp:All> 
			<ex:NestedAssertion> 
			<wsp:Policy/> 
			</ex:NestedAssertion> 
			</wsp:All> 
			</wsp:ExactlyOne> 
			</wsp:Policy> 
			According to the statement above, these
assertions are expected to be "compatible" but the intersection
algorithm in Section 4.5 does not confirm this expectation: 

			{If either assertion contains a nested policy
expression, the two assertions are compatible if they both have a nested
policy expression and the alternative in the nested policy expression of
one is compatible with the alternative in the nested policy expression
of the other. } 

			According to the previous statement, the nested
expressions in (1) and (2) are NOT compatible assertions, either in
strict or lax mode because of the definition of the compatibity of the
alternatives are governed by the following. (Lets consider strict mode
for simplicity) 

			{If the mode is strict, two policy alternatives
A and B are compatible: 

				*	if each assertion in A is
compatible with an assertion in B, and 
				*	if each assertion in B is
compatible with an assertion in A.} 

			The alternative in (1) is <wsp:Policy>
<ex:Foo/></wsp:Policy>. The alternative in (2) is <wsp:Policy/>.
According to the compatibility definition, these two alternatives are
not compatible as there is no nested ex:Foo element within the second
alternative for (2). 

			Therefore, including a nested policy expression
WILL STILL FAIL the intersection algorithm in contradiction to the
statement: 

			{The reason for requiring at least an empty
<wsp:Policy/> Element above is to ensure that two assertions of the same
type will always be compatible and an intersection would not fail (see
Section 4.5 Policy Intersection). } 

			Thus the specification is in conflict with
itself and this should be resolved. See proposal section for two
alternative ways of fixing this. 

			Target: Framework, Primer 

			Justification: The specification is
contradictory with itself. It does not explain the utility of nesting
and empty policy expression well. The clarification should be included
in the framework as well as the primer since it was deemed necessary for
an explanation in the framework document itself for further
clarification in the first place. Readers who are not familiar with the
nesting will definitely get this wrong, especially there is
contradictory statements in the specification. 

			Proposal: 
			There are two ways to interpret this conflict as
there are two possible ways forward depending on the intent of the
specification: 

			(a) The statement in 4.3.2 quoted is in error.
Including a nested empty policy expression allows the compatibility
testing to occur, but does NOT guarantee the same types to be compatible
for intersection (which is implied by the intersection algorithm). Using
this logic, expressions 1 and 2 are not compatible as the intersection
algorithm suggests. 

			This requires fixing the last sentence in the
quoted paragraph in Section 4.3.2. 
			(b) The intersection algorithm makes a special
provision for an empty policy assertion to allow compatibity with
nesting. This means expressions 1 and 2 are always compatible with each
other. This means when we have nested empty policies, it is a cop-out
for cheating the intersection algorithm and thus requires the
intersection algorithm to account for this specifically. 

			The resolution requires including an example,
preferably to the framework, alternatively to the primer to illustrate
the result of intersection with the examples provided in this report. If
(b) is chosen, adding some guidance to Guidelines document will be
appropriate as well as the framework fix. 

			This report is filed as [Bug 4142]. 

			[1] http://www.w3.org/TR/ws-policy/
<http://www.w3.org/TR/ws-policy/>  
			[2] 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142>  
			---------------------- 

			Dr. Umit Yalcinalp 
			Research Scientist 
			SAP Labs, LLC 
			Email: umit.yalcinalp@sap.com Tel: (650)
320-3095 
			SDN: 
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
<https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238>  
			-------- 
			"Nearly all men can stand adversity, but if you
want to test a man's character, give him power." Abraham Lincoln.