2006/ws/policy ws-policy-primer.html,1.20,1.21 ws-policy-primer.xml,1.16,1.17

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

Modified Files:
	ws-policy-primer.html ws-policy-primer.xml 
Log Message:
Implemented resolution for Issue 3815
Editors Action Item 55
Remove personal names from primer

Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- ws-policy-primer.html	21 Oct 2006 00:06:09 -0000	1.20
+++ ws-policy-primer.html	28 Oct 2006 05:24:19 -0000	1.21
@@ -129,24 +129,24 @@
           implied by this message respectively. (The prefix <code>wsa</code> is used here to denote
           the Web Services Addressing XML Namespace. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the
           namespaces and prefixes that are used in this document.)</p><p>Let us look at a fictitious scenario used in this document to illustrate the features of
-          the policy language. Tony is a Web service developer. He is building a client application
+          the policy language. A Web service developer is building a client application
           that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real
-          time data using Web services. Tony has Contoso’s advertised WSDL description of these Web
+          time data using Web services. The developer has Contoso’s advertised WSDL description of these Web
           services. Contoso requires the use of addressing headers for messaging. Just the WSDL
-          description is not sufficient for Tony to enable the interaction between his client and
+          description is not sufficient for the developer to enable the interaction between her client and
           these Web services. WSDL constructs do not indicate requirements such as the use of
           addressing.</p><p>(<em>The example companies, organizations, products, domain names, e-mail addresses,
             logos, people, places, and events depicted herein are fictitious. No association with
             any real company, organization, product, domain name, email address, logo, person,
             places, or events is intended or should be inferred.</em>)</p><p>Providers have the option to convey requirements, such as the use of addressing, through
           word-of-mouth and documentation – as they always have. To interact successfully with this
-          service, Tony may have to read any related documentation, call someone at Contoso to
+          service, the developer may have to read any related documentation, call someone at Contoso to
           understand the service metadata, or look at sample SOAP messages and infer such
           requirements or behaviors.</p><p>Web Services Policy is a machine-readable language for representing these Web service
           capabilities and requirements as policies. Policy makes it possible for providers to
           represent such capabilities and requirements in a machine-readable form. For example,
           Contoso may augment the service WSDL description with a policy that requires the use of
-          addressing. Tony can use a policy-aware client that understands this policy and engages
+          addressing. The client application developer can use a policy-aware client that understands this policy and engages
           addressing automatically.</p><p>How does Contoso use policy to represent the use of addressing? The example below
           illustrates a policy expression that requires the use of addressing.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-2. </span>Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;wsap:UsingAddressing /&gt;
@@ -191,7 +191,7 @@
           This assertion identifies the use of transport-level security – such as <code>HTTPS</code>
           - for protecting messages. Policy-aware clients can recognize this policy assertion,
           engage transport-level security for protecting messages and include security timestamps in
-          SOAP Envelopes.</p><p>Tony can use a policy-aware client that recognizes this policy expression and engages
+          SOAP Envelopes.</p><p>The client application developer can use a policy-aware client that recognizes this policy expression and engages
           both addressing and transport-level security automatically.</p><p>For the moment, let us set aside the contents of the <code>sp:TransportBinding</code>
           policy assertion and consider its details in a later section.</p></div><div class="div2">
 <h3><a name="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
@@ -203,7 +203,7 @@
           assertions and engage these behaviors automatically.</p><p>Providers, like Contoso, have the option to combine behaviors for an interaction from
           domains such as messaging, security, reliability and transactions. Using policy
           assertions, providers can represent these behaviors in a machine-readable form. Web
-          service developers, like Tony, can use policy-aware clients that recognize these
+          service developers can use policy-aware clients that recognize these
           assertions and engage these behaviors automatically.</p><p>Who defines policy assertions? Where are they? Policy assertions are defined by Web
           services developers, product designers, protocol authors and users. Like XML Schema
           libraries, policy assertions are a growing collection. Several WS-* protocol
@@ -293,7 +293,7 @@
             <code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
           security for protecting messages. Just indicating the use of transport-level security for
           protecting messages is not sufficient. To successfully interact with Contoso’s Web
-          services, Tony must know what transport token to use, what secure transport to use, what
+          services, the developer must know what transport token to use, what secure transport to use, what
           algorithm suite to use for performing cryptographic operations, etc. The
             <code>sp:TransportBinding</code> policy assertion can represent these dependent
           behaviors. In this section, let us look at how to capture these dependent behaviors in a
