RE: NEW ISSUE 4138: Normalization Algorithm is broken

The following is a joint proposal from Asir, Dan, Maryann and Umit. This proposal solves the general case.

Change 1 (Target: Section 4.3, Compact Policy Expression):

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./

Change 2 (Target: 4.3.3 Policy Operators)

Add a new primitive rule to the 'Equivalence' sub section:

A collection of assertions in an wsp:All operator is equivalent to a policy alternative. For instance,

<wsp:All>
  <!-- assertion 1 -->
  <!-- assertion 2 -->
</wsp:All>

is equivalent to

<wsp:ExactlyOne>
  <wsp:All>
    <!-- assertion 1 -->
    <!-- assertion 2 -->
  </wsp:All>
</wsp:ExactlyOne>

Regards,
 
Asir S Vedamuthu
Microsoft Corporation







From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B Ferris
Sent: Tuesday, January 16, 2007 11:54 AM
To: public-ws-policy@w3.org
Subject: RE: NEW ISSUE 4138: Normalization Algorithm is broken


The WG is considering a proposal discussed this morning in the F2F. 

Specifically, add the following step to the set of steps in 

http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#Compact_Policy_Expression 

5. If the resulting expression contains a single assertion or a set of assertions grouped by wsp:All, the expression is equivalent to a policy with a single alternative where the content of the resulting expression comprises its content. 

See http://www.w3.org/2007/01/16-ws-policy-irc#T19-51-29 

Please respond to this thread with any support or concerns. Discussion and resolution will be taken up during tomorrow's f2f 
proceedings. 

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295 

public-ws-policy-request@w3.org wrote on 01/16/2007 12:14:22 PM:

> 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 
> [2] http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Compact_Policy_Expression 
> [3] http://www.w3.org/TR/2006/WD-ws-
> policy-20061117/#Normal_Form_Policy_Expression 
> [4] 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 Dis always"
> 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. 
> 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" 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 and 4.3.2 
> Policy Assertion Nesting. 
> 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. 
>   
> 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/ 
> [Bug 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 
> -------- 
> "Nearly all men can stand adversity, but if you want to test a man's
> character, give him power." Abraham Lincoln. 
>  

Received on Wednesday, 17 January 2007 17:07:14 UTC