W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

RE: NEW ISSUE 4138: Normalization Algorithm is broken

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 16 Jan 2007 09:14:22 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D6416503241892@uspale20.pal.sap.corp>
To: "Asir Vedamuthu" <asirveda@microsoft.com>, <public-ws-policy@w3.org>
I am glad at least we agree that is the expected semantics. 
 
I guess what we do not agree is the explicitness of the rule 4 to get
there. 
 
--umit
 


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
	Sent: Monday, Jan 15, 2007 11:51 PM
	To: Yalcinalp, Umit; public-ws-policy@w3.org
	Subject: RE: NEW ISSUE 4138: Normalization Algorithm is broken 
	
	

	>"what is the expected result"

	 

	<Policy>

	  <ExactlyOne>

	    <All>

	      <wsap:UsingAddressing/>

	    </All>

	  </ExactlyOne>

	</Policy>

	 

	How to get there?

	 

	Rule 4 applies. The Policy operator is equivalent to All. That
is, '<All><wsap:UsingAddressing/></All>'. This is a policy alternative
with one assertion. Construct a normal form as per Section 4.1 = the
above result.

	 

	I 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 Yalcinalp, Umit
	Sent: Monday, January 15, 2007 10:36 AM
	To: Asir Vedamuthu; public-ws-policy@w3.org
	Subject: RE: NEW ISSUE 4138: Normalization Algorithm is broken 

	 

	Asir, 

	 

	Instead of thinking of "what is the minimum change", I would
like to approach it as to "what is the expected result" first and then
find out how we can achieve it. 

	 

	Could you tell me first what the normalized form of 

	 

	<wsp:Policy>

	      <wsap:UsingAddressing/>

	</wsp:Policy>

	 

	is? 

	 

	Lets go from there. "Construct a normal form" for this does not
really follow and indicate what the result should be. 

	 

	Thanks, 

	 

	--umit

	 

		 

________________________________

		From: Asir Vedamuthu [mailto:asirveda@microsoft.com] 
		Sent: Sunday, Jan 14, 2007 10:59 PM
		To: Yalcinalp, Umit; public-ws-policy@w3.org
		Subject: RE: NEW ISSUE 4138: Normalization Algorithm is
broken 

		>Thus, readers following the Framework with 

		>the primer document and trying to formulate

		>a normal form will not be able to get what 

		>they want.

		 

		First, thank you for carefully reviewing the
normalization algorithm and manually working out an example (this is
equivalent to running a unit test).

		 

		We looked into interop test cases. There are many test
cases that use the form <Policy><wsap:UsingAddressing /></Policy> in the
contributed interop scenarios pack [1]. Several implementers ran these
test cases. The good news is that there aren't any related interop
issues.

		 

		Framework document says [2], "4. Apply the policy
operator indicated by D to the normalized Element Information Items in
its [children] property and construct a normal form per Section 4.3.3
Policy Operators."

		 

		In the above sentence, 'construct a normal form' is the
key phrase and it refers to the normal form in Section 4.1 [3]. Section
4.1 XML outline and prose describe how a policy alternative in the
normal form looks like. To help readers make this connection, we suggest
that the normalization algorithm carry an explicit reference to the
normal form. This means, the proposed change is:

		 

		s/4. Apply the policy operator indicated by D to the
normalized Element Information Items in its [children] property and
construct a normal form per Section 4.3.3 Policy Operators./4. Apply the
policy operator indicated by D to the normalized Element Information
Items in its [children] property and construct a normal form per Section
4.3.3 Policy Operators and 4.1 Normal Form Policy Expression./

		 

		We belive that the above proposed change is the minimum
needed to resolve issue 4138 [4].

		 

		[1]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Jun/0010.html
<http://lists.w3.org/Archives/Public/public-ws-policy/2006Jun/0010.html>


		[2]
http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Compact_Policy_Expressi
on
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Compact_Policy_Express
ion>  

		[3]