@@ -330,8 +330,8 @@
           assertion requires the use of the algorithm suite identified by its nested policy
           assertion (<code>sp:Basic256Rsa15</code>
           <em>in the example above</em>) and further qualifies the behavior of the
-            <code>sp:TransportBinding</code> policy assertion.</p><p>Setting aside the details of using transport-level security, Web service developers, like
-          Tony, can use a policy-aware client that recognizes this policy assertion and engages
+            <code>sp:TransportBinding</code> policy assertion.</p><p>Setting aside the details of using transport-level security, Web service developers
+        can use a policy-aware client that recognizes this policy assertion and engages
           transport-level security and its dependent behaviors automatically. That is, the
           complexity of security usage is absorbed by a policy-aware client and hidden from these
           Web service developers.</p></div><div class="div2">
@@ -425,8 +425,8 @@
           requirements. A policy aware client should not conclude anything (other than ‘no claims’)
           about the absence of policy expressions.</p><p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
           represent the capabilities and requirements of a Web service as policies. A WSDL document
-          may specify varying behaviors across Web service endpoints. Web service developers, like
-          Tony, can use a policy-aware client that recognizes these policy expressions in WSDL
+          may specify varying behaviors across Web service endpoints. Web service developers
+          can use a policy-aware client that recognizes these policy expressions in WSDL
           documents and engages behaviors automatically for each of these endpoints. Any complexity
           of varying behaviors across Web service endpoints is absorbed by a policy-aware client or
           tool and hidden from these Web service developers.</p></div><div class="div2">
@@ -434,7 +434,7 @@
             <code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
           one attribute - <code>wsp:Optional</code>. In practice, service providers, like Contoso,
           use policy expressions to represent combinations of capabilities and requirements. Web
-          service developers, like Tony, use policy-aware clients that understand policy expressions
+          service developers use policy-aware clients that understand policy expressions
           and engage the behaviors represented by providers automatically. A sizable amount of
           complexity is absorbed by policy-aware clients (or tools) and is invisible to these Web
           service developers.</p><p>Web Services Policy extends the foundation on which to build interoperable Web services,
@@ -568,7 +568,7 @@
 <h3><a name="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>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
-          like the one used by Tony (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 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
@@ -579,8 +579,8 @@
           choose exactly one of them for a successful Web service interaction. Clients may choose a
           different policy alternative for a subsequent interaction. It is important to understand
           that a policy is a useful piece of metadata in machine-readable form that enables tooling,
-          yet is not required for a successful Web service interaction. Why? Web service developers,
-          like Tony, could use the documentation, talk to the service providers, or look at message
+          yet is not required for a successful Web service interaction. Why? Web service developers
+          could use the documentation, talk to the service providers, or look at message
           traces to infer these conditions for an interaction. Developers continue to have these
           options, as they always had.</p><p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
           or condition. A policy assertion has a QName that identifies its behavior or requirement
@@ -606,7 +606,7 @@
               alternatives.</p></li><li><p>The <code>Policy</code> wrapper element and policy alternatives which correspond to
                 the <code>Policy/ExactlyOne</code> element map to a policy.</p></li></ul><p>The diagram below describes this mapping from the normal form of a policy expression to
           the policy data model.</p><div class="figure" style="text-align: center"><br><img src="normal-form-2-data-model.jpg" alt="Mapping from Normal Form to Policy Data Model"><p style="text-align:left"><i><span>Figure 3-2. </span>Mapping from Normal Form to Policy Data Model</i></p><br></div></div><div class="div2">
-<h3><a name="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Contoso, and a requester, like Tony’s policy-aware client, may represent
+<h3><a name="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
           their capabilities and requirements for an interaction as policies and want to limit their
           message exchanges to mutually compatible policies. Web Services Policy defines an
           intersection mechanism for selecting compatible policy alternatives when there are two or
@@ -622,23 +622,23 @@
     &lt;/All&gt;
     …
   &lt;/ExactlyOne&gt;
-&lt;/Policy&gt;</pre></div></div><p>Tony’s organization requires the use of addressing and transport-level security for any
-          interaction with Contoso’s Web services. Tony represents these behaviors using a policy
+&lt;/Policy&gt;</pre></div></div><p>The client application developer's organization requires the use of addressing and transport-level security for any
+          interaction with Contoso’s Web services. The developer represents these behaviors using a policy
           expression illustrated in the example below in normal form. This policy expression
           contains one policy alternative that requires the use of addressing and transport-level
-          security.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-7. </span>Tony’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+          security.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-7. </span>The Client Application's Policy Expression in Normal Form</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
-    &lt;All&gt; &lt;!-- - - - - - - - - - - - - -  Tony’s Policy Alternative --&gt;
+    &lt;All&gt; &lt;!-- - - - - - - - - - - - - -  Client’s Policy Alternative --&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) --&gt;
      &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) --&gt;
       &lt;wsap:UsingAddressing/&gt;
     &lt;/All&gt;
   &lt;/ExactlyOne&gt;
