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

NEW ISSUE: Contradictory recommendation for nesting and intersection

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 2 Jan 2007 17:56:54 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D641650308B88C@uspale20.pal.sap.corp>
To: <public-ws-policy@w3.org>

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 Wednesday, 3 January 2007 01:56:00 GMT

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