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

2006/ws/policy guidelines-bestpractices.xml,1.2,1.3 ws-policy-guidelines.html,1.61,1.62 xmlspec-policy.xsl,1.8,1.9

From: Felix Sasaki via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 24 May 2007 14:29:11 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1HrEJT-0001kA-T1@lionel-hutz.w3.org>

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

Modified Files:
	guidelines-bestpractices.xml ws-policy-guidelines.html 
	xmlspec-policy.xsl 
Log Message:
"ACTION-287 - Update the stylesheets to say Best Practice instead of Good Practice " done.

Index: xmlspec-policy.xsl
===================================================================
RCS file: /sources/public/2006/ws/policy/xmlspec-policy.xsl,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- xmlspec-policy.xsl	2 May 2007 17:07:39 -0000	1.8
+++ xmlspec-policy.xsl	24 May 2007 14:29:09 -0000	1.9
@@ -225,7 +225,7 @@
             <p>
                 <a name="{@id}" id="{@id}"/>
                 <span class="practicelab">
-                    <xsl:text>Good
+                    <xsl:text>Best
 practice </xsl:text>
                     <xsl:value-of select="$practicenumber"/>
                     <xsl:text>: </xsl:text>

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -d -r1.61 -r1.62
--- ws-policy-guidelines.html	20 May 2007 17:58:14 -0000	1.61
+++ ws-policy-guidelines.html	24 May 2007 14:29:09 -0000	1.62
@@ -390,7 +390,7 @@
 				For example, if an assertion applies to the SOAP protocol, it would be necessary
 				to consider how its presence must interact with other policy assertions that
 				are defined for security.
-				</p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Good
+				</p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Best
 practice 1: Parts of an Assertion Specification</span></p><p class="practice">
 					Assertion Authors should include the following items in an 
 					assertion specification: </p></div><p>
@@ -415,7 +415,7 @@
 				attachment mechanism. Independence from a specific attachment mechanism 
 				allows policy tools to choose the most appropriate mechanism to attach a 
 				policy without having to analyze the contents of the policy. 
-				</p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Good
+				</p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Best
 practice 2: Semantics Independent of 
 				Attachment Mechanisms</span></p><p class="practice">
 			    The semantics of a policy assertion should not depend on the 
@@ -447,7 +447,7 @@
 				policy expression would be when it is processed. As a result, the
 				description for a policy assertion should not depend on the style used
 				to author a policy expression that contains the assertion.
-			</p><div class="boxedtext"><p><a name="bp-semantics-and-form" id="bp-semantics-and-form"></a><span class="practicelab">Good
+			</p><div class="boxedtext"><p><a name="bp-semantics-and-form" id="bp-semantics-and-form"></a><span class="practicelab">Best
 practice 3: Semantics Independent of the Form</span></p><p class="practice">The semantics of an assertion should be independent of
 					the form (compact or normal form) of policy expressions that contain the
 					assertion.</p></div><p>
@@ -544,7 +544,7 @@
 					a simple working assertion that allows extensibility. As the design 
 					work progresses, one may add more parameters or nested policy assertions 
 					to meet one's interoperability needs. 
-         			</p><div class="boxedtext"><p><a name="bp-assertion-start" id="bp-assertion-start"></a><span class="practicelab">Good
+         			</p><div class="boxedtext"><p><a name="bp-assertion-start" id="bp-assertion-start"></a><span class="practicelab">Best
 practice 4: Start with Simple Assertion</span></p><p class="practice">An assertion author should start with a simple working assertion 
           				that allows assertion parameter extensibility. </p></div><p>New Assertion Authors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
          			relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex domain that has been decomposed into a set of policy expressions.
@@ -556,7 +556,7 @@
             		represent an assertion parameter as a child element (by leveraging natural XML nesting)
             		or an attribute of an assertion. The general guidelines on when to use XML elements
           			versus attributes apply is. Use a unique QName to identify a distinct behavior and provide 
-          			an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Good
+          			an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Best
 practice 5: Use Unique QNames</span></p><p class="practice">An assertion author should use a unique QName to identify a distinct behavior.</p></div><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
             		document). If the assertion has a nested policy expression then the assertion XML
             		outline can enumerate the nested assertions that are allowed. An example is the following:
@@ -575,10 +575,10 @@
   ...
 &lt;/sp:IssuedToken&gt;
  
- </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Good
+ </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Best
 practice 6: Specify Semantics Clearly</span></p><p class="practice"> An assertion description must clearly and completely specify the semantics of a policy 
 			  	    assertion.
-			  	    </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Good
+			  	    </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
 practice 7: Provide an XML Outline</span></p><p class="practice"> An assertion description should provide an XML outline plus an XML schema to specify the
 			  	    syntax of the assertion.
 			  	    </p></div><div class="exampleOuter"><div class="exampleInner"><pre>
@@ -615,7 +615,7 @@
      				consider how to make messages self describing when utilizing
      				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">Good
+     				</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 8: Not Necessary to Understand a Message</span></p><p class="practice">An assertion author 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
@@ -645,7 +645,7 @@
 					their service descriptions. 
 					</p><p>It is the responsibility of the assertion authors to avoid duplication of assertions. 
 					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">Good
+					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 9: Avoid Duplication of Assertions</span></p><p class="practice">An assertion author 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
@@ -660,7 +660,7 @@
 					affect the outcome of policy intersection unless the assertion specifies 
 					domain specific processing for policy intersection.</p><p>In the XML representation of a policy assertion, the child elements 
 					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">Good
+					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 10: Use Parameters for Useful 
 					Information</span></p><p class="practice">An assertion author should represent useful (or additional) 
                         information necessary for engaging the behavior represented by a policy 
@@ -694,10 +694,10 @@
 						description should declare it and enumerate the nested policy assertions 
 						that are allowed. There is one caveat to watch out for: policy assertions
 						with deeply nested policy can greatly increase the complexity of a policy and should be
-						avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Good
+						avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Best
 practice 11: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">An assertion author 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">Good
+						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
 						of assertions is that <em>the framework intersection
@@ -719,7 +719,7 @@
 						specific comparison algorithms may need to be devised and be
 						delegated to the specific domain handlers that are not visible
 						to the WS-Policy framework. However, domain specific intersection processing reduces 
-						interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Good
+						interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Best
 practice 13: Discourage Domain Specific Intersection</span></p><p class="practice">An 
 							assertion description should only specify domain specific intersection 
 							semantics when policy intersection is insufficient.</p></div><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
@@ -815,11 +815,11 @@
 			  	compatability assessment between two alternatives. See [tbd] for details on the use 
 			  	of the ignorable attribute.
 				</p><div class="div3">
-<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Good
+<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
 practice 14: Assertions Document Ignorable Behavior</span></p><p class="practice"> An assertion description should use the wsp:Ignorable attribute
 			  	    to indicate that the behavior indicated by the QName may be ignored by policy intersection. 
 			  	    </p></div></div><div class="div3">
-<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Good
+<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
 practice 15: Ignorable Attribute in XML</span></p><p class="practice"> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
 			  	    to indicate ignorable behavior.
 			  	    </p></div></div></div><div class="div2">
@@ -838,7 +838,7 @@
 					include policy alternatives in a policy expression, by using  
 					the wsp:Optional attribute. An assertion author should clearly indicate in the assertion 
 					definition that it is possible to be optional 
-					and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Good
+					and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
 practice 16: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to 
 						indicate optional behaviors.</p></div><p>To give a general example, the definition of assertion syntax for a hypothetical assertion such as SampleAssertion, 
 					should allow attribute extensibility as part of the XML definition, allowing the wsp:Optional attribute to be used:
@@ -846,7 +846,7 @@
 <p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>Use of @any for attribute extensibility</i></p><div class="exampleInner"><pre>/samplePrefix:SampleAssertion/@any
 This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
 				</pre></div></div><p>The portion of the assertion definition that describes policy subjects and assertion attachment should indicate
-				that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Good
+				that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Best
 practice 17: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the 
 						behavior indicated by the QName is optional for the associated policy subject.</p></div><p>Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should 
 					include discussion of optionality.
@@ -861,7 +861,7 @@
 					"optional" with a value "true" since this would allow the
 					consumer to select the policy alternative that does not contain the assertion,
 					and thus not engaging the behavior.
-				</p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Good
+				</p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Best
 practice 18: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present 
 						in compatible policy expressions.</p></div><p> The target scope of an optional assertion is an important factor for
 					Assertion Authors to consider as it determines the
@@ -893,7 +893,7 @@
 					introduce both message and endpoint policy subjects for one of its 
 					assertions and require the use of endpoint policy subject 
 					when message policy subject is used via attachment.
-				</p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Good
+				</p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Best
 practice 19: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest 
 						possible granularity to limit the degree to which optionality applies.</p></div><p>
 					Behaviors must be engaged
@@ -907,7 +907,7 @@
 					the optional behavior is engaged. 
 					(Such an out of band mechanism is outside the scope of WS-Policy 
 					Framework).  
-				</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Good
+				</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>
@@ -946,7 +946,7 @@
          				subject is the service policy subject. </p></li><li><p>If the behavior applies to any message exchange
           				made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
 	  					defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
-	  					the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Good
+	  					the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
 practice 21: Assertion Description Should Specify a Policy Subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.  
 						For instance, if a policy assertion is to be used with WSDL, the assertion description 
 						should specify a WSDL policy subject – such as service, endpoint, operation and message.
@@ -978,7 +978,7 @@
         		policy subject instead of a message policy subject. However such 
         		policy attachments to policy subjects of broader scope and granularity 
         		should be done only after careful evaluation. 
-        		</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Good
+        		</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
 practice 22: Choose a Granular Policy Subject</span></p><p class="practice">Assertion authors should choose the most granular policy subject 
 						that the behavior represented by a policy assertion applies to.
 					</p></div><p>
@@ -989,7 +989,7 @@
         		the burden to describe the semantics of multiple instances of the
         		same assertion attached to different policy subjects at the same
         		time in order to avoid conflicting behavior.
-				</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Good
+				</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Best
 practice 23: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy 
 						subjects, the assertion description should describe the semantics of multiple 
 						instances of the same assertion attached to multiple policy subjects 
@@ -1030,7 +1030,7 @@
 				also considers the case when sequences are present. In addition, 
 				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">Good
+				</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
 practice 24: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy 
 						subject, an assertion author should specify a preferred attachment 
 						point for the chosen policy subject.
@@ -1049,7 +1049,7 @@
 				at the endpoint could have more than one SignedParts assertion in the
 				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">Good
+			   </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 
@@ -1068,7 +1068,7 @@
 				Assertions [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. </p><p>Assertion authors should not duplicate existing  
 				assertions and should also make sure that when adding assertions those new assertions are consistent  
 				with pre-existing assertions of any  
-				interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Good
+				interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Best
 practice 26: Specify Composition with Related Assertions</span></p><p class="practice">An assertion description should clearly specify how the assertion may compose 
 				with other related assertions, if any.</p></div></div></div><div class="div1">
 <h2><a name="versioning-policy-assertions" id="versioning-policy-assertions"></a>6. Versioning Policy Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
@@ -1098,7 +1098,7 @@
            			vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
            			[<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">Good
+           			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 27: Use Independent Assertions for Multiple Versions of a Behavior</span></p><p class="practice">An assertion author should use independent assertions for modeling multiple 
            			versions of a behavior.</p></div><p>The
            			policy expression in the example below requires the use of
@@ -1127,7 +1127,7 @@
 				provided that endpoint policy subject is also retained in its design. When 
 				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">Good
+			</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
 practice 28: Change of the Policy Subject Over Time</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 class="div1">

Index: guidelines-bestpractices.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/guidelines-bestpractices.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- guidelines-bestpractices.xml	2 May 2007 17:07:39 -0000	1.2
+++ guidelines-bestpractices.xml	24 May 2007 14:29:09 -0000	1.3
@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8"?><ulist><item><p><specref ref="bp-assertion-specification-parts"/></p></item><item><p><specref ref="bp-assertion-semantics"/></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="bp-assertions-and-message-semantics"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></item><item><p><specref ref="bp-assertion-definition"/></p></item><item><p><specref ref="bp-nesting"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref 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-independent-assertions"/></p></item><item><p><specref ref="bp-olicy-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-specification-parts"/></p></item><item><p><specref ref="bp-assertion-semantics"/></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="AssertionDefinitions"/></p></item><item><p><specref ref="XMLOutline"/></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><tem><p><specref 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
Received on Thursday, 24 May 2007 14:29:19 GMT

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