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

2006/ws/policy guidelines-bestpractices.xml,1.5,1.6 ws-policy-guidelines.html,1.92,1.93 ws-policy-guidelines.xml,1.107,1.108

From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 27 Jul 2007 20:04:07 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IEW2i-00085H-Fl@lionel-hutz.w3.org>

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

Modified Files:
	guidelines-bestpractices.xml ws-policy-guidelines.html 
	ws-policy-guidelines.xml 
Log Message:
Implemented the resolution for issue 4660. Editors' action: 342.

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -d -r1.92 -r1.93
--- ws-policy-guidelines.html	19 Jul 2007 08:31:09 -0000	1.92
+++ ws-policy-guidelines.html	27 Jul 2007 20:04:03 -0000	1.93
@@ -203,13 +203,12 @@
         the question.
         </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-semantics"><b>1. Semantics Independent of 
-				Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Behaviors Relevant to Compatibility Tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Assertion Authors Should Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Assertion Authors Should Document Use of the Ignorable 
-Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Assertion Authors should allow use of wsp:Optional 
-attribute</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful 
-					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</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 message 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-leverage-defined-attachment-mechanisms"><b>21. Assertion
-						Authors Should Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Assertion
-						Authors Should Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Assertion Authors should Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26.  Define Rules for Attachment of an Assertion 
-							type to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Use Independent Assertions for Different Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+				Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Document Use of the Ignorable 
+Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful 
+					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</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 message 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-leverage-defined-attachment-mechanisms"><b>21. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Identiy Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26.  Define Rules for Attachment of an Assertion 
+							type to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Independent Assertions for Different Versions of a
+           					Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Document changes to policy 
+			subject</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
@@ -421,7 +420,7 @@
 				Attachment Mechanisms</span></p><p class="practice">
 			    The semantics of a policy assertion should not depend on the 
 				attachment mechanism used.</p></div><div class="boxedtext"><p><a name="bp-compatibility-tests" id="bp-compatibility-tests"></a><span class="practicelab">Best
-Practice 2: Behaviors Relevant to Compatibility Tests</span></p><p class="practice">
+Practice 2: Define assertions relevant to compatibility tests</span></p><p class="practice">
 						Assertion authors should define assertions for behaviors that are relevant to compatibility assessment, such as web service protocols that manifest on the wire.
 					</p></div><p>Assertion authors may define assertions that are not related to compatibility assessment.  These assertions may be used to accurately describe behaviour, even if they do not affect compatibility.  WS-Policy has the wsp:Ignorable attribute that may be used for indicating assertions that are not related to compatibility assessment, described in <a href="#Ignorable"><b>5.5 Designating Ignorable Behavior</b></a></p><div class="boxedtext"><p><a name="bp-ignorable-for-not-related-to-compatibility-tests" id="bp-ignorable-for-not-related-to-compatibility-tests"></a><span class="practicelab">Best
 Practice 3: Mark Ignorable Assertions not related to compatibility</span></p><p class="practice">
@@ -602,11 +601,11 @@
 Practice 8: Specify Semantics Clearly</span></p><p class="practice"> Assertion authors should clearly and completely specify the
  			  	    	 semantics of a policy assertion.
 			  	    </p></div><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
-Practice 9: Assertion Authors Should Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or 
+Practice 9: Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or 
 constraint against the use of) the wsp:Ignorable attribute to indicate 
 whether or not the behavior indicated by the QName may be ignored by policy 
 intersection. </p></div><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
-Practice 10: Assertion Authors Should Document Use of the Ignorable 
+Practice 10: Document Use of the Ignorable 
 Attribute in XML </span></p><p class="practice"> An Assertion Author should document, in the XML outline and/or schema for 
 the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute. 
 			  	    </p></div><p>To give an example, the WS-ReliableMessaging Policy document specifies attribute extensibility as part of the XML definition, allowing the wsp:Ignorable attribute:
@@ -620,8 +619,7 @@
 for the use of the wsp:Optional attribute in the XML outline and/or schema 
 definition of an assertion as this will allow policy expression authors to 
 compose compact policy expressions.</p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
-Practice 11: Assertion Authors should allow use of wsp:Optional 
-attribute</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use 
+Practice 11: Allow use of wsp:Optional</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use 
 of the wsp:Optional attribute so as to enable policy authors to compose 
 compact policy expressions.</p></div><p>For example, consider the following two equivalent policy expressions:</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 5-6. </span>Normal form expression:</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
@@ -671,7 +669,7 @@
      				their assertions by specifying additional properties, headers,
      				etc. that must be present in a message as part of their assertion design.
      				</p><div class="boxedtext"><p><a name="bp-not-necessary-to-understand-a-message" id="bp-not-necessary-to-understand-a-message"></a><span class="practicelab">Best
-Practice 12: Not Necessary to Understand a Message</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
+Practice 12: Define message format only</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
      				in policy that isn't attached to the message, it isn't possible
      				to later decipher it. This is very different from expressing, in
      				policy, what ciphers (and so forth) are supported by a particular
