2006/ws/policy ws-policy-guidelines.html,1.42,1.43 ws-policy-guidelines.xml,1.56,1.57

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

Modified Files:
	ws-policy-guidelines.html ws-policy-guidelines.xml 
Log Message:
Fixed Good Practice links in section 5.5

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -d -r1.42 -r1.43
--- ws-policy-guidelines.html	24 Apr 2007 01:14:36 -0000	1.42
+++ ws-policy-guidelines.html	24 Apr 2007 15:22:18 -0000	1.43
@@ -830,8 +830,8 @@
 					serialization). Thus, this optional behavior is self describing. For example, an 
 					inbound message to a web service that requires MTOM must adhere to  Optimized MIME 
 					Serialization. By examining the message, the provider can determine whether the policy
-					alternate that contains the MTOM assertion is being obeyed (Good Practice 
-					[<b><a href="#bp-indicate-optional-assertion-use">???</a></b>).
+					alternate that contains the MTOM assertion is being obeyed (
+						<a href="#bp-indicate-optional-assertion-use">Good Practice: Indicate use of an Optional Assertion</a>).
 				</p><p>
 					Note that if a MTOM assertion were only bound to an inbound message endpoint, 
 					then it would not be clear whether the outbound message from the provider would 
@@ -840,8 +840,7 @@
 					to avoid inappropriate assumptions by implementations. This is important for an 
 					optional assertion where  it may not be clear whether it is to apply in a message 
 					exchange when optionally used in part of that exchange  
-					(Good Practice 
-					[<b><a href="#bp-entire-mep-for-optional">???</a></b>).
+					(<a href="#bp-entire-mep-for-optional">Good Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</a>).
 				</p></div></div></div><div class="div2">
 <h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.6 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
         		associated policy subject. If a policy assertion is to be used

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -d -r1.56 -r1.57
--- ws-policy-guidelines.xml	24 Apr 2007 01:14:36 -0000	1.56
+++ ws-policy-guidelines.xml	24 Apr 2007 15:22:18 -0000	1.57
@@ -1016,8 +1016,8 @@
 					serialization). Thus, this optional behavior is self describing. For example, an 
 					inbound message to a web service that requires MTOM must adhere to  Optimized MIME 
 					Serialization. By examining the message, the provider can determine whether the policy
-					alternate that contains the MTOM assertion is being obeyed (Good Practice 
-					[<specref ref="bp-indicate-optional-assertion-use" />).
+					alternate that contains the MTOM assertion is being obeyed (
+						<loc href="#bp-indicate-optional-assertion-use">Good Practice: Indicate use of an Optional Assertion</loc>).
 				</p><p>
 					Note that if a MTOM assertion were only bound to an inbound message endpoint, 
 					then it would not be clear whether the outbound message from the provider would 
@@ -1026,8 +1026,7 @@
 					to avoid inappropriate assumptions by implementations. This is important for an 
 					optional assertion where  it may not be clear whether it is to apply in a message 
 					exchange when optionally used in part of that exchange  
-					(Good Practice 
-					[<specref ref="bp-entire-mep-for-optional" />).
+					(<loc href="#bp-entire-mep-for-optional">Good Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</loc>).
 				</p>
 					</div4>
 			</div3>

Received on Tuesday, 24 April 2007 15:22:23 UTC