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

2006/ws/policy ws-policy-guidelines.xml,1.114,1.115

From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 12 Sep 2007 19:37:21 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IVY1Z-0000ZI-Ha@lionel-hutz.w3.org>

Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv2156

Modified Files:
	ws-policy-guidelines.xml 
Log Message:
Implemented the resolution for issue 5041. Editors' action: 356. 

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -d -r1.114 -r1.115
--- ws-policy-guidelines.xml	23 Aug 2007 01:53:04 -0000	1.114
+++ ws-policy-guidelines.xml	12 Sep 2007 19:37:18 -0000	1.115
@@ -86,7 +86,7 @@
         <head>Introduction</head>
       
         <p>The WS-Policy specification defines a policy to be a collection
-        of policy alternatives. Each policy alternative a
+        of policy alternatives. Each policy alternative is a
         collection of policy assertions. The &framework.title; provides a flexible framework to 
         represent
         consistent combinations of behaviors from a variety of domains.
@@ -427,7 +427,7 @@
 				<p>
 				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 and, a set of valid policy subjects to which the assertion
+				of the assertion’s semantics and a set of valid policy subjects to which the assertion
 				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,
@@ -470,7 +470,7 @@
 				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 
+				subject. For instance, an assertion "Foo" has the same semantics 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 
@@ -622,11 +622,11 @@
          		<div3 id="minimal-approach">
           			<head>Minimal approach</head>
 					<p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
-        		 	behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
+        		 	behavior. Sets of assertions can by grouped by an operator "All". This indicates that there is a relationship between
          			the assertions. 
          			</p>
          			<p>If grouping is utilized, choices between such groupings can be indicated by
-         			an "exactly one" operator. This basic set of operators allows
+         			an "ExactlyOne" operator. This basic set of operators allows
          			Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.
          			</p>
 					<p>It requires a good deal of effort to evaluate the
@@ -1100,7 +1100,7 @@
 				<div3>
 				<head>Ignorable behavior in authoring</head>
      			<p>  
-     			The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict).  The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives.  [see <bibref ref="WS-Policy"/> and <bibref ref="WS-Policy-Primer"/>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <specref ref="DefineIgnorable"/> and <specref ref="ignorableAssertions"/> to include this guidance in the assertion's definition.</p>
+     			The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict).  The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatibility assessment between two alternatives.  [see <bibref ref="WS-Policy"/> and <bibref ref="WS-Policy-Primer"/>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <specref ref="DefineIgnorable"/> and <specref ref="ignorableAssertions"/> to include this guidance in the assertion's definition.</p>
 			</div3> 
 				<div3>
 				<head>Ignorable behavior at runtime</head>
@@ -1122,9 +1122,6 @@
 		
 			<div3>
 				<head>Optional behavior at runtime</head>
-				<ednote>
-<edtext>This section does not have Working Group consensus and there is an outstanding action item to revise it</edtext>
-</ednote>
 				<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
@@ -1534,7 +1531,7 @@
 					Section 4.2, the <code>sp:issuedToken</code> assertion utilizes the
 					<code>sp:RequestSecurityTokenTemplate</code> parameter that contains necessary
 					information to request a security token. The contents of the parameter
-					are static and allows reuse in different security scenerios.</p>
+					are static and allow reuse in different security scenarios.</p>
 			</div2>
 			<div2 id="extending-assertions">
 					<head> Evolution of Assertions (Versioning and Compatibility)</head>
@@ -1846,8 +1843,8 @@
 	</bibl>
         <bibl id="SAWSDL" key="SAWSDL"
           href="http://www.w3.org/TR/sawsdl/">
-          <titleref>Semantic Annotations for WSDL and XML Schema</titleref> Joel Farrell, Holger          Lausen, Editors. World Wide Web Consortium, 26 January 2007. This version of the
-          specification is at http://www.w3.org/TR/sawsdl. The <loc href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</loc> is available at
+          <titleref>Semantic Annotations for WSDL and XML Schema</titleref> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, 28 Augusty 2007. This is a W3C recommendation and the
+        	specification can be found at http://www.w3.org/TR/2007/REC-sawsdl-20070828/. The <loc href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</loc> is available at
           http://www.w3.org/TR/sawsdl/.</bibl>
 				<bibl key="XML Schema Datatypes" id="XMLSchemaPart2" href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">
 					<titleref>XML Schema Part 2: Datatypes Second
@@ -2674,10 +2671,19 @@
 						</td>
 					</tr> 
 				  <tr>
-          <td>20070806</td>
-          <td>FS</td>
-          <td>Updated references for draft publication.</td>
-         </tr>  
+          				<td>20070806</td>
+          				<td>FS</td>
+          				<td>Updated references for draft publication.</td>
+         		  </tr>
+					<tr>
+						<td>20070912</td>
+						<td>PY</td>
+						<td>Implemented the resolution for issue 
+							<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5041">5041</loc>. 
+							Editors' action: 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">356</loc>.
+						</td>
+					</tr>
 				</tbody>
 			</table>
 		</inform-div1>
Received on Wednesday, 12 September 2007 19:37:31 GMT

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