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.