- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 31 Jan 2007 21:09:25 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv1994
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Implemented resolution for issue 4270, corresponding to editors action 151.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -d -r1.35 -r1.36
--- ws-policy-primer.html 22 Jan 2007 20:57:24 -0000 1.35
+++ ws-policy-primer.html 31 Jan 2007 21:09:22 -0000 1.36
@@ -60,7 +60,7 @@
complete normative description of the Web Services Policy language. </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="#basic-concepts-policy-expression">Basic Concepts: Policy Expression</a><br> 2.1 <a href="#web-services-policy">Web Services Policy</a><br> 2.2 <a href="#simple-message">Simple Message</a><br> 2.3 <a href="#secure-message">Secure Message</a><br> 2.4 <a href="#other-assertions">Other Assertions</a><br> 2.5 <a href="#combining-policy-assertions">Combining Policy Assertions</a><br> 2.6 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 2.7 <a href="#ignorable-policy-assertions">Ignorable Policy Expressions</a><br> 2.8 <a href="#nested-policy-expressions">Nested Policy Expressions</a><br> 2.9 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a<br> 2.10 <a href="#attaching-policy-expressions-to-wsdl">Attaching Policy Expressions to WSDL</a><br> 2.11 <a href="#policy-automates-web-services-interaction">Policy Automates Web Services Interaction</a><br>3. <a href="#advanced-concepts-policy-expression">Advanced Concepts: Policy Expression</a><br> 3.1 <a href="#policy-expression">Policy Expression</a><br> 3.2 <a href="#normal-form-for-policy-expressions">Normal Form for Policy Expressions</a><br> 3.3 <a href="#policy-data-model">Policy Data Model</a><br> 3.4 <a href="#compatible-policies">Compatible Policies</a><br> 3.4.1 <a href="#strict-lax-policy-intersection">Strict and Lax Policy Intersection</a><br> 3.5 <a href="#attaching-policy-expressions-to-wsdl2">Attaching Policy Expressions to WSDL</a><br> 3.6 <a href="#policy-rerieval">Policy Retrieval</a><br> 3.7 <a href="#combine-policies">Combine Policies</a><br> 3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br> 3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br> 3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br> 3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br> 3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>4. <a href="#conclusion">Conclusion</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="#basic-concepts-policy-expression">Basic Concepts: Policy Expression</a><br> 2.1 <a href="#web-services-policy">Web Services Policy</a><br> 2.2 <a href="#simple-message">Simple Message</a><br> 2.3 <a href="#secure-message">Secure Message</a><br> 2.4 <a href="#other-assertions">Other Assertions</a><br> 2.5 <a href="#combining-policy-assertions">Combining Policy Assertions</a><br> 2.6 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 2.7 <a href="#ignorable-policy-assertions">Ignorable Policy Expressions</a><br> 2.8 <a href="#nested-policy-expressions">Nested Policy Expressions</a><br> 2.9 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a<br> 2.10 <a href="#attaching-policy-expressions-to-wsdl">Attaching Policy Expressions to WSDL</a><br> 2.11 <a href="#policy-automates-web-services-interaction">Policy Automates Web Services Interaction</a><br>3. <a href="#advanced-concepts-policy-expression">Advanced Concepts: Policy Expression</a><br> 3.1 <a href="#policy-expression">Policy Expression</a><br> 3.2 <a href="#normal-form-for-policy-expressions">Normal Form for Policy Expressions</a><br> 3.3 <a href="#policy-data-model">Policy Data Model</a><br> 3.4 <a href="#compatible-policies">Compatible Policies</a><br> 3.4.1 <a href="#strict-lax-policy-intersection">Strict and Lax Policy Intersection</a><br> 3.5 <a href="#attaching-policy-expressions-to-wsdl2">Attaching Policy Expressions to WSDL</a><br> 3.6 <a href="#policy-rerieval">Policy Retrieval</a><br> 3.7 <a href="#combine-policies">Combine Policies</a><br> 3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br> 3.8.1 <a href="#ignorable-and-versioning">Ignorable and Versioning</a><br> 3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br> 3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br> 3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br> 3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>4. <a href="#conclusion">Conclusion</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 - Primer Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2><p>This document, <em>Web Services Policy 1.5 - Primer</em>, provides an introductory description of the
Web Services Policy language and should be read alongside the formal descriptions contained
@@ -166,7 +166,7 @@
transport-level security for protecting messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Secure Message</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand="1" >
- <wsu:Timestamp u:Id="_0">
+ <wsu:Timestamp wsu:Id="_0">
<wsu:Created>2006-01-19T02:49:53.914Z</u:Created>
<wsu:Expires>2006-01-19T02:54:53.914Z</u:Expires>
</wsu:Timestamp>
@@ -482,7 +482,7 @@
expressions?</p></li><li><p>What is the policy data model?</p></li><li><p>How to select a compatible policy alternative?</p></li><li><p>How to attach policy expressions to WSDL constructs?</p></li><li><p>How to combine policies?</p></li><li><p>What are the extensibility points?</p></li><li><p>What are the parts of a policy assertion?</p></li></ul><div class="div2">
<h3><a name="policy-expression"></a>3.1 Policy Expression</h3><p>A policy expression is the XML representation and interoperable form of a Web Services
Policy. A policy expression consists of a <code>Policy</code> wrapper element and a
- variety of child and descendent elements. Child and descendent elements from the policy
+ variety of child and descendant elements. Child and descendent elements from the policy
language are <code>Policy, All</code>, <code>ExactlyOne</code>
and <code>PolicyReference</code>. Other child elements of <code>Policy</code>,
<code>All</code> and <code>ExactlyOne</code> are policy assertions. (The <code>Policy</code>
@@ -881,7 +881,65 @@
intervention. As you would recognize, there is nothing new in this practice. This is
similar to how a proxy generator that generates code from WSDL creates code for all the
known WSDL constructs and allows Web service developers to fill in code for custom or
- unknown constructs in the WSDL.</p></div><div class="div2">
+ unknown constructs in the WSDL.
+ </p><div class="div3">
+<h4><a name="ignorable-and-versioning"></a>3.8.1 Ignorable and Versioning</h4><p>
+ One potential use of the wsp:Ignorable attribute is to mark versioning related
+ information. One scenario is that a service will support a particular version
+ of a service until a certain point in time. After that time, the service will
+ not be supported. The expiry date and time of the service would be a domain
+ expression, but it could be marked as
+ ignorable. When an alternative does have an expiry, it is usually
+ useful to convey this information to help smooth the versioning process.
+ </p><p>
+ Contoso could specify that the older policy alternative will expire at a
+ certain point in time using a Contoso specific expiry assertion. The example
+ below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+ Assertion.
+ </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+ Assertion</i></p><div class="exampleInner"><pre>
+ <Policy>
+ <ExactlyOne>
+ <All>
+ <contoso:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</contoso:EndOfLife>
+ <wsap:UsingAddressing/>
+ <sp:TransportBinding>...</sp:TransportBinding>
+ </All>
+
+ <!-- NEW Policy Alternative -->
+ <All>
+ <contoso:EndOfLife wsp:Ignorable="true">Mar-31-2999</contoso:EndOfLife>
+ <wsap:UsingAddressing/>
+ <sp:AsymmetricBinding>...</sp:AsymmetricBinding>
+ </All>
+ </ExactlyOne>
+ </Policy>
+ </pre></div></div><p>
+ In this variant of the versioning scenario, the use of ignorable allows
+ versioning related information to be conveyed and used where understood.
+ </p><p>
+ In a scenario such as this, where an assertion type is used for ignorable
+ information, the use of strict or lax mode and presence or absence of the
+ assertion type in the first version are important decisions. If Contoso wishes
+ clients to always be able to ignore the assertion, particularly those using
+ strict intersection, the first policy alternative offered should contain the
+ policy assertion type. If Contoso adds the policy assertion type to a
+ subsequent alternative, then requesters using strict mode will not understand
+ the assertion type and the alternative with the ignorable information will not
+ be compatible with the older version of the alternative as per the intersection
+ rules. Thus the widest possible alternative compatibility will be to have the
+ ignorable policy assertion type in the very first version of the alternative.
+ The second alternative shown also contains the hypothetical EndOfLife policy
+ Assertion type.
+ Because the actual value is not known, a value that is roughly infinitely in
+ the future is used. A subsequent policy alternative could refine the value.
+ </p><p>
+ The advantage of adding the end of life information is that some clients will have a
+ machine processable way of knowing when the alternative will no longer be
+ supported. Without this information, the information must be conveyed in some
+ other way or it will not be conveyed at all. This can usefully smooth the
+ transition between versions.
+ </p></div></div><div class="div2">
<h3><a name="parts-of-a-policy-assertion"></a>3.9 Parts of a Policy Assertion</h3><p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
or condition. A policy assertion has a QName that identifies its behavior or requirement
or condition. A policy assertion may contain assertion parameters and a nested policy.</p><p>Let us look at the anatomy of a policy assertion from the security domain. The policy
@@ -929,7 +987,7 @@
The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div3">
<h4><a name="versioning-policy-framework"></a>3.10.1 Policy Framework</h4><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
- After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
+ After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
...
@@ -938,7 +996,7 @@
...
</wsp:All>
</wsp:ExactlyOne>
-</wsp:Policy></pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
+</wsp:Policy></pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:ExactlyOne>
<wsp:All>
@@ -952,12 +1010,12 @@
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Alternatively, the wsp:Optional could be set to "true" on the choice, as
- in:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
+ in:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
wsp:Optional="true">
...
</wsp16:Choice>
-</wsp:Policy></pre></div></div><p>The normalized form will be:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
+</wsp:Policy></pre></div></div><p>The normalized form will be:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
@@ -968,7 +1026,7 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Because the wsp16:Choice alternative isn't understood in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored. Policy intersection may be more difficult with such compatible extensions. For example, the previous will "look"
like it has a wsp16:Choice typed assertion. To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done. However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expected result.
- </p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
+ </p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -978,7 +1036,7 @@
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Notice that using a new namespace can result in backwards and forwards compatibility if normalization results in an optional alternative. </p><p>Best practice: insert new elements in an optional alternative or mark with wsp:Optional="true". </p><p>Incompatible versions of the Policy language may be indicated by a new namespace name for at least the new and/or incompatible elements or attributes. Imagine that the Choice operator is required by a future version of Policy, then there will be a new namespace for the Policy element. We use the wsp20 prefix to indicate a hypothetical Policy Language 2.0 that is intended to be incompatible with Policy Language
- 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
+ 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp20:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -986,12 +1044,12 @@
...
</wsp20:ExactlyOne>
</wsp20:Policy> </pre></div></div><p>The new Policy operator could be embedded inside an existing Policy
- element:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
+ element:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
</wsp20:Choice>
...
-</wsp20:Policy> </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation. This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
+</wsp20:Policy> </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation. This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1000,7 +1058,7 @@
</wsp:ExactlyOne>
</wsp20:Policy> </pre></div></div><p>It is difficult to predict whether this functionality would be useful. The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div3">
<h4><a name="versioning-policy-attachment"></a>3.10.2 Policy Attachment</h4><p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
- WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+ WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1021,7 +1079,7 @@
</wsp:Policy>
<wsdl11:operation name="GetLastTradePrice" > ....
...</pre></div></div><p>The PolicyReference element is element or attribute extensible.
- One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+ One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-23. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1253,7 +1311,7 @@
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">Frederick</a> and
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</a> to the list of editors.
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</a>.
- </td></tr><tr><td rowspan="1" colspan="1">20061207</td><td rowspan="1" colspan="1">FH</td><td rowspan="1" colspan="1">Implemented the resolution for
+ </td></tr><tr><td rowspan="1" colspan="1">20061207</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution for
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3952">issue 3952</a>
<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0018.html">as outlined</a>
(with editorial correction replacing "for as" with "as"),
@@ -1275,4 +1333,5 @@
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/118">118</a>
Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</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">20070131</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4270">4270</a> as Resolved on 31 January 2007,
+ closing editors action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/151">151</a>.</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -d -r1.31 -r1.32
--- ws-policy-primer.xml 22 Jan 2007 20:54:16 -0000 1.31
+++ ws-policy-primer.xml 31 Jan 2007 21:09:22 -0000 1.32
@@ -235,7 +235,7 @@
<eg xml:space="preserve"><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand="1" >
- <wsu:Timestamp u:Id="_0">
+ <wsu:Timestamp wsu:Id="_0">
<wsu:Created>2006-01-19T02:49:53.914Z</u:Created>
<wsu:Expires>2006-01-19T02:54:53.914Z</u:Expires>
</wsu:Timestamp>
@@ -740,7 +740,7 @@
<head>Policy Expression</head>
<p>A policy expression is the XML representation and interoperable form of a Web Services
Policy. A policy expression consists of a <code>Policy</code> wrapper element and a
- variety of child and descendent elements. Child and descendent elements from the policy
+ variety of child and descendant elements. Child and descendent elements from the policy
language are <code>Policy, All</code>, <code>ExactlyOne</code>
and <code>PolicyReference</code>. Other child elements of <code>Policy</code>,
<code>All</code> and <code>ExactlyOne</code> are policy assertions. (The <code>Policy</code>
@@ -1334,8 +1334,77 @@
intervention. As you would recognize, there is nothing new in this practice. This is
similar to how a proxy generator that generates code from WSDL creates code for all the
known WSDL constructs and allows Web service developers to fill in code for custom or
- unknown constructs in the WSDL.</p>
- </div2>
+ unknown constructs in the WSDL.
+ </p>
+ <div3 id="ignorable-and-versioning">
+ <head>Ignorable and Versioning</head>
+ <p>
+ One potential use of the wsp:Ignorable attribute is to mark versioning related
+ information. One scenario is that a service will support a particular version
+ of a service until a certain point in time. After that time, the service will
+ not be supported. The expiry date and time of the service would be a domain
+ expression, but it could be marked as
+ ignorable. When an alternative does have an expiry, it is usually
+ useful to convey this information to help smooth the versioning process.
+ </p>
+ <p>
+ Contoso could specify that the older policy alternative will expire at a
+ certain point in time using a Contoso specific expiry assertion. The example
+ below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+ Assertion.
+ </p>
+ <example>
+ <head>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+ Assertion</head>
+ <eg xml:space="preserve">
+ <Policy>
+ <ExactlyOne>
+ <All>
+ <contoso:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</contoso:EndOfLife>
+ <wsap:UsingAddressing/>
+ <sp:TransportBinding>...</sp:TransportBinding>
+ </All>
+
+ <!-- NEW Policy Alternative -->
+ <All>
+ <contoso:EndOfLife wsp:Ignorable="true">Mar-31-2999</contoso:EndOfLife>
+ <wsap:UsingAddressing/>
+ <sp:AsymmetricBinding>...</sp:AsymmetricBinding>
+ </All>
+ </ExactlyOne>
+ </Policy>
+ </eg>
+ </example>
+ <p>
+ In this variant of the versioning scenario, the use of ignorable allows
+ versioning related information to be conveyed and used where understood.
+ </p>
+ <p>
+ In a scenario such as this, where an assertion type is used for ignorable
+ information, the use of strict or lax mode and presence or absence of the
+ assertion type in the first version are important decisions. If Contoso wishes
+ clients to always be able to ignore the assertion, particularly those using
+ strict intersection, the first policy alternative offered should contain the
+ policy assertion type. If Contoso adds the policy assertion type to a
+ subsequent alternative, then requesters using strict mode will not understand
+ the assertion type and the alternative with the ignorable information will not
+ be compatible with the older version of the alternative as per the intersection
+ rules. Thus the widest possible alternative compatibility will be to have the
+ ignorable policy assertion type in the very first version of the alternative.
+ The second alternative shown also contains the hypothetical EndOfLife policy
+ Assertion type.
+ Because the actual value is not known, a value that is roughly infinitely in
+ the future is used. A subsequent policy alternative could refine the value.
+ </p>
+ <p>
+ The advantage of adding the end of life information is that some clients will have a
+ machine processable way of knowing when the alternative will no longer be
+ supported. Without this information, the information must be conveyed in some
+ other way or it will not be conveyed at all. This can usefully smooth the
+ transition between versions.
+ </p>
+ </div3>
+ </div2>
<div2 id="parts-of-a-policy-assertion">
<head>Parts of a Policy Assertion</head>
<p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
@@ -2011,7 +2080,7 @@
</tr>
<tr>
<td>20061207</td>
- <td>FH</td>
+ <td>FJH</td>
<td>Implemented the resolution for
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3952">issue 3952</loc>
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0018.html">as outlined</loc>
@@ -2065,6 +2134,12 @@
<td>Completed action item:
<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>20070131</td>
+ <td>FJH</td>
+ <td>Implemented resolution for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4270">4270</loc> as Resolved on 31 January 2007,
+ closing editors action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/151">151</loc>.</td>
</tr>
</tbody>
</table>
Received on Wednesday, 31 January 2007 21:09:55 UTC