- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 30 Jan 2007 22:18:18 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv22601
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Completed Action 144, Resolutions for 3985 and 3986
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- ws-policy-guidelines.html 22 Jan 2007 21:12:07 -0000 1.18
+++ ws-policy-guidelines.html 30 Jan 2007 22:18:15 -0000 1.19
@@ -63,7 +63,7 @@
guide to using the specifications. </p></div><div>
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">What is an Assertion? </a><br>3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e511">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e519">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#apropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">Scenario and a worked example</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">What is an Assertion? </a><br>3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e504">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e512">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#apropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">Scenario and a worked example</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2><p>The WS-Policy specification defines a policy to be a collection
@@ -497,19 +497,31 @@
assertion beyond its type. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the approach.
</p><div class="div3">
-<h4><a name="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows Assertion Authors to define parameters, for example, to
- qualify an assertion. For some domains it will be appropriate
- to specify these parameters instead of nesting assertion elements.
- </p><p> Note that parameters of assertions include the following:</p><ul><li><p> Complex elements with element children that cannot be policy assertions.
- </p></li><li><p> Elements that have attributes </p></li></ul><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements
- are the two assertion parameters of the <code>sp:SignedParts</code> policy assertion (this
- assertion requires the parts of a message to be protected).
- </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><Policy>
+<h4><a name="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows WS-Policy domain authors to define
+ policy assertion parameters to qualify an assertion.
+ Policy assertion parameters are the opaque payload of an assertion.
+ Assertion parameters carry additional useful pieces of information
+ necessary for engaging the behavior described by an assertion.
+ Assertion parameters are not considered when performing policy
+ intersection unless domain specific compatibility processing
+ semantics are specified by the assertion.
+ In the XML representation of a policy assertion the child elements
+ and attributes of the assertion excluding child elements and attributes
+ from the policy xml language namespace are the assertion parameters.
+ </p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code>
+ elements are the two assertion parameters of the
+ <code>sp:SignedParts</code> policy assertion
+ (this assertion requires the parts of a message to be protected).
+ </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><wsp:Policy>
<sp:SignedParts>
- <sp:Body />
- <sp:Header />
+ <sp:Body/>
+ <sp:Header/>
</sp:SignedParts>
-</Policy></pre></div></div></div><div class="div3">
+</wsp:Policy></pre></div></div><p>Best practice: Define policy assertion parameters for
+ specifying useful pieces of information necessary for engaging
+ the behavior described by an assertion but not relevant to policy
+ intersection.
+ </p></div><div class="div3">
<h4><a name="nested-assertions"></a>4.4.2 Nested Assertions</h4><p>The framework provides the ability to "nest" policy assertions. For domains with a complex set of
options, nesting provides one way to indicate dependent
elements within a behavior. The granularity of assertions is
@@ -601,7 +613,7 @@
to the WS-Policy framework.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e511"></a>4.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="d3e504"></a>4.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
@@ -612,7 +624,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="d3e519"></a>4.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="d3e512"></a>4.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
@@ -1241,4 +1253,6 @@
the Document</b></a>.
</td></tr><tr><td rowspan="1" colspan="1">20070122</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Completed action item:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/127">127</a>
- Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</a></td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</a></td></tr><tr><td rowspan="1" colspan="1">20070130</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Completed action item:
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/144">144</a>
+ Resolution for issues <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3985">3985</a> and <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3986">3986</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.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- ws-policy-guidelines.xml 22 Jan 2007 21:10:19 -0000 1.27
+++ ws-policy-guidelines.xml 30 Jan 2007 22:18:15 -0000 1.28
@@ -714,34 +714,40 @@
<div3 id="parameterized-assertions">
<head>Assertions with Parameters</head>
- <p>The framework allows Assertion Authors to define parameters, for example, to
- qualify an assertion. For some domains it will be appropriate
- to specify these parameters instead of nesting assertion elements.
- </p>
- <p> Note that parameters of assertions include the following:</p>
- <ulist>
- <item>
- <p> Complex elements with element children that cannot be policy assertions.
- </p>
- </item>
- <item>
- <p> Elements that have attributes </p>
- </item>
- </ulist>
-
- <p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements
- are the two assertion parameters of the <code>sp:SignedParts</code> policy assertion (this
- assertion requires the parts of a message to be protected).
- </p>
+
+ <p>The framework allows WS-Policy domain authors to define
+ policy assertion parameters to qualify an assertion.
+ Policy assertion parameters are the opaque payload of an assertion.
+ Assertion parameters carry additional useful pieces of information
+ necessary for engaging the behavior described by an assertion.
+ Assertion parameters are not considered when performing policy
+ intersection unless domain specific compatibility processing
+ semantics are specified by the assertion.
+ In the XML representation of a policy assertion the child elements
+ and attributes of the assertion excluding child elements and attributes
+ from the policy xml language namespace are the assertion parameters.
+ </p>
+
+ <p>In the example below, <code>sp:Body</code> and <code>sp:Header</code>
+ elements are the two assertion parameters of the
+ <code>sp:SignedParts</code> policy assertion
+ (this assertion requires the parts of a message to be protected).
+ </p>
<example> <head>Policy Assertion with Assertion Parameters</head>
- <eg xml:space="preserve"><Policy>
+ <eg xml:space="preserve"><wsp:Policy>
<sp:SignedParts>
- <sp:Body />
- <sp:Header />
+ <sp:Body/>
+ <sp:Header/>
</sp:SignedParts>
-</Policy></eg>
+</wsp:Policy></eg>
</example>
+ <p>Best practice: Define policy assertion parameters for
+ specifying useful pieces of information necessary for engaging
+ the behavior described by an assertion but not relevant to policy
+ intersection.
+ </p>
+
</div3>
<div3 id="nested-assertions">
@@ -1907,6 +1913,13 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/127">127</loc>
Resolution for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</loc></td>
</tr>
+<tr>
+ <td>20070130</td>
+ <td>UY</td>
+ <td>Completed action item:
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/144">144</loc>
+ Resolution for issues <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3985">3985</loc> and <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3986">3986</loc></td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Tuesday, 30 January 2007 22:18:27 UTC