W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > May 2007

2006/ws/policy ws-policy-guidelines.html,1.66,1.67 ws-policy-guidelines.xml,1.80,1.81

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
Message-Id: <E1HtAgD-0006sU-RF@lionel-hutz.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 @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#doc-ignorable-assertions">Assertions and Ignorable Behavior</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#XML-ignorable-assertions">XML Outline for Ignorable </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e766">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2 <a href="#d3e806">Optional behavior at runtime</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2.1 <a href="#d3e851">Example</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e767">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2 <a href="#d3e807">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2.1 <a href="#d3e852">Example</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:03 GMT