- 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