http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Normal_Form_Policy_Expr
ession
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Normal_Form_Policy_Exp
ression> 

		[4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4138
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=4138>  

		 

		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: Tuesday, January 02, 2007 11:58 AM
		To: public-ws-policy@w3.org
		Subject: NEW ISSUE: Normalization Algorithm is broken 

		 

		Title: Normalization Algorithm is broken 

		Description: The Normalization Algorithm in the
WS-Policy framework is broken in converting a single expression of
conjuncts in compact form to an equivalent expression normal form and
does not lead to a normal form expression as illustrated below.

		For expressions of the following form where the
wsp:Policy element may have single element child, or a multiple element
children composition with wsp:All such as: 

		<wsp:Policy> 
		    <ex:Assertion1/> 
		</wsp:Policy> 

		or 

		<wsp:Policy> 
		    <wsp:All> 
		       <ex:Assertion1/> 
		       <ex:Assertion2/> 
		    </wsp:All> 
		</wsp:Policy> 

		The normalization algorithm fails to convert this into
an equivalent expression. It would be expected to derive a normal form
expression with a single alternative of the form from such expressions. 

		<wsp:Policy> 
		    <wsp:ExactlyOne> 
		       <wsp:All> 
		            List of Assertions 
		       </wsp:All> 
		    </wsp:ExactlyOne> 
		</wsp:Policy> 

		but the algorithm fails to do so. 

		In both cases, there is no wsp:optional attribute to
introduce two alternatives into the resulting expression converted to
the normal form. Thus, no wsp:exactlyOne is introduced in this case, and
the resulting expression can not be normalized. 

		Note that the primer [1] uses such an example for the
use of WS-Addressing in Example 2.2. Thus, readers following the
Framework with the primer document and trying to formulate a normal form
will not be able to get what they want. I will illustrate the result
using the following example: 

		<Policy> 
		  <wsap:UsingAddressing /> 
		</Policy> 

		Taking the first form (a single child element) as an
example, here is the rundown of the normalization algorithm: 

		 

			1.	Start with the [document element]
property D of the Document Information Item of the policy expression.
The [namespace name] of D is always "http://www.w3.org/2006/07/ws-policy
<http://www.w3.org/2006/07/ws-policy> ". In the base case, the [local
name] property of D is "Policy"; in the recursive case, the [local name]
property of D is "Policy", "ExactlyOne", or "All". 
			2.	Expand Element Information Items in the
[children] property of D that are policy references per Section 4.3.5
Policy Inclusion <file:///\\l%20> . 
			3.	Convert each Element Information Item C
in the [children] property of D into normal form. 

				1.	If the [namespace name] property
of C is "http://www.w3.org/2006/07/ws-policy
<http://www.w3.org/2006/07/ws-policy> " and the [local name] property of
C is "Policy", "ExactlyOne", or "All", C is an expression of a policy
operator; normalize C by recursively applying this procedure. 
				2.	Otherwise the Element
Information Item C is an assertion; normalize C per Sections 4.3.1
Optional Policy Assertions <file:///\\l%20>  and 4.3.2 Policy Assertion
Nesting <file:///\\l%20> . 

			4.	Apply the policy operator indicated by D
to the normalized Element Information Items in its [children] property
and construct a normal form per Section 4.3.3 Policy Operators
<file:///\\l%20> . 

		 

		Here is what happens if you follow this step by step. 

		1. applies <wsp:Policy> 
		2. does not apply 
		3. The element information item C is
wsap:UsingAddressing. 
		    4. does not apply 
		    5.  there is nothing to normalize (as 4.3.1, or
4.3.2 does not apply) 
		6. The policy operator indicated by D is wsp:Policy
which is equivant to "wsp:All" 

		    "Applying" wsp:All to wsaw:UsingAddressing is 

		     <wsp:All><wsaw:UsingAddressing/></wsp:All> 

		     There is no optional assertion, etc. Thus,
<wsp:exactlyOne> is not introduced anywhere per the rules of the
algorithm. 

		The resulting Expression is 

		     <wsp:All><wsaw:UsingAddressing/></wsp:All> 

		This is not in normal form!!! 

		It is noted that it is impossible to convert an
assertion which does not have an wsp:optional attribute to a normal
form. This appears to be a deficiency of the algorithm, and not its
intention. This is a bug in the framework. 

		Justification: 

		A common form of the expression is expected to work
without the presence of wsp:optional attribute. It is possible to create
such expressions using the policy framework. As a matter of fact, the
example is from our own primer document itself. The algorithm should
work for simple cases when single alternatives are intended by compact
form as well as complicated cases where alternatives are introduced by
the presence of the wsp:optional attribute implicitly. The algoritm
should not assume the presence of wsp:optional to introduce
alternatives. 

		Proposal: 

		Add another step for the normalization algorithm along
the lines of 

		7. If the resulting expression contains no alternatives,
the expression is equivalent to a policy with a single alternative where
the content of the resulting expression comprises its content.

		 

		This issue is filed as [Bug 4138] with the content that
is provided above. 

		 

		[1]
http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/
<http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/>  
		[Bug 4138]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4138
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=4138>  

		 

		---------------------- 

		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. 

		 
Received on Tuesday, 16 January 2007 17:13:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT