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

2006/ws/policy ws-policy-guidelines.html,1.40,1.41 ws-policy-guidelines.xml,1.54,1.55

From: David Orchard via cvs-syncmail <cvsmail@w3.org>
Date: Mon, 16 Apr 2007 19:27:50 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1HdWre-0000v2-MV@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.html ws-policy-guidelines.xml 
Log Message:
Sec 6.2 and 6.3 of 3989

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -d -r1.40 -r1.41
--- ws-policy-guidelines.html	11 Apr 2007 22:05:26 -0000	1.40
+++ ws-policy-guidelines.html	16 Apr 2007 19:27:47 -0000	1.41
@@ -119,7 +119,7 @@
 <h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
 2. <a href="#best-practices-list">List of Best Practices Statements</a><br>
 3. <a href="#Assertions">What is an Assertion? </a><br>
-4. <a href="#d3e232">Who is involved in authoring Assertions? </a><br>
+4. <a href="#d3e228">Who is involved in authoring Assertions? </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#roles"> Roles and Responsibilities </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.2 <a href="#consumers">Consumers</a><br>
@@ -137,8 +137,8 @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e646">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e654">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e642">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e650">Optional behavior at runtime</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#interrelated-domains">Interrelated domains</a><br>
 6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
@@ -206,7 +206,7 @@
         the Socratic style of beginning with a question, and then answering 
         the question.
         </p></div><div class="div1">
-<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practices Statements</h2><p>TBD:</p><ol class="enumar"><li><p><a href="#bp-assertion-specification-parts">Parts of an Assertion Specification</a></p></li><li><p><a href="#bp-assertion-semantics">Semantics of Policy Assertions</a></p></li><li><p><a href="#bp-semantics-and-form">Semantics of an Assertion and its form</a></p></li><li><p><a href="#bp-assertion-start">Starting to Build an Assertion</a></p></li><li><p><a href="#bp-unique-qnames">Unique QNames</a></p></li><li><p><a href="#bp-assertions-and-message-semantics">Assertions and Message Semantics</a></p></li><li><p><a href="#bp-assertion-duplication">Duplication of Assertions</a></p></li><li><p><a href="#bp-assertion-definition">Definition of Policy Assertions</a></p></li><li><p><a href="#bp-nesting">Nesting of Assertions</a></p></li><li><p><a href="#bp-optional-assertions">Optional Assertions</a></p></li><li><p><a href="#bp-independent-assertions">Independent Assertions</a>/p></li><li><p><a href="#bp-assertion-description">Description of Assertions</a></p></li><li><p><a href="#bp-policy-subject-change">Change of the Policy Subject Over Time</a></p></li></ol></div><div class="div1">
+<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practices Statements</h2><p>TBD:</p><ol class="enumar"><li><p><a href="#bp-assertion-specification-parts">Parts of an Assertion Specification</a></p></li><li><p><a href="#bp-assertion-semantics">Semantics of Policy Assertions</a></p></li><li><p><a href="#bp-semantics-and-form">Semantics of an Assertion and its form</a></p></li><li><p><a href="#bp-assertion-start">Starting to Build an Assertion</a></p></li><li><p><a href="#bp-unique-qnames">Unique QNames</a></p></li><li><p><a href="#bp-assertions-and-message-semantics">Assertions and Message Semantics</a></p></li><li><p><a href="#bp-assertion-duplication">Duplication of Assertions</a></p></li><li><p><a href="#bp-assertion-definition">Definition of Policy Assertions</a></p></li><li><p><a href="#bp-nesting">Nesting of Assertions</a></p></li><li><p><a href="#bp-optional-assertions">Optional Assertions</a></p></li><li><p><a href="#bp-independent-assertions">Independent Assertions</a>/p></li><li><p><a href="#bp-policy-subject-change">Change of the Policy Subject Over Time</a></p></li></ol></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
@@ -265,7 +265,7 @@
       	best practices will be an assertion specification that describes
       	a contract for the consumers and providers of the capabilities and constraints of the domain.
       	</p></div><div class="div1">
-<h2><a name="d3e232" id="d3e232"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="d3e228" id="d3e228"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
 		express their own domain knowledge, it is necessary to provide basic
 		functionality that all domains could exploit and then allow
 		points of extension where authors of the various WS-Policy
@@ -746,7 +746,7 @@
         			delegated to the specific domain handlers that are not visible
         			to the WS-Policy framework.</p></div></div></div><div class="div2">
 <h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e646" id="d3e646"></a>5.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h4><a name="d3e642" id="d3e642"></a>5.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
         			compact authoring form for assertions, behaviors are marked by
         			using <code>wsp:Optional</code> attribute that has a value,
         			"true". During the process of normalization, the runtime
@@ -757,7 +757,7 @@
         			runtime behavior. In order to simplify reference to such
         			assertions, we just use the term optional assertions in this section. 
         			</p></div><div class="div3">
-<h4><a name="d3e654" id="d3e654"></a>5.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+<h4><a name="d3e650" id="d3e650"></a>5.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
         			example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
         			optional behavior that can be engaged by a consumer. The
         			primer proposes that an assertion that identifies the use of
@@ -944,7 +944,9 @@
            			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. The