@@ -862,7 +860,7 @@
 						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>  
-     			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. Assertion Authors Should Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Assertion Authors Should Document Use of the Ignorable 
+     			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
 			  	indicate the semantic of the runtime behavior in the description of the assertion.
@@ -958,15 +956,13 @@
 						policy assertion would need to be written with different (and possibly
 						unknown) attachment mechanisms in mind.
 					</p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
-Practice 21: Assertion
-						Authors Should Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+Practice 21: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
 							Assertion Authors should leverage defined attachment models when
 							possible to extend the deployment of their policy assertions and ensure
 							that there are no additional semantics implied by their
 							assertions.</p></div><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments 
 						specification when possible. </p><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
-Practice 22: Assertion
-						Authors Should Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+Practice 22: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
 							Authors should leverage defined policy subjects when possible to
 							facilitate the deployment of their policy assertions. Common Policy
 							subjects have been defined and used by other policy assertion authors
@@ -979,7 +975,7 @@
 						combined without conflict. Each domain should define any limitations at
 						the policy subject level that might impact interoperability. 
 					</p><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
-Practice 23: Assertion Authors should Identify Policy Subjects</span></p><p class="practice">
+Practice 23: Identify Policy Subjects</span></p><p class="practice">
 							Assertion
 							Authors should review the policy subjects defined in
 							WS-PolicyAttachments and identify existing policy subjects when possible
@@ -1083,7 +1079,7 @@
 				when the policy assertions do not target wire-level behaviors but
 				rather abstract requirements, this technique does not apply. 
 				</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
-Practice 27: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple attachment points 
+Practice 27: Specify Preferred Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points 
 					    within a policy subject, Assertion Authors should specify a 
 					    preferred attachment point for the chosen policy subject.
 					</p></div><p>Assertion Authors that utilize WSDL policy subjects need to 
@@ -1157,7 +1153,8 @@
            			[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
            			are mutually exclusive for an interaction. Such equivalent
            			behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Best
-Practice 30: Use Independent Assertions for Different Versions of a Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different 
+Practice 30: Independent Assertions for Different Versions of a
+           					Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different 
            			versions of a behavior.</p></div><p>The
            			policy expression in the example below requires the use of
            			WSS: SOAP Message Security 1.0. </p><div class="exampleOuter">
@@ -1186,7 +1183,8 @@
 				new policy subjects are added it is incumbent on the authors to retain the 
 				semantic of the policy assertion. 
 			</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
-Practice 31: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time, 
+Practice 31: Document changes to policy 
+			subject</span></p><p class="practice">If the policy subjects change over time, 
 				the assertion description should also be versioned to reflect this 
 				change.</p></div></div></div></div><div class="back"><div class="div1">
 <h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
@@ -1539,7 +1537,7 @@
 							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.
-						</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-not-necessary-to-understand-a-message"><b>12. Not Necessary to Understand a Message</b></a> (from
+						</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-not-necessary-to-understand-a-message"><b>12. Define message format only</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="#self-describing"><b>5.3.3  Self Describing Messages </b></a>.
@@ -1641,4 +1639,8 @@
 							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4859">4859</a>. 
 							Editors' action: 
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</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">4660</a>. 
+							Editors' action: 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</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.107
retrieving revision 1.108
diff -u -d -r1.107 -r1.108
--- ws-policy-guidelines.xml	19 Jul 2007 08:31:09 -0000	1.107
+++ ws-policy-guidelines.xml	27 Jul 2007 20:04:03 -0000	1.108
@@ -484,7 +484,7 @@
 				</p>
 				
 				<p role="practice" id="bp-compatibility-tests">
-					<quote>Behaviors Relevant to Compatibility Tests</quote>
+					<quote>Define assertions relevant to compatibility tests</quote>
 					<quote>
 						Assertion authors should define assertions for behaviors that are relevant to compatibility assessment, such as web service protocols that manifest on the wire.
 					</quote>
@@ -726,13 +726,13 @@
 			  	    </quote>
 			  	    </p>
 		  	    
-			  		    <p role="practice" id="DefineIgnorable"><quote>Assertion Authors Should Document Ignorable Behavior</quote> >
+			  		    <p role="practice" id="DefineIgnorable"><quote>Document Ignorable Behavior</quote> >
 			  	    <quote>An assertion description should include guidance as to the use of (or 
 constraint against the use of) the wsp:Ignorable attribute to indicate 
 whether or not the behavior indicated by the QName may be ignored by policy 
 intersection. </quote>
 			  	    </p>
-     			  	    <p role="practice" id="ignorableAssertions"> <quote>Assertion Authors Should Document Use of the Ignorable 
+     			  	    <p role="practice" id="ignorableAssertions"> <quote>Document Use of the Ignorable 
 Attribute in XML </quote> >
 			  	    <quote> An Assertion Author should document, in the XML outline and/or schema for 
 the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute. 
@@ -753,8 +753,7 @@
 definition of an assertion as this will allow policy expression authors to 
 compose compact policy expressions.</p>
 				<p role="practice" id="bp-assertion-xml-allow-optional">
-					<quote>Assertion Authors should allow use of wsp:Optional 
-attribute</quote>
+					<quote>Allow use of wsp:Optional</quote>
 					<quote>An assertion's XML outline and/or schema definition should allow the use 
 of the wsp:Optional attribute so as to enable policy authors to compose 
 compact policy expressions.</quote>
@@ -823,7 +822,7 @@
      				etc. that must be present in a message as part of their assertion design.
      				</p>
         			<p role="practice" id="bp-not-necessary-to-understand-a-message">
-        				<quote>Not Necessary to Understand a Message</quote>
+        				<quote>Define message format only</quote>
         				<quote>Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</quote>
         			</p>
      				<p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
@@ -1236,8 +1235,8 @@
 						unknown) attachment mechanisms in mind.
 					</p>
 					
