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

2006/ws/policy ws-policy-primer.html,1.64,1.65

From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 12 Sep 2007 19:12:13 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IVXdF-0005tV-Ep@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-primer.html 
Log Message:
Implemented the resolution for issue 5036. Editors' action 355. 

Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -d -r1.64 -r1.65
--- ws-policy-primer.html	23 Aug 2007 01:53:04 -0000	1.64
+++ ws-policy-primer.html	12 Sep 2007 19:12:11 -0000	1.65
@@ -95,7 +95,7 @@
 &nbsp;&nbsp;&nbsp;&nbsp;3.7 <a href="#combine-policies">Combine Policies</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href="#d3e1405">Policy Expressions</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href="#d3e1411">Policy Expressions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.3 <a href="#ignorable-and-versioning">Use of Ignorable attribute and an alternative Versioning Scenario</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.4 <a href="#ignorable-and-optional-and-versioning">Use of Ignorable and Optional attributes</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
@@ -164,8 +164,8 @@
           determine the compatibility of policies, to name and reference policies and to associate
           policies with Web service metadata constructs such as service, endpoint and operation. Web
           Services Policy is a simple language that has four elements - <code>Policy, All</code>,
-            <code>ExactlyOne</code> and <code>PolicyReference</code> - and one attribute -
-            <code>wsp:Optional</code>.</p></div><div class="div2">
+            <code>ExactlyOne</code> and <code>PolicyReference</code> - and two attributes -
+          <code>wsp:Optional</code> and <code>wsp:Ignorable</code>.</p></div><div class="div2">
 <h3><a name="simple-message" id="simple-message"></a>2.2 Simple Message</h3><p>Let us start by considering a SOAP Message in the example below.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-1. </span>SOAP Message</i></p><div class="exampleInner"><pre>&lt;soap:Envelope&gt;
   &lt;soap:Header&gt;
@@ -203,7 +203,7 @@
 &lt;/Policy&gt;</pre></div></div><p>
           The policy expression in the above example consists of a Policy main  
           element and a child element wsam:Addressing. Child elements of  
-          the Policy element are policy assertions. Company-X attaches the above  
+          the Policy element that are not from the Policy namespace are policy assertions. Company-X attaches the above  
           policy expression to a WSDL binding description.
           </p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Policy Expression Attached to Binding</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" &gt;
@@ -397,7 +397,7 @@
           </p></div><div class="div2">
 <h3><a name="Both-Optional-Ignorable" id="Both-Optional-Ignorable"></a>2.8 Marking Assertions both Optional and Ignorable</h3><p>As described in the sections above and in Section <a href="#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy Intersection</b></a>, 
         the WS-Policy 1.5 specification defines two 
-        attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both "optional" 
+        attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both "Optional" 
         and "Ignorable" attributes simultaneously. The presence of "@wsp:optional=true" on an assertion 
         is a syntactic compact form for two alternatives in normal form, one with the assertion 
         and the other without the assertion. Hence syntactically marking an assertion "A" with both the 
@@ -491,7 +491,7 @@
           inline the policy expression.
         </p><p>A policy expression may be identified by an IRI and referenced for re-use as a standalone
           policy or within another policy expression. There are three mechanisms to identify a policy
-          expression: the <code>wsu:Id</code> <code>xml:id</code> and <code>Name</code> attributes. A
+          expression: the <code>wsu:Id</code>, <code>xml:id</code> and <code>Name</code> attributes. A
             <code>PolicyReference</code> element can be used to reference a policy expression
           identified using either of these mechanisms.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”common”&gt;
@@ -550,12 +550,12 @@
           assertions from different domains are used in a policy expression,
           complex expressions will emerge. Naming parts of complex expressions for
           reuse and building more complex policies through referencing enables
-          building more complicated policy scenerios easily. This approach enables
+          building more complicated policy scenarios easily. This approach enables
           the association of additional policy subjects to identified policy
           expressions.  It also promotes manageability of the expressions as they
-          are uniquely identified and allows profiles for common scenerios to be
+          are uniquely identified and allows profiles for common scenarios to be
           developed. Note that when a named expression has assertions that
-          contains parametrized expressions, care must be given to ensure that the
+          contains parameterized expressions, care must be given to ensure that the
           parameterized content is statically available to enable reuse.</p></div><div class="div2">
 <h3><a name="attaching-policy-expressions-to-wsdl" id="attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy Expressions to WSDL</h3><p>A majority of Company-X’s customers use WSDL for building their client applications.
           Company-X leverages this usage by attaching policy expressions to the WSDL binding
@@ -609,7 +609,7 @@
           tool and hidden from these Web service developers.</p></div><div class="div2">
 <h3><a name="policy-automates-web-services-interaction" id="policy-automates-web-services-interaction"></a>2.12 Policy Automates Web Services Interaction</h3><p>As you have seen, Web Services Policy is a simple language that has four elements -
             <code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
-          one attribute - <code>wsp:Optional</code>. In practice, service providers, like Company-X,
+          two attributes - <code>wsp:Optional</code> and <code>wsp:Ignorable</code>. In practice, service providers, like Company-X,
           use policy expressions to represent combinations of capabilities and requirements. Web
           service developers use policy-aware clients that understand policy expressions
           and engage the behaviors represented by providers automatically. A sizable amount of
@@ -705,8 +705,8 @@
           policy expression in the normal form. As you can see, the compact form is less verbose
           than the normal form. The normal form represents a policy as a collection of policy
           alternatives. Each of the <code>All</code> operators is a policy alternative. There are
-          four policy alternatives in the normal form. These alternatives map to bullets (a) through
-          (d) above.</p><div class="exampleOuter">
+          four policy alternatives in the normal form. These alternatives map to list items (1) through
+          (4) above.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Company-X’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (a) --&gt;
@@ -740,7 +740,7 @@
 <h3><a name="policy-data-model" id="policy-data-model"></a>3.3 Policy Data Model</h3><p>In the previous section, we considered the normal form for policy expressions. As we
           discussed, the normal form represents a policy as a collection of policy alternatives. In
           this section, let us look at the policy data model.</p><p>Company-X uses a policy to convey the conditions for an interaction. Policy-aware clients,
-          like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view policy as an unordered collection of
+          like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view a policy as an unordered collection of
           zero or more policy alternatives. A policy alternative is an unordered collection of zero
           or more policy assertions. A policy alternative represents a collection of behaviors or
           requirements or conditions for an interaction. In simple words, each policy alternative
@@ -765,7 +765,6 @@
           are the assertion parameters. For example @wsp:Optional and @wsp:Ignorable are not assertion parameters.</p><p>We considered nested policy expressions in the context of a security usage scenario. Let
           us look at its shape in the policy data model. A nested policy expression is a policy expression that is 
           a child element of an
-
           assertion. In the normal form, a nested policy expression has at most one
           policy alternative. The policy alternative in a nested policy expression
           represents a collection of associated or dependent behaviors, requirements or
@@ -836,7 +835,7 @@
           conform to a standard policy. For example, a major retailer might require all their
           supplier endpoints to be compatible with an agreed upon policy.</p><div class="div3">
 <h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
-            The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the 
+            The previous sections outlined how the normal-form of a policy expression relates to the policy data model and how the 
             compatibility of requester and provider policies may be determined.  
             This section outlines how ignorable assertions may impact the process of determining compatibility.
           </p><p>
@@ -1011,7 +1010,7 @@
           and treats unknown children of the <code>Policy</code>, <code>ExactlyOne</code>, <code>All</code> 
           elements as policy assertions. The child elements of <code>wsp:PolicyReference</code> are ignored. 
           </p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p></div><div class="div3">
-<h4><a name="d3e1405" id="d3e1405"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
+<h4><a name="d3e1411" id="d3e1411"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
           continue the use of older policy alternatives in a backward compatible manner. This
           versioning practice allows service providers, like Company-X, to deploy new behaviors using additional (or new) policy
           assertions without breaking compatibility with clients that rely on any older policy
@@ -1157,7 +1156,7 @@
           priority, effective dating, negotiation. </p><p>WS-Policy provides extensibility points on 6 elements with a combination of attribute and/or element extensibility.  
           The possible extensibility points are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and any element</p></li><li><p>ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment:  element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div2">
 <h3><a name="versioning-policy-framework" id="versioning-policy-framework"></a>4.1 Policy Framework</h3><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy, 
-          ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false". 
+          ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional is "false". 
           After normalization, such an element will be inside an ExactlyOne/All operator.  </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace.  We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 4-1. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;wsp:ExactlyOne&gt;
@@ -1303,7 +1302,7 @@
             </td><td rowspan="1" colspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
               <code>wsam</code>
             </td><td rowspan="1" colspan="1">
-              <code>http://www.w3.org/2007/05/addressing/metadata</code>
+              <code>http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/</code>
             </td><td rowspan="1" colspan="1">[<cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
               <code>wsdl</code>
             </td><td rowspan="1" colspan="1">
@@ -1355,10 +1354,10 @@
           Addressing 1.0 - Core Recommendation is
           http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
             - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WS-AddressingMetadata"></a>[WS-Addressing Metadata] </dt><dd>
-          <cite><a href="http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
+          <cite><a href="http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
           Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 31 July 2007. This is a work in progress. This version of
           the Web Services Addressing 1.0 - Metadata is
-          http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/. The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
+          http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
             Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. </dd><dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
           <cite><a href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic Transaction</a></cite>, L. P. Cabrera, et al, Authors.
           Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc., 
@@ -1438,7 +1437,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.
@@ -1603,4 +1602,7 @@
             <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857">4857</a>. Editors' action 
               <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</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=5036">5036</a>. Editors' action 
+              <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">355</a>.
+            </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 12 September 2007 19:12:18 GMT

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