[Bug 4138] Normalization Algorithm is broken (single conjunctive expressions)

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

           Summary: Normalization Algorithm is broken (single conjunctive
                    expressions)
           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: 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: 



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". 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".
Expand Element Information Items in the [children] property of D that are
policy references per Section 4.3.5 Policy Inclusion.
Convert each Element Information Item C in the [children] property of D into
normal form.
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.
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.
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.





[1] http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/

Received on Tuesday, 2 January 2007 19:54:55 UTC