- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 27 Jul 2007 20:14:21 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv756
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Implemented the resolution for issue 4695. Editors' action: 347.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -d -r1.93 -r1.94
--- ws-policy-guidelines.html 27 Jul 2007 20:04:03 -0000 1.93
+++ ws-policy-guidelines.html 27 Jul 2007 20:14:19 -0000 1.94
@@ -136,10 +136,10 @@
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
- 5.5.1 <a href="#d3e806">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d3e819">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d3e803">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d3e816">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e834">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d3e831">Optional behavior at runtime</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
5.7.1 <a href="#general-attachment-guidelines">General Guidelines</a><br>
5.7.2 <a href="#wsdl-attachment-guidelines">Considerations for Policy Attachment in WSDL</a><br>
@@ -700,14 +700,17 @@
A review by a broad community is the best way to ensure that the granularity of a set
of domain assertions is appropriate.</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Best
Practice 13: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
-<h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
- assertion beyond its type. We cover these two cases below followed by a
- comparison of these approaches targeting when to use either of the approach.
+<h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information
+ in an assertion beyond its type: assertion parameters and nested policy
+ expressions. We cover these two cases below followed by a comparison of these
+ approaches targeting when to use either of the two approaches.</p><p>The main consideration for choosing between use of parameters or nested policy
+ expressions is that the framework intersection algorithm processes nested
+ policy expressions, but does not consider parameters in the algorithm.
</p><div class="div3">
<h4><a name="parameterized-assertions" id="parameterized-assertions"></a>5.4.1 Assertions with Parameters</h4><p>Policy assertion parameters are the opaque payload of an assertion.
Parameters carry additional useful information for engaging the
behavior described by an assertion and are preserved through policy
- processing such as normalize, merge and policy intersection.
+ processing such as normalization, merge and policy intersection.
Requesters may use policy intersection to select a compatible
policy alternative for an interaction. Assertion parameters do not
affect the outcome of policy intersection unless the assertion specifies
@@ -715,7 +718,7 @@
and attributes of the assertion excluding child elements and attributes
from the policy language namespace name are the assertion parameters.</p><div class="boxedtext"><p><a name="bp-assertion-parameters" id="bp-assertion-parameters"></a><span class="practicelab">Best
Practice 14: Use Parameters for Useful
- Information</span></p><p class="practice">Assertion Authors should represent useful (or additional)
+ Information</span></p><p class="practice">Assertion Authors should represent useful additive
information necessary for engaging the behavior represented by a policy
assertion as assertion parameters.
</p></div><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code>
@@ -751,11 +754,7 @@
to a compatibility test and apply to the same policy subject using
nested policy assertions.</p></div><div class="boxedtext"><p><a name="bp-declare-nested-assertions" id="bp-declare-nested-assertions"></a><span class="practicelab">Best
Practice 16: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors
- should enumerate the nested policy assertions that are allowed.</p></div><p>The main consideration for selecting parameters or nesting
- of assertions is that <em>the framework intersection
- algorithm processes nested alternatives, but does not consider
- parameters in its algorithm</em>.
- </p><p>Assertion Authors should recognize that the framework can
+ should enumerate the nested policy assertions that are allowed.</p></div><p>Assertion Authors should recognize that the framework can
yield multiple assertions of the same type. The <em>QName</em>
of the assertion is the only vehicle for the framework to
match a specific assertion, NOT the contents of the
@@ -859,16 +858,16 @@
certificate will not be able to use this provider solely on the basis
of intersection algorithm alone.</p></div></div><div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
-<h4><a name="d3e806" id="d3e806"></a>5.5.1 Ignorable behavior in authoring</h4><p>
+<h4><a name="d3e803" id="d3e803"></a>5.5.1 Ignorable behavior in authoring</h4><p>
The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
-<h4><a name="d3e819" id="d3e819"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d3e816" id="d3e816"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
indicate the semantic of the runtime behavior in the description of the assertion.
</p><p>
As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e834" id="d3e834"></a>5.6.1 Optional behavior at runtime</h4><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e831" id="d3e831"></a>5.6.1 Optional behavior at runtime</h4><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><p>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since this would allow the
@@ -1643,4 +1642,8 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4660</a>.
Editors' action:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070727</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4695</a>.
+ Editors' action:
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.108
retrieving revision 1.109
diff -u -d -r1.108 -r1.109
--- ws-policy-guidelines.xml 27 Jul 2007 20:04:03 -0000 1.108
+++ ws-policy-guidelines.xml 27 Jul 2007 20:14:19 -0000 1.109
@@ -868,9 +868,14 @@
</div2>
<div2 id="comparison">
<head>Comparison of Nested and Parameterized Assertions</head>
- <p>There are two different ways to provide additional information in an
- assertion beyond its type. We cover these two cases below followed by a
- comparison of these approaches targeting when to use either of the approach.
+ <p>There are two different ways to provide additional information
+ in an assertion beyond its type: assertion parameters and nested policy
+ expressions. We cover these two cases below followed by a comparison of these
+ approaches targeting when to use either of the two approaches.</p>
+
+ <p>The main consideration for choosing between use of parameters or nested policy
+ expressions is that the framework intersection algorithm processes nested
+ policy expressions, but does not consider parameters in the algorithm.
</p>
<div3 id="parameterized-assertions">
@@ -878,7 +883,7 @@
<p>Policy assertion parameters are the opaque payload of an assertion.
Parameters carry additional useful information for engaging the
behavior described by an assertion and are preserved through policy
- processing such as normalize, merge and policy intersection.
+ processing such as normalization, merge and policy intersection.
Requesters may use policy intersection to select a compatible
policy alternative for an interaction. Assertion parameters do not
affect the outcome of policy intersection unless the assertion specifies
@@ -890,7 +895,7 @@
<p role="practice" id="bp-assertion-parameters"><quote>Use Parameters for Useful
Information</quote>
- <quote>Assertion Authors should represent useful (or additional)
+ <quote>Assertion Authors should represent useful additive
information necessary for engaging the behavior represented by a policy
assertion as assertion parameters.
</quote>
@@ -956,12 +961,6 @@
<quote>If there is a nested policy expression, then the Assertion Authors
should enumerate the nested policy assertions that are allowed.</quote>
</p>
-
- <p>The main consideration for selecting parameters or nesting
- of assertions is that <emph>the framework intersection
- algorithm processes nested alternatives, but does not consider
- parameters in its algorithm</emph>.
- </p>
<p>Assertion Authors should recognize that the framework can
yield multiple assertions of the same type. The <emph>QName</emph>
@@ -2654,6 +2653,15 @@
Editors' action:
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</loc>.
</td>
+ </tr>
+ <tr>
+ <td>20070727</td>
+ <td>ASV</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4695</loc>.
+ Editors' action:
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</loc>.
+ </td>
</tr>
</tbody>
</table>
Received on Friday, 27 July 2007 20:14:38 UTC