-&lt;/Policy&gt;</pre></div></div><p>Tony lets his policy-aware client select a compatible policy alternative in Contoso’s
+&lt;/Policy&gt;</pre></div></div><p>The developer lets her policy-aware client select a compatible policy alternative in Contoso’s
           policy. How does this client select a compatible policy alternative? It is simple – it
-          uses the policy intersection. That is, Tony’s policy-aware client uses these two policy
-          expressions (Tony’s and Contoso’s) and the policy intersection to select a compatible
+          uses the policy intersection. That is, the policy-aware client uses these two policy
+          expressions (the client’s and Contoso’s) and the policy intersection to select a compatible
           policy alternative for this interaction. Let us look at the details of policy
           intersection.</p><p>For two policy assertions to be compatible they must have the same QName. And, if either
           assertion has a nested policy, both assertions must have a nested policy and the nested
@@ -648,12 +648,12 @@
           they have the same QName and their nested policies are compatible.</p><p>Two policy alternatives are compatible if each policy assertion in one alternative is
           compatible with a policy assertion in the other and vice-versa. For example, policy
           assertions (c1) and (c2) in Contoso’s policy alternative are compatible with policy
-          assertions (t2) and (t1) in Tony’s policy alternative. Contoso’s policy alternative (a)
-          and Tony’s policy alternative are compatible because assertions in these two alternatives
+          assertions (t2) and (t1) in tje client’s policy alternative. Contoso’s policy alternative (a)
+          and the client’s policy alternative are compatible because assertions in these two alternatives
           are compatible.</p><p>Two policies are compatible if a policy alternative in one is compatible with a policy
           alternative in the other. For example, Contoso’s policy alternative (a) is compatible with
-          Tony’s policy alternative. Contoso’s policy and Tony’s policy are compatible because one
-          of Contoso’s policy alternative is compatible with Tony’s policy alternative.</p><p>For this interaction, Tony’s policy-aware client can use policy alternative (a) to
+          the client’s policy alternative. Contoso’s policy and the client’s policy are compatible because one
+          of Contoso’s policy alternative is compatible with the client’s policy alternative.</p><p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
           satisfy Contoso’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
           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><div class="div2">
@@ -1307,4 +1307,7 @@
             </td></tr><tr><td rowspan="1" colspan="1">20061020</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented resolution for Issue
               <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3827">3827.</a>
               Editors Action Item <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/56">56.</a>
+            </td></tr><tr><td rowspan="1" colspan="1">20061027</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Implemented resolution for Issue
+              <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3815">3815.</a>
+              Editors Action Item <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/55">55.</a>
             </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- ws-policy-primer.xml	21 Oct 2006 00:04:03 -0000	1.16
+++ ws-policy-primer.xml	28 Oct 2006 05:24:19 -0000	1.17
@@ -173,11 +173,11 @@
           the Web Services Addressing XML Namespace. <specref ref="xml-namespaces"/> lists all the
           namespaces and prefixes that are used in this document.)</p>
         <p>Let us look at a fictitious scenario used in this document to illustrate the features of
-          the policy language. Tony is a Web service developer. He is building a client application
+          the policy language. A Web service developer is building a client application
           that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real
-          time data using Web services. Tony has Contoso’s advertised WSDL description of these Web
+          time data using Web services. The developer has Contoso’s advertised WSDL description of these Web
           services. Contoso requires the use of addressing headers for messaging. Just the WSDL
-          description is not sufficient for Tony to enable the interaction between his client and
+          description is not sufficient for the developer to enable the interaction between her client and
           these Web services. WSDL constructs do not indicate requirements such as the use of
           addressing.</p>
         <p>(<emph>The example companies, organizations, products, domain names, e-mail addresses,
@@ -186,14 +186,14 @@
             places, or events is intended or should be inferred.</emph>)</p>
         <p>Providers have the option to convey requirements, such as the use of addressing, through
           word-of-mouth and documentation – as they always have. To interact successfully with this
