- From: Asir Vedamuthu <asirveda@microsoft.com>
- Date: Sun, 14 Jan 2007 22:58:57 -0800
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-policy@w3.org>
- Message-ID: <1E0F0378382054439F14D5450650478F0BFD796A@RED-MSG-42.redmond.corp.microsoft.com>
>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
<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_Expressi
on
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Compact_Policy_Express
ion>
[3]
http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Normal_Form_Policy_Expr
ession
<http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Normal_Form_Policy_Exp
ression>
[4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4138
<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 D is always "http://www.w3.org/2006/07/ws-policy
<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 <file:///\\l%20> .
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
<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 <file:///\\l%20> and 4.3.2 Policy Assertion Nesting
<file:///\\l%20> .
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
<file:///\\l%20> .
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/
<http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/>
[Bug 4138] http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
<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 Monday, 15 January 2007 07:01:12 UTC