W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > May 2007

2006/ws/policy ws-policy-guidelines.xml,1.66,1.67 ws-policy-guidelines.html,1.51,1.52

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
Message-Id: <E1HlE8y-0004zx-JF@lionel-hutz.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 @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e661">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e701">Optional behavior at runtime</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2.1 <a href="#d3e746">Example</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e660">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e700">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2.1 <a href="#d3e745">Example</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:03 GMT