- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 29 May 2007 23:00:41 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv26417
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Implemented Resolution in Editors' action 294.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -d -r1.66 -r1.67
--- ws-policy-guidelines.html 29 May 2007 22:52:06 -0000 1.66
+++ ws-policy-guidelines.html 29 May 2007 23:00:39 -0000 1.67
@@ -139,9 +139,9 @@
5.5.1 <a href="#doc-ignorable-assertions">Assertions and Ignorable Behavior</a><br>
5.5.2 <a href="#XML-ignorable-assertions">XML Outline for Ignorable </a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e766">Optional behavior in Compact authoring</a><br>
- 5.6.2 <a href="#d3e806">Optional behavior at runtime</a><br>
- 5.6.2.1 <a href="#d3e851">Example</a><br>
+ 5.6.1 <a href="#d3e767">Optional behavior in Compact authoring</a><br>
+ 5.6.2 <a href="#d3e807">Optional behavior at runtime</a><br>
+ 5.6.2.1 <a href="#d3e852">Example</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
5.8 <a href="#interrelated-domains">Interrelated domains</a><br>
6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
@@ -210,7 +210,7 @@
</p></div><div class="div1">
<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practice Statements</h2><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-specification-parts"><b>1. Parts of an Assertion Specification</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>2. Semantics Independent of
Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>6. Specify Semantics Clearly</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML Outline</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>10. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Declare Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Assertion description should explicitly indicate that wsp:Optional is allowed.</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire mesage exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>21. Assertion Description Should Specify a Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose a Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Kind</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Multple Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Assertion description should explicitly indicate that wsp:Optional is allowed.</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire essage exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>21. Assertion Description Should Specify a Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose a Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Kind</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Mutiple Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
<h2><a name="Assertions" id="Assertions"></a>3. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
are typically defined in a dedicated specification that describes
@@ -698,8 +698,8 @@
Practice 11: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant
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 12: Declare Nested Assertions</span></p><p class="practice">If there is a nested policy expression, an assertion description should declare it
- and enumerate the nested policy assertions that are allowed.</p></div><p>The main consideration for selecting parameters or nesting
+Practice 12: 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>.
@@ -824,7 +824,7 @@
to indicate ignorable behavior.
</p></div></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="d3e766" id="d3e766"></a>5.6.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
+<h4><a name="d3e767" id="d3e767"></a>5.6.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
compact authoring form for assertions, such behaviors are marked by
using <code>wsp:Optional</code> attribute with a value of
"true". (In order to simplify reference to such assertions,
@@ -855,7 +855,7 @@
it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port.
The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.
</pre></div></div></div><div class="div3">
-<h4><a name="d3e806" id="d3e806"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e807" id="d3e807"></a>5.6.2 Optional behavior at runtime</h4><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
@@ -910,7 +910,7 @@
</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Best
Practice 20: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
either out of band or as reflected by the message content.</p></div><div class="div4">
-<h5><a name="d3e851" id="d3e851"></a>5.6.2.1 Example</h5><p>
+<h5><a name="d3e852" id="d3e852"></a>5.6.2.1 Example</h5><p>
The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the
use of
<cite><a href="#MTOM">MTOM</a></cite> as an optional behavior that can be engaged by a consumer.
@@ -1700,4 +1700,6 @@
</td></tr><tr><td rowspan="1" colspan="1">20070529</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented Resolution in Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/291">291</a>.
Consistent use of should in place of must in the best practice statements.
+ </td></tr><tr><td rowspan="1" colspan="1">20070529</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented Resolution in Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/294">294</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.80
retrieving revision 1.81
diff -u -d -r1.80 -r1.81
--- ws-policy-guidelines.xml 29 May 2007 22:52:06 -0000 1.80
+++ ws-policy-guidelines.xml 29 May 2007 23:00:39 -0000 1.81
@@ -870,9 +870,10 @@
nested policy assertions.</quote></p>
<p role="practice" id="bp-declare-nested-assertions">
- <quote>Declare Nested Assertions</quote>
- <quote>If there is a nested policy expression, an assertion description should declare it
- and enumerate the nested policy assertions that are allowed.</quote></p>
+ <quote>Enumerate Nested Assertions</quote>
+ <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
@@ -2612,6 +2613,13 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/291">291</loc>.
Consistent use of should in place of must in the best practice statements.
</td>
+ </tr>
+ <tr>
+ <td>20070529</td>
+ <td>PY</td>
+ <td>Implemented Resolution in Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/294">294</loc>.
+ </td>
</tr>
</tbody>
</table>
Received on Tuesday, 29 May 2007 23:00:45 UTC