- From: Toufic Boubez via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 02 May 2007 21:09:44 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv15589
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Further changes for Editors' action 239
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -d -r1.52 -r1.53
--- ws-policy-primer.html 1 May 2007 23:24:56 -0000 1.52
+++ ws-policy-primer.html 2 May 2007 21:09:41 -0000 1.53
@@ -880,10 +880,11 @@
</p><p>
In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an
assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary.
- The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
- When using the strict intersection mode ignorable assertions are part of the policy alternative vocabulary, so the
- <code>wsp:Ignorable</code> attribute does not impact the intersection result even when the <code>wsp:Ignorable</code>
- attribute value is “true”.
+ The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
+ </p><p>
+ When using the strict intersection mode all assertions are part of the policy alternative vocabulary,
+ including those marked with <code>wsp:Ignorable</code>. Thus the <code>wsp:Ignorable</code> attribute
+ does not impact the intersection result even when its attribute value is “true”.
</p><p>
If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax
intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the
@@ -901,6 +902,18 @@
Domain-specific processing could take advantage of any
information from the policy data model, such as the ignorable property of a
policy assertion.
+ </p><p>
+ A requester can decide how to process a provider's policy to determine
+ if and how the requester will interact with the provider. The requester
+ can have its own policy that expresses its own capabilities and
+ requirements, and can make one or more attempts at policy intersection
+ in order to determine a compatible alternative and/or isolate the cause
+ of an empty intersection result. The requester can use and analyze the
+ result(s) of policy intersection to select a compatible alternative or
+ trigger other domain-specific processing options. For example, a
+ requester can at first attempt strict mode intersection, and then lax
+ mode as another choice, if the previous attempt returns an empty
+ intersection result.
</p></div></div><div class="div2">
<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Company-X attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
@@ -1604,4 +1617,7 @@
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.
</td></tr><tr><td rowspan="1" colspan="1">20070501</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Reset Section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
+ </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></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.55
retrieving revision 1.56
diff -u -d -r1.55 -r1.56
--- ws-policy-primer.xml 1 May 2007 23:24:56 -0000 1.55
+++ ws-policy-primer.xml 2 May 2007 21:09:41 -0000 1.56
@@ -1139,14 +1139,18 @@
<p>
In order to determine compatibility of its policy expression with a provider policy expression, a
requester may use either a "lax" or "strict" mode of the intersection algorithm.
- </p><p>
+ </p>
+ <p>
In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an
assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary.
- The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
- When using the strict intersection mode ignorable assertions are part of the policy alternative vocabulary, so the
- <att>wsp:Ignorable</att> attribute does not impact the intersection result even when the <att>wsp:Ignorable</att>
- attribute value is “true”.
- </p><p>
+ The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
+ </p>
+ <p>
+ When using the strict intersection mode all assertions are part of the policy alternative vocabulary,
+ including those marked with <att>wsp:Ignorable</att>. Thus the <att>wsp:Ignorable</att> attribute
+ does not impact the intersection result even when its attribute value is “true”.
+ </p>
+ <p>
If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax
intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the
<att>wsp:Ignorable</att> attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode
@@ -1166,6 +1170,19 @@
information from the policy data model, such as the ignorable property of a
policy assertion.
</p>
+ <p>
+ A requester can decide how to process a provider's policy to determine
+ if and how the requester will interact with the provider. The requester
+ can have its own policy that expresses its own capabilities and
+ requirements, and can make one or more attempts at policy intersection
+ in order to determine a compatible alternative and/or isolate the cause
+ of an empty intersection result. The requester can use and analyze the
+ result(s) of policy intersection to select a compatible alternative or
+ trigger other domain-specific processing options. For example, a
+ requester can at first attempt strict mode intersection, and then lax
+ mode as another choice, if the previous attempt returns an empty
+ intersection result.
+ </p>
</div3>
</div2>
<div2 id="attaching-policy-expressions-to-wsdl2">
@@ -2403,6 +2420,14 @@
<td>Reset Section <specref ref="change-description"/>.
</td>
</tr>
+ <tr>
+ <td>20070502</td>
+ <td>TIB</td>
+ <td>Further changes for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue 4393</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 Wednesday, 2 May 2007 21:09:46 UTC