- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 17 Oct 2007 17:04:55 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv12414
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Implemented the resolution for issue 5204. Editors' action 370.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -d -r1.72 -r1.73
--- ws-policy-primer.html 26 Sep 2007 16:37:30 -0000 1.72
+++ ws-policy-primer.html 17 Oct 2007 17:04:52 -0000 1.73
@@ -80,7 +80,7 @@
}
@media screen {
- p.practice, {
+ p.practice {
position: relative;
top: -2em;
padding: 0;
@@ -394,8 +394,8 @@
</All></pre></div></div><p>Company-X is able to meet their customer needs by adding optional support for the Optimized MIME
Serialization. Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and
detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization.
- An optional policy assertion represents a behavior that may be engaged. When a
- policy assertion is absent from a policy vocabulary (See section 3.2, Web Services Policy 1.5 - Framework),
+ An optional policy assertion represents a behavior that may be engaged. When that
+ policy assertion is absent from a policy alternative (See section 3.2, Web Services Policy 1.5 - Framework),
a policy-aware client should not conclude anything (other than ‘no claims’)
about the absence of that policy assertion. See section
<a href="#attaching-policy-expressions-to-wsdl"><b>2.11 Attaching Policy Expressions to WSDL</b></a> on the absence of policy expressions.</p></div><div class="div2">
@@ -922,10 +922,10 @@
requester may use either a "lax" or "strict" mode of the intersection algorithm.
</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.
+ assertion in the other, and vice versa (See section 4.5, Web Services Policy 1.5 - Framework). For this to be possible they must contain the same policy assertion types.
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,
+ When using the strict intersection mode compatibility is computed for all assertions that are part of the policy alternative,
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>
@@ -933,8 +933,8 @@
intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the
<code>wsp:Ignorable</code> attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode
two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the
- other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for
- all “non-ignorable” assertions.
+ other, and vice versa. For this to be possible the two policy alternatives must contain the same policy assertion types
+ for all “non-ignorable” assertions.
</p><p>
Regardless of the chosen intersection mode, ignorable assertions do
not express any wire-level requirements on the behavior of consumers -
@@ -1686,4 +1686,7 @@
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">362</a> to drop the ed-note.
</td></tr><tr><td rowspan="1" colspan="1">20070921</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated references [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>].
</td></tr><tr><td rowspan="1" colspan="1">20070921</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">20071017</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5204">5204</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/370">370</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.78
retrieving revision 1.79
diff -u -d -r1.78 -r1.79
--- ws-policy-primer.xml 26 Sep 2007 16:37:30 -0000 1.78
+++ ws-policy-primer.xml 17 Oct 2007 17:04:53 -0000 1.79
@@ -451,8 +451,8 @@
<p>Company-X is able to meet their customer needs by adding optional support for the Optimized MIME
Serialization. Optional support is outlined in section 3.4 &framework.title; and
detailed in section 4.5.2, &guidelines.title;, specifically for Optimized MIME Serialization.
- An optional policy assertion represents a behavior that may be engaged. When a
- policy assertion is absent from a policy vocabulary (See section 3.2, &framework.title;),
+ An optional policy assertion represents a behavior that may be engaged. When that
+ policy assertion is absent from a policy alternative (See section 3.2, &framework.title;),
a policy-aware client should not conclude anything (other than ‘no claims’)
about the absence of that policy assertion. See section
<specref ref="attaching-policy-expressions-to-wsdl"/> on the absence of policy expressions.</p>
@@ -1205,11 +1205,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.
+ assertion in the other, and vice versa (See section 4.5, &framework.title;). For this to be possible they must contain the same policy assertion types.
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,
+ When using the strict intersection mode compatibility is computed for all assertions that are part of the policy alternative,
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>
@@ -1218,8 +1218,8 @@
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
two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the
- other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for
- all “non-ignorable” assertions.
+ other, and vice versa. For this to be possible the two policy alternatives must contain the same policy assertion types
+ for all “non-ignorable” assertions.
</p>
<p>
Regardless of the chosen intersection mode, ignorable assertions do
@@ -2644,7 +2644,15 @@
<td>ASV</td>
<td>Reset Section <specref ref="change-description"/>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20071017</td>
+ <td>FJH</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5204">5204</loc>. Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/370">370</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Wednesday, 17 October 2007 17:05:06 UTC