- 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
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>
4.1 <a href="#roles"> Roles and Responsibilities </a><br>
4.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
4.1.2 <a href="#consumers">Consumers</a><br>
@@ -137,8 +137,8 @@
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
5.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.5.1 <a href="#d3e646">Optional behavior in Compact authoring</a><br>
- 5.5.2 <a href="#d3e654">Optional behavior at runtime</a><br>
+ 5.5.1 <a href="#d3e642">Optional behavior in Compact authoring</a><br>
+ 5.5.2 <a href="#d3e650">Optional behavior at runtime</a><br>
5.6 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
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><Policy>
@@ -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><Policy>
<sp:Wss11>…</sp:Wss11>
-</Policy></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">
+</Policy></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 <p>Best Practice: to <p role="practice"></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 <p>Best Practice: to <p role="practice"></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"><Policy>
<sp:Wss11>…</sp:Wss11>
</Policy></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 <p>Best Practice: to <p role="practice"></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 UTC