- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 15 Mar 2007 00:47:11 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv10165
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Resolution for issue 4072, editors action 204. http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- ws-policy-guidelines.html 8 Mar 2007 23:44:50 -0000 1.30
+++ ws-policy-guidelines.html 15 Mar 2007 00:47:08 -0000 1.31
@@ -89,8 +89,8 @@
4.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 4.5.1 <a href="#d3e512">Optional behavior in Compact authoring</a><br>
- 4.5.2 <a href="#d3e520">Optional behavior at runtime</a><br>
+ 4.5.1 <a href="#d3e519">Optional behavior in Compact authoring</a><br>
+ 4.5.2 <a href="#d3e527">Optional behavior at runtime</a><br>
4.6 <a href="#typing-assertions">Typing Assertions</a><br>
4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
4.8 <a href="#interrelated-domains">Interrelated domains</a><br>
@@ -316,75 +316,63 @@
relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally
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>4.1 Assertions and Their Target Use</h3><p>Assertion Authors need to have some definition of what the goal is for the assertions
- they author. Assertion Authors should also understand the
- functionality the WS-Policy framework provides and apply the
- knowledge of 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 one or two
- assertions or they may choose to specify many assertion
- elements that require parameters or other nested
- assertions. There are advantages to simplifying the set of
- assertions. The ultimate goal of policy assertions is to
- enable interoperability and assertions that define behavior
- for consumers and providers that can be clearly understood
- will most likely be consumed by a broad audience.
- </p><p>If a domain has a wide range of behaviors, the ability
- to combine individual assertions may also need to be considered.
- </p><p>The number of different subjects to which an assertion
- can be attached is also a factor when defining an
- assertion. For attaching to WSDL subjects see <a href="#levels-of-abstraction"><b>4.7 Levels of Abstraction in WSDL </b></a> for more detail.
- </p><p> Once the range of policy subjects is identified, there are choices for ways of
- attaching multiple instances of a simple policy
- assertion to multiple subjects. One way is to utilize
- the referencing mechanism that is present in the
- framework. By defining the assertion once and using it
- in different policies (e.g. with different
- alternatives) via reference, a policy assertion may be
- associated with different alternatives and subjects. A
- referencing mechanism is very useful in a tooling
- environment; when creating a domain specific
- attachment in multiple WSDL files or Endpoint
- References in which the same set of policies are expected to be applied.
- </p><p>WS-PolicyAttachment provides various
- mechanisms to attach a policy to a policy
- subject. Although a policy assertion may be
- tailored for or constrained to a specific set
- of policy subjects by design, its semantics
- are not dependent upon the mechanism by which
- a policy expression is attached to a given
- policy subject. For instance, an assertion
- "Foo" has the same semantic when attached to a
- WSDL1.1 operation regardless of whether it was
- attached using XML element policy attachment
- or the external URI 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>Best practice: Assertion Authors should include the following
- items in the dialect specification:
- </p><ul><li><p><em>The definition of the
- assertion</em>. Does the assertion pertain to a specific
- behavior that is tied to a context or is the behavior
- different in each possible context? For example an
- assertion that may have different semantics for a single
- message exchange or for all message exchanges that pertain
- to an endpoint would probably be represented by separate assertions.
- </p></li><li><p><em>Scoping of the assertion</em>. Where
- does the assertion apply? Is the assertion about a
- specific description in WSDL? Is the assertion about a
- specific aspect of protocol? Is the assertion about a
- specific coordination between parties? Determination of
- the subject of an assertion is helpful in specifying the
- different scopes and subjects that it applies to.
- </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></div><div class="div2">
+<h3><a name="assertion-target" id="assertion-target"></a>4.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.
+ </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>
+ 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 <a href="#levels-of-abstraction"><b>4.7 Levels of Abstraction in WSDL </b></a> for more detail.
+ 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
+ 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
+ subject. For instance, an assertion "Foo" has the same semantic when
+ attached to an operation policy subject regardless of whether it was
+ attached using XML element policy attachment or the external URI
+ 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>
+ Best practice: Assertion Authors should include the following items in an
+ assertion specification:
+ </p><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><p>
+ Best practice: The semantics a policy assertion should not depend on the
+ attachment mechanism used.
+ </p></div><div class="div2">
<h3><a name="compact-full" id="compact-full"></a>4.2 Authoring Styles </h3><p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
constructs: an attribute to decorate an assertion (to indicate whether it is required or optional), semantics for
recursively nested policy operators, and a policy reference/inclusion mechanism.
@@ -676,7 +664,7 @@
to the WS-Policy framework.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e512" id="d3e512"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h4><a name="d3e519" id="d3e519"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
using <code>wsp:Optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
@@ -687,7 +675,7 @@
runtime behavior. In order to simplify reference to such
assertions, we just use the term optional assertions in this section.
</p></div><div class="div3">
-<h4><a name="d3e520" id="d3e520"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+<h4><a name="d3e527" id="d3e527"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
@@ -1351,4 +1339,7 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3987">3987</a>.
Related editorial action is
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/153">153</a>.
- </td></tr><tr><td rowspan="1" colspan="1">20070308</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Changed "lifecycle" spec references to versioning to fix build. </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ </td></tr><tr><td rowspan="1" colspan="1">20070308</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Changed "lifecycle" spec references to versioning to fix build. </td></tr><tr><td rowspan="1" colspan="1">20070314</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented <a href="http://www.w3.org/2007/03/14-ws-policy-irc#T18-14-48">resolution</a> for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</a>
+ as outlined in
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html">proposal</a>.
+ Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/204">204</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.39
retrieving revision 1.40
diff -u -d -r1.39 -r1.40
--- ws-policy-guidelines.xml 8 Mar 2007 23:44:50 -0000 1.39
+++ ws-policy-guidelines.xml 15 Mar 2007 00:47:08 -0000 1.40
@@ -411,96 +411,72 @@
<div2 id="assertion-target">
<head>Assertions and Their Target Use</head>
-
- <p>Assertion Authors need to have some definition of what the goal is for the assertions
- they author. Assertion Authors should also understand the
- functionality the WS-Policy framework provides and apply the
- knowledge of 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 one or two
- assertions or they may choose to specify many assertion
- elements that require parameters or other nested
- assertions. There are advantages to simplifying the set of
- assertions. The ultimate goal of policy assertions is to
- enable interoperability and assertions that define behavior
- for consumers and providers that can be clearly understood
- will most likely be consumed by a broad audience.
- </p>
- <p>If a domain has a wide range of behaviors, the ability
- to combine individual assertions may also need to be considered.
- </p>
- <p>The number of different subjects to which an assertion
- can be attached is also a factor when defining an
- assertion. For attaching to WSDL subjects see <specref ref="levels-of-abstraction"/> for more detail.
- </p>
- <p> Once the range of policy subjects is identified, there are choices for ways of
- attaching multiple instances of a simple policy
- assertion to multiple subjects. One way is to utilize
- the referencing mechanism that is present in the
- framework. By defining the assertion once and using it
- in different policies (e.g. with different
- alternatives) via reference, a policy assertion may be
- associated with different alternatives and subjects. A
- referencing mechanism is very useful in a tooling
- environment; when creating a domain specific
- attachment in multiple WSDL files or Endpoint
- References in which the same set of policies are expected to be applied.
- </p>
-
- <p>WS-PolicyAttachment provides various
- mechanisms to attach a policy to a policy
- subject. Although a policy assertion may be
- tailored for or constrained to a specific set
- of policy subjects by design, its semantics
- are not dependent upon the mechanism by which
- a policy expression is attached to a given
- policy subject. For instance, an assertion
- "Foo" has the same semantic when attached to a
- WSDL1.1 operation regardless of whether it was
- attached using XML element policy attachment
- or the external URI 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>Best practice: Assertion Authors should include the following
- items in the dialect specification:
- </p>
+ <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.
+ </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>
+ 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.
+ 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
+ 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
+ subject. For instance, an assertion "Foo" has the same semantic when
+ attached to an operation policy subject regardless of whether it was
+ attached using XML element policy attachment or the external URI
+ 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>
+ Best practice: Assertion Authors should include the following items in an
+ assertion specification:
+ </p><p>
<ulist>
- <item>
- <p><emph>The definition of the
- assertion</emph>. Does the assertion pertain to a specific
- behavior that is tied to a context or is the behavior
- different in each possible context? For example an
- assertion that may have different semantics for a single
- message exchange or for all message exchanges that pertain
- to an endpoint would probably be represented by separate assertions.
- </p>
- </item>
- <item>
- <p><emph>Scoping of the assertion</emph>. Where
- does the assertion apply? Is the assertion about a
- specific description in WSDL? Is the assertion about a
- specific aspect of protocol? Is the assertion about a
- specific coordination between parties? Determination of
- the subject of an assertion is helpful in specifying the
- different scopes and subjects that it applies to.
- </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>
+ <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>
- </div2>
-
+ </p>
+ <p>
+ Best practice: The semantics a policy assertion should not depend on the
+ attachment mechanism used.
+ </p>
+ </div2>
<div2 id="compact-full">
<head>Authoring Styles </head>
<p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
@@ -2006,6 +1982,14 @@
<td>DBO</td>
<td>Changed "lifecycle" spec references to versioning to fix build. </td>
</tr>
+ <tr>
+ <td>20070314</td>
+ <td>FJH</td>
+ <td>Implemented <loc href="http://www.w3.org/2007/03/14-ws-policy-irc#T18-14-48">resolution</loc> for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</loc>
+ as outlined in
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html">proposal</loc>.
+ Editorial action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/204">204</loc>. </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Thursday, 15 March 2007 00:47:27 UTC