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

2006/ws/policy ws-policy-guidelines.html,1.71,1.72 ws-policy-guidelines.xml,1.85,1.86

From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 30 May 2007 18:50:02 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1HtTFC-0002cJ-Hp@lionel-hutz.w3.org>

Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv10041

Modified Files:
	ws-policy-guidelines.html ws-policy-guidelines.xml 
Log Message:
Implemented resolution in Editors Action 307

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -d -r1.71 -r1.72
--- ws-policy-guidelines.html	30 May 2007 18:45:07 -0000	1.71
+++ ws-policy-guidelines.html	30 May 2007 18:49:59 -0000	1.72
@@ -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. 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 Authors Should Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most 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 fo Multiple 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 Authors Should Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most 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 Type</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 fo Multiple 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
@@ -1051,11 +1051,11 @@
 				same alternative. However, the clear semantics defined by the SignedParts 
 				assertion enable processing of the multiple occurrences properly.	
 			   </p><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Best
-Practice 25: Describe Semantics of Multiple Assertions of Same Kind</span></p><p class="practice">A policy alternative can contain multiple instances of the 
-						same policy assertion. An assertion description should specify the 
-						semantics of multiple instances of a policy assertion in the same 
+Practice 25: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the 
+						same type of policy assertion. An assertion description should specify the 
+						semantics of multiple instances of same type of policy assertion in the same 
 						policy alternative and the semantics of parameters and nested policy
-						(if any) when there are multiple instances of a policy assertion in 
+						(if any) when there are multiple instances of a policy assertion type in 
 						the same policy alternative.
 					</p></div></div><div class="div2">
 <h3><a name="interrelated-domains" id="interrelated-domains"></a>5.8 Interrelated domains</h3><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%">&nbsp;</td></tr><tr><td colspan="2" align="left" valign="top">To be re-structured to use the format in the Architecture of the WWW doc.</td></tr></table><p>Assertion Authors need to be clear about how assertions defined in  
@@ -1677,7 +1677,6 @@
 							(<a href="#change-description"><b>E. Changes in this Version of the Document</b></a>). 
 						</td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a> (from
 							the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM 
-
 							and MS Contribution</a> to 
 							<a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that 
 							Section <a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a> needs to be re-structured.
@@ -1712,4 +1711,6 @@
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/305">305</a>.
 						</td></tr><tr><td rowspan="1" colspan="1">20070530</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/306">306</a>.
+						</td></tr><tr><td rowspan="1" colspan="1">20070530</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/307">307</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.85
retrieving revision 1.86
diff -u -d -r1.85 -r1.86
--- ws-policy-guidelines.xml	30 May 2007 18:45:07 -0000	1.85
+++ ws-policy-guidelines.xml	30 May 2007 18:49:59 -0000	1.86
@@ -1377,12 +1377,12 @@
 			   </p>
 			   
 				<p role="practice" id="bp-WSDL-policy-multiple-instance-semantics">
-					<quote>Describe Semantics of Multiple Assertions of Same Kind</quote>
+					<quote>Describe Semantics of Multiple Assertions of Same Type</quote>
 					<quote>A policy alternative can contain multiple instances of the 
-						same policy assertion. An assertion description should specify the 
-						semantics of multiple instances of a policy assertion in the same 
+						same type of policy assertion. An assertion description should specify the 
+						semantics of multiple instances of same type of policy assertion in the same 
 						policy alternative and the semantics of parameters and nested policy
-						(if any) when there are multiple instances of a policy assertion in 
+						(if any) when there are multiple instances of a policy assertion type in 
 						the same policy alternative.
 					</quote>
 				</p>
@@ -2649,6 +2649,13 @@
 						<td>Implemented Resolution in Editors' action 
 							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/306">306</loc>.
 						</td>
+					</tr>
+					<tr>
+						<td>20070530</td>
+						<td>PY</td>
+						<td>Implemented Resolution in Editors' action 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/307">307</loc>.
+						</td>
 					</tr>                			 
 				</tbody>
 			</table>
Received on Wednesday, 30 May 2007 18:50:16 GMT

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