+           			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
+practice 11: Independent Assertions</span></p><p class="practice">Use independent assertions for modeling multiple equivalent
+           						behaviors.</p></div><p>The
            			policy expression in the example below requires the use of
            			WSS: SOAP Message Security 1.0. </p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 6-1. </span>Message-level Security and WSS: SOAP Message Security 1.0</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
@@ -954,11 +956,9 @@
            						policy assertions.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 6-2. </span>Message-level Security and WSS: SOAP Message Security 1.1</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;sp:Wss11&gt;…&lt;/sp:Wss11&gt;
-&lt;/Policy&gt;</pre></div></div><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Good
-practice 11: Independent Assertions</span></p><p class="practice">Use independent assertions for modeling multiple equivalent
-           						behaviors.</p></div></div><div class="div2">
+&lt;/Policy&gt;</pre></div></div></div><div class="div2">
 <h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>6.3 Supporting New Policy Subjects</h3><p>
-				<a href="#Assertions">Section 2</a> identifies that it is a best practice for policy authors to 
+				The <a href="#bp-assertion-specification-parts">Good practice: Parts of an Assertion Specification</a> specifies that policy authors should 
 				define the set of policy subjects to which policy assertions can be 
 				attached.  Over time, new policy subjects may need to be defined.  When 
 				this occurs, a policy assertion author may update the list of policy 
@@ -973,10 +973,8 @@
 				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-assertion-description" id="bp-assertion-description"></a><span class="practicelab">Good
-practice 12: Description of Assertions</span></p><p class="practice">An assertion description should specify a policy 
-				subject.</p></div><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Good
-practice 13: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time, 
+			</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Good
+practice 12: 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">
 <h2><a name="best-practices-attachment" id="best-practices-attachment"></a>7. Applying Best Practices for  Policy Attachment</h2><div class="div2">
@@ -1448,4 +1446,4 @@
 							Editors' action 
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207">207</a>.
 						</td></tr><tr><td rowspan="1" colspan="1">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated section <a href="#change-description"><b>E. Changes in this Version of
-          the Document</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070329</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Changed all &lt;p&gt;Best Practice:  to &lt;p role="practice"&gt;</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+          the Document</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070329</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Changed all &lt;p&gt;Best Practice:  to &lt;p role="practice"&gt;</td></tr><tr><td rowspan="1" colspan="1">20070416</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Updated 6.2 and 6.3 for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>..  Note, removed one best practice that was a dup.</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.54
retrieving revision 1.55
diff -u -d -r1.54 -r1.55
--- ws-policy-guidelines.xml	11 Apr 2007 22:05:27 -0000	1.54
+++ ws-policy-guidelines.xml	16 Apr 2007 19:27:47 -0000	1.55
@@ -1212,7 +1212,10 @@
            			vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
            			[<bibref ref="WS-Addressing"/>]. These equivalent behaviors
            			are mutually exclusive for an interaction. Such equivalent
-           			behaviors can be modeled as independent assertions. The
+           			behaviors can be modeled as independent assertions. </p>
+           			           					<p role="practice" id="bp-independent-assertions"><quote>Independent Assertions</quote><quote>Use independent assertions for modeling multiple equivalent
+           						behaviors.</quote></p>
+           			<p>The
            			policy expression in the example below requires the use of
            			WSS: SOAP Message Security 1.0. </p> 
            			<example>
@@ -1228,13 +1231,12 @@
 <eg xml:space="preserve">&lt;Policy&gt;
   &lt;sp:Wss11&gt;&hellip;&lt;/sp:Wss11&gt;
 &lt;/Policy&gt;</eg></example>
-           					<p role="practice" id="bp-independent-assertions"><quote>Independent Assertions</quote><quote>Use independent assertions for modeling multiple equivalent
-           						behaviors.</quote></p>
+
 			</div2>	
 		<div2 id="supporting-new-policy-subjects">
 			<head>Supporting New Policy Subjects</head>
 			<p>
-				<loc href="#Assertions">Section 2</loc> identifies that it is a best practice for policy authors to 
+				The <loc href="#bp-assertion-specification-parts">Good practice: Parts of an Assertion Specification</loc> specifies that policy authors should 
 				define the set of policy subjects to which policy assertions can be 
 				attached.  Over time, new policy subjects may need to be defined.  When 
 				this occurs, a policy assertion author may update the list of policy 
@@ -1251,8 +1253,7 @@
 				new policy subjects are added it is incumbent on the authors to retain the 
 				semantic of the policy assertion. 
 			</p>
-			<p role="practice" id="bp-assertion-description"><quote>Description of Assertions</quote><quote>An assertion description should specify a policy 
-				subject.</quote></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, 
 				the assertion description should also be versioned to reflect this 
 				change.</quote>
@@ -2106,7 +2107,13 @@
 						<td>20070329</td>
 						<td>DBO</td>
 						<td>Changed all &lt;p&gt;Best Practice:  to &lt;p role="practice"&gt;</td>
-					</tr>    
+					</tr>  
+					
+						<tr>
+						<td>20070416</td>
+						<td>DBO</td>
+						<td>Updated 6.2 and 6.3 for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</loc>..  Note, removed one best practice that was a dup.</td>
+					</tr>     
 				</tbody>
 			</table>
 		</inform-div1>
Received on Monday, 16 April 2007 19:28:01 GMT

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