2006/ws/policy ws-policy-guidelines.html,1.98,1.99

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

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

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.98
retrieving revision 1.99
diff -u -d -r1.98 -r1.99
--- ws-policy-guidelines.html	23 Aug 2007 01:53:04 -0000	1.98
+++ ws-policy-guidelines.html	12 Sep 2007 19:38:04 -0000	1.99
@@ -114,7 +114,7 @@
 F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br>
 </p></div><hr><div class="body"><div class="div1">
 <h2><a name="introduction" id="introduction"></a>1. Introduction</h2><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 Web Services Policy 1.5 - Framework provides a flexible framework to 
         represent
         consistent combinations of behaviors from a variety of domains.
@@ -334,7 +334,7 @@
 				</p><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,
@@ -366,7 +366,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 
@@ -485,10 +485,10 @@
          		and capabilities at runtime.
          		</p><div class="div3">
 <h4><a name="minimal-approach" id="minimal-approach"></a>5.3.1 Minimal approach</h4><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
          			capabilities of a domain and capture them in a way that
@@ -816,7 +816,7 @@
 						of intersection algorithm alone.</p></div></div><div class="div2">
 <h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
 <h4><a name="d3e803" id="d3e803"></a>5.5.1 Ignorable behavior in authoring</h4><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 <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. 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 <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable 
+     			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 <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. 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 <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable 
 Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
 <h4><a name="d3e816" id="d3e816"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
 			  	indicate the semantic of the runtime behavior in the description of the assertion.
@@ -824,7 +824,7 @@
 As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion. 
 			  	</p></div></div><div class="div2">
 <h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e831" id="d3e831"></a>5.6.1 Optional behavior at runtime</h4><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%">&nbsp;</td></tr><tr><td colspan="2" align="left" valign="top">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e831" id="d3e831"></a>5.6.1 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
@@ -1102,7 +1102,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></div><div class="div2">
+					are static and allow reuse in different security scenarios.</p></div><div class="div2">
 <h3><a name="extending-assertions" id="extending-assertions"></a>6.2  Evolution of Assertions (Versioning and Compatibility)</h3><p>Over time, there may be multiple equivalent behaviors emerging in the Web
            			Service interaction space. Examples of such multiple equivalent behaviors are WSS: SOAP Message Security 1.0
            			vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
@@ -1291,8 +1291,8 @@
 	  the UDDI 3.0</a> specification is available at
 	  http://uddi.org/pubs/uddi_v3.htm.
 	</dd><dt class="label"><a name="SAWSDL"></a>[SAWSDL] </dt><dd>
-          <cite><a href="http://www.w3.org/TR/sawsdl/">Semantic Annotations for WSDL and XML Schema</a></cite> 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 <a href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</a> is available at
+          <cite><a href="http://www.w3.org/TR/sawsdl/">Semantic Annotations for WSDL and XML Schema</a></cite> 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 <a href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</a> is available at
           http://www.w3.org/TR/sawsdl/.</dd><dt class="label"><a name="XMLSchemaPart2"></a>[XML Schema Datatypes] </dt><dd>
 					<cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second
 						Edition</a></cite>, P. Byron and A. Malhotra, Editors. World
@@ -1315,7 +1315,7 @@
   Working Group</a>.</p><p>
     Members of the Working Group are (at the time of writing, and by
     alphabetical order):
-      Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+      Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).
   </p><p>
     Previous members of the Working Group were:
       Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.
@@ -1604,4 +1604,8 @@
 							Editors' action: 
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</a>.
 						</td></tr><tr><td rowspan="1" colspan="1">20070727</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated Section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
-						</td></tr><tr><td rowspan="1" colspan="1">20070806</td><td rowspan="1" colspan="1">FS</td><td rowspan="1" colspan="1">Updated references for draft publication.</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+						</td></tr><tr><td rowspan="1" colspan="1">20070806</td><td rowspan="1" colspan="1">FS</td><td rowspan="1" colspan="1">Updated references for draft publication.</td></tr><tr><td rowspan="1" colspan="1">20070912</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented the resolution for issue 
+							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5041">5041</a>. 
+							Editors' action: 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">356</a>.
+						</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file

Received on Wednesday, 12 September 2007 19:38:16 UTC