- From: David Orchard via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 03 May 2007 18:39:48 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv24881
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Resolve 4414
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -d -r1.53 -r1.54
--- ws-policy-primer.html 2 May 2007 21:09:41 -0000 1.53
+++ ws-policy-primer.html 3 May 2007 18:39:45 -0000 1.54
@@ -137,7 +137,10 @@
3.6 <a href="#policy-retrieval">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.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
+ 3.8.2 <a href="#d3e1405">Policy Expressions</a><br>
+ 3.8.3 <a href="#ignorable-and-versioning">Use of Ignorable attribute and an alternative Versioning Scenario</a><br>
+ 3.8.4 <a href="#ignorable-and-optional-and-versioning">Use of Ignorable and Optional attributes</a><br>
3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
4. <a href="#versioning-policy-language">Versioning Policy Language</a><br>
4.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
@@ -1034,7 +1037,8 @@
unordered collection of policy alternatives. That is, the order of policy alternatives is
insignificant. Therefore, the order of combining these policy expressions is
insignificant.</p></div><div class="div2">
-<h3><a name="extensibility-and-versioning" id="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><p>Web Services Policy language is an extensible language by design. The
+<h3><a name="extensibility-and-versioning" id="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><div class="div3">
+<h4><a name="ext-vers-policylanguage" id="ext-vers-policylanguage"></a>3.8.1 Policy Language</h4><p>Web Services Policy language is an extensible language by design. The
<code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
and <code>wsp:PolicyReference</code> elements are extensible. The <code>Policy</code>
element allows child element and attribute extensibility, while the
@@ -1044,11 +1048,12 @@
A consuming processor processes known attributes and elements, ignores unknown attributes
and treats unknown children of the <code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
elements as policy assertions. The child elements of <code>wsp:PolicyReference</code> are ignored.
- </p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p><p>Web Services Policy language enables simple versioning practices that allow requesters to
- continue the use of any older policy alternatives in a backward compatible manner. This
- allows service providers, like Company-X, to deploy new behaviors using additional policy
+ </p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p></div><div class="div3">
+<h4><a name="d3e1405" id="d3e1405"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
+ continue the use of older policy alternatives in a backward compatible manner. This
+ versioning practice allows service providers, like Company-X, to deploy new behaviors using additional (or new) policy
assertions without breaking compatibility with clients that rely on any older policy
- alternatives.</p><p>The example below represents a Company-X version 1 policy expression. This expression
+ alternatives. We use examples below to illustrate how versioning might be done.</p><p>The example below represents a Company-X version 1 policy expression. This expression
requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
@@ -1058,10 +1063,10 @@
</All>
</ExactlyOne>
</Policy></pre></div></div><p>Over time, Company-X adds support for advanced behaviors: requiring the use of addressing
- and message-level security for protecting messages. They added this advanced support
+ and message-level security for protecting messages. They would like to add this advanced support
without breaking compatibility with requesters that rely on addressing and transport-level
security. The example below is Company-X’s version 2 policy expression. In this version,
- Company-X’s adds a new policy alternative that requires the use of addressing and
+ Company-X adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
may continue to interact with Company-X’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
@@ -1080,10 +1085,10 @@
</Policy></pre></div></div><p>When Company-X added support for advanced behaviors, they spent time to plan for the
continued support for existing clients, the smooth migration from using current to
advanced behaviors, and the switch to use only the advanced behaviors in the near future
- (i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
+ (i.e. sun-setting current behaviors). In this versioning scenario, a policy expression with multiple alternatives was used to
represent current and advanced behaviors in a non-disruptive manner: no immediate changes
to existing clients are required and these clients can smoothly migrate to new
- functionality when they choose to. This level of versioning support in policy enables the
+ functionality when they choose to. This level of versioning support in a policy expression enables the
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like Company-X,
incrementally deploy advanced behaviors, some requesters may not recognize these new
@@ -1096,20 +1101,14 @@
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 class="div3">
-<h4><a name="ignorable-and-versioning" id="ignorable-and-versioning"></a>3.8.1 Ignorable and Versioning</h4><p>
+ </p></div><div class="div3">
+<h4><a name="ignorable-and-versioning" id="ignorable-and-versioning"></a>3.8.3 Use of Ignorable attribute and an alternative Versioning Scenario</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
+ information by creating a new policy assertion within a policy expression. The new assertion is added to the original policy expression and then the service can update the assertion parameter values when the service expires.</p><p> One scenario that illustrates this is a service which 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.
+ not be supported. In this scenario, the expiry date and time of the service would be a new policy assertion [see Guidelines section 4] that the service provider defines . This hypothetical EndOfLife policy assertion is then included in the original policy expression, but it could be marked as ignorable. The service, in this case, wants to inform the consumers it does have an expiry time, and so it is useful to convey this information from the beginning to help smooth the versioning process.
</p><p>
- Company-X could specify that the older policy alternative will expire at a
- certain point in time using a Company-X specific expiry assertion. The example
- below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
- Assertion.
+Company-X could specify that one policy alternative will expire at a certain point in time using the hypothetical ignorable Company-X expiry assertion. The example below shows how Company-X can create a new version 2 policy expression with a second hypothetical ignorable EndOfLife Assertion with a different date and time.
</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</i></p><div class="exampleInner"><pre><Policy>
@@ -1131,28 +1130,14 @@
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 Company-X 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 Company-X 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">
+ In a scenario such as this, CompanyX is acting as both a policy assertion author and a policy expression author. As a policy expression author, when an assertion type is tagged as ignorable information, the use of strict or lax mode and presence or absence of the assertion type in the first version are important decisions.
+ </p></div><div class="div3">
+<h4><a name="ignorable-and-optional-and-versioning" id="ignorable-and-optional-and-versioning"></a>3.8.4 Use of Ignorable and Optional attributes</h4><p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it may or may not mark that assertion with wsp:Optional="true" in the first version. If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="false", then a client that:</p><ul><li><p>does not know about the assertion and using lax intersection will produce an intersection.</p></li><li><p>does not know about the assertion and using strict intersection will not produce an intersection. </p></li><li><p>does know about the assertion and using strict or lax intersection will produce an intersection. </p></li></ul><p>
+If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="true", then a client that:</p><ul><li><p>does or does not know about the assertion and using lax or strict intersection will produce an intersection. </p></li></ul><p>The following table summarizes the requester assertion knowledge and intersection mode on the left vs provider ignorable and optional on the top</p><table summary="Requester assertion knowledge and intersection mode vs provider ignorable and optional" border="true"><tbody><tr><td rowspan="1" colspan="1">Requester \ Provider</td><td rowspan="1" colspan="1">wsp:Ignorable="false", wsp:Optional="false"</td><td rowspan="1" colspan="1">wsp:Ignorable="true", wsp:Optional="false"</td><td rowspan="1" colspan="1">wsp:Ignorable="false", wsp:Optional="true"</td><td rowspan="1" colspan="1">wsp:Ignorable="true", wsp:Optional="true"</td></tr><tr><td rowspan="1" colspan="1">does not know, lax</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Ye</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does not know, strict</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, lax</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, strict</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr></tbody></table><br><p>If Company-X adds the hypothetical EndOfLife policy assertion type to a subsequent Alternative and does not mark the assertion with wsp:Optional="true", then after the policy expression has been deployed/used the same algorithm holds true, notably that a client using strict mode that does not understand the ssertion will not intersect
+with the alternative. If CompanyX adds the hypothetical EndOfLife policy assertion with an ignorable attribute and does mark the assertion with wsp:Optional="true", then clients using strict mode who do not understand the hypothetical EndOfLife assertion with the ignorable information will still be compatible with the alternative that does not contain the hypothetical EndOfLife policy assertion as per the intersection rules and the server can return an error if the request is received after the expiry date.</p><p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under any mode by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing strict intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion wih wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
+</p><p>Because the actual value of the date/time may not be known when the policy expression is first created, a value that is roughly infinitely in the future is used. A subsequent policy alternative could refine the value and domain specific processing of the assertion can differentiate the value.
+The advantage of adding the end of life information through a domain specific assertion is that some clients will have a machine processable way of knowing when the alternative will no longer be supported by evaluating the policy assertions in a policy expression. Without this information in a policy expression, 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 of a service. </p><p>The disadvantage of adding the end of life information through a domain specific assertion is that clients need to understand the semantics of the hypothetical EndOfLife assertion in order to know whether a particular alternative is still valid. For example, a client that doesn’t know what the parameter “Mar-31-2008” means, will not know that the service is no longer available on April 1, and may send messages to this service in April, and if the service enforces “end of life”, these messages may fail.
+</p></div></div><div class="div2">
<h3><a name="parts-of-a-policy-assertion" id="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
@@ -1609,7 +1594,7 @@
for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue 4300</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</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">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Formatted the example in <a href="#ignorable-and-versioning"><b>3.8.1 Ignorable and Versioning</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070322</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Deleted residual text in <a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a>; <code>s/The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:/The possible extensibility points are:/</code> ; <code>s/PolicyReference: any attribute and a proposal to add any element/PolicyReference: any attribute and any element/</code>.</td></tr><tr><td rowsan="1" colspan="1">20070426</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Editorial changes to align with the OASIS WS-SecurityPolicy specification.
+ </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">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Formatted the example in <a href="#ignorable-and-versioning"><b>3.8.3 Use of Ignorable attribute and an alternative Versioning Scenario</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070322</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Deleted residual text in <a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a>; <code>s/The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:/The possible extensibility points are:/</code> ; <code>s/PolicyReference: any attribute and a proposal to add any element/PolicyReference: any attribute and ay element/</code>.</td></tr><tr><td rowspan="1" colspan="1">20070426</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Editorial changes to align with the OASIS WS-SecurityPolicy specification.
For <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4318">issue 4318</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/244">244</a>.
@@ -1620,4 +1605,7 @@
</td></tr><tr><td rowspan="1" colspan="1">20070502</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Further changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue 4393</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070502</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Finished changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414">issue 4414</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</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.57
retrieving revision 1.58
diff -u -d -r1.57 -r1.58
--- ws-policy-primer.xml 2 May 2007 21:51:36 -0000 1.57
+++ ws-policy-primer.xml 3 May 2007 18:39:45 -0000 1.58
@@ -1399,7 +1399,7 @@
continue the use of older policy alternatives in a backward compatible manner. This
versioning practice allows service providers, like Company-X, to deploy new behaviors using additional (or new) policy
assertions without breaking compatibility with clients that rely on any older policy
- alternatives. We use two examples below to illustrate how versioning might be done.</p>
+ alternatives. We use examples below to illustrate how versioning might be done.</p>
<p>The example below represents a Company-X version 1 policy expression. This expression
requires the use of addressing and transport-level security for protecting messages. </p>
<example>
@@ -1414,10 +1414,10 @@
</Policy></eg>
</example>
<p>Over time, Company-X adds support for advanced behaviors: requiring the use of addressing
- and message-level security for protecting messages. They added this advanced support
+ and message-level security for protecting messages. They would like to add this advanced support
without breaking compatibility with requesters that rely on addressing and transport-level
security. The example below is Company-X’s version 2 policy expression. In this version,
- Company-X’s adds a new policy alternative that requires the use of addressing and
+ Company-X adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
may continue to interact with Company-X’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
@@ -1440,10 +1440,10 @@
<p>When Company-X added support for advanced behaviors, they spent time to plan for the
continued support for existing clients, the smooth migration from using current to
advanced behaviors, and the switch to use only the advanced behaviors in the near future
- (i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
+ (i.e. sun-setting current behaviors). In this versioning scenario, a policy expression with multiple alternatives was used to
represent current and advanced behaviors in a non-disruptive manner: no immediate changes
to existing clients are required and these clients can smoothly migrate to new
- functionality when they choose to. This level of versioning support in policy enables the
+ functionality when they choose to. This level of versioning support in a policy expression enables the
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p>
<p>Let us look at tooling for unknown policy assertions. As service providers, like Company-X,
@@ -1460,21 +1460,16 @@
</p>
</div3>
<div3 id="ignorable-and-versioning">
- <head>Ignorable and Versioning</head>
+ <head>Use of Ignorable attribute and an alternative Versioning Scenario</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
+ information by creating a new policy assertion within a policy expression. The new assertion is added to the original policy expression and then the service can update the assertion parameter values when the service expires.</p>
+ <p> One scenario that illustrates this is a service which 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.
+ not be supported. In this scenario, the expiry date and time of the service would be a new policy assertion [see Guidelines section 4] that the service provider defines . This hypothetical EndOfLife policy assertion is then included in the original policy expression, but it could be marked as ignorable. The service, in this case, wants to inform the consumers it does have an expiry time, and so it is useful to convey this information from the beginning to help smooth the versioning process.
</p>
<p>
- Company-X could specify that the older policy alternative will expire at a
- certain point in time using a Company-X specific expiry assertion. The example
- below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
- Assertion.
+Company-X could specify that one policy alternative will expire at a certain point in time using the hypothetical ignorable Company-X expiry assertion. The example below shows how Company-X can create a new version 2 policy expression with a second hypothetical ignorable EndOfLife Assertion with a different date and time.
</p>
<example>
<head>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
@@ -1501,29 +1496,78 @@
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 Company-X 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 Company-X 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.
+ In a scenario such as this, CompanyX is acting as both a policy assertion author and a policy expression author. As a policy expression author, when an assertion type is tagged as ignorable information, the use of strict or lax mode and presence or absence of the assertion type in the first version are important decisions.
</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>
+ <div3 id="ignorable-and-optional-and-versioning">
+ <head>Use of Ignorable and Optional attributes</head>
+ <p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it may or may not mark that assertion with wsp:Optional="true" in the first version. If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="false", then a client that:</p>
+<ulist>
+<item>
+<p>does not know about the assertion and using lax intersection will produce an intersection.</p>
+</item>
+<item>
+<p>does not know about the assertion and using strict intersection will not produce an intersection. </p>
+</item>
+<item>
+<p>does know about the assertion and using strict or lax intersection will produce an intersection. </p>
+</item>
+</ulist>
+<p>
+If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="true", then a client that:</p>
+<ulist>
+<item>
+<p>does or does not know about the assertion and using lax or strict intersection will produce an intersection. </p>
+</item>
+</ulist>
+<p>The following table summarizes the requester assertion knowledge and intersection mode on the left vs provider ignorable and optional on the top</p>
+<table summary="Requester assertion knowledge and intersection mode vs provider ignorable and optional" border="true">
+<tbody>
+<tr>
+<td>Requester \ Provider</td>
+<td>wsp:Ignorable="false", wsp:Optional="false"</td>
+<td>wsp:Ignorable="true", wsp:Optional="false"</td>
+<td>wsp:Ignorable="false", wsp:Optional="true"</td>
+<td>wsp:Ignorable="true", wsp:Optional="true"</td>
+</tr>
+<tr>
+<td>does not know, lax</td>
+<td>No</td>
+<td>Yes</td>
+<td>Yes</td>
+<td>Yes</td>
+</tr>
+<tr>
+<td>does not know, strict</td>
+<td>No</td>
+<td>No</td>
+<td>Yes</td>
+<td>Yes</td>
+</tr>
+<tr>
+<td>does know, lax</td>
+<td>Yes</td>
+<td>Yes</td>
+<td>Yes</td>
+<td>Yes</td>
+</tr>
+<tr>
+<td>does know, strict</td>
+<td>Yes</td>
+<td>Yes</td>
+<td>Yes</td>
+<td>Yes</td>
+</tr>
+</tbody>
+</table>
+<p>If Company-X adds the hypothetical EndOfLife policy assertion type to a subsequent Alternative and does not mark the assertion with wsp:Optional="true", then after the policy expression has been deployed/used the same algorithm holds true, notably that a client using strict mode that does not understand the assertion will not intersect
+with the alternative. If CompanyX adds the hypothetical EndOfLife policy assertion with an ignorable attribute and does mark the assertion with wsp:Optional="true", then clients using strict mode who do not understand the hypothetical EndOfLife assertion with the ignorable information will still be compatible with the alternative that does not contain the hypothetical EndOfLife policy assertion as per the intersection rules and the server can return an error if the request is received after the expiry date.</p>
+<p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under any mode by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing strict intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
+</p>
+ <p>Because the actual value of the date/time may not be known when the policy expression is first created, a value that is roughly infinitely in the future is used. A subsequent policy alternative could refine the value and domain specific processing of the assertion can differentiate the value.
+The advantage of adding the end of life information through a domain specific assertion is that some clients will have a machine processable way of knowing when the alternative will no longer be supported by evaluating the policy assertions in a policy expression. Without this information in a policy expression, 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 of a service. </p>
+<p>The disadvantage of adding the end of life information through a domain specific assertion is that clients need to understand the semantics of the hypothetical EndOfLife assertion in order to know whether a particular alternative is still valid. For example, a client that doesn’t know what the parameter “Mar-31-2008” means, will not know that the service is no longer available on April 1, and may send messages to this service in April, and if the service enforces “end of life”, these messages may fail.
+</p>
</div3>
</div2>
<div2 id="parts-of-a-policy-assertion">
@@ -2435,6 +2479,14 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</loc>.
</td>
</tr>
+ <tr>
+ <td>20070502</td>
+ <td>DBO</td>
+ <td>Finished changes for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414">issue 4414</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Thursday, 3 May 2007 18:40:09 UTC