-					<p role="practice" id="bp-leverage-defined-attachment-mechanisms"><quote>Assertion
-						Authors Should Leverage Defined Attachment Mechanisms</quote><quote>
+					<p role="practice" id="bp-leverage-defined-attachment-mechanisms">
+					<quote>Leverage Defined Attachment Mechanisms</quote><quote>
 							Assertion Authors should leverage defined attachment models when
 							possible to extend the deployment of their policy assertions and ensure
 							that there are no additional semantics implied by their
@@ -1245,8 +1244,8 @@
 					<p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments 
 						specification when possible. </p>
 					
-					<p role="practice" id="bp-use-defined-policy-subjects"><quote>Assertion
-						Authors Should Use Defined Policy Subjects</quote><quote> Assertion
+					<p role="practice" id="bp-use-defined-policy-subjects">
+					<quote>Use Defined Policy Subjects</quote><quote> Assertion
 							Authors should leverage defined policy subjects when possible to
 							facilitate the deployment of their policy assertions. Common Policy
 							subjects have been defined and used by other policy assertion authors
@@ -1261,7 +1260,7 @@
 						the policy subject level that might impact interoperability. 
 					</p>
 					<p role="practice" id="bp-identify-policy-subjects">
-						<quote>Assertion Authors should Identify Policy Subjects</quote><quote>
+						<quote>Identify Policy Subjects</quote><quote>
 							Assertion
 							Authors should review the policy subjects defined in
 							WS-PolicyAttachments and identify existing policy subjects when possible
@@ -1419,7 +1418,7 @@
 				</p>
 				
 				<p role="practice" id="bp-WSDL-preferred-attachment-point">
-					<quote>Specify Preferred Attachment Point for an Assertion</quote>
+					<quote>Specify Preferred Attachment Point</quote>
 					<quote>If an assertion can be attached at multiple attachment points 
 					    within a policy subject, Assertion Authors should specify a 
 					    preferred attachment point for the chosen policy subject.
@@ -1547,7 +1546,8 @@
            			are mutually exclusive for an interaction. Such equivalent
            			behaviors can be modeled as independent assertions. </p>
            			<p role="practice" id="bp-independent-assertions">
-           			<quote>Use Independent Assertions for Different Versions of a Behavior</quote>
+           				<quote>Independent Assertions for Different Versions of a
+           					Behavior</quote>
            			<quote>Assertion Authors should use independent assertions for modeling different 
            			versions of a behavior.</quote></p>
            			
@@ -1590,7 +1590,8 @@
 				semantic of the policy assertion. 
 			</p>
 
-			<p role="practice" id="bp-policy-subject-change"><quote>Change of the Policy Subject Over Time</quote><quote>If the policy subjects change over time, 
+			<p role="practice" id="bp-policy-subject-change"><quote>Document changes to policy 
+			subject</quote><quote>If the policy subjects change over time, 
 				the assertion description should also be versioned to reflect this 
 				change.</quote>
 			</p>
@@ -2644,6 +2645,15 @@
 							Editors' action: 
 							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</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">4660</loc>. 
+							Editors' action: 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</loc>.
+						</td>
 					</tr> 
 				</tbody>
 			</table>

Index: guidelines-bestpractices.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/guidelines-bestpractices.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- guidelines-bestpractices.xml	13 Jul 2007 15:40:25 -0000	1.5
+++ guidelines-bestpractices.xml	27 Jul 2007 20:04:02 -0000	1.6
@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8"?><ulist><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-compatibility-tests"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></item><item><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><secref ref="bp-assertion-description-explicitly-allow-optional"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist>
\ No newline at end of file
+<?xml version="1.0" encoding="UTF-8"?><ulist><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-compatibility-tests"/></p></item><item><p><specref ref="bp-ignorable-for-not-related-to-compatibility-tests"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></item><iem><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-leverage-defined-attachment-mechanisms"/></p></item><item><p><specref ref="bp-use-defined-policy-subjects"/></p></item><item><p><specref ref="bp-identify-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist
\ No newline at end of file
Received on Friday, 27 July 2007 20:04:26 GMT

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