-          service, Tony may have to read any related documentation, call someone at Contoso to
+          service, the developer may have to read any related documentation, call someone at Contoso to
           understand the service metadata, or look at sample SOAP messages and infer such
           requirements or behaviors.</p>
         <p>Web Services Policy is a machine-readable language for representing these Web service
           capabilities and requirements as policies. Policy makes it possible for providers to
           represent such capabilities and requirements in a machine-readable form. For example,
           Contoso may augment the service WSDL description with a policy that requires the use of
-          addressing. Tony can use a policy-aware client that understands this policy and engages
+          addressing. The client application developer can use a policy-aware client that understands this policy and engages
           addressing automatically.</p>
         <p>How does Contoso use policy to represent the use of addressing? The example below
           illustrates a policy expression that requires the use of addressing.</p>
@@ -261,7 +261,7 @@
           - for protecting messages. Policy-aware clients can recognize this policy assertion,
           engage transport-level security for protecting messages and include security timestamps in
           SOAP Envelopes.</p>
-        <p>Tony can use a policy-aware client that recognizes this policy expression and engages
+        <p>The client application developer can use a policy-aware client that recognizes this policy expression and engages
           both addressing and transport-level security automatically.</p>
         <p>For the moment, let us set aside the contents of the <code>sp:TransportBinding</code>
           policy assertion and consider its details in a later section.</p>
@@ -278,7 +278,7 @@
         <p>Providers, like Contoso, have the option to combine behaviors for an interaction from
           domains such as messaging, security, reliability and transactions. Using policy
           assertions, providers can represent these behaviors in a machine-readable form. Web
-          service developers, like Tony, can use policy-aware clients that recognize these
+          service developers can use policy-aware clients that recognize these
           assertions and engage these behaviors automatically.</p>
         <p>Who defines policy assertions? Where are they? Policy assertions are defined by Web
           services developers, product designers, protocol authors and users. Like XML Schema
@@ -437,7 +437,7 @@
             <code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
           security for protecting messages. Just indicating the use of transport-level security for
           protecting messages is not sufficient. To successfully interact with Contoso’s Web
-          services, Tony must know what transport token to use, what secure transport to use, what
+          services, the developer must know what transport token to use, what secure transport to use, what
           algorithm suite to use for performing cryptographic operations, etc. The
             <code>sp:TransportBinding</code> policy assertion can represent these dependent
           behaviors. In this section, let us look at how to capture these dependent behaviors in a
@@ -483,8 +483,8 @@
           assertion (<code>sp:Basic256Rsa15</code>
           <emph>in the example above</emph>) and further qualifies the behavior of the
             <code>sp:TransportBinding</code> policy assertion.</p>
-        <p>Setting aside the details of using transport-level security, Web service developers, like
-          Tony, can use a policy-aware client that recognizes this policy assertion and engages
+        <p>Setting aside the details of using transport-level security, Web service developers
+        can use a policy-aware client that recognizes this policy assertion and engages
           transport-level security and its dependent behaviors automatically. That is, the
           complexity of security usage is absorbed by a policy-aware client and hidden from these
           Web service developers.</p>
@@ -624,8 +624,8 @@
           about the absence of policy expressions.</p>
         <p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
           represent the capabilities and requirements of a Web service as policies. A WSDL document
-          may specify varying behaviors across Web service endpoints. Web service developers, like
-          Tony, can use a policy-aware client that recognizes these policy expressions in WSDL
+          may specify varying behaviors across Web service endpoints. Web service developers
+          can use a policy-aware client that recognizes these policy expressions in WSDL
           documents and engages behaviors automatically for each of these endpoints. Any complexity
           of varying behaviors across Web service endpoints is absorbed by a policy-aware client or
           tool and hidden from these Web service developers.</p>
@@ -636,7 +636,7 @@
             <code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
           one attribute - <code>wsp:Optional</code>. In practice, service providers, like Contoso,
           use policy expressions to represent combinations of capabilities and requirements. Web
-          service developers, like Tony, use policy-aware clients that understand policy expressions
+          service developers use policy-aware clients that understand policy expressions
           and engage the behaviors represented by providers automatically. A sizable amount of
           complexity is absorbed by policy-aware clients (or tools) and is invisible to these Web
           service developers.</p>
@@ -867,7 +867,7 @@
           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>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
-          like the one used by Tony (as explained earlier in <specref
+          like the one used by the developer in our example (as explained earlier in <specref
             ref="basic-concepts-policy-expression"/>), view 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
@@ -881,8 +881,8 @@
           choose exactly one of them for a successful Web service interaction. Clients may choose a
           different policy alternative for a subsequent interaction. It is important to understand
           that a policy is a useful piece of metadata in machine-readable form that enables tooling,
-          yet is not required for a successful Web service interaction. Why? Web service developers,
-          like Tony, could use the documentation, talk to the service providers, or look at message
+          yet is not required for a successful Web service interaction. Why? Web service developers
+          could use the documentation, talk to the service providers, or look at message
           traces to infer these conditions for an interaction. Developers continue to have these
           options, as they always had.</p>
         <p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
@@ -933,7 +933,7 @@
       </div2>
       <div2 id="compatible-policies">
         <head>Compatible Policies</head>
-        <p>A provider, like Contoso, and a requester, like Tony’s policy-aware client, may represent
+        <p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
           their capabilities and requirements for an interaction as policies and want to limit their
           message exchanges to mutually compatible policies. Web Services Policy defines an
           intersection mechanism for selecting compatible policy alternatives when there are two or
@@ -956,16 +956,16 @@
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <p>Tony’s organization requires the use of addressing and transport-level security for any
-          interaction with Contoso’s Web services. Tony represents these behaviors using a policy
+        <p>The client application developer's organization requires the use of addressing and transport-level security for any
+          interaction with Contoso’s Web services. The developer represents these behaviors using a policy
           expression illustrated in the example below in normal form. This policy expression
           contains one policy alternative that requires the use of addressing and transport-level
           security.</p>
         <example>
-          <head>Tony’s Policy Expression in Normal Form</head>
+          <head>The Client Application's Policy Expression in Normal Form</head>
           <eg xml:space="preserve">&lt;Policy&gt;
   &lt;ExactlyOne&gt;
-    &lt;All&gt; &lt;!-- - - - - - - - - - - - - -  Tony’s Policy Alternative --&gt;
+    &lt;All&gt; &lt;!-- - - - - - - - - - - - - -  Client’s Policy Alternative --&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) --&gt;
      &lt;sp:TransportBinding&gt;&hellip;&lt;/sp:TransportBinding&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) --&gt;
@@ -974,10 +974,10 @@
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <p>Tony lets his policy-aware client select a compatible policy alternative in Contoso’s
+        <p>The developer lets her policy-aware client select a compatible policy alternative in Contoso’s
           policy. How does this client select a compatible policy alternative? It is simple – it
-          uses the policy intersection. That is, Tony’s policy-aware client uses these two policy
-          expressions (Tony’s and Contoso’s) and the policy intersection to select a compatible
+          uses the policy intersection. That is, the policy-aware client uses these two policy
+          expressions (the client’s and Contoso’s) and the policy intersection to select a compatible
           policy alternative for this interaction. Let us look at the details of policy
           intersection.</p>
         <p>For two policy assertions to be compatible they must have the same QName. And, if either
@@ -989,14 +989,14 @@
         <p>Two policy alternatives are compatible if each policy assertion in one alternative is
           compatible with a policy assertion in the other and vice-versa. For example, policy
           assertions (c1) and (c2) in Contoso’s policy alternative are compatible with policy
-          assertions (t2) and (t1) in Tony’s policy alternative. Contoso’s policy alternative (a)
-          and Tony’s policy alternative are compatible because assertions in these two alternatives
+          assertions (t2) and (t1) in tje client’s policy alternative. Contoso’s policy alternative (a)
+          and the client’s policy alternative are compatible because assertions in these two alternatives
           are compatible.</p>
         <p>Two policies are compatible if a policy alternative in one is compatible with a policy
           alternative in the other. For example, Contoso’s policy alternative (a) is compatible with
-          Tony’s policy alternative. Contoso’s policy and Tony’s policy are compatible because one
-          of Contoso’s policy alternative is compatible with Tony’s policy alternative.</p>
-        <p>For this interaction, Tony’s policy-aware client can use policy alternative (a) to
+          the client’s policy alternative. Contoso’s policy and the client’s policy are compatible because one
+          of Contoso’s policy alternative is compatible with the client’s policy alternative.</p>
+        <p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
           satisfy Contoso’s conditions or requirements.</p>
         <p>Similarly, policy intersection can be used to check if providers expose endpoints that
           conform to a standard policy. For example, a major retailer might require all their
@@ -2143,6 +2143,14 @@
               Editors Action Item <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/56">56.</loc>
             </td>
           </tr>
+          <tr>
+            <td>20061027</td>
+            <td>TIB</td>
+            <td>Implemented resolution for Issue
+              <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3815">3815.</loc>
+              Editors Action Item <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/55">55.</loc>
+            </td>
+          </tr>
         </tbody>
       </table>
     </inform-div1>

Received on Saturday, 28 October 2006 05:24:35 UTC