[Bug 4142] Contradictory recommendation for nesting and intersection

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142

           Summary: Contradictory recommendation for nesting and
                    intersection
           Product: WS-Policy
           Version: LC
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: umit.yalcinalp@sap.com
         QAContact: public-ws-policy-qa@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, guidance to Guidelines
document will be appropriate in addition to the framework fix. 


[1] http://www.w3.org/TR/ws-policy/

Received on Wednesday, 3 January 2007 01:54:20 UTC