- From: Toufic Boubez via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 08 May 2007 01:05:32 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv19191
Modified Files:
ws-policy-guidelines.xml ws-policy-guidelines.html
Log Message:
Updated 5.1 Assertions and their Target Use for issue 3989 and editors' action item 227.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -d -r1.51 -r1.52
--- ws-policy-guidelines.html 7 May 2007 20:04:36 -0000 1.51
+++ ws-policy-guidelines.html 8 May 2007 01:05:29 -0000 1.52
@@ -137,9 +137,9 @@
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
5.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.5.1 <a href="#d3e661">Optional behavior in Compact authoring</a><br>
- 5.5.2 <a href="#d3e701">Optional behavior at runtime</a><br>
- 5.5.2.1 <a href="#d3e746">Example</a><br>
+ 5.5.1 <a href="#d3e660">Optional behavior in Compact authoring</a><br>
+ 5.5.2 <a href="#d3e700">Optional behavior at runtime</a><br>
+ 5.5.2.1 <a href="#d3e745">Example</a><br>
5.6 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
5.7 <a href="#interrelated-domains">Interrelated domains</a><br>
6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
@@ -361,24 +361,40 @@
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p><ul><li><p>What is the intended use of the policy assertion?</p></li><li><p>Which authoring style will be used?</p></li><li><p>Is this a new policy domain? Does it need to compose with other domains?</p></li><li><p>How complex are the assertions?</p></li><li><p>Is there a need to consider nesting?</p></li><li><p>Do optional behaviors need to be represented?</p></li></ul><div class="div2">
<h3><a name="assertion-target" id="assertion-target"></a>5.1 Assertions and Their Target Use</h3><p>
- Assertion Authors need to have a specific goal in mind for the assertions
- that they author. Assertion Authors should also understand the
- functionality that the WS-Policy framework provides and apply the
- knowledge of the policy framework processing when defining the set of
- assertions.
- </p><p>Assertions can be simple or they can be complex. Assertion Authors may
- choose to specify multiple peer assertions, each carrying the semantic of
- a particular behavior, or they may choose to specify assertions that
- contains assertion parameters and/or nested policy expression (nested
- assertions), each of which relate to an aspect of the behavior, yet
- encapsulated within a single assertion. There are advantages to
- simplifying the set of assertions. The ultimate goal of policy is to
- enable interoperability. By keeping assertion design as simple as
- possible, Assertion Authors will more likely be able to meet that
- objective.
+ Assertion Authors should understand the functionality that the WS-Policy
+ framework provides and apply the knowledge of the policy framework processing
+ when defining the set of assertions.
</p><p>
- If a set of assertions describes a wide range of behaviors, the ability to
- combine individual assertions may also need to be considered.
+ Assertions can be simple or they can be complex. Assertion Authors may choose
+ to specify multiple peer assertions, each carrying the semantic of a particular
+ behavior, or they may choose to specify assertions that contains assertion parameters
+ and/or nested policy expression (nested assertions), each of which relate to an
+ aspect of the behavior, yet encapsulated within a single assertion.
+ There are advantages to simplifying the set of assertions. The ultimate goal of
+ policy is to enable interoperability. By keeping assertion design as simple as
+ possible, Assertion Authors will more likely be able to meet that objective.
+ </p><p>
+ Therefore, Assertion Authors need to have a specific goal in mind for the assertions
+ that they author. Assertion specifications should include a detailed specification
+ of the assertion’s semantics, a set of valid policy subjects to which the asserction
+ maybe attached. The specification should also include the scope of the assertion
+ in the context of a particular policy subject. For example, an assertion with
+ Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
+ or it can be scoped to all messages exchanged with that endpoint. The former case
+ permits a client to select a different alternative with each successive message
+ exchange. Finally, if a set of assertions describes a wide range of behaviors,
+ the ability to combine individual assertions may also need to be considered.
+ For example, if an assertion applies to the SOAP protocol, it would be necessary
+ to consider how its presence must interact with other policy assertions that
+ are defined for security.
+ </p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Good
+practice 1: Parts of an Assertion Specification</span></p><p class="practice">
+ Assertion Authors should include the following items in an
+ assertion specification: </p></div><p>
+ <ul><li><p><em>The definition of the assertion's semantic.</em> </p></li><li><p><em>The specification of the set of valid policy subjects to which an
+ assertion may be attached.</em></p></li><li><p><em>The scope of the assertion in the context of a particular policy
+ subject.</em></p></li><li><p><em>Any composition considerations if the assertion is used with
+ other assertions in a context.</em></p></li></ul>
</p><p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
@@ -386,9 +402,7 @@
Additionally, the framework provides for the means to extend the set of
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
- </p><p>
- The WS-Policy Attachment specification provides various mechanisms to
- attach a policy expression to a policy subject. Although a policy
+ </p><p>Although a policy
assertion may be constrained to a specific set of policy subjects by
assertion authors, its semantics should not be dependent upon the
mechanism by which the policy expression is attached to a given policy
@@ -398,22 +412,7 @@
attachment mechanism. Independence from a specific attachment mechanism
allows policy tools to choose the most appropriate mechanism to attach a
policy without having to analyze the contents of the policy.
- </p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Good
-practice 1: Parts of an Assertion Specification</span></p><p class="practice">
- Assertion Authors should include the following items in an
- assertion specification: </p></div><p>
- <ul><li><p><em>The definition of the assertion's semantic.</em> </p></li><li><p><em>The specification of the set of valid policy subjects to which an
- assertion may be attached.</em></p></li><li><p><em>The scope of the assertion in the context of a particular policy
- subject.</em> For example, an assertion with Endpoint Policy Subject can be
- scoped to a given message exchange with that endpoint, or it can be scoped
- to all messages exchanged with that endpoint. The former case permits a
- client to select a different alternative with each successive message
- exchange.</p></li><li><p><em>Composition</em>. If the assertion is used with other assertions in a
- context, it is necessary to consider how the assertion may, or may not,
- affect the composition. For example, if an assertion applies to the SOAP
- protocol, it would be necessary to consider how its presence must interact
- with other policy assertions that are defined for security.</p></li></ul>
- </p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Good
+ </p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Good
practice 2: Semantics of Policy Assertions</span></p><p class="practice">
The semantics a policy assertion should not depend on the
attachment mechanism used.</p></div></div><div class="div2">
@@ -765,7 +764,7 @@
delegated to the specific domain handlers that are not visible
to the WS-Policy framework.</p></div></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e661" id="d3e661"></a>5.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
+<h4><a name="d3e660" id="d3e660"></a>5.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
compact authoring form for assertions, such behaviors are marked by
using <code>wsp:Optional</code> attribute with a value of
"true". (In order to simplify reference to such assertions,
@@ -796,7 +795,7 @@
it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port.
The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.
</pre></div></div></div><div class="div3">
-<h4><a name="d3e701" id="d3e701"></a>5.5.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e700" id="d3e700"></a>5.5.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since this would allow the
@@ -851,7 +850,7 @@
</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Good
practice 14: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
either out of band or as reflected by the message content.</p></div><div class="div4">
-<h5><a name="d3e746" id="d3e746"></a>5.5.2.1 Example</h5><p>
+<h5><a name="d3e745" id="d3e745"></a>5.5.2.1 Example</h5><p>
The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the
use of
<cite><a href="#MTOM">MTOM</a></cite> as an optional behavior that can be engaged by a consumer.
@@ -1535,4 +1534,8 @@
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">232</a>,
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">253</a>, and
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070507</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Updated 5.1 Assertions and their Target Use for
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
+ and editors' action item
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</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.66
retrieving revision 1.67
diff -u -d -r1.66 -r1.67
--- ws-policy-guidelines.xml 7 May 2007 20:01:34 -0000 1.66
+++ ws-policy-guidelines.xml 8 May 2007 01:05:29 -0000 1.67
@@ -410,26 +410,54 @@
<div2 id="assertion-target">
<head>Assertions and Their Target Use</head>
<p>
- Assertion Authors need to have a specific goal in mind for the assertions
- that they author. Assertion Authors should also understand the
- functionality that the WS-Policy framework provides and apply the
- knowledge of the policy framework processing when defining the set of
- assertions.
+ Assertion Authors should understand the functionality that the WS-Policy
+ framework provides and apply the knowledge of the policy framework processing
+ when defining the set of assertions.
</p>
- <p>Assertions can be simple or they can be complex. Assertion Authors may
- choose to specify multiple peer assertions, each carrying the semantic of
- a particular behavior, or they may choose to specify assertions that
- contains assertion parameters and/or nested policy expression (nested
- assertions), each of which relate to an aspect of the behavior, yet
- encapsulated within a single assertion. There are advantages to
- simplifying the set of assertions. The ultimate goal of policy is to
- enable interoperability. By keeping assertion design as simple as
- possible, Assertion Authors will more likely be able to meet that
- objective.
- </p><p>
- If a set of assertions describes a wide range of behaviors, the ability to
- combine individual assertions may also need to be considered.
- </p><p>
+ <p>
+ Assertions can be simple or they can be complex. Assertion Authors may choose
+ to specify multiple peer assertions, each carrying the semantic of a particular
+ behavior, or they may choose to specify assertions that contains assertion parameters
+ and/or nested policy expression (nested assertions), each of which relate to an
+ aspect of the behavior, yet encapsulated within a single assertion.
+ There are advantages to simplifying the set of assertions. The ultimate goal of
+ policy is to enable interoperability. By keeping assertion design as simple as
+ possible, Assertion Authors will more likely be able to meet that objective.
+ </p>
+ <p>
+ Therefore, Assertion Authors need to have a specific goal in mind for the assertions
+ that they author. Assertion specifications should include a detailed specification
+ of the assertion’s semantics, a set of valid policy subjects to which the asserction
+ maybe attached. The specification should also include the scope of the assertion
+ in the context of a particular policy subject. For example, an assertion with
+ Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
+ or it can be scoped to all messages exchanged with that endpoint. The former case
+ permits a client to select a different alternative with each successive message
+ exchange. Finally, if a set of assertions describes a wide range of behaviors,
+ the ability to combine individual assertions may also need to be considered.
+ For example, if an assertion applies to the SOAP protocol, it would be necessary
+ to consider how its presence must interact with other policy assertions that
+ are defined for security.
+ </p>
+
+ <p role="practice" id="bp-assertion-specification-parts"><quote>Parts of an Assertion Specification</quote>
+ <quote>
+ Assertion Authors should include the following items in an
+ assertion specification: </quote>
+ </p>
+ <p>
+ <ulist>
+ <item><p><emph>The definition of the assertion's semantic.</emph> </p></item>
+ <item><p><emph>The specification of the set of valid policy subjects to which an
+ assertion may be attached.</emph></p></item>
+ <item><p><emph>The scope of the assertion in the context of a particular policy
+ subject.</emph></p></item>
+ <item><p><emph>Any composition considerations if the assertion is used with
+ other assertions in a context.</emph></p></item>
+ </ulist>
+ </p>
+
+ <p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
WSDL subjects see <specref ref="levels-of-abstraction"/> for more detail.
@@ -437,9 +465,7 @@
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
</p>
- <p>
- The WS-Policy Attachment specification provides various mechanisms to
- attach a policy expression to a policy subject. Although a policy
+ <p>Although a policy
assertion may be constrained to a specific set of policy subjects by
assertion authors, its semantics should not be dependent upon the
mechanism by which the policy expression is attached to a given policy
@@ -449,27 +475,7 @@
attachment mechanism. Independence from a specific attachment mechanism
allows policy tools to choose the most appropriate mechanism to attach a
policy without having to analyze the contents of the policy.
- </p><p role="practice" id="bp-assertion-specification-parts"><quote>Parts of an Assertion Specification</quote><quote>
- Assertion Authors should include the following items in an
- assertion specification: </quote>
- </p><p>
- <ulist>
- <item><p><emph>The definition of the assertion's semantic.</emph> </p></item>
- <item><p><emph>The specification of the set of valid policy subjects to which an
- assertion may be attached.</emph></p></item>
- <item><p><emph>The scope of the assertion in the context of a particular policy
- subject.</emph> For example, an assertion with Endpoint Policy Subject can be
- scoped to a given message exchange with that endpoint, or it can be scoped
- to all messages exchanged with that endpoint. The former case permits a
- client to select a different alternative with each successive message
- exchange.</p></item>
- <item><p><emph>Composition</emph>. If the assertion is used with other assertions in a
- context, it is necessary to consider how the assertion may, or may not,
- affect the composition. For example, if an assertion applies to the SOAP
- protocol, it would be necessary to consider how its presence must interact
- with other policy assertions that are defined for security.</p></item>
- </ulist>
- </p>
+ </p>
<p role="practice" id="bp-assertion-semantics"><quote>Semantics of Policy Assertions</quote><quote>
The semantics a policy assertion should not depend on the
attachment mechanism used.</quote>
@@ -2259,6 +2265,15 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</loc>.
</td>
</tr>
+ <tr>
+ <td>20070507</td>
+ <td>TIB</td>
+ <td>Updated 5.1 Assertions and their Target Use for
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</loc>
+ and editors' action item
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Tuesday, 8 May 2007 01:05:35 UTC