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                                          To 
             @iona.com>                "Yalcinalp, Umit"                   
             Sent by:                  <umit.yalcinalp@sap.com>,           
             public-ws-policy-         <public-ws-policy@w3.org>           
             request@w3.org                                             cc 
                                                                           
                                                                   Subject 
             01/03/2007 12:28          Re: NEW ISSUE: Contradictory        
             PM                        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
 To: 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/
 [2] 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
 --------
 "Nearly all men can stand adversity, but if you want to test a man's
 character, give him power." Abraham Lincoln.

Received on Tuesday, 9 January 2007 17:08:02 UTC