2006/ws/policy wsdl11elementidentifiers-diff20070131.html,NONE,1.1 wsdl11elementidentifiers-diff20070131.xml,NONE,1.1 wsdl11elementidentifiers-tr20070131.xml,NONE,1.1 build.xml,1.25,1.26 entities.dtd,1.18,1.19 entitiesedcopy.dtd,1.8,1.9 entitieswd.dtd,1.9,1.10 ws-policy-attachment-diff20070228.html,1.1,1.2 ws-policy-attachment-diff20070228.xml,1.1,1.2 ws-policy-attachment-tr20070228.xml,1.1,1.2 ws-policy-attachment.xml,1.95,1.96 ws-policy-framework-diff20070228.html,1.1,1.2 ws-policy-framework-diff20070228.xml,1.1,1.2 ws-policy-framework-tr20070228.xml,1.1,1.2 ws-policy-framework.xml,1.127,1.128 ws-policy-guidelines-diff20061221.html,1.2,1.3 ws-policy-guidelines-diff20061221.xml,1.2,1.3 ws-policy-guidelines.xml,1.48,1.49 ws-policy-primer-diff20061221.html,1.2,1.3 ws-policy-primer-diff20061221.xml,1.2,1.3 ws-policy-primer.xml,1.45,1.46 wsdl11elementidentifiers.xml,1.17,1.18

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

Modified Files:
	build.xml entities.dtd entitiesedcopy.dtd entitieswd.dtd 
	ws-policy-attachment-diff20070228.html 
	ws-policy-attachment-diff20070228.xml 
	ws-policy-attachment-tr20070228.xml ws-policy-attachment.xml 
	ws-policy-framework-diff20070228.html 
	ws-policy-framework-diff20070228.xml 
	ws-policy-framework-tr20070228.xml ws-policy-framework.xml 
	ws-policy-guidelines-diff20061221.html 
	ws-policy-guidelines-diff20061221.xml ws-policy-guidelines.xml 
	ws-policy-primer-diff20061221.html 
	ws-policy-primer-diff20061221.xml ws-policy-primer.xml 
	wsdl11elementidentifiers.xml 
Added Files:
	wsdl11elementidentifiers-diff20070131.html 
	wsdl11elementidentifiers-diff20070131.xml 
	wsdl11elementidentifiers-tr20070131.xml 
Log Message:
Updated entities and previous published WDs for diff generation. Added wsdl11ei to diff task in build.xml . Generated diffs.

Index: ws-policy-attachment-diff20070228.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment-diff20070228.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-attachment-diff20070228.html	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-attachment-diff20070228.html	22 Mar 2007 07:11:39 -0000	1.2
@@ -78,7 +78,7 @@
 <h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
 <a href="ws-policy-attachment.html">ws-policy-attachment.html</a>
 </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
-            <a href="http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117">http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117</a>
+            <div class="diff-chg"><a href="http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/"><span class="diff-chg"><span>http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/</span></span></a></div>
         </dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark/a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
 <h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
 	This specification, Web Services Policy 1.5 - Attachment, defines two
@@ -132,9 +132,9 @@
 &nbsp;&nbsp;&nbsp;&nbsp;6.4 <a href="#RegisteringPoliciesUDDIVersion3">Registering Policies in UDDI Version 3</a><br>
 7. <a href="#SecurityConsiderations">Security Considerations</a><br>
 8. <a href="#Conformance">Conformance</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;8.1 <a href="#d2e4049">External Policy Attachment Conformance</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;8.2 <a href="#d2e4062">WSDL 1.1 Attachment Conformance</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;8.3 <a href="#d2e4071">WSDL 2.0 Attachment Conformance</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;8.1 <a href="#d2e4058">External Policy Attachment Conformance</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;8.2 <a href="#d2e4071">WSDL 1.1 Attachment Conformance</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;8.3 <a href="#d2e4080">WSDL 2.0 Attachment Conformance</a><br>
 </p>
 <h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#References">References</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;A.1 <a href="#Normative-References">Normative References</a><br>
@@ -289,11 +289,11 @@
       </dt><dd><p>The
 	<b>element policy</b> is the <a title="" href="#policy">policy</a> attached to the <a title="" href="#policy_subject">policy subjects</a> associated with
 	the element information item that contains it.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#ignorable_policy_assertion">ignorable policy assertion</a>
-      </dt><dd><p id="ignorable_policy_assertion">An 
-	    <b>ignorable policy assertion</b> is 
-	    an assertion that may be ignored for policy intersection (as defined in 
-	        <a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection">4.5 Policy Intersection</a>).</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#ignorable_policy_assertion">ignorable policy assertion</a>
+      </dt><dd><p id="ignorable_policy_assertion">An
+                            <b>ignorable policy assertion</b> is an assertion that may be
+                        ignored for policy intersection (as defined in <a href="http://www.w3.org/TR/ws-policy#Policy_Intersection">4.5 Policy
+                            Intersection</a>).</p></dd><dt class="label">
          <a href="#merge">merge</a>
       </dt><dd><p>A <b>merge</b>
 	consists of serializing each policy as a
@@ -302,30 +302,32 @@
 	<code>wsp:All</code> element, and placing each as
 	children of a wrapper <code>wsp:Policy</code>
 	element.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy">policy</a>
-      </dt><dd><p id="policy">A <b>policy</b> is a potentially empty collection of 
-	    <a title="" href="#policy_alternative">policy alternatives</a>. </p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_alternative">policy alternative</a>
-      </dt><dd><p id="policy_alternative">A <b>policy alternative</b> 
-	    is a potentially empty collection of <a title="" href="#policy_assertion">policy assertions</a>.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_assertion">policy assertion</a>
-      </dt><dd><p id="policy_assertion">A <b>policy assertion</b> 
-		represents a requirement, a capability, or other property of a behavior.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_attachment">policy attachment</a>
-      </dt><dd><p id="policy_attachment">A 
-	    <b>policy attachment</b> is a mechanism for associating 
-	    <a title="" href="#policy">policy</a> with one or more <a title="" href="#policy_scope">policy scopes</a>.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_expression">policy expression</a>
-      </dt><dd><p id="policy_expression">A <b>policy expression</b> 
-		is an XML Infoset representation of a <a title="" href="#policy">policy</a>, 
-		either in a normal form or in an equivalent compact form.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_scope">policy scope</a>
-      </dt><dd><p id="policy_scope">A <b>policy scope</b> is a collection of 
-	    <a title="" href="#policy_subject">policy subjects</a> to which a policy may apply.</p></dd><dt class="label">
-         <a href="ws-policy-framework.html#policy_subject">policy subject</a>
-      </dt><dd><p id="policy_subject">A <b>policy subject</b> is an entity 
-	    (e.g., an endpoint, message, resource, operation) with which a 
-	    <a title="" href="#policy">policy</a> can be associated. </p></dd></dl><ul><li><p>ignorable_policy_assertion</p></li><li><p>policy</p></li><li><p>policy_alternative</p></li><li><p>policy_assertion</p></li><li><p>policy_expression</p></li><li><p>policy_subject</p></li><li><p>policy_scope</p></li><li><p>policy_attachment</p></li></ul></div><div class="div2">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy">policy</a>
+      </dt><dd><p id="policy">A <b>policy</b> is a potentially empty
+                        collection of <a title="" href="#policy_alternative">policy
+                        alternatives</a>. </p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_alternative">policy alternative</a>
+      </dt><dd><p id="policy_alternative">A <b>policy
+                            alternative</b> is a potentially empty collection of <a title="" href="#policy_assertion">policy assertions</a>.</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_assertion">policy assertion</a>
+      </dt><dd><p id="policy_assertion">A <b>policy
+                        assertion</b> represents a requirement, a capability, or other property
+                        of a behavior.</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_attachment">policy attachment</a>
+      </dt><dd><p id="policy_attachment">A <b>policy
+                                        attachment</b> is a mechanism for associating <a title="" href="#policy">policy</a> with one or more <a title="" href="#policy_scope">policy scopes</a>.</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_expression">policy expression</a>
+      </dt><dd><p id="policy_expression">A <b>policy expression</b>
+                    is an XML Infoset representation of a <a title="" href="#policy">policy</a>,
+                    either in a normal form or in an equivalent compact form.</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_scope">policy scope</a>
+      </dt><dd><p id="policy_scope">A <b>policy
+                                    scope</b> is a collection of <a title="" href="#policy_subject">policy subjects</a> to which a policy may
+                                apply.</p></dd><dt class="label">
+         <a href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_subject">policy subject</a>
+      </dt><dd><p id="policy_subject">A <b>policy subject</b> is
+                        an entity (e.g., an endpoint, message, resource, operation) with which a
+                            <a title="" href="#policy">policy</a> can be associated. </p></dd></dl><ul><li><p>ignorable_policy_assertion</p></li><li><p>policy</p></li><li><p>policy_alternative</p></li><li><p>policy_assertion</p></li><li><p>policy_expression</p></li><li><p>policy_subject</p></li><li><p>policy_scope</p></li><li><p>policy_attachment</p></li></ul></div><div class="div2">
 <h3><a name="Example" id="Example"></a>2.4 Example</h3><p>This specification defines several mechanisms for
 	associating policies (Web Services Policy 1.5 - Framework, [<a href="#WS-Policy">[Web Services Policy Framework]</a>]) with various XML Web service entities. For
 	brevity, we define two sample <a title="" href="#policy_expression">policy expressions</a> that the
@@ -1315,7 +1317,7 @@
 pre-defines one tModel that is used to associate a remotely accessible
 <a title="" href="#policy">policy</a> with an entity in a UDDI registry.</p><p>This new tModel is called the remote policy reference category
 system and is defined in Appendix <a href="#RemotePolicyReferenceCategorySystem"><b>B.1 Remote Policy Reference Category System</b></a>.</p><p>UDDI registries <span class="rfc2119">MUST</span> use the (UDDI V2 [<a href="#UDDIDataStructure20">[UDDI Data Structure 2.0]</a>]) <code>tModelKey</code>
-<code>uuid:a27078e4-fd38-320a-806f-6749e84f8005</code> to uniquely identify this
+<code><span class="diff-chg"><span>uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1</span></span></code> to uniquely identify this
 tModel so that UDDI registry users can expect the same behavior across
 different UDDI registries.</p><p>The tModel's valid values are those IRIs that identify external
 <a title="" href="#policy_expression">policy expressions</a>; that is, when referencing this category system in
@@ -1333,7 +1335,7 @@
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp; &nbsp;keyName="Policy Expression for example's Web services"
 &nbsp; &nbsp; &nbsp; &nbsp;keyValue="http://www.example.com/myservice/policy"
-&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /&gt;
+&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" /&gt;
 &nbsp; &lt;/categoryBag&gt;
 &lt;/businessService&gt;</span></span></pre></div><p>The <code>tModelKey</code> of the <code>keyedReference</code>
 <span class="rfc2119">MUST</span> match
@@ -1348,7 +1350,7 @@
 &nbsp; &lt;accessPoint&gt;…&lt;/accessPoint&gt;
 &nbsp; &lt;tModelInstanceDetails&gt;
 &nbsp; &nbsp; &lt;tModelInstanceInfo
-&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" &gt;
+&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" &gt;
 &nbsp; &nbsp; &nbsp; &lt;instanceDetails&gt;
 &nbsp; &nbsp; &nbsp; &nbsp; &lt;instanceParms&gt;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://www.example.com/myservice/policy
@@ -1382,11 +1384,11 @@
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp; &nbsp;keyName="Reusable policy Expression"
 &nbsp; &nbsp; &nbsp; &nbsp;keyValue="policy"
-&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" /&gt;
+&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" /&gt;
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp; &nbsp;keyName="Policy Expression for example's Web services"
 &nbsp; &nbsp; &nbsp; &nbsp;keyValue="http://www.example.com/myservice/policy"
-&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /&gt;
+&nbsp; &nbsp; &nbsp; &nbsp;tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" /&gt;
 &nbsp; &lt;/categoryBag&gt;
 &lt;/tModel&gt;</span></span></pre></div><p>The first <code>keyedReference</code> specifies that the tModel represents a
 <a title="" href="#policy_expression">policy expression</a> — rather than only being associated with one
@@ -1402,7 +1404,7 @@
 associate such a pre-registered, locally available <a title="" href="#policy_expression">policy expressions</a>
 with an entity in a UDDI registry</p><p>This new tModel is called the local policy reference category
 system and is defined in Appendix <a href="#LocalPolicyReferenceCategorySystem"><b>B.3 Local Policy Reference Category System</b></a>.</p><p>UDDI registries <span class="rfc2119">MUST</span> use the <code>tModelKey</code>
-<code>uuid:a27f7d45-ec90-31f7-a655-efe91433527c</code> to uniquely identify this
+<code><span class="diff-chg"><span>uuid:5da4fc61-a302-35ad-91d3-775150429035</span></span></code> to uniquely identify this
 tModel so that UDDI registry users can expect the same behavior across
 different UDDI registries.</p><p>The local policy reference category system is based on
 tModelKeys. The valid values of this category system are those
@@ -1421,7 +1423,7 @@
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp;  keyName="Policy Expression for example's Web services"
 &nbsp; &nbsp; &nbsp;  keyValue="uuid:04cfa…"
-&nbsp; &nbsp; &nbsp;  tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" /&gt;
+&nbsp; &nbsp; &nbsp;  tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" /&gt;
 &nbsp; &lt;/categoryBag&gt;
 &lt;/businessService&gt;</span></span></pre></div><p>The <code>tModelKey</code> of the <code>keyedReference</code>
 <span class="rfc2119">MUST</span> match
@@ -1435,7 +1437,7 @@
 &nbsp; &lt;accessPoint&gt;…&lt;/accessPoint&gt;
 &nbsp; &lt;tModelInstanceDetails&gt;
 &nbsp; &nbsp; &lt;tModelInstanceInfo
-&nbsp; &nbsp; &nbsp;  tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" &gt;
+&nbsp; &nbsp; &nbsp;  tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" &gt;
 &nbsp; &nbsp; &nbsp; &lt;instanceDetails&gt;
 &nbsp; &nbsp; &nbsp; &nbsp; &lt;instanceParms&gt;uuid:04cfa…&lt;/instanceParms&gt;
 &nbsp; &nbsp; &nbsp; &lt;/instanceDetails&gt;
@@ -1455,8 +1457,8 @@
 introduced in this specification are already programmatically derived
 from the Version 3 keys given below.</p><p>The <code>tModelKey</code> for the remote policy reference tModel changes
 from
-<code>"uuid:a27078e4-fd38-320a-806f-6749e84f8005"</code> to
-<code>"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"</code>.</p><p>The <code>tModelKey</code> for the Web Services Policy Types tModel changes from <code>"uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993"</code> to <code>"uddi:schemas.xmlsoap.org:policytypes:2003_03"</code>.</p><p>The <code>tModelKey</code> for the local policy reference tModel changes from <code>"uuid:a27f7d45-ec90-31f7-a655-efe91433527c"</code> to <code>"uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"</code>.</p><p>Second, rather than putting <a title="" href="#policy_expression">policy expression</a> references in a
+<code><span class="diff-chg"><span>"uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1"</span></span></code> to
+<code><span class="diff-chg"><span>"uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"</span></span></code>.</p><p>The <code>tModelKey</code> for the Web Services Policy Types tModel changes from <code><span class="diff-chg"><span>"uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941"</span></span></code> to <code><span class="diff-chg"><span>"uddi:w3.org:ws-policy:v1.5:attachment:policytypes"</span></span></code>.</p><p>The <code>tModelKey</code> for the local policy reference tModel changes from <code><span class="diff-chg"><span>"uuid:5da4fc61-a302-35ad-91d3-775150429035"</span></span></code> to <code><span class="diff-chg"><span>"uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference"</span></span></code>.</p><p>Second, rather than putting <a title="" href="#policy_expression">policy expression</a> references in a
 <code>bindingTemplate</code>'s <code>tModelInstanceInfo</code>, they are added to the
 <code>bindingTemplate</code>'s <code>categoryBag</code>, analogous to the mechanism described
 for other UDDI entities. For example, the example <code>bindingTemplate</code> from
@@ -1468,7 +1470,7 @@
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp;  keyName="Policy Expression for example's Web services"
 &nbsp; &nbsp; &nbsp;  keyValue="http://www.example.com/myservice/policy"
-&nbsp; &nbsp; &nbsp;  tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+&nbsp; &nbsp; &nbsp;  tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
 &nbsp; &nbsp; /&gt;
 &nbsp; &lt;/categoryBag&gt;
 &lt;/bindingTemplate&gt;</span></span></pre></div><p>Third, inquiries for reusable <a title="" href="#policy_expression">policy expression</a> tModels
@@ -1482,7 +1484,7 @@
 &nbsp; &lt;categoryBag&gt;
 &nbsp; &nbsp; &lt;keyedReference
 &nbsp; &nbsp; &nbsp;  keyValue="http://www.example.com/"
-&nbsp; &nbsp; &nbsp;  tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+&nbsp; &nbsp; &nbsp;  tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
 &nbsp; &nbsp; /&gt;
 &nbsp; &lt;/categoryBag&gt;
 &nbsp; &lt;findQualifiers&gt;
@@ -1502,11 +1504,11 @@
     Security Considerations section of the Web Services Policy 1.5 - Framework document [<a href="#WS-Policy">[Web Services Policy Framework]</a>].
   </p></div><div class="div1">
 <h2><a name="Conformance" id="Conformance"></a>8. Conformance</h2><div class="div2">
-<h3><a name="d2e4049" id="d2e4049"></a>8.1 External Policy Attachment Conformance</h3><p>An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [<a href="#XMLSchemaPart1">[XML Schema Structures]</a>] for that element as defined by this specification (<span class="diff-chg"><a href="http://www.w3.org/2007/02/ws-policy.xsd"><span class="diff-chg"><span>http://www.w3.org/2007/02/ws-policy.xsd</span></span></a></span>) and additionally adheres to all the constraints contained in Section <a href="#ExternalPolicyAttachment"><b>3.4 External Policy Attachment</b></a> of this specification. Such a conformant element information item constitutes an external policy attachment. </p></div><div class="div2">
-<h3><a name="d2e4062" id="d2e4062"></a>8.2 WSDL 1.1 Attachment Conformance</h3><p>
+<h3><a name="d2e4058" id="d2e4058"></a>8.1 External Policy Attachment Conformance</h3><p>An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [<a href="#XMLSchemaPart1">[XML Schema Structures]</a>] for that element as defined by this specification (<span class="diff-chg"><a href="http://www.w3.org/2007/02/ws-policy.xsd"><span class="diff-chg"><span>http://www.w3.org/2007/02/ws-policy.xsd</span></span></a></span>) and additionally adheres to all the constraints contained in Section <a href="#ExternalPolicyAttachment"><b>3.4 External Policy Attachment</b></a> of this specification. Such a conformant element information item constitutes an external policy attachment. </p></div><div class="div2">
+<h3><a name="d2e4071" id="d2e4071"></a>8.2 WSDL 1.1 Attachment Conformance</h3><p>
  A WSDL 1.1 [<a href="#WSDL11">[WSDL 1.1]</a>] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section <a href="#AttachingPolicyUsingWSDL1.1"><b>4. Attaching Policies Using WSDL 1.1</b></a>
 </p></div><div class="div2">
-<h3><a name="d2e4071" id="d2e4071"></a>8.3 WSDL 2.0 Attachment Conformance</h3><p>
+<h3><a name="d2e4080" id="d2e4080"></a>8.3 WSDL 2.0 Attachment Conformance</h3><p>
  A WSDL 2.0 [<a href="#WSDL20">[WSDL 2.0 Core Language]</a>] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section <a href="#ws-policy-attachment-for-wsdl20"><b>5. WS-Policy Attachment for WSDL 2.0</b></a>
 </p></div></div></div><div class="back"><div class="div1">
 <h2><a name="References" id="References"></a>A. References</h2><div class="div2">
@@ -1691,7 +1693,7 @@
         (See http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf.)</dd><dt class="label"><a name="WSDL11BindingforSOAP12" id="WSDL11BindingforSOAP12"></a>[WSDL 1.1 Binding for SOAP 1.2] </dt><dd>
 <a href="http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/"><cite>WSDL 1.1 Binding for SOAP 1.2</cite></a>,
 	D. Angelov, et al, Authors. World Wide Web Consortium, 5 April
-	2006.  <span class="diff-del"><span>Available </span></span><span class="diff-add"><span>&nbsp;Available </span></span>at
+	2006. <span class="diff-chg"><span>&nbsp;Available </span></span>at
 	http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.
         (See http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.)</dd><dt class="label"><a name="XML-Signature" id="XML-Signature"></a>[XML-Signature] </dt><dd>
 <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/"><cite>XML-Signature Syntax and Processing</cite></a>,
@@ -1719,23 +1721,23 @@
     (See http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.)</dd></dl></div></div><div class="div1">
 <h2><a name="AppendixA" id="AppendixA"></a>B. UDDI tModel Definitions</h2><p>This section contains the UDDI tModel definitions for the canonical
 tModels used in Section <a href="#AttachingPoliciesUsingUDDI"><b>6. Attaching Policies Using UDDI</b></a>. The tModelKeys shown in the tModel
-structure sections are valid UDDI Version 2 keys. When using UDDI
-Version 3, the corresponding derived UDDI Version 2 keys must be
+structure sections are valid UDDI Version <span class="diff-chg"><span>3 </span></span>keys. When using UDDI
+Version <span class="diff-chg"><span>2, </span></span>the corresponding derived UDDI Version 2 keys must be
 used.</p><div class="div2">
 <h3><a name="RemotePolicyReferenceCategorySystem" id="RemotePolicyReferenceCategorySystem"></a>B.1 Remote Policy Reference Category System</h3><div class="div3">
 <h4><a name="DesigGoals1" id="DesigGoals1"></a>B.1.1 Design Goals</h4><p>This tModel is used to attach a <a title="" href="#policy">policy</a> to a UDDI entity by referencing the policy's IRI.</p></div><div class="div3">
 <h4><a name="tModelDefinition1" id="tModelDefinition1"></a>B.1.2 tModel Definition</h4><a name="Table7"></a><table border="1" cellpadding="5" cellspacing="0"><tbody><tr><th colspan="1" rowspan="1">Name:</th><td colspan="1" rowspan="1">
-<a href="http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference/">http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference</a>
+  <div class="diff-chg"><a href="http://www.w3.org/ns/ws-policy/remotepolicyreference/"><span class="diff-chg"><span>http://www.w3.org/ns/ws-policy/remotepolicyreference</span></span></a></div>
 </td></tr><tr><th colspan="1" rowspan="1">Description:</th><td colspan="1" rowspan="1">Category system used for UDDI entities
 to point to an external Web services policy attachment policy that
 describes their characteristics. See Web Services Policy 1.5 - Attachment specification
 for further details.</td></tr><tr><th colspan="1" rowspan="1">UDDI Key (V3):</th><td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03</code>
+<code><span class="diff-chg"><span>uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">UDDI V1,V2 format key:</th><td colspan="1" rowspan="1">
-<code>uuid:a27078e4-fd38-320a-806f-6749e84f8005</code>
+<code><span class="diff-chg"><span>uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">Categorization:</th><td colspan="1" rowspan="1">categorization</td></tr><tr><th colspan="1" rowspan="1">Checked:</th><td colspan="1" rowspan="1">No</td></tr></tbody></table><br></div><div class="div3">
-<h4><a name="ModelStructure1" id="ModelStructure1"></a>B.1.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" &gt;
-&nbsp; &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference&lt;/name&gt;
+<h4><a name="ModelStructure1" id="ModelStructure1"></a>B.1.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" &gt;
+  &nbsp; &lt;name&gt;http://www.w3.org/ns/ws-policy/remotepolicyreference&lt;/name&gt;
 &nbsp; &lt;description xml:lang="EN"&gt;Category system used for UDDI entities to point to an external
    Web Services Policy Attachment policy expression that describes their characteristics.
    See Web Services Policy 1.5 - Attachment specification for further details.&lt;/description&gt;
@@ -1754,15 +1756,15 @@
 this very <a title="" href="#policy_expression">policy expression</a> using the remote policy reference category
 system.</p></div><div class="div3">
 <h4><a name="tModelDefinition2" id="tModelDefinition2"></a>B.2.2 tModel Definition</h4><a name="Table8"></a><table border="1" cellpadding="5" cellspacing="0"><tbody><tr><th colspan="1" rowspan="1">Name:</th><td colspan="1" rowspan="1">
-<a href="http://schemas.xmlsoap.org/ws/2003/03/policytypes/">http://schemas.xmlsoap.org/ws/2003/03/policytypes</a>
+<div class="diff-chg"><a href="http://www.w3.org/ns/ws-policy/policytypes/"><span class="diff-chg"><span>http://www.w3.org/ns/ws-policy/policytypes</span></span></a></div>
 </td></tr><tr><th colspan="1" rowspan="1">Description:</th><td colspan="1" rowspan="1">Web services policy types category system used for UDDI tModels to
 characterize them as Web services policy–based <a title="" href="#policy_expression">policy expressions</a>.</td></tr><tr><th colspan="1" rowspan="1">UDDI Key (V3):</th><td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:policytypes:2003_03</code>
+<code><span class="diff-chg"><span>uddi:w3.org:ws-policy:v1.5:attachment:policytypes</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">UDDI V1,V2 format key:</th><td colspan="1" rowspan="1">
-<code>uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993</code>
+<code><span class="diff-chg"><span>uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">Categorization:</th><td colspan="1" rowspan="1">categorization</td></tr><tr><th colspan="1" rowspan="1">Checked:</th><td colspan="1" rowspan="1">No</td></tr></tbody></table><br></div><div class="div3">
-<h4><a name="ModelStructure2" id="ModelStructure2"></a>B.2.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" &gt;
-&nbsp; &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/policytypes&lt;/name&gt;
+<h4><a name="ModelStructure2" id="ModelStructure2"></a>B.2.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" &gt;
+&nbsp; &lt;name&gt;http://www.w3.org/ns/ws-policy/policytypes&lt;/name&gt;
 &nbsp; &lt;description xml:lang="EN"&gt;Web Services Policy Types category system used for UDDI tModels
    to characterize them as Web Services Policy – based policy expressions.&lt;/description&gt;
 &nbsp; &lt;categoryBag&gt;
@@ -1781,17 +1783,17 @@
 expressions</a> using the Web services policy types category
 system.</p></div><div class="div3">
 <h4><a name="tModelDefinition3" id="tModelDefinition3"></a>B.3.2 tModel Definition</h4><a name="Table9"></a><table border="1" cellpadding="5" cellspacing="0"><tbody><tr><th colspan="1" rowspan="1">Name:</th><td colspan="1" rowspan="1">
-<a href="http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference/">http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference</a>
+<div class="diff-chg"><a href="http://www.w3.org/ns/ws-policy/localpolicyreference/"><span class="diff-chg"><span>http://www.w3.org/ns/ws-policy/localpolicyreference</span></span></a></div>
 </td></tr><tr><th colspan="1" rowspan="1">Description:</th><td colspan="1" rowspan="1">Category system used for UDDI entities to point to a Web services
 policy <a title="" href="#policy_expression">policy expression</a>
 tModel that describes their characteristics. See Web Services Policy 1.5 - Attachment
 specification for further details.</td></tr><tr><th colspan="1" rowspan="1">UDDI Key (V3):</th><td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:localpolicyreference:2003_03</code>
+<code><span class="diff-chg"><span>uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">UDDI V1,V2 format key:</th><td colspan="1" rowspan="1">
-<code>uuid:a27f7d45-ec90-31f7-a655-efe91433527c</code>
+<code><span class="diff-chg"><span>uuid:5da4fc61-a302-35ad-91d3-775150429035</span></span></code>
 </td></tr><tr><th colspan="1" rowspan="1">Categorization:</th><td colspan="1" rowspan="1">categorization</td></tr><tr><th colspan="1" rowspan="1">Checked:</th><td colspan="1" rowspan="1">Yes</td></tr></tbody></table><br></div><div class="div3">
-<h4><a name="ModelStructure3" id="ModelStructure3"></a>B.3.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" &gt;
-&nbsp; &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference&lt;/name&gt;
+<h4><a name="ModelStructure3" id="ModelStructure3"></a>B.3.3 tModel Structure</h4><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;tModel tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" &gt;
+&nbsp; &lt;name&gt;http://www.w3.org/ns/ws-policy/localpolicyreference&lt;/name&gt;
 &nbsp; &lt;description xml:lang="en"&gt;Category system used for UDDI entities to point to a
    Web Services Policy policy expression tModel that describes their characteristics.
    See Web Services Policy 1.5 - Attachment specification for further details.&lt;/description&gt;
@@ -1823,11 +1825,14 @@
     on public-ws-policy@w3.org</a> are also gratefully
     acknowledged.
   </p></div><div class="div1">
-<h2><a name="change-description" id="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated 17 November, 2006
-      is below:</p><ul><li><p>Clarified the relationship between URI domain expression and 
-          WSDL 1.1 Element Identifiers 
-            [<a href="#WSDL11EI">[WSDL11 ElementIds]</a>] in Section <a href="#uri-domain-expression"><b>3.4.1 URI Domain Expression</b></a>.</p></li><li><p>Explicitly described the interaction between policy attachment mechanisms and XML Base in
-         Section <a href="#IRI_Policy_Attachment"><b>3.5 Use of IRIs in Policy Attachment</b></a>.</p></li></ul></div><div class="div1">
+<h2><a name="change-description" id="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated <span class="diff-chg"><span>28 February, 2007
+      </span></span>is below:</p><ul><li><p><span class="diff-chg"><span>Aligned </span></span>the <span class="diff-add"><span>UDDI</span></span><span class="diff-del"><span>relationship between URI domain </span></span><span class="diff-chg"><span>names </span></span>and 
+          <span class="diff-del"><span>WSDL 1.1 Element Identifiers 
+            [] in Section </span></span><span class="diff-add"><span>keys</span></span><span class="diff-del"><span>.         
+        
+       Explicitly </span></span><span class="diff-chg"><span>with </span></span>the <span class="diff-add"><span>XML</span></span><span class="diff-del"><span>interaction between policy </span></span><span class="diff-chg"><span>namespace name of </span></span><span class="diff-add"><span>the
+          Web</span></span><span class="diff-del"><span>XML </span></span><span class="diff-chg"><span>Services </span></span><span class="diff-add"><span>Policy</span></span><span class="diff-del"><span>in
+         Section </span></span><span class="diff-add"><span>language.</span></span><span class="diff-del"><span>.</span></span></p></li></ul></div><div class="div1">
 <h2><a name="change-log" id="change-log"></a>E. Web Services Policy 1.5 - Attachment Change Log (Non-Normative)</h2><a name="ws-policy-attachment-changelog-table"></a><table border="1"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><tr><td colspan="1" rowspan="1">20060712</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated the list of editors. Completed action items 
             <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action20">20</a> 
             from the Austin F2F.</td></tr><tr><td colspan="1" rowspan="1">20060712</td><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">Completed action item <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action12">12</a>
@@ -1985,4 +1990,7 @@
     </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070315</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">PY</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the resolution for issue
       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4391"><span class="diff-add"><span>4391</span></span></a>.
       Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/200"><span class="diff-add"><span>200</span></span></a>.
-    </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
+    </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070316</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">PY</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented part of the resolution as it applies to the Attachment spec, for issue
+      <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4389"><span class="diff-add"><span>4389</span></span></a>.
+      Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/209"><span class="diff-add"><span>209</span></span></a>.
+    </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070321</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Reset Section <a href="#change-description"><b>D. Changes in this Version of the Document</b></a>. </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: ws-policy-primer-diff20061221.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20061221.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-primer-diff20061221.xml	16 Mar 2007 13:15:02 -0000	1.2
+++ ws-policy-primer-diff20061221.xml	22 Mar 2007 07:11:39 -0000	1.3
@@ -5,9 +5,9 @@
 <!ENTITY % entities SYSTEM "entities.dtd" >
 %entities;
 <!ENTITY status SYSTEM "status-primer.xml">
-<!ENTITY document.status "Editors' copy $Date$">
+<!ENTITY document.status.primer "Editors' copy $Date$">
 <!ENTITY primer-title "&primer.title;">
-<!ENTITY prevloc "">
+<!ENTITY prevloc "http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221">
 <!ENTITY hellip "&#8230;">
 ]><spec role="editors-copy" w3c-doctype="wd">
   <header>
@@ -22,11 +22,10 @@
     <publoc>
       <loc href="ws-policy-primer.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ws-policy-primer.html</loc>
     </publoc> 
-    <!--
-	<prevlocs>
-            <loc href="&prevloc;">&prevloc;</loc>
-        </prevlocs>
--->
+	<prevlocs diff="add">
+            <loc href="http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221</phrase></loc>
+        </prevlocs> 
+    
     <latestloc>
       <loc href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</loc>
     </latestloc>
@@ -107,7 +106,9 @@
         explains the basics of normalizing policy expressions, merging policies, determining the
         compatibility (intersection) of policies, the policy data model, the policy expression and
         the extensibility points built into the Web Services Policy language.</p>
-      <p>The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors 
+      <p><specref diff="add" ref="versioning-policy-language"></specref> <phrase diff="add">provides examples and best practices on 
+      versioning of the policy language itself, mostly intended for policy implementers.</phrase></p>
+      <p diff="add">The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors 
          specification provides guidelines for designing policy assertions and enumerates 
          the minimum requirements for describing policy assertions in specifications.</p>
       <p>This is a non-normative document and does not provide a definitive specification of the Web
@@ -163,13 +164,13 @@
         <p>Let us start by considering a SOAP Message in the example below.</p>
         <example>
           <head>SOAP Message</head>
-          <eg xml:space="preserve">&lt;soap:Envelope&gt;
+          <eg xml:space="preserve"><phrase diff="chg">&lt;soap:Envelope&gt;
   &lt;soap:Header&gt;
-   &lt;wsa:To&gt;http://stock.contoso.com/realquote&lt;/wsa:To&gt;
-   &lt;wsa:Action&gt;http://stock.contoso.com/GetRealQuote&lt;/wsa:Action&gt;
+            &lt;wsa:To&gt;http://x.example.com/realquote&lt;/wsa:To&gt;
+            &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
   &lt;/soap:Header&gt;
   &lt;soap:Body&gt;...&lt;/soap:Body&gt;
-&lt;/soap:Envelope&gt;</eg>
+&lt;/soap:Envelope&gt;</phrase></eg>
         </example>
         <p>This message uses message addressing headers. The <code>wsa:To</code>
           and <code>wsa:Action</code> header blocks identify the destination and the semantics
@@ -178,9 +179,9 @@
           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. 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. The developer has Contoso’s advertised WSDL description of these Web
-          services. Contoso requires the use of addressing headers for messaging. Just the WSDL
+          that retrieves real time stock quote information from <phrase diff="chg">Company-X, </phrase>Ltd. <phrase diff="chg">Company-X </phrase>supplies real
+          time data using Web services. The developer has <phrase diff="chg">Company-X’s </phrase>advertised WSDL description of these Web
+          services. <phrase diff="chg">Company-X </phrase>requires the use of addressing headers for messaging. Just the WSDL
           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>
@@ -190,16 +191,16 @@
             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, the developer 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 <phrase diff="chg">Company-X </phrase>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
+          <phrase diff="chg">Company-X </phrase>may augment the service WSDL description with a policy that requires the use of
           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
+        <p>How does <phrase diff="chg">Company-X </phrase>use policy to represent the use of addressing? The example below
           illustrates a policy expression that requires the use of addressing.</p>
         <example>
           <head>Policy Expression</head>
@@ -211,7 +212,7 @@
           The policy expression in the above example consists of a Policy main  
           element and a child element wsap:UsingAddressing. Child elements of  
           the 
-          Policy element are policy assertions. Contoso attaches the above  
+          Policy element are policy assertions. <phrase diff="chg">Company-X </phrase>attaches the above  
           policy expression to a WSDL binding description.
           </p>
         <example diff="add">
@@ -242,7 +243,7 @@
       </div2>
       <div2 id="secure-message">
         <head>Secure Message</head>
-        <p>In addition to requiring the use of addressing, Contoso requires the use of
+        <p>In addition to requiring the use of addressing, <phrase diff="chg">Company-X </phrase>requires the use of
           transport-level security for protecting messages.</p>
         <example>
           <head>Secure Message</head>
@@ -254,18 +255,18 @@
        &lt;wsu:Expires&gt;2006-01-19T02:54:53.914Z&lt;/u:Expires&gt;
       &lt;/wsu:Timestamp&gt;
     &lt;/wss:Security&gt;
-   &lt;wsa:To&gt;http://real.contoso.com/quote&lt;/wsa:To&gt;
-   &lt;wsa:Action&gt;http://real.contoso.com/GetRealQuote&lt;/wsa:Action&gt;
+   &lt;wsa:To&gt;http://x.example.com/quote&lt;/wsa:To&gt;
+   &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
   &lt;/soap:Header&gt;
   &lt;soap:Body&gt;...&lt;/soap:Body&gt;
 &lt;/soap:Envelope&gt;</phrase></eg>
         </example>
         <p>The SOAP message in the example above includes security timestamps that express creation
-          and expiration times of this message. Contoso requires the use of security timestamps and
+          and expiration times of this message. <phrase diff="chg">Company-X </phrase>requires the use of security timestamps and
           transport-level security - such as <code>HTTPS</code> – for protecting messages. (The
           prefixes <code>wss</code> and <code>wsu</code> are used here to denote the Web Services
           Security and Utility namespaces.)</p>
-        <p>Similar to the use of addressing, Contoso indicates the use of transport-level security
+        <p>Similar to the use of addressing, <phrase diff="chg">Company-X </phrase>indicates the use of transport-level security
           using a policy expression. The example below illustrates a policy expression that requires
           the use of addressing and transport-level security for securing messages.</p>
         <example>
@@ -288,14 +289,14 @@
       </div2>
       <div2 id="other-assertions">
         <head>Other Assertions</head>
-        <p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
+        <p>Thus far, we explored how <phrase diff="chg">Company-X </phrase>uses policy expressions and assertions for representing
           behaviors that must be engaged for a Web service interaction. What is a policy assertion?
           What role does it play? In brief, a policy assertion is a piece of service metadata, and
           it identifies a domain (such as messaging, security, reliability and transaction) specific
-          behavior that is a requirement. Contoso uses a policy assertion to convey a condition
+          behavior that is a requirement. <phrase diff="chg">Company-X </phrase>uses a policy assertion to convey a condition
           under which they offer a Web service. A policy-aware client can recognize policy
           assertions and engage these behaviors automatically.</p>
-        <p>Providers, like Contoso, have the option to combine behaviors for an interaction from
+        <p>Providers, like <phrase diff="chg">Company-X, </phrase>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 can use policy-aware clients that recognize these
@@ -353,10 +354,10 @@
   &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
 &lt;/All&gt;</eg>
         </example>
-        <p>In addition to requiring the use of addressing, Contoso allows either the use of
+        <p>In addition to requiring the use of addressing, <phrase diff="chg">Company-X </phrase>allows either the use of
           transport- or message-level security for protecting messages. Web Services Policy language
           can indicate this choice of behaviors in a machine-readable form. To indicate the use of
-          message-level security for protecting messages, Contoso uses the
+          message-level security for protecting messages, <phrase diff="chg">Company-X </phrase>uses the
             <code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p>
         <example>
           <head>Asymmetric Binding Security Policy Assertion</head>
@@ -368,7 +369,7 @@
           1.0</emph> - for protecting messages. Policy-aware clients can recognize this policy
           assertion, engage message-level security for protecting messages and use headers such
             as <code>wss:Security</code> in SOAP Envelopes.</p>
-        <p>To allow the use of either transport- or message-level security, Contoso uses the
+        <p>To allow the use of either transport- or message-level security, <phrase diff="chg">Company-X </phrase>uses the
             <code>ExactlyOne</code> policy operator. Policy assertions combined using the
             <code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
           the assertions. The policy expression in the example below requires the use of either
@@ -380,7 +381,7 @@
   &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
 &lt;/ExactlyOne&gt;</eg>
         </example>
-        <p>Contoso requires the use of addressing and requires the use of either transport- or
+        <p><phrase diff="chg">Company-X </phrase>requires the use of addressing and requires the use of either transport- or
           message-level security for protecting messages. They represent this combination using
             the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
           to represent different combinations of behaviors (capabilities and requirements). The
@@ -396,17 +397,17 @@
   &lt;/ExactlyOne&gt;
 &lt;/All&gt;</eg>
         </example>
-        <p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
+        <p>Using this policy expression, <phrase diff="chg">Company-X </phrase>gives the choice of mechanisms for protecting
           messages to clients (or requesters).</p>
       </div2>
       <div2 id="optional-policy-assertion">
         <head>Optional Policy Assertion</head>
-        <p>Through a customer survey program, Contoso learns that a significant number of their
+        <p>Through a customer survey program, <phrase diff="chg">Company-X </phrase>learns that a significant number of their
           customers prefer to use the Optimized MIME Serialization (as defined in the MTOM
-          specification) for sending and receiving messages. Contoso adds optional support for the
+          specification) for sending and receiving messages. <phrase diff="chg">Company-X </phrase>adds optional support for the
           Optimized MIME Serialization and expresses this optional behavior in a machine-readable
           form.</p>
-        <p>To indicate the use of optimization using the Optimized MIME Serialization, Contoso uses
+        <p>To indicate the use of optimization using the Optimized MIME Serialization, <phrase diff="chg">Company-X </phrase>uses
           the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p>
         <example>
           <head>Optimized MIME Serialization Policy Assertion</head>
@@ -419,7 +420,7 @@
           messages. Policy-aware clients can recognize this policy assertion and engage Optimized
           MIME Serialization for messages. The semantics of this assertion are reflected in
           messages: they use an optimized wire format (MIME Multipart/Related serialization).</p>
-        <p>Like Contoso’s optional support for Optimized MIME Serialization, there are behaviors
+        <p>Like <phrase diff="chg">Company-X’s </phrase>optional support for Optimized MIME Serialization, there are behaviors
           that may be engaged (in contrast to must be engaged) for a Web service interaction. A
           service provider will not fault if these behaviors are not engaged. Policy assertions can
           be marked optional to represent behaviors that may be engaged for an interaction. A policy
@@ -447,7 +448,7 @@
   &lt;/ExactlyOne&gt;
 &lt;/All&gt;</eg>
         </example>
-        <p>Contoso is able to meet their customer needs by adding optional support for the Optimized
+        <p><phrase diff="chg">Company-X </phrase>is able to meet their customer needs by adding optional support for the Optimized
           <phrase diff="del">MIME </phrase><phrase diff="add">MIME 
         </phrase>Serialization. <phrase diff="add">Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and 
         detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization. 
@@ -460,12 +461,12 @@
       <div2 diff="add" id="ignorable-policy-assertions">
         <head><phrase diff="add">Ignorable Policy Expressions</phrase></head>
         <p>
-          <phrase diff="add">Suppose Contoso decides that it will log SOAP messages sent and received in an exchange. 
+          <phrase diff="add">Suppose Company-X decides that it will log SOAP messages sent and received in an exchange. 
           This behavior has no direct impact on the messages sent on the wire, and does not affect interoperability. 
-          Some parties might have a concern about such logging and might decide not to interact with Contoso knowing 
-          that such logging is performed.  To address this concern, Contoso includes a Logging assertion in its policy to enable 
+          Some parties might have a concern about such logging and might decide not to interact with Company-X knowing 
+          that such logging is performed.  To address this concern, Company-X includes a Logging assertion in its policy to enable 
           such parties to be aware of logging. By marking the Logging assertion with the </phrase><att><phrase diff="add">wsp:Ignorable</phrase></att> <phrase diff="add">attribute with a
-           value of "true" Contoso indicates that a requester may choose to either ignore such assertions or to consider 
+           value of "true" Company-X indicates that a requester may choose to either ignore such assertions or to consider 
            them as part of policy intersection.  An assertion that may be ignored for policy intersection is called an 
            ignorable assertion.
           </phrase></p>
@@ -514,10 +515,10 @@
         <head>Nested Policy Expressions</head>
         <p>In the previous sections, we considered two security policy assertions. In this section,
           let us look at one of the security policy assertions in little more detail.</p>
-        <p>As you would expect, securing messages is a complex usage scenario. Contoso uses the
+        <p>As you would expect, securing messages is a complex usage scenario. <phrase diff="chg">Company-X </phrase>uses the
             <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
+          protecting messages is not sufficient. To successfully interact with <phrase diff="chg">Company-X’s </phrase>Web
           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
@@ -526,7 +527,7 @@
         <p>A policy assertion – like the <code>sp:TransportBinding</code> - identifies a visible
           domain specific behavior that is a requirement. Given an assertion, there may be other
           dependent behaviors that need to be enumerated for a Web Service interaction. In the case
-          of the <code>sp:TransportBinding</code> policy assertion, Contoso needs to identify the
+          of the <code>sp:TransportBinding</code> policy assertion, <phrase diff="chg">Company-X </phrase>needs to identify the
           use of a transport token, a secure transport, an algorithm suite for performing
           cryptographic operations, etc. A nested policy expression can be used to enumerate such
           dependent behaviors.</p>
@@ -569,14 +570,34 @@
           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>
+          <p diff="add"> <phrase diff="add">In another example, WS-Security Policy defines a sp:HttpToken assertion to 
+          contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication 
+          and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a
+          policy expression by a provider, it will indicate that none of the dependent behaviors namely 
+          authentication or client certificate is required. A non-anonymous client who requires authentication 
+          or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.
+</phrase><example>
+<head> <phrase diff="add">Empty Nested Assertion </phrase></head>
+<eg xml:space="preserve">&lt;sp:TransportToken&gt;
+    &lt;wsp:Policy&gt;
+      &lt;sp:HttpsToken&gt; 
+       &lt;wsp:Policy/&gt; 
+      &lt;/sp:HttpsToken&gt; 
+    &lt;/wsp:Policy&gt;
+&lt;/sp:TransportToken&gt;
+</eg> 
+</example>
+ 	  </p>
+          
+      
       </div2>
       <div2 id="Referencing_Policy_Expressions">
         <head>Referencing Policy Expressions</head>
-        <p>Contoso has numerous Web service offerings that provide different kinds of real-time
+        <p><phrase diff="chg">Company-X </phrase>has numerous Web service offerings that provide different kinds of real-time
           quotes and book information on securities such as
             <code>GetRealQuote</code>, <code>GetRealQuotes</code> and
-          <code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
-          Contoso supports multiple WSDL bindings for these Web services. Contoso provides
+          <code>GetExtendedRealQuote</code>. To accommodate the diversity of <phrase diff="chg">Company-X’s </phrase>customers,
+          <phrase diff="chg">Company-X </phrase>supports multiple WSDL bindings for these Web services. <phrase diff="chg">Company-X </phrase>provides
           consistent ways to interact with their services and wants to represent these capabilities
           and requirements consistently across all of their offerings without duplicating policy
           expressions multiple times. How? It is simple - a policy expression can be named and
@@ -607,12 +628,12 @@
         <p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
           expression. The value of the <code>wsu:Id</code> attribute is an XML ID. The relative IRI
           for referencing this policy expression (within the same document) is <code>#common</code>.
-          If the policy document IRI is <code>http://real.contoso.com/policy.xml</code> then the
+          If the policy document IRI is <code><phrase diff="chg">http://x.example.com/policy.xml</phrase></code> then the
           absolute IRI for referencing this policy expression is
-            <code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
+            <code><phrase diff="chg">http://x.example.com/policy.xml#common. </phrase>(</code>The absolute IRI is formed by
           combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
           attribute.)</p>
-        <p> <phrase diff="add">In addition to the Example 2-12, Contoso could have used either the xml:id or wsu:Id.
+        <p> <phrase diff="add">In addition to the Example 2-12, Company-X could have used either the xml:id or wsu:Id.
           An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </phrase></p>
        <example diff="add">
        <head><phrase diff="add">Common Policy Expression [xml:id]</phrase></head>
@@ -641,7 +662,7 @@
           <head>PolicyReference to Common Policy Expression</head>
           <eg xml:space="preserve">&lt;PolicyReference URI="#common"/&gt;</eg>
         </example>
-        <p>For referencing a policy expression within the same XML document, Contoso uses the
+        <p>For referencing a policy expression within the same XML document, <phrase diff="chg">Company-X </phrase>uses the
             <code>wsu:Id</code> attribute for identifying a policy expression and an IRI to this ID
           value for referencing this policy expression using a <code>PolicyReference</code> element.</p>
         <p>The example below is a policy expression that re-uses the common policy expression within
@@ -666,18 +687,18 @@
           resides in. As such, referencing a policy expression using the <code>Name</code> attribute
           relies on additional out of band information. In the example below, the <code>Name</code>
           attribute identifies the policy expression. The IRI of this policy expression is
-            <code>http://real.contoso.com/policy/common</code>.</p>
+            <code><phrase diff="chg">http://x.example.com/policy/common</phrase></code>.</p>
         <example>
           <head>Common Policy Expression</head>
-          <eg xml:space="preserve">&lt;Policy Name=”http://real.contoso.com/policy/common”&gt;
+          <eg xml:space="preserve"><phrase diff="chg">&lt;Policy Name=”http://x.example.com/policy/common”&gt;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsap:UsingAddressing /&gt;
-&lt;/Policy&gt;</eg>
+&lt;/Policy&gt;</phrase></eg>
         </example>
         <p>The example below is a policy expression that re-uses the common policy expression above.</p>
         <example>
           <head>PolicyReference to Common Policy Expression</head>
-          <eg xml:space="preserve">&lt;PolicyReference URI="http://real.contoso.com/policy/common"/&gt;</eg>
+          <eg xml:space="preserve"><phrase diff="chg">&lt;PolicyReference URI="http://x.example.com/policy/common"/&gt;</phrase></eg>
         </example>
         <p diff="add"><phrase diff="add">As policy expressions are composed from other policy expressions and
           assertions from different domains are used in a policy expression,
@@ -693,14 +714,14 @@
       </div2>
       <div2 id="attaching-policy-expressions-to-wsdl">
         <head>Attaching Policy Expressions to WSDL</head>
-        <p>A majority of Contoso’s customers use WSDL for building their client applications.
-          Contoso leverages this usage by attaching policy expressions to the WSDL binding
+        <p>A majority of <phrase diff="chg">Company-X’s </phrase>customers use WSDL for building their client applications.
+          <phrase diff="chg">Company-X </phrase>leverages this usage by attaching policy expressions to the WSDL binding
           descriptions.</p>
         <p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
           binding for an interface that provides real-time quotes and book information on
           securities. (The prefixes <code>wsdl</code> and <code>tns</code> are used here to denote
           the Web Services Description language XML namespace and target namespace of this WSDL
-          document.) To require the use of security for these offerings, Contoso attaches the secure
+          document.) To require the use of security for these offerings, <phrase diff="chg">Company-X </phrase>attaches the secure
           policy expression in the previous section to this binding description. The WSDL
             <code>binding</code> element is a common policy attachment point. The secure policy
           expression attached to the <code>SecureBinding</code> WSDL binding description applies to
@@ -715,11 +736,11 @@
   …
 &lt;/wsdl:binding&gt;</eg>
         </example>
-        <p>In addition to providing real-time quotes and book information on securities, Contoso
-          provides other kinds of data through Web services such as quotes delayed by 20 minutes and
+        <p>In addition to providing real-time quotes and book information on securities, <phrase diff="chg">Company-X
+          </phrase>provides other kinds of data through Web services such as quotes delayed by 20 minutes and
           security symbols through Web services (for example <code>GetDelayedQuote</code>,
             <code>GetDelayedQuotes,</code>
-          <code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
+          <code>GetSymbol</code> and <code>GetSymbols</code>). <phrase diff="chg">Company-X </phrase>does not require the use of
           security for these services, but requires the use of addressing and allows the use of
           optimization.</p>
         <example>
@@ -733,7 +754,7 @@
         <p>In the example above, the <code>OpenBinding</code> WSDL binding description defines a
           binding for an interface that provides other kinds of data such as quotes delayed by 20
           minutes and security symbols. To require the use of addressing and allow the use of
-          optimization, Contoso attaches the common policy expression in the previous section to
+          optimization, <phrase diff="chg">Company-X </phrase>attaches the common policy expression in the previous section to
           this binding description. As we have seen in the <code>SecureBinding</code> case, the
           common policy expression attached to the <code>OpenBinding</code> WSDL binding description
           applies to any message exchange associated with any <code>port</code> that supports this
@@ -747,7 +768,7 @@
           security and optimization. Or, the service may not have such capabilities and
           requirements. A policy aware client should not conclude anything <phrase diff="del">(other than ‘no claims’)
           </phrase>about the absence of policy expressions.</p>
-        <p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
+        <p>Service providers, like <phrase diff="chg">Company-X, </phrase>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
           can use a policy-aware client that recognizes these policy expressions in WSDL
@@ -759,8 +780,8 @@
         <head>Policy Automates Web Services Interaction</head>
         <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 Contoso,
-          use policy expressions to represent combinations of capabilities and requirements. Web
+          one attribute - <code>wsp:Optional</code>. In practice, service providers, like <phrase diff="chg">Company-X,
+          </phrase>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
           complexity is absorbed by policy-aware clients (or tools) and is invisible to these Web
@@ -814,10 +835,10 @@
           nested policy expression. Policy assertions can also be marked optional to represent
           behaviors that may be engaged (capabilities) for an interaction. The optional marker is
           the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p>
-        <p>Let us take a closer look at Contoso’s policy expression (see below) from the previous
+        <p>Let us take a closer look at <phrase diff="chg">Company-X’s </phrase>policy expression (see below) from the previous
           section.</p>
         <example>
-          <head>Contoso’s Secure Policy Expression</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Secure Policy Expression</head>
           <eg xml:space="preserve">&lt;Policy&gt;
   &lt;All&gt;
     &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
@@ -887,7 +908,7 @@
         </example>
         <p>A policy expression in the compact form can be converted to the normal form. Web Services
           Policy language describes the algorithm for this conversion.</p>
-        <p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
+        <p>Let us re-consider <phrase diff="chg">Company-X’s </phrase>policy expression (see the example below). <phrase diff="chg">Company-X </phrase>requires
           the use of addressing and either transport- or message-level security and allows the use
           of optimization. This policy expression is in the compact form and has four policy
           alternatives for requesters:</p>
@@ -906,7 +927,7 @@
           </item>
         </olist>
         <example>
-          <head>Contoso’s Secure Policy Expression in Compact Form</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Secure Policy Expression in Compact Form</head>
           <eg xml:space="preserve">&lt;Policy wsu:Id=”secure”&gt;
   &lt;All&gt;
     &lt;PolicyReference URI=”#common”/&gt;
@@ -922,14 +943,14 @@
   &lt;wsap:UsingAddressing /&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <p>Let us look at the normal form for this policy expression. The example below is Contoso’s
-          policy expression in the normal form. As you can see, the compact form is less verbose
+        <p>Let us look at the normal form for this policy expression. The example below is <phrase diff="chg">Company-X’s
+          </phrase>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>
         <example>
-          <head>Contoso’s Policy Expression in Normal Form</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Policy Expression in Normal Form</head>
           <eg xml:space="preserve">&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt; &lt;!-- - - - - - - - - - - - - - Policy Alternative (a) --&gt;
@@ -969,7 +990,7 @@
         <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,
+        <p><phrase diff="chg">Company-X </phrase>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 <specref ref="basic-concepts-policy-expression"></specref>), 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
@@ -1037,19 +1058,19 @@
         <head>Compatible Policies</head>
        
       
-        <p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
+        <p>A provider, like <phrase diff="chg">Company-X, </phrase>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
           more policies.</p>
-        <p>The example below is a copy of Contoso’s policy expression (from <specref ref="normal-form-for-policy-expressions"></specref>). As we saw before, Contoso offers four
+        <p>The example below is a copy of <phrase diff="chg">Company-X’s </phrase>policy expression (from <specref ref="normal-form-for-policy-expressions"></specref>). As we saw before, <phrase diff="chg">Company-X </phrase>offers four
           policy alternatives. Of them, one of the policy alternatives requires the use of
           addressing and transport-level security.</p>
         <example>
-          <head>Contoso’s Policy Expression</head>
-          <eg xml:space="preserve">&lt;Policy&gt;
+          <head><phrase diff="chg">Company-X’s </phrase>Policy Expression</head>
+          <eg xml:space="preserve"><phrase diff="chg">&lt;Policy&gt;
   &lt;ExactlyOne&gt;
-    &lt;All&gt; &lt;!-- - - - - - - - - -  Contoso’s Policy Alternative (a) --&gt;
+    &lt;All&gt; &lt;!-- - - - - - - - - -  Company-X’s Policy Alternative (a) --&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) --&gt;
        &lt;wsap:UsingAddressing/&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) --&gt;
@@ -1057,10 +1078,10 @@
     &lt;/All&gt;
     …
   &lt;/ExactlyOne&gt;
-&lt;/Policy&gt;</eg>
+&lt;/Policy&gt;</phrase></eg>
         </example>
         <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
+          interaction with <phrase diff="chg">Company-X’s </phrase>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>
@@ -1077,10 +1098,10 @@
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <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
+        <p>The developer lets her policy-aware client select a compatible policy alternative in <phrase diff="chg">Company-X’s
+          </phrase>policy. How does this client select a compatible policy alternative? It is simple – it
           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
+          expressions (the client’s and <phrase diff="chg">Company-X’s) </phrase>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
@@ -1091,16 +1112,16 @@
           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 tje client’s policy alternative. Contoso’s policy alternative (a)
+          assertions (c1) and (c2) in <phrase diff="chg">Company-X’s </phrase>policy alternative are compatible with policy
+          assertions (t2) and (t1) in tje client’s policy alternative. <phrase diff="chg">Company-X’s </phrase>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
-          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>
+          alternative in the other. For example, <phrase diff="chg">Company-X’s </phrase>policy alternative (a) is compatible with
+          the client’s policy alternative. <phrase diff="chg">Company-X’s </phrase>policy and the client’s policy are compatible because one
+          of <phrase diff="chg">Company-X’s </phrase>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>
+          satisfy <phrase diff="chg">Company-X’s </phrase>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>
@@ -1139,7 +1160,7 @@
       </div2>
       <div2 id="attaching-policy-expressions-to-wsdl2">
         <head>Attaching Policy Expressions to WSDL</head>
-        <p>In <specref ref="basic-concepts-policy-expression"></specref>, we looked into how Contoso attached
+        <p>In <specref ref="basic-concepts-policy-expression"></specref>, we looked into how <phrase diff="chg">Company-X </phrase>attached
           their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
             <code>binding</code> element, a policy expression can be attached to other WSDL elements
           such as <code>service</code>, <code>port</code>, <code>operation</code>
@@ -1170,7 +1191,7 @@
           that message.</p>
         <p>In the example below, the policy expression is attached to an endpoint policy subject.</p>
         <example>
-          <head>Contoso’s Policy Expression Attached to WSDL binding Element</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Policy Expression Attached to WSDL binding Element</head>
           <eg xml:space="preserve">&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
   &lt;PolicyReference URI="#secure" /&gt;
   &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
@@ -1252,7 +1273,7 @@
       <div2 id="combine-policies">
         <head>Combine Policies</head>
         <p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
-          Contoso could have used multiple policy expressions in a WSDL document. In the example
+          <phrase diff="chg">Company-X </phrase>could have used multiple policy expressions in a WSDL document. In the example
           below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
           attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
           WSDL port descriptions.</p>
@@ -1298,7 +1319,7 @@
           the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code> WSDL port
           descriptions. The <code>#common2</code> policy expression has two policy alternatives. The
           <code>#secure2</code> policy expression has two policy alternatives. The
-          combination of these two policies is equivalent to Contoso’s secure policy in <specref ref="basic-concepts-policy-expression"></specref> and has four policy alternatives. In other
+          combination of these two policies is equivalent to <phrase diff="chg">Company-X’s </phrase>secure policy in <specref ref="basic-concepts-policy-expression"></specref> and has four policy alternatives. In other
           words, the combination of two policies is the cross product of alternatives in these two
           policies.</p>
         <example>
@@ -1343,13 +1364,13 @@
         <p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p>
         <p>Web Services Policy language enables simple versioning practices that allow requesters to
           continue the use of any older policy alternatives in a backward compatible manner. This
-          allows service providers, like Contoso, to deploy new behaviors using additional policy
+          allows service providers, like <phrase diff="chg">Company-X, </phrase>to deploy new behaviors using additional policy
           assertions without breaking compatibility with clients that rely on any older policy
           alternatives.</p>
-        <p>The example below represents a Contoso version 1 policy expression. This expression
+        <p>The example below represents a <phrase diff="chg">Company-X </phrase>version 1 policy expression. This expression
           requires the use of addressing and transport-level security for protecting messages. </p>
         <example>
-          <head>Contoso’s Version 1 Policy Expression</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Version 1 Policy Expression</head>
           <eg xml:space="preserve">&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
@@ -1359,17 +1380,17 @@
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
+        <p>Over time, <phrase diff="chg">Company-X </phrase>adds support for advanced behaviors: requiring the use of addressing
           and message-level security for protecting messages. They added this advanced support
           without breaking compatibility with requesters that rely on addressing and transport-level
-          security. The example below is Contoso’s version 2 policy expression. In this version,
-          Contoso’s adds a new policy alternative that requires the use of addressing and
+          security. The example below is <phrase diff="chg">Company-X’s </phrase>version 2 policy expression. In this version,
+          <phrase diff="chg">Company-X’s </phrase>adds a new policy alternative that requires the use of addressing and
           message-level security. The clients that rely on addressing and transport-level security
-          may continue to interact with Contoso’s using the old policy alternative. Of course, these
+          may continue to interact with <phrase diff="chg">Company-X’s </phrase>using the old policy alternative. Of course, these
           clients have the option to migrate from using old policy alternatives to new policy
           alternatives.</p>
         <example>
-          <head>Contoso’s Version 2 Policy Expression</head>
+          <head><phrase diff="chg">Company-X’s </phrase>Version 2 Policy Expression</head>
           <eg xml:space="preserve">&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
@@ -1383,7 +1404,7 @@
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</eg>
         </example>
-        <p>When Contoso added support for advanced behaviors, they spent time to plan for the
+        <p>When <phrase diff="chg">Company-X </phrase>added support for advanced behaviors, they spent time to plan for the
           continued support for existing clients, the smooth migration from using current to
           advanced behaviors, and the switch to use only the advanced behaviors in the near future
           (i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
@@ -1392,8 +1413,8 @@
           functionality when they choose to. This level of versioning support in policy enables the
           same class of versioning best practices built into WSDL constructs such as service, port
           and binding.</p>
-        <p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
-          incrementally deploy advanced behaviors, some requesters may not recognize these new
+        <p>Let us look at tooling for unknown policy assertions. As service providers, like <phrase diff="chg">Company-X,
+          </phrase>incrementally deploy advanced behaviors, some requesters may not recognize these new
           policy assertions. As discussed before, these requesters may continue to interact using
           old policy alternatives. New policy assertions will emerge to represent new behaviors and
           slowly become part of everyday interoperable interaction between requesters and providers.
@@ -1416,32 +1437,30 @@
           useful to convey this information to help smooth the versioning process.
           </phrase></p>
         <p>
-          <phrase diff="add">Contoso could specify that the older policy alternative will expire at a
-          certain point in time using a Contoso specific expiry assertion.  The example
-          below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+          <phrase diff="add">Company-X could specify that the older policy alternative will expire at a
+          certain point in time using a Company-X specific expiry assertion.  The example
+          below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
           Assertion.
           </phrase></p>
           <example>
-            <head><phrase diff="add">Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+            <head><phrase diff="add">Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
               Assertion</phrase></head>
-            <eg xml:space="preserve">
-              &lt;Policy&gt;
-                &lt;ExactlyOne&gt;
-                  &lt;All&gt;
-                   &lt;contoso:EndOfLife wsp:Ignorable="true"/&gt;Mar-31-2008&lt;/contoso:EndOfLife&gt;
-                   &lt;wsap:UsingAddressing/&gt;
-                   &lt;sp:TransportBinding&gt;...&lt;/sp:TransportBinding&gt;
-                  &lt;/All&gt;
+            <eg xml:space="preserve">&lt;Policy&gt;
+  &lt;ExactlyOne&gt;
+    &lt;All&gt;
+      &lt;company-x:EndOfLife wsp:Ignorable="true"/&gt;Mar-31-2008&lt;/company-x:EndOfLife&gt;
+      &lt;wsap:UsingAddressing/&gt;
+      &lt;sp:TransportBinding&gt;...&lt;/sp:TransportBinding&gt;
+    &lt;/All&gt;
                 
-                  &lt;!-- NEW Policy Alternative --&gt;
-                  &lt;All&gt; 
-                    &lt;contoso:EndOfLife wsp:Ignorable="true"&gt;Mar-31-2999&lt;/contoso:EndOfLife&gt;
-                    &lt;wsap:UsingAddressing/&gt;
-                    &lt;sp:AsymmetricBinding&gt;...&lt;/sp:AsymmetricBinding&gt;
-                  &lt;/All&gt;
-                &lt;/ExactlyOne&gt;
-              &lt;/Policy&gt;
-          </eg>
+    &lt;!-- NEW Policy Alternative --&gt;
+    &lt;All&gt; 
+      &lt;company-x:EndOfLife wsp:Ignorable="true"&gt;Mar-31-2999&lt;/company-x:EndOfLife&gt;
+        &lt;wsap:UsingAddressing/&gt;
+        &lt;sp:AsymmetricBinding&gt;...&lt;/sp:AsymmetricBinding&gt;
+      &lt;/All&gt;
+  &lt;/ExactlyOne&gt;
+&lt;/Policy&gt;</eg>
             </example>
           <p>
           <phrase diff="add">In this variant of the versioning scenario, the use of ignorable allows
@@ -1450,10 +1469,10 @@
           <p>
           <phrase diff="add">In a scenario such as this, where an assertion type is used for ignorable
           information, the use of strict or lax mode and presence or absence of the
-          assertion type in the first version are important decisions.  If Contoso wishes
+          assertion type in the first version are important decisions.  If Company-X wishes
           clients to always be able to ignore the assertion, particularly those using
           strict intersection, the first policy alternative offered should contain the
-          policy assertion type.  If Contoso adds the policy assertion type to a
+          policy assertion type.  If Company-X adds the policy assertion type to a
           subsequent alternative, then requesters using strict mode will not understand
           the assertion type and the alternative with the ignorable information will not
           be compatible with the older version of the alternative as per the intersection
@@ -1517,12 +1536,13 @@
         <p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
           specific behavior: the use of a security token – such as SAML token - issued by a third
           party for protecting messages. This behavior is relevant to a Web service interaction. For
-          the sake of discussion, let us assume that Contoso requires the use of a SAML token issued
-          by a third party. Service providers, like Contoso, must convey this usage and all the
+          the sake of discussion, let us assume that <phrase diff="chg">Company-X </phrase>requires the use of a SAML token issued
+          by a third party. Service providers, like <phrase diff="chg">Company-X, </phrase>must convey this usage and all the
           necessary information to obtain this security token for Web service developers. This is a
-          key piece of metadata for a successful interaction with Contoso’s Web services.</p>
+          key piece of metadata for a successful interaction with <phrase diff="chg">Company-X’s </phrase>Web services.</p>
       </div2>
-      <div2 id="versioning-policy-language"><head>Versioning Policy Language</head>
+      </div1>
+      <div1 diff="add" id="versioning-policy-language"><head>Versioning Policy Language</head>
         <p> 
           <ednote> 
             <edtext>
@@ -1541,7 +1561,7 @@
           <item><p>AppliesTo: any element and any attribute</p></item>
         </olist>
         
-        <div3 id="versioning-policy-framework"><head>Policy Framework</head>
+        <div2 id="versioning-policy-framework"><head>Policy Framework</head>
           <p>WS-Policy Framework 1.5 specifies that any <phrase diff="add">child </phrase>element that is not known inside a Policy, 
           ExactlyOne or All will be treated as an assertion. The default value for <phrase diff="chg">wsp:Optional="false". 
           After normalization, such an element </phrase>will be inside an ExactlyOne/All operator.  </p>
@@ -1662,8 +1682,8 @@
           </example>
           
           <p>It is difficult to predict whether this functionality would be useful.  The future version of WS-Policy doesn't appear to be precluded from doing this.</p>
-        </div3>
-        <div3 id="versioning-policy-attachment"><head>Policy Attachment</head>
+        </div2>
+        <div2 id="versioning-policy-attachment"><head>Policy Attachment</head>
           <p>Policy attachment provides WSDL 1.1 and UDDI attachment points.  It appears that exchange of Policy will be in the context of WSDL or UDDI.
             WRT WSDL, the policy model is an extension of the WSDL definition.  As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL.  One alternative is that there would be a separate WSDL for each version of Policy.  The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL.  </p>
           
@@ -1716,8 +1736,8 @@
           <p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored.  A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p>
           
           <p>PolicyAttachment and AppliesTo also have extensibility points.  We choose not to illustrate these at this time.</p>
-        </div3>
-      </div2>
+        </div2>
+      
     </div1>
     
     <div1 id="conclusion">
@@ -2019,16 +2039,19 @@
 </inform-div1>
  <inform-div1 id="change-description">
       <head>Changes in this Version of the Document</head>
-      <p>A list of substantive changes since the Working Draft dated <phrase diff="chg">21 December, </phrase>2006 is below:</p>
+      <p>A list of <phrase diff="add">major editorial</phrase><phrase diff="del">substantive </phrase>changes since the Working Draft dated <phrase diff="chg">21 December, </phrase>2006 is below:</p>
       <ulist>
-        <item><p><phrase diff="add">TBD.</phrase><phrase diff="del">Moved 
+        <item><p><phrase diff="add">Added</phrase><phrase diff="del">Moved 
           Sections 
-            4.2 Parts of a Policy Assertion and 
+            4.2 Parts of </phrase>a <phrase diff="add">new</phrase><phrase diff="del">Policy Assertion and 
           
-            4.4.8 Versioning Policy Language into Section ; 
-          moved Section
+            4.4.8 Versioning Policy Language </phrase><phrase diff="chg">section: </phrase><specref diff="add" ref="ignorable-policy-assertions"></specref><phrase diff="add">.</phrase></p></item>
+        <item diff="add"><p><phrase diff="add">Added</phrase><phrase diff="del">Section </phrase><phrase diff="add">a</phrase><phrase diff="del">; 
+          moved </phrase><phrase diff="add">new</phrase><phrase diff="del">Section
           
-            4 Advanced Concepts II: Policy Assertion Design into the Guidelines document.</phrase></p></item>
+            4 </phrase><phrase diff="chg">section: </phrase><specref ref="Both-Optional-Ignorable"></specref><phrase diff="add">.</phrase></p></item>
+        <item diff="add"><p><phrase diff="add">Added</phrase><phrase diff="del">Concepts </phrase><phrase diff="chg">a new section: </phrase><specref ref="strict-lax-policy-intersection"></specref><phrase diff="add">.</phrase></p></item>
+        <item diff="add"><p><phrase diff="add">Added</phrase><phrase diff="del">Design </phrase><phrase diff="chg">a new section: </phrase><specref ref="ignorable-and-versioning"></specref><phrase diff="add">.</phrase><phrase diff="del">document.</phrase></p></item>
       </ulist>
     </inform-div1>
     <inform-div1 id="change-log">
@@ -2318,7 +2341,43 @@
               (editors action 
               <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">191</phrase></loc>).
             </td>
-            
+          </tr>
+             <tr diff="add">
+            <td colspan="1" diff="add" rowspan="1">20070319</td>
+            <td colspan="1" diff="add" rowspan="1">MH</td>
+            <td colspan="1" diff="add" rowspan="1">Implemented the resolution for
+              <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4213" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 4213</phrase></loc>   
+              <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">as outlined.</phrase></loc> 
+              Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">189</phrase></loc>.
+            </td>
+          </tr> 
+          <tr diff="add">
+            <td colspan="1" diff="add" rowspan="1">20070319</td>
+            <td colspan="1" diff="add" rowspan="1">PY</td>
+            <td colspan="1" diff="add" rowspan="1">Implemented the resolution for
+              <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 4103</phrase></loc>   
+              <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">as outlined.</phrase></loc> 
+              Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">193</phrase></loc>.
+            </td>
+          </tr>
+          <tr diff="add">
+            <td colspan="1" diff="add" rowspan="1">20070320</td>
+            <td colspan="1" diff="add" rowspan="1">ASV</td>
+            <td colspan="1" diff="add" rowspan="1">Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300#c1" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">resolution</phrase></loc> 
+              for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 4300</phrase></loc>.
+              Editors' action 
+              <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">190</phrase></loc>.
+            </td>            
+          </tr>
+          <tr diff="add">
+            <td colspan="1" diff="add" rowspan="1">20070321</td>
+            <td colspan="1" diff="add" rowspan="1">ASV</td>
+            <td colspan="1" diff="add" rowspan="1">Updated section <specref ref="change-description"></specref>. </td>
+          </tr>
+          <tr diff="add">
+            <td colspan="1" diff="add" rowspan="1">20070321</td>
+            <td colspan="1" diff="add" rowspan="1">ASV</td>
+            <td colspan="1" diff="add" rowspan="1">Formatted the example in <specref ref="ignorable-and-versioning"></specref>. </td>
           </tr>                          
                      
         </tbody>

--- NEW FILE: wsdl11elementidentifiers-diff20070131.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.2+WSDL//EN" "xmlspec.dtd" [
        <!ENTITY prefix "wsdl11elementidentifiers">
	<!ENTITY % entities SYSTEM "entities.dtd">
	%entities;
	<!ENTITY status SYSTEM "status-wsdl11ei.xml">
	<!ENTITY document.status.wsdl11ei "Editors' copy $Date: 2007/03/22 07:11:39 $">
	<!ENTITY prevloc "http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131">
	<!ENTITY wsdl-ns "http://schemas.xmlsoap.org/wsdl/">
]><spec role="editors-copy" w3c-doctype="wd">
	<header>
		<title>WSDL 1.1 Element Identifiers</title>
		<w3c-designation>wsdl11elementidentifiers.html</w3c-designation>
		<w3c-doctype>Editors' copy $Date: 2007/03/22 07:11:39 $</w3c-doctype>
		<pubdate>
			<day>@@</day>
			<month>@@@@</month>
			<year>@@@@</year>
		</pubdate>
		<publoc>
			<loc href="wsdl11elementidentifiers.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">wsdl11elementidentifiers.html</loc>
		</publoc>
	    
	    <prevlocs diff="add">
            <loc href="http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131</phrase></loc>
        </prevlocs>
		
	    
		<latestloc>
			<loc href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html?content-type=text/html;charset=utf-8" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html?content-type=text/html;charset=utf-8</loc>
		</latestloc>

		<authlist>
			<author>
				<name>David Orchard</name>
				<affiliation>BEA Systems</affiliation>
			</author>
			<author role="editor">
				<name>Asir S Vedamuthu</name>
				<affiliation>Microsoft Corporation</affiliation>
			</author>
			<author role="editor">
				<name>Frederick Hirsch</name>
				<affiliation>Nokia</affiliation>
			</author>
			<author role="editor">
				<name>Maryann Hondo</name>
				<affiliation>IBM Corporation</affiliation>
			</author>
			<author role="editor">
				<name>Prasad Yendluri</name>
				<affiliation>webMethods, Inc.</affiliation>
			</author>
			<author role="editor">
				<name>Toufic Boubez</name>
				<affiliation>Layer 7 Technologies</affiliation>
			</author>
			<author role="editor">
				<name>Ümit Yalçinalp</name>
				<affiliation>SAP AG.</affiliation>
			</author>
		</authlist>
		<abstract>
			<p>WSDL 1.1 Element Identifiers defines a syntax to identify individual elements in a WSDL 1.1 document.</p>
		</abstract>
		<status xml:base="file:///C:/2006/ws/policy/entitiesedcopy.dtd"><p></p></status>
		<langusage>
			<language id="en">English</language>
		</langusage>
		<revisiondesc>
			<p>Last Modified: $Date: 2007/03/22 07:11:39 $ CET</p>
		</revisiondesc>
	</header>
	<body>
		<div1 id="intro">
			<head>Introduction</head>
			<p>This document defines an element identifier syntax for WSDL 1.1 elements.
			</p>
			<div2 id="notcon">
				<head>Notational Conventions</head>
				<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in RFC 2119 [<bibref ref="RFC2119"></bibref>].</p>
				<p>With the exception of examples and sections explicitly marked
    	as "Non-Normative", all parts of this specification are
    	normative.</p>
			</div2>
		</div1>
			<div1 id="frag-ids">
	<head>Fragment Identifiers</head>
	<p>
	This section defines a fragment identifier syntax for identifying elements of a WSDL 1.1 document.
	This fragment identifier syntax is compliant with the
	[<bibref ref="XPTR"></bibref>].  This document is primarily based upon [<bibref ref="WSDL-PART1"></bibref>].  There is a substantial difference between the WSDL 1.1 and WSDL 2.0 fragment identifiers.WSDL 2.0 defines fragment identifiers with respect to the WSDL 2.0 component model, whereas WSDL 1.1 defines XML element and attribute syntax only.  Because there is no WSDL 1.1 component model, the WSDL 1.1 fragment identifiers <phrase diff="add">identify</phrase><phrase diff="del">are to the </phrase>WSDL 1.1 elements.  <phrase diff="chg">Note: </phrase>the fragment identifers <phrase diff="add">identify</phrase><phrase diff="del">are to </phrase>the WSDL 1.1 elements prior to any processing of the WSDL document, such as validation, inclusion, imports, schema type validation, etc.  <phrase diff="add">Note further: WSDL 1.1 fragment identifiers require a targetNamespace so WSDL 1.1 documents without a targetNamespace will not have fragment identifiers. 
	  
	</phrase></p>
	<p>
	A WSDL 1.1 fragment identifier is an XPointer [<bibref ref="XPTR"></bibref>], 
 augmented with WSDL 1.1 pointer parts as defined below. Note that many 
 of these parts require the pre-appearance of one or more <code>xmlns</code> pointer 
 parts (see 3.4 Namespace Binding Context in [<bibref ref="XPTR"></bibref>]).
	The pointer parts have a scheme name that corresponds to one
	of the standard WSDL 1.1 element names, and scheme data that is a path composed
	of names that identify the elements. 
	The scheme names all begin with the prefix "wsdl11." to avoid
	name conflicts with other schemes.
	The names in the path are of type either QName, NCName,
	IRI, URI, or Pointer Part depending on the context.
	The scheme data for WSDL 1.1 extension elements is defined by the 
	corresponding extension specification.
	</p>
	<p>
	For QNames, any prefix
	MUST be defined by a preceding xmlns pointer part.
	If a QName does not have a prefix then its namespace
	name is the target namespace of the WSDL 1.1 document.
	</p>

	<p>
		The fragment identifier is typically constructed from the <code>name</code>
		property of the element and the <code>name</code> properties of its
		ancestors as a path according to
		<specref ref="frag-ids-table"></specref>.
	    The first column of this table gives the name of the WSDL 1.1
		element. Columns labeled 1 through 3 specify the identifiers that
		uniquely identify the element within its context. Identifiers
		are typically formed from the <code>name</code> property, although in
		several cases references to other elements are used. These
		identifiers are then used to construct the pointer part in
		the last column.
		The fragment identifier in a WSDL 1.1 element IRI-reference
		MUST resolve to some element as defined by the construction rules
		in <specref ref="frag-ids-table"></specref>.
	</p>

	<table border="1" id="frag-ids-table">
	  <caption>Rules for determining pointer parts for WSDL 1.1 elements</caption>
	    <col span="1" width="19%"></col>
	    <col span="1" width="12%"></col>
	    <col span="1" width="12%"></col>
	    <col span="1" width="12%"></col>
	    <col span="1" width="45%"></col>
	<tbody>
	<tr>
	  <th colspan="1" rowspan="1">element</th>
          <th colspan="1" rowspan="1">1</th>
          <th colspan="1" rowspan="1">2</th>
          <th colspan="1" rowspan="1">3</th>
          <th colspan="1" rowspan="1">Pointer Part</th>
	</tr>
	<tr>
	  	  <td colspan="1" rowspan="1">Definitions</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code>wsdl11.definitions()</code></td>
	</tr>
	<tr>
          <td colspan="1" diff="del" rowspan="1">MessageType Definition</td>
          <td colspan="1" diff="del" rowspan="1"><code><phrase diff="chg">message</phrase></code> NCNameQName </td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.message(</phrase></code><code role="code-emph"><phrase diff="chg">message</phrase></code><code>)</code></td>
	</tr>
		<tr>
          <td colspan="1" diff="chg" rowspan="1">Message Part</td>
          <td colspan="1" diff="del" rowspan="1"><code><phrase diff="chg">message</phrase></code> NCNameQName </td>
          <td colspan="1" diff="del" rowspan="1"><code diff="add"><phrase diff="add">part</phrase></code> NCNamen/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.messagePart(</phrase></code><code role="code-emph"><phrase diff="chg">message/part</phrase></code><code>)</code></td>
	</tr>
<tr>
	  	  <td colspan="1" diff="chg" rowspan="1">portType</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">portType</phrase></code> NCName </td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.portType(</phrase></code><code role="code-emph"><phrase diff="chg">portType</phrase></code><code>)</code></td>
	</tr>
	<tr>
	      <td colspan="1" diff="chg" rowspan="1">portType Operation</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">portType</phrase></code> NCName</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">operation</phrase></code> NCName</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.portTypeOperation(</phrase></code><code role="code-emph"><phrase diff="chg">portType/operation</phrase></code><code>)</code></td>
	</tr>
	<tr>
          <td colspan="1" diff="add" rowspan="1">portType Operation Input</td>
          <td colspan="1" rowspan="1"><code>portType</code> NCName </td>
          <td colspan="1" diff="del" rowspan="1"><code diff="add"><phrase diff="add">operation</phrase></code> NCNamen/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.portTypeOperation.input(</phrase></code><code role="code-emph"><phrase diff="chg">portType/operation</phrase></code><code>)</code></td>
	</tr>
	<tr>
          <td colspan="1" diff="add" rowspan="1">portType Operation Output</td>
          <td colspan="1" rowspan="1"><code>portType</code> NCName</td>
          <td colspan="1" rowspan="1"><code>operation</code> NCName</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.portTypeOperation.output(</phrase></code><code role="code-emph">portType/operation</code><code>)</code></td>
	</tr>
	<tr>
          <td colspan="1" diff="chg" rowspan="1">portType Operation Fault</td>
          <td colspan="1" rowspan="1"><code>portType</code> NCName</td>
          <td colspan="1" rowspan="1"><code>operation</code> NCName</td>
           <td colspan="1" rowspan="1"><code><phrase diff="chg">fault</phrase></code> NCName</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.portTypeOperation.fault(</phrase></code><code role="code-emph"><phrase diff="chg">portType/operation/fault</phrase></code><code>)</code></td>
	</tr>
	<tr>
	  	  <td colspan="1" diff="del" rowspan="1">BindingportType Operation Fault</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">binding</phrase></code> NCName</td>
          <td colspan="1" diff="del" rowspan="1">n/aoperation NCName</td>
          <td colspan="1" diff="del" rowspan="1">n/afault QName</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.binding(</phrase></code><code role="code-emph"><phrase diff="chg">binding</phrase></code><code>)</code></td>
	</tr>
	<tr>
	  <td colspan="1" diff="add" rowspan="1">Binding Operation</td>
          <td colspan="1" rowspan="1"><code>binding</code> NCName</td>
          <td colspan="1" diff="del" rowspan="1"><code diff="add"><phrase diff="add">operation</phrase></code> QNamen/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.bindingOperation(</phrase></code><code role="code-emph"><phrase diff="chg">binding/operation</phrase></code><code>)</code></td>
	</tr>
	<tr>
	  <td colspan="1" diff="add" rowspan="1">Binding Operation Input</td>
          <td colspan="1" rowspan="1"><code>binding</code> NCName</td>
          <td colspan="1" rowspan="1"><code>operation</code> QName</td>
          <td colspan="1" diff="chg" rowspan="1">na/</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.bindingOperation.input(</phrase></code><code role="code-emph">binding/operation</code><code>)</code></td>
	</tr>
	
		<tr>
	  <td colspan="1" diff="chg" rowspan="1">Binding Operation Output</td>
          <td colspan="1" rowspan="1"><code>binding</code> NCName</td>
          <td colspan="1" rowspan="1"><code>operation</code> QName</td>
          <td colspan="1" diff="del" rowspan="1">na/message NCName</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.bindingOperation.output(</phrase></code><code role="code-emph"><phrase diff="chg">binding/operation</phrase></code><code>)</code></td>
	</tr>
	
		<tr>
	  <td colspan="1" rowspan="1">Binding Operation Fault</td>
          <td colspan="1" rowspan="1"><code>binding</code> NCName</td>
          <td colspan="1" rowspan="1"><code>operation</code> QName</td>
          <td colspan="1" rowspan="1"><code>fault</code> NCName</td>
          <td colspan="1" rowspan="1"><code><phrase diff="chg">wsdl11.bindingOperation.fault(</phrase></code><code role="code-emph">binding/operation/fault</code><code>)</code></td>
	</tr>

	<tr>
	  <td colspan="1" rowspan="1">Service</td>
          <td colspan="1" rowspan="1"><code>service</code> NCName</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code>wsdl11.service(</code><code role="code-emph">service</code><code>)</code></td>
	</tr>
	<tr>
	  <td colspan="1" rowspan="1">port</td>
          <td colspan="1" rowspan="1"><code>service</code> NCName</td>
          <td colspan="1" rowspan="1"><code>port</code> NCName</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code>wsdl11.port(</code><code role="code-emph">service/port</code><code>)</code></td>
	</tr>
		<tr>
	  <td colspan="1" rowspan="1">Extensions</td>
          <td colspan="1" rowspan="1"><code>namespace</code> URI</td>
          <td colspan="1" rowspan="1"><code>identifier</code> extension-specific-syntax</td>
          <td colspan="1" rowspan="1">n/a</td>
          <td colspan="1" rowspan="1"><code>wsdl11.extension(</code><code role="code-emph">namespace,identifier</code><code>)</code></td>
	</tr>
	
      </tbody>
      </table>

      </div1>
<div1 id="wsdl-iri-references">
	<head>IRI-References for WSDL 1.1 Elements</head>

	<p>
		This section provides a syntax for IRI-references for all
		elements found in a [<bibref ref="WSDL11"></bibref>] document. The IRI-references are easy
		to understand and compare, while imposing no burden on the WSDL 1.1
		author.
	</p>

	<div2 id="wsdl-iris">
	<head>WSDL 1.1 IRIs</head>
	<p>There are two main cases for WSDL 1.1 IRIs:</p>
	<ulist>
	<item><p>the IRI of a WSDL 1.1 document</p></item>
	<item><p>the IRI of a WSDL 1.1 namespace</p></item>
	</ulist>
	<p>
		The IRI of a WSDL 1.1 document can be dereferenced to give a
		resource representation that contributes elements
		to a single WSDL 1.1 namespace. If the media type is set to the WSDL 1.1
		media type i.e. application/xml, then the fragment identifiers can be used to
		identify the main elements that are defined in the document.
	</p>

	<p>
		In keeping with WSDL 1.1, which has a recommendation that 
		that the namespace URI be dereferencible to a WSDL 1.1 document,
		this section specifies the use of the namespace IRI with the
		WSDL 1.1 fragment identifiers to form an IRI-reference.
	</p>

	<p>
		The IRI in an IRI-reference for a WSDL 1.1 element is the
		namespace name of the
		<code>name</code>
		property of either the element itself, in the case of
		<code>portType</code>
		,
		<code>Binding</code>
		, and
		<code>Service</code>
		elements, or the
		<code>name</code>
		property of the ancestor top-level element. The IRI provided
		by the namespace name of the
		<code>name</code>
		property is combined with a zero or more
		<code>xmlns</code>
		pointer parts (see
		3.4 Namespace Binding Context
		in
		[<bibref ref="XPTR"></bibref>]
		) followed by a single WSDL 1.1 pointer part, following the same rules as defined for WSDL 1.1 fragment ids
		<specref ref="frag-ids"></specref>
		.
	</p>

	</div2>
	
	<div2 id="soap-binding-decl-fragid">
          <head>IRI Identification Of SOAP Binding elements</head>

	  <p><code>SOAP Binding</code> elements (binding, operation, body, header, fault, headerfault, and address) can be identified using the
	  <emph>wsdl11.extension</emph>
	  XPointer Framework scheme according to the following rules:</p>

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.binding(</code><code role="code-emph">parent</code><code>)</code>), where: </p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Binding's parent</code> element
	    </p>
	    </item>
	  </ulist>	  

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.operation(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Operation's parent</code> element
	    </p>
	    </item>
	  </ulist>	  

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.body(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Body's parent</code> element
	    </p>
	    </item>
	  </ulist>	  
	  
	  	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.header(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Header's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	 <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.headerfault(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP HeaderFault's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.fault(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Fault's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.address(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Address's parent</code> element
	    </p>
	    </item>
	  </ulist>	 

	</div2>
	<div2 id="element-designator-canonical-form">
		<head>Canonical Form for WSDL 1.1 element identifiers</head>
		<p>
			The IRI-references described above MAY be used as WSDL 1.1
			element identifiers. For ease of comparison, the fragment
			identifier of WSDL 1.1 element identifiers SHOULD conform
			to the following canonicalization rules:
		</p>
		<ulist>
			<item>
				<p>
						The fragment identifier consists of a sequence
						zero or more
						<code>xmlns()</code>
						pointer parts followed by exactly one
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						Each
						<code>xmlns()</code>
						pointer part that appears in the fragment
						identifier defines a namespace that is
						referenced by the
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						Each
						<code>xmlns()</code>
						pointer part defines a unique namespace.
				</p>
			</item>
			<item>
				<p>
						The
						<code>xmlns()</code>
						pointer parts define namespaces in the same
						order as they are referenced in the
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						The namespace prefixes defined by the
						<code>xmlns()</code>
						pointer parts are named
						<code>ns1</code>
						,
						<code>ns2</code>
						, etc., in the order of their appearance.
				</p>
			</item>
			<item>
				<p>
						The fragment identifier contains no optional
						whitespace.
				</p>
			</item>
		</ulist>
	</div2>

	<div2 id="Iri-ref-ex">
	<head>Example</head>
	<p>Consider WSDL 1.1 document located at
	http://example.org/TicketAgent.wsdl.  Each WSDL 1.1 Element Identifier is shown in comments above the WSDL 1.1 element
	</p>
	<example id="iri-ref-example-wsdl">
	<head>IRI-References - Example WSDL 1.1 Document</head>
	<eg xml:space="preserve"><![CDATA[<?xml version="1.0" encoding="UTF-8"?> 

<wsdl:definitions targetNamespace="http://example.org/TicketAgent.wsdl11"
    xmlns:tns="http://example.org/TicketAgent.wsdl11" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ http://www.w3.org/TR/2001/NOTE-wsdl-20010315/wsdl11.xsd">

    <!-- http://example.org/TicketAgent.wsdl11#wsd11.definitions() -->

    <wsdl:types>
        <xs:schema xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd"
            targetNamespace="http://example.org/TicketAgent.xsd">
            <xs:element name="listFlightsRequest" type="xsTicketAgent:tListFlights"/>
            <xs:complexType name="tListFlights">
                <xs:sequence>
                    <xs:element name="travelDate" type="xs:date"/>
                    <xs:element name="startCity" type="xs:string"/>
                    <xs:element name="endCity" type="xs:string"/>
                </xs:sequence>
            </xs:complexType>
            <xs:element name="listFlightsResponse" type="xsTicketAgent:tFlightsResponse"/>
            <xs:complexType name="tFlightsResponse">
                <xs:sequence>
                    <xs:element name="flightNumber" type="xs:integer" minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:complexType>
        </xs:schema>
    </wsdl:types>

    <wsdl:message name="listFlightsRequest">
        <!-- Starting from here, http://example.org/TicketAgent.wsdl11 will be shortened to http://... -->
        <!-- http://...#wsdl11.message(listFlightsRequest) -->
        <wsdl:part name="body" element="xsTicketAgent:listFlightsRequest"/>
        <!-- http://...#wsdl11.messagePart(listFlightsRequest/body) -->
    </wsdl:message>

    <wsdl:message name="listFlightsResponse">
        <!-- http://...#wsdl11.message(listFlightsResponse) -->
        <wsdl:part name="body" element="xsTicketAgent:listFlightsResponse"/>
        <!-- http://...#wsdl11.messagePart(listFlightsResponse/body) -->
    </wsdl:message>

    <wsdl:portType name="TicketAgent">
        <!-- http://...#wsdl11.portType(TicketAgent) -->
        <wsdl:operation name="listFlights">
            <!-- http://...#wsdl11.portTypeOperation(TicketAgent/listFlights) -->
            <wsdl:input message="tns:listFlightsRequest"/>
            <!-- http://...#wsdl11.portTypeOperation.input(TicketAgent/listFlights) -->
            <wsdl:output message="tns:listFlightsResponse"/>
            <!-- http://...#wsdl11.portTypeOperation.output(TicketAgent/listFlights) -->
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="TicketAgentSoap" type="tns:TicketAgent">
        <!-- http://...#wsdl11.binding(TicketAgentSoap) -->
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
             w11soap.binding( wsdl11.binding(TicketAgentSoap)) -->
        <wsdl:operation name="listFlights">
            <!-- http://...#wsdl11.bindingOperation(TicketAgentSoap/listFlights) -->
            <wsdl:input>
                <!-- http://...#wsdl11.bindingOperation.input(TicketAgentSoap/listFlights) -->
                <soap:body parts="body" use="literal"/>
                <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperation.input
                                           (TicketAgentSoap/listFlights)) -->
            </wsdl:input>
            <wsdl:output>
                <!-- http://...#wsdl11.bindingOperation.output(TicketAgentSoap/listFlights) -->
                <soap:body parts="body" use="literal"/>
                <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperation.output
                                           (TicketAgentSoap/listFlights)) -->
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>

</wsdl:definitions>]]></eg>
</example>
	</div2>
    </div1>		
		
		<div1 id="refs">
			<head>References</head>
			<div2 id="refs-norm">
				<head>Normative References</head>
				<blist>

<bibl href="http://www.ietf.org/rfc/rfc3023.txt" id="RFC3023" key="RFC 3023" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">IETF
	  "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July
	  1998.</bibl>
	  
	  <bibl href="http://www.w3.org/TR/2006/CR-wsdl20-20060327" id="WSDL-PART1" key="WSDL 2.0 Core" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
	  	<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
		 Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language
	  	</titleref>, R. Chinnici, J-J.
	  	Moreau, A. Ryman, S. Weerawarana, Editors. W3C Candidate Recommendation 27 March 2006. The current version of <loc href="http://www.w3.org/TR/2006/CR-wsdl20-20060327" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language</loc> is available at
	  	http://www.w3.org/TR/2006/CR-wsdl20-20060327 . The
	  	<loc href="http://www.w3.org/TR/wsdl20" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
	  		latest version of "Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language"
	  	</loc>
	  	is available at
	  	http://www.w3.org/TR/wsdl20.
	  </bibl>


	  <bibl href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" id="WSDL11" key="WSDL 1.1" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
	  <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services definitions Language (WSDL)
	  1.1</titleref>, E. Christensen, F. Curbera, G. Meredith, and
	  S. Weerawarana, Authors. W3C Note 15 March
	  2002. The current version of <loc href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Description Language (WSDL) 1.1</loc> is available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315 . The <loc href="http://www.w3.org/TR/wsdl" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">latest version of Web
	  Services definitions Language 1.1</loc> is available at
	  http://www.w3.org/TR/wsdl11.
	</bibl>
	
<bibl href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/" id="XPTR" key="XPointer Framework" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
	    <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">XPointer Framework</titleref>,Paul Grosso, Eve
	    Maler, Jonathan Marsh, Norman Walsh, Editors. W3C Recommendation 25 March 2003.  The current version of <loc href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">XPointer Framework</loc> is available at 
	    http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . The
	    <loc href="http://www.w3.org/TR/xptr-framework/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">latest
	    version of XPointer Framework</loc> is available at
	    http://www.w3.org/TR/xptr-framework/.
	  </bibl>
					<bibl href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119" key="RFC 2119" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">IETF "RFC 2119:
	  Key words for use in RFCs to Indicate Requirement Levels",
	  S. Bradner, March 1997.</bibl>
					<bibl href="http://www.ietf.org/rfc/rfc3986.txt" id="RFC3986" key="RFC 3986" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">IETF "RFC 3986:
	  Uniform Resource Identifiers (URI): Generic Syntax",
	  T. Berners-Lee, R. Fielding, L. Masinter, January 2005. </bibl>
				</blist>
			</div2>
			<!--<div2 id="refs-inform">
				<head>Informative References</head>

			</div2> -->
		</div1>
	</body>
	<back>
		<inform-div1 id="changelog">
			<head>Change Log</head>
			<table border="1">
				<caption>Changes</caption>
				<thead>
					<tr>
						<th colspan="1" rowspan="1">Who</th>
						<th colspan="1" rowspan="1">When</th>
						<th colspan="1" rowspan="1">What</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td colspan="1" rowspan="1">DBO</td>
						<td colspan="1" rowspan="1">20061108</td>
						<td colspan="1" rowspan="1">Initial Revision</td>
					</tr>
					
					<tr>
						<td colspan="1" rowspan="1">DBO</td>
						<td colspan="1" rowspan="1">20061212</td>
						<td colspan="1" rowspan="1">Uncommented canonical section, fixed editorial items</td>
					</tr>
					<tr>
<td colspan="1" rowspan="1">DBO</td>
<td colspan="1" rowspan="1">20070122</td>
<td colspan="1" rowspan="1">Resolution of bug <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4208" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">4208</loc>, AI is <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/145" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">145</loc>
</td>
</tr>
				    <tr>
				        <td colspan="1" rowspan="1">FS</td>
				        <td colspan="1" rowspan="1">20070127</td>
				        <td colspan="1" rowspan="1">Editorial fixes for publication preparation</td>
				    </tr>	
				    
				    <tr diff="add">
<td colspan="1" diff="add" rowspan="1">DBO</td>
<td colspan="1" diff="add" rowspan="1">20070219</td>
<td colspan="1" diff="add" rowspan="1">Changed MessageReference to .input and .output, resolution of bug <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4251" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4251</phrase></loc>, AI is <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/150" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">150</phrase></loc>
</td>
</tr>			
				    <tr diff="add">
<td colspan="1" diff="add" rowspan="1">DBO</td>
<td colspan="1" diff="add" rowspan="1">20070308</td>
<td colspan="1" diff="add" rowspan="1">Added note about targetnamespace being required. <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4331" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4331</phrase></loc>, AI is <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/177" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">177</phrase></loc>
</td>
</tr>	
				    <tr diff="add">
<td colspan="1" diff="add" rowspan="1">DBO</td>
<td colspan="1" diff="add" rowspan="1">20070308</td>
<td colspan="1" diff="add" rowspan="1">Removed Schema element and type defs. <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4332" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4332</phrase></loc>, AI is <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/178" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">178</phrase></loc>
</td>
</tr>	
								
				</tbody>
			</table>
		</inform-div1>
	</back>
</spec>

Index: ws-policy-framework-diff20070228.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework-diff20070228.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-framework-diff20070228.html	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-framework-diff20070228.html	22 Mar 2007 07:11:39 -0000	1.2
@@ -78,7 +78,7 @@
 <h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
             <a href="ws-policy-framework.html">ws-policy-framework.html</a>
         </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
-            <a href="http://www.w3.org/TR/2006/WD-ws-policy-20061117">http://www.w3.org/TR/2006/WD-ws-policy-20061117</a>
+            <div class="diff-chg"><a href="http://www.w3.org/TR/2007/CR-ws-policy-20070228"><span class="diff-chg"><span>http://www.w3.org/TR/2007/CR-ws-policy-20070228</span></span></a></div>
         </dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark/a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
 <h2><a name="abstract" id="abstract"></a>Abstract</h2><p>The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding 
 	    <span class="diff-del"><span>syntax </span></span><span class="diff-add"><span>syntax
@@ -257,51 +257,56 @@
                         "<span class="rfc2119">OPTIONAL</span>" in this document are to be interpreted as
                     described in RFC 2119 [<a href="#RFC2119">[IETF RFC 2119]</a>]. </p><p>We introduce the following terms that are used throughout this document:</p><dl><dt class="label">
          <a href="#ignorable_policy_assertion">ignorable policy assertion</a>
-      </dt><dd><p>An 
-	    <b>ignorable policy assertion</b> is 
-	    an assertion that may be ignored for policy intersection (as defined in 
-	        <a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection">4.5 Policy Intersection</a>).</p></dd><dt class="label">
+      </dt><dd><p>An
+                            <b>ignorable policy assertion</b> is an assertion that may be
+                        ignored for policy intersection (as defined in <a href="http://www.w3.org/TR/ws-policy#Policy_Intersection">4.5 Policy
+                            Intersection</a>).</p></dd><dt class="label">
          <a href="#nested_policy_expression">nested policy expression</a>
-      </dt><dd><p>A <b>nested policy expression</b> is a <a title="policy expression" href="#policy_expression">policy expression</a> that is an Element Information Item in the <em>children</em> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p></dd><dt class="label">
+      </dt><dd><p>A <b>nested policy expression</b>
+                            is a <a title="policy expression" href="#policy_expression">policy expression</a> that
+                            is an Element Information Item in the <em>children</em> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p></dd><dt class="label">
          <a href="#policy">policy</a>
-      </dt><dd><p>A <b>policy</b> is a potentially empty collection of 
-	    <a title="policy alternative" href="#policy_alternative">policy alternatives</a>. </p></dd><dt class="label">
+      </dt><dd><p>A <b>policy</b> is a potentially empty
+                        collection of <a title="policy alternative" href="#policy_alternative">policy
+                        alternatives</a>. </p></dd><dt class="label">
          <a href="#policy_alternative">policy alternative</a>
-      </dt><dd><p>A <b>policy alternative</b> 
-	    is a potentially empty collection of <a title="policy assertion" href="#policy_assertion">policy assertions</a>.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy
+                            alternative</b> is a potentially empty collection of <a title="policy assertion" href="#policy_assertion">policy assertions</a>.</p></dd><dt class="label">
          <a href="#policy_alternative_vocabulary">policy alternative vocabulary</a>
-      </dt><dd><p>A <b>policy alternative vocabulary</b> is the set of
-	    all <a title="policy assertion type" href="#policy_assertion_type">policy assertion
-	    types</a> within the <a title="policy alternative" href="#policy_alternative">policy
-	    alternative</a>.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy alternative vocabulary</b> is the set of all <a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> within the
+                            <a title="policy alternative" href="#policy_alternative">policy
+                    alternative</a>.</p></dd><dt class="label">
          <a href="#policy_assertion">policy assertion</a>
-      </dt><dd><p>A <b>policy assertion</b> 
-		represents a requirement, a capability, or other property of a behavior.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy
+                        assertion</b> represents a requirement, a capability, or other property
+                        of a behavior.</p></dd><dt class="label">
          <a href="#policy_assertion_parameter">policy assertion parameter</a>
-      </dt><dd><p>A <b>policy assertion parameter</b> 
-	    qualifies the behavior indicated by a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy assertion parameter</b>
+                        qualifies the behavior indicated by a <a title="policy assertion" href="#policy_assertion">policy
+                            assertion</a>.</p></dd><dt class="label">
          <a href="#policy_assertion_type">policy assertion type</a>
-      </dt><dd><p>A <b>policy assertion type</b> 
-	    represents a class of <a title="policy assertion" href="#policy_assertion">policy assertions</a> and implies a 
-	    schema for the assertion and assertion-specific semantics.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy
+                            assertion type</b> represents a class of <a title="policy assertion" href="#policy_assertion">policy assertions</a> and implies a schema
+                        for the assertion and assertion-specific semantics.</p></dd><dt class="label">
          <a href="#policy_attachment">policy attachment</a>
-      </dt><dd><p>A 
-	    <b>policy attachment</b> is a mechanism for associating 
-	    <a title="policy" href="#policy">policy</a> with one or more <a title="policy scope" href="#policy_scope">policy scopes</a>.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy
+                                        attachment</b> is a mechanism for associating <a title="policy" href="#policy">policy</a> with one or more <a title="policy scope" href="#policy_scope">policy scopes</a>.</p></dd><dt class="label">
          <a href="#policy_expression">policy expression</a>
-      </dt><dd><p>A <b>policy expression</b> 
-		is an XML Infoset representation of a <a title="policy" href="#policy">policy</a>, 
-		either in a normal form or in an equivalent compact form.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy expression</b>
+                    is an XML Infoset representation of a <a title="policy" href="#policy">policy</a>,
+                    either in a normal form or in an equivalent compact form.</p></dd><dt class="label">
          <a href="#policy_scope">policy scope</a>
-      </dt><dd><p>A <b>policy scope</b> is a collection of 
-	    <a title="policy subject" href="#policy_subject">policy subjects</a> to which a policy may apply.</p></dd><dt class="label">
+      </dt><dd><p>A <b>policy
+                                    scope</b> is a collection of <a title="policy subject" href="#policy_subject">policy subjects</a> to which a policy may
+                                apply.</p></dd><dt class="label">
          <a href="#policy_subject">policy subject</a>
-      </dt><dd><p>A <b>policy subject</b> is an entity 
-	    (e.g., an endpoint, message, resource, operation) with which a 
-	    <a title="policy" href="#policy">policy</a> can be associated. </p></dd><dt class="label">
+      </dt><dd><p>A <b>policy subject</b> is
+                        an entity (e.g., an endpoint, message, resource, operation) with which a
+                            <a title="policy" href="#policy">policy</a> can be associated. </p></dd><dt class="label">
          <a href="#policy_vocabulary">policy vocabulary</a>
-      </dt><dd><p>A <b>policy vocabulary</b> is the set of all 
-	    <a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a policy.</p></dd></dl></div></div><div class="div1">
+      </dt><dd><p>A
+                            <b>policy vocabulary</b> is the set of all <a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a
+                        policy.</p></dd></dl></div></div><div class="div1">
 <h2><a name="Policy_Model" id="Policy_Model"></a>3. Policy Model</h2><p>This section defines an abstract model for policies and for operations upon policies.</p><p>The descriptions below use XML Infoset terminology for convenience of description.
                 However, this abstract model itself is independent of how it is represented as an
                 XML Infoset. </p><div class="div2">
@@ -958,7 +963,8 @@
                                     </span></span>resolvable; retrieval mechanisms are beyond the scope of this
                                     specification. After retrieval, there is no requirement to check
                                     that the retrieved policy expression is associated (Section
-                                        <a href="#Policy_Identification"><b>4.2 Policy Identification</b></a>) with this IRI. <span class="diff-chg"><span>&nbsp; </span></span><span class="diff-add"><span>The
+                                        <a href="#Policy_Identification"><b>4.2 Policy Identification</b></a>) with this IRI.  
+<span class="diff-del"><span>The </span></span><span class="diff-add"><span>&nbsp; The
                                     </span></span>IRI included in the retrieved policy expression, if any,
                                         <span class="rfc2119">MAY</span> be different than the IRI used to
                                     retrieve the policy expression. </p></dd><dt class="label">
@@ -1451,12 +1457,15 @@
     on public-ws-policy@w3.org</a> are also gratefully
     acknowledged.
   </p></div><div class="div1">
-<h2><a name="change-description" id="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated 17 November, 2006
-    <span class="diff-del"><span>is </span></span><span class="diff-add"><span>is
-                </span></span>below:</p><ul><li><p>Reorganized the content in Section <a href="#Compact_Policy_Expression"><b>4.3 Compact Policy Expression</b></a>.</p></li><li><p>Documented the schema outline &amp; description for policy operators
-                            (<code>wsp:Policy</code>, <code>wsp:All</code> and <code>wsp:ExactlyOne</code>
-                        elements) in Section <a href="#Policy_Operators"><b>4.3.3 Policy Operators</b></a>.</p></li><li><p>Explicitly described the interaction between Web Services Policy and XML Base
-                        in Section <a href="#IRI_Policy_Expressions"><b>4.6 Use of IRIs in Policy Expressions</b></a>.</p></li></ul></div><div class="div1">
+<h2><a name="change-description" id="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated <span class="diff-chg"><span>28 February, </span></span><span class="diff-add"><span>2007</span></span><span class="diff-del"><span>2006
+    is </span></span><span class="diff-add"><span>is
+                </span></span>below:</p><ul><span class="diff-del"><span>Reorganized the content in Section 
+        .
+        Documented the schema outline &amp; description for policy operators 
+        (wsp:Policy, wsp:All and wsp:ExactlyOne elements)
+        in Section .
+        </span></span><li><p><span class="diff-add"><span>None.</span></span><span class="diff-del"><span>Explicitly described the interaction between Web Services Policy and XML Base in
+        Section .</span></span></p></li></ul></div><div class="div1">
 <h2><a name="change-log" id="change-log"></a>E. Web Services Policy 1.5 - Framework Change Log (Non-Normative)</h2><a name="ws-policy-framework-changelog-table"></a><table border="1"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><tr><td colspan="1" rowspan="1">20060712</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated the list of editors. Completed action items <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action12">12</a>, <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action16">16</a> and <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action20">20</a> from the Austin F2F.</td></tr><tr><td colspan="1" rowspan="1">20060718</td><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">Completed action items: RFC2606 for domain names <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action09">09</a> (note: PLH had already done but it ddn't show up in the
                             change log) </td></tr><tr><td colspan="1" rowspan="1">20060726</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Incorporated the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0107.html">XML namespace URI versioning policy</a> adopted by the WG. </td></tr><tr><td colspan="1" rowspan="1">20060803</td><td colspan="1" rowspan="1">PY</td><td colspan="1" rowspan="1">Completed Issue: <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3551">3551</a>
                             Misc updates throughout. </td></tr><tr><td colspan="1" rowspan="1">20060808</td><td colspan="1" rowspan="1">PY</td><td colspan="1" rowspan="1">Completed action item: <a href="http://www.w3.org/2006/07/13-ws-policy-minutes.html#action20">20</a> to highlight infoset terms uniformly. </td></tr><tr><td colspan="1" rowspan="1">20060808</td><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">Completed action items: <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action15">15</a> as early as possible in the doc, use the definition that
@@ -1503,4 +1512,4 @@
                             to <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4379"><span class="diff-add"><span>issue 4379</span></span></a>
                             with minor editorial revision (editors action 
                             <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/181"><span class="diff-add"><span>181</span></span></a>).
-                            </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
+                            </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070321</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Reset Section <a href="#change-description"><b>D. Changes in this Version of the Document</b></a>. </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: wsdl11elementidentifiers.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/wsdl11elementidentifiers.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- wsdl11elementidentifiers.xml	22 Mar 2007 03:48:55 -0000	1.17
+++ wsdl11elementidentifiers.xml	22 Mar 2007 07:11:39 -0000	1.18
@@ -8,7 +8,7 @@
 	<!ENTITY prevloc "http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131">
 	<!ENTITY wsdl-ns "http://schemas.xmlsoap.org/wsdl/">
 ]>
-<spec w3c-doctype="wd" role="&document.role;">
+<spec w3c-doctype="&doctype.wsdl11ei;" role="&document.role;">
 	<header>
 		<title>&wsdl11ei.title;</title>
 		<w3c-designation>&w3c-designation-wsdl11ei;</w3c-designation>

Index: entitiesedcopy.dtd
===================================================================
RCS file: /sources/public/2006/ws/policy/entitiesedcopy.dtd,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- entitiesedcopy.dtd	22 Mar 2007 03:33:41 -0000	1.8
+++ entitiesedcopy.dtd	22 Mar 2007 07:11:39 -0000	1.9
@@ -45,6 +45,16 @@
 
 <!ENTITY document.role "editors-copy">
 
+<!ENTITY doctype.framework "wd">
+
+<!ENTITY doctype.attachment "wd">
+
+<!ENTITY doctype.primer "wd">
+
+<!ENTITY doctype.guidelines "wd">
+
+<!ENTITY doctype.wsdl11ei "wd">
+
 <!ENTITY status "<status><p></p></status>">
 
 <!ENTITY altlocs.framework "">

Index: entitieswd.dtd
===================================================================
RCS file: /sources/public/2006/ws/policy/entitieswd.dtd,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- entitieswd.dtd	22 Mar 2007 03:33:41 -0000	1.9
+++ entitieswd.dtd	22 Mar 2007 07:11:39 -0000	1.10
@@ -32,16 +32,21 @@
 <!ENTITY document.role "public">
 
 <!-- The following is used for framework and attachment document .-->
-<!ENTITY document.status "W3C Working Draft">
-<!ENTITY w3c.status "WD">
+<!ENTITY document.status "W3C Candidate Recommendation">
+<!ENTITY w3c.status "CR">
+<!ENTITY doctype.framework "wd">
+<!ENTITY doctype.attachment "wd">
 
 <!-- The following is used for primer, guidelines and elementID documents.-->
 <!ENTITY document.status.primer "W3C Working Draft">
 <!ENTITY w3c.status.primer "WD">
 <!ENTITY document.status.guidelines "W3C Working Draft">
 <!ENTITY w3c.status.guidelines "WD">
-<!ENTITY document.status.wsdl11ei "W3C Working Draft">
-<!ENTITY w3c.status.wsdl11ei "WD">
+<!ENTITY document.status.wsdl11ei "W3C Working Group Note">
+<!ENTITY w3c.status.wsdl11ei "NOTE">
+<!ENTITY doctype.primer "wd">
+<!ENTITY doctype.guidelines "wd">
+<!ENTITY doctype.wsdl11ei "wd">
 
 <!ENTITY w3c-designation-framework
   "&w3c.tr.latest;/&draft.year;/&w3c.status;-&framework.prefix;-&draft.date;">

Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -d -r1.45 -r1.46
--- ws-policy-primer.xml	22 Mar 2007 05:42:14 -0000	1.45
+++ ws-policy-primer.xml	22 Mar 2007 07:11:39 -0000	1.46
@@ -11,7 +11,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="wd" role="&document.role;">
+<spec w3c-doctype="&doctype.primer;" role="&document.role;">
   <header>
     <title>&primer.title;</title>
     <w3c-designation>&w3c-designation-primer;</w3c-designation>

Index: build.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/build.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -d -r1.25 -r1.26
--- build.xml	16 Mar 2007 13:15:02 -0000	1.25
+++ build.xml	22 Mar 2007 07:11:39 -0000	1.26
@@ -5,6 +5,7 @@
     <path id="saxon8.classpath">
 <pathelement location="saxon8/saxon8.jar"/>
 </path>
+	<property name="htmlOutputDir" value=""/>
 	<property name="stylesheet" value="xmlspec-policy.xsl"/>
 	<property name="glossary"
 	value="extract-glist.xsl"/>
@@ -12,6 +13,7 @@
 	<property name="last-public-draft" value="20070228"/>
 	<property name="primer-last-public-draft" value="20061221"/>
 	<property name="guidelines-last-public-draft" value="20061221"/>
+	<property name="wsdl11elementidentifiers-last-public-draft" value="20070131"/>
 	
 	<target name="clean">
 		<delete quiet="true" file="ws-policy-framework.html"/>
@@ -68,35 +70,35 @@
 	<java fork="true" classname="net.sf.saxon.Transform">
 <classpath refid="saxon8.classpath"/>
 <arg value="-o"/>
-<arg value="ws-policy-framework.html"/>
+<arg value="${htmlOutputDir}ws-policy-framework.html"/>
 <arg value="ws-policy-framework.xml"/>
 <arg value="${stylesheet}"/>
 </java>
 <java fork="true" classname="net.sf.saxon.Transform">
 <classpath refid="saxon8.classpath"/>
 <arg value="-o"/>
-<arg value="ws-policy-attachment.html"/>
+<arg value="${htmlOutputDir}ws-policy-attachment.html"/>
 <arg value="ws-policy-attachment.xml"/>
 <arg value="${stylesheet}"/>
 </java>
 <java fork="true" classname="net.sf.saxon.Transform">
 <classpath refid="saxon8.classpath"/>
 <arg value="-o"/>
-<arg value="ws-policy-primer.html"/>
+<arg value="${htmlOutputDir}ws-policy-primer.html"/>
 <arg value="ws-policy-primer.xml"/>
 <arg value="${stylesheet}"/>
 </java>
 <java fork="true" classname="net.sf.saxon.Transform">
 <classpath refid="saxon8.classpath"/>
 <arg value="-o"/>
-<arg value="ws-policy-guidelines.html"/>
+<arg value="${htmlOutputDir}ws-policy-guidelines.html"/>
 <arg value="ws-policy-guidelines.xml"/>
 <arg value="${stylesheet}"/>
 </java>
 		<java fork="true" classname="net.sf.saxon.Transform">
 		<classpath refid="saxon8.classpath"/>
 		<arg value="-o"/>
-		<arg value="wsdl11elementidentifiers.html"/>
+		<arg value="${htmlOutputDir}wsdl11elementidentifiers.html"/>
 		<arg value="wsdl11elementidentifiers.xml"/>
 		<arg value="${stylesheet}"/>
 		</java>		
@@ -135,7 +137,7 @@
       <arg value="ws-policy-framework-diff${last-public-draft}.xml"/>
       <classpath path="diffmk.jar:DiffMk.properties">    
       </classpath>
-    </java>
+    </java>      	
     <java classname="com.sun.xtc.diffmk.DiffMk" fork="true">
   <arg value="-doctype"/>    
       <arg value="xmlspec"/>
@@ -171,35 +173,54 @@
             <arg value="ws-policy-primer-diff${primer-last-public-draft}.xml"/>
             <classpath path="diffmk.jar:DiffMk.properties">    
             </classpath>
-        </java>      	
+        </java> 
+      	<java classname="com.sun.xtc.diffmk.DiffMk" fork="true">
+      	  <arg value="-doctype"/>    
+      	      <arg value="xmlspec"/>
+      	      <arg value="-diff"/>
+      	      <arg value="both"/>
+      	      <arg value="-words"/>
+      	      <arg value="wsdl11elementidentifiers-tr${wsdl11elementidentifiers-last-public-draft}.xml"/>
+      	      <arg value="wsdl11elementidentifiers.xml"/>
+      	      <arg value="wsdl11elementidentifiers-diff${wsdl11elementidentifiers-last-public-draft}.xml"/>
+      	      <classpath path="diffmk.jar:DiffMk.properties">    
+      	      </classpath>
+      	    </java>
       	<java fork="true" classname="net.sf.saxon.Transform">
       	<classpath refid="saxon8.classpath"/>
       		<arg value="-o"/>
-      		<arg value="ws-policy-framework-diff${last-public-draft}.html"/>
+      		<arg value="${htmlOutputDir}ws-policy-framework-diff${last-public-draft}.html"/>
       		<arg value="ws-policy-framework-diff${last-public-draft}.xml"/>
       		<arg value="diffspec.xsl"/>
       	</java>
       	<java fork="true" classname="net.sf.saxon.Transform">
       	      	<classpath refid="saxon8.classpath"/>
       	      		<arg value="-o"/>
-      	      		<arg value="ws-policy-attachment-diff${last-public-draft}.html"/>
+      	      		<arg value="${htmlOutputDir}ws-policy-attachment-diff${last-public-draft}.html"/>
       	      		<arg value="ws-policy-attachment-diff${last-public-draft}.xml"/>
       	      		<arg value="diffspec.xsl"/>
       	</java>
       	<java fork="true" classname="net.sf.saxon.Transform">
       	      	      	<classpath refid="saxon8.classpath"/>
       	      	      		<arg value="-o"/>
-      	      	      		<arg value="ws-policy-primer-diff${primer-last-public-draft}.html"/>
+      	      	      		<arg value="${htmlOutputDir}ws-policy-primer-diff${primer-last-public-draft}.html"/>
       	      	      		<arg value="ws-policy-primer-diff${primer-last-public-draft}.xml"/>
       	      	      		<arg value="diffspec.xsl"/>
       	      	</java>
       	<java fork="true" classname="net.sf.saxon.Transform">
       	      	      	<classpath refid="saxon8.classpath"/>
       	      	      		<arg value="-o"/>
-      	      	      		<arg value="ws-policy-guidelines-diff${guidelines-last-public-draft}.html"/>
+      	      	      		<arg value="${htmlOutputDir}ws-policy-guidelines-diff${guidelines-last-public-draft}.html"/>
       	      	      		<arg value="ws-policy-guidelines-diff${guidelines-last-public-draft}.xml"/>
       	      	      		<arg value="diffspec.xsl"/>
       	      	</java>	
+    	<java fork="true" classname="net.sf.saxon.Transform">
+          	      	      	<classpath refid="saxon8.classpath"/>
+          	      	      		<arg value="-o"/>
+          	      	      		<arg value="${htmlOutputDir}wsdl11elementidentifiers-diff${wsdl11elementidentifiers-last-public-draft}.html"/>
+          	      	      		<arg value="wsdl11elementidentifiers-diff${wsdl11elementidentifiers-last-public-draft}.xml"/>
+          	      	      		<arg value="diffspec.xsl"/>
+          	      	</java>	
       </target>
   
 	<target name="changelog" description="Generate XML out of the CVS change log">

Index: ws-policy-framework-tr20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework-tr20070228.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-framework-tr20070228.xml	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-framework-tr20070228.xml	22 Mar 2007 07:11:39 -0000	1.2
@@ -11,7 +11,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="cr" role="&document.role;">
+<spec w3c-doctype="&doctype.framework;" role="&document.role;">
     <header>
         <title>&framework.title;</title>
         <w3c-designation>&w3c-designation-framework;</w3c-designation>

Index: ws-policy-attachment.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment.xml,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -d -r1.95 -r1.96
--- ws-policy-attachment.xml	22 Mar 2007 05:42:15 -0000	1.95
+++ ws-policy-attachment.xml	22 Mar 2007 07:11:39 -0000	1.96
@@ -11,7 +11,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="wd" role="&document.role;">
+<spec w3c-doctype="&doctype.attachment;" role="&document.role;">
 <header>
 <title>&attachment.title;</title>
 <w3c-designation>&w3c-designation-attachment;</w3c-designation>

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -d -r1.48 -r1.49
--- ws-policy-guidelines.xml	22 Mar 2007 05:42:15 -0000	1.48
+++ ws-policy-guidelines.xml	22 Mar 2007 07:11:39 -0000	1.49
@@ -10,7 +10,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="wd" role="&document.role;">
+<spec w3c-doctype="&doctype.guidelines;" role="&document.role;">
   <header>
     <title>&guidelines.title;</title>
     <w3c-designation>&w3c-designation-guidelines;</w3c-designation>

Index: ws-policy-framework.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.xml,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -d -r1.127 -r1.128
--- ws-policy-framework.xml	22 Mar 2007 05:42:14 -0000	1.127
+++ ws-policy-framework.xml	22 Mar 2007 07:11:39 -0000	1.128
@@ -11,7 +11,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="wd" role="&document.role;">
+<spec w3c-doctype="&doctype.framework;" role="&document.role;">
     <header>
         <title>&framework.title;</title>
         <w3c-designation>&w3c-designation-framework;</w3c-designation>

Index: ws-policy-primer-diff20061221.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20061221.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-primer-diff20061221.html	16 Mar 2007 13:15:02 -0000	1.2
+++ ws-policy-primer-diff20061221.html	22 Mar 2007 07:11:39 -0000	1.3
@@ -77,7 +77,9 @@
 <h1><a name="title" id="title"></a>Web Services Policy 1.5 - Primer</h1>
 <h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
       <a href="ws-policy-primer.html">ws-policy-primer.html</a>
-    </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematis">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
+    </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</a></dd><div class="diff-add"><dt>Previous version:</dt><dd>
+            <a href="http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221"><span class="diff-add"><span>http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221</span></span></a>
+        </dd></div><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">traemark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
 <h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
         <em>Web Services Policy 1.5 - Primer</em> is an introductory description of the Web Services Policy
         language. This document describes the policy language features using numerous examples. The
@@ -111,10 +113,10 @@
 &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="#ignorable-and-versioning">Ignorable and Versioning</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>
-4. <a href="#conclusion">Conclusion</a><br>
+4. <a href="#versioning-policy-language">Versioning Policy Language</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>
+5. <a href="#conclusion">Conclusion</a><br>
 </p>
 <h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>
 B. <a href="#xml-namespaces">XML Namespaces</a><br>
@@ -137,9 +139,10 @@
         that provides more in-depth materials for policy implementers and assertion authors. It
         explains the basics of normalizing policy expressions, merging policies, determining the
         compatibility (intersection) of policies, the policy data model, the policy expression and
-        the extensibility points built into the Web Services Policy language.</p><p>The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors 
+        the extensibility points built into the Web Services Policy language.</p><p><span class="diff-add"><a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a></span> <span class="diff-add"><span>provides examples and best practices on 
+      versioning of the policy language itself, mostly intended for policy implementers.</span></span></p><div class="diff-add"><p class="diff-add">The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors 
          specification provides guidelines for designing policy assertions and enumerates 
-         the minimum requirements for describing policy assertions in specifications.</p><p>This is a non-normative document and does not provide a definitive specification of the Web
+         the minimum requirements for describing policy assertions in specifications.</p></div><p>This is a non-normative document and does not provide a definitive specification of the Web
         Services Policy language. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the namespaces that are used in
         this document. (XML elements without a namespace prefix are from the Web Services Policy XML
         Namespace.)</p></div><div class="div1">
@@ -178,21 +181,21 @@
             <code>ExactlyOne</code> and <code>PolicyReference</code> - and one attribute -
             <code>wsp:Optional</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;
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-1. </span>SOAP Message</i></p><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;soap:Envelope&gt;
   &lt;soap:Header&gt;
-   &lt;wsa:To&gt;http://stock.contoso.com/realquote&lt;/wsa:To&gt;
-   &lt;wsa:Action&gt;http://stock.contoso.com/GetRealQuote&lt;/wsa:Action&gt;
+            &lt;wsa:To&gt;http://x.example.com/realquote&lt;/wsa:To&gt;
+            &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
   &lt;/soap:Header&gt;
   &lt;soap:Body&gt;...&lt;/soap:Body&gt;
-&lt;/soap:Envelope&gt;</pre></div></div><p>This message uses message addressing headers. The <code>wsa:To</code>
+&lt;/soap:Envelope&gt;</span></span></pre></div></div><p>This message uses message addressing headers. The <code>wsa:To</code>
           and <code>wsa:Action</code> header blocks identify the destination and the semantics
           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. 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. The developer has Contoso’s advertised WSDL description of these Web
-          services. Contoso requires the use of addressing headers for messaging. Just the WSDL
+          that retrieves real time stock quote information from <span class="diff-chg"><span>Company-X, </span></span>Ltd. <span class="diff-chg"><span>Company-X </span></span>supplies real
+          time data using Web services. The developer has <span class="diff-chg"><span>Company-X’s </span></span>advertised WSDL description of these Web
+          services. <span class="diff-chg"><span>Company-X </span></span>requires the use of addressing headers for messaging. Just the WSDL
           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,
@@ -200,14 +203,14 @@
             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, the developer 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 <span class="diff-chg"><span>Company-X </span></span>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
+          <span class="diff-chg"><span>Company-X </span></span>may augment the service WSDL description with a policy that requires the use of
           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
+          addressing automatically.</p><p>How does <span class="diff-chg"><span>Company-X </span></span>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;
@@ -215,7 +218,7 @@
           The policy expression in the above example consists of a Policy main  
           element and a child element wsap:UsingAddressing. Child elements of  
           the 
-          Policy element are policy assertions. Contoso attaches the above  
+          Policy element are policy assertions. <span class="diff-chg"><span>Company-X </span></span>attaches the above  
           policy expression to a WSDL binding description.
           </p><div class="diff-add"><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span><span class="diff-add"><span>Policy Expression Attached to Binding</span></span></i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" &gt;
@@ -237,7 +240,7 @@
           reference WSDL constructs (such as port, binding and portType), Web Services Policy does
           not require a message to reference a policy expression though the policy expression
           describes the message.</p></div><div class="div2">
-<h3><a name="secure-message" id="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, Contoso requires the use of
+<h3><a name="secure-message" id="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, <span class="diff-chg"><span>Company-X </span></span>requires the use of
           transport-level security for protecting messages.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-4. </span>Secure Message</i></p><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;soap:Envelope&gt;
   &lt;soap:Header&gt;
@@ -247,15 +250,15 @@
        &lt;wsu:Expires&gt;2006-01-19T02:54:53.914Z&lt;/u:Expires&gt;
       &lt;/wsu:Timestamp&gt;
     &lt;/wss:Security&gt;
-   &lt;wsa:To&gt;http://real.contoso.com/quote&lt;/wsa:To&gt;
-   &lt;wsa:Action&gt;http://real.contoso.com/GetRealQuote&lt;/wsa:Action&gt;
+   &lt;wsa:To&gt;http://x.example.com/quote&lt;/wsa:To&gt;
+   &lt;wsa:Action&gt;http://x.example.com/GetRealQuote&lt;/wsa:Action&gt;
   &lt;/soap:Header&gt;
   &lt;soap:Body&gt;...&lt;/soap:Body&gt;
 &lt;/soap:Envelope&gt;</span></span></pre></div></div><p>The SOAP message in the example above includes security timestamps that express creation
-          and expiration times of this message. Contoso requires the use of security timestamps and
+          and expiration times of this message. <span class="diff-chg"><span>Company-X </span></span>requires the use of security timestamps and
           transport-level security - such as <code>HTTPS</code> – for protecting messages. (The
           prefixes <code>wss</code> and <code>wsu</code> are used here to denote the Web Services
-          Security and Utility namespaces.)</p><p>Similar to the use of addressing, Contoso indicates the use of transport-level security
+          Security and Utility namespaces.)</p><p>Similar to the use of addressing, <span class="diff-chg"><span>Company-X </span></span>indicates the use of transport-level security
           using a policy expression. The example below illustrates a policy expression that requires
           the use of addressing and transport-level security for securing messages.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-5. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
@@ -269,13 +272,13 @@
           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" id="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
+<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how <span class="diff-chg"><span>Company-X </span></span>uses policy expressions and assertions for representing
           behaviors that must be engaged for a Web service interaction. What is a policy assertion?
           What role does it play? In brief, a policy assertion is a piece of service metadata, and
           it identifies a domain (such as messaging, security, reliability and transaction) specific
-          behavior that is a requirement. Contoso uses a policy assertion to convey a condition
+          behavior that is a requirement. <span class="diff-chg"><span>Company-X </span></span>uses a policy assertion to convey a condition
           under which they offer a Web service. A policy-aware client can recognize policy
-          assertions and engage these behaviors automatically.</p><p>Providers, like Contoso, have the option to combine behaviors for an interaction from
+          assertions and engage these behaviors automatically.</p><p>Providers, like <span class="diff-chg"><span>Company-X, </span></span>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 can use policy-aware clients that recognize these
@@ -304,17 +307,17 @@
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-6. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre>&lt;All&gt;
   &lt;wsap:UsingAddressing /&gt;
   &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
-&lt;/All&gt;</pre></div></div><p>In addition to requiring the use of addressing, Contoso allows either the use of
+&lt;/All&gt;</pre></div></div><p>In addition to requiring the use of addressing, <span class="diff-chg"><span>Company-X </span></span>allows either the use of
           transport- or message-level security for protecting messages. Web Services Policy language
           can indicate this choice of behaviors in a machine-readable form. To indicate the use of
-          message-level security for protecting messages, Contoso uses the
+          message-level security for protecting messages, <span class="diff-chg"><span>Company-X </span></span>uses the
             <code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-7. </span>Asymmetric Binding Security Policy Assertion</i></p><div class="exampleInner"><pre>&lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;</pre></div></div><p>The <code>sp:AsymmetricBinding</code> element is a policy assertion. (The prefix
           <code>sp</code> is used here to denote the Web Services Security Policy namespace.) This
           assertion identifies the use of message-level security – such as <em>WS-Security
           1.0</em> - for protecting messages. Policy-aware clients can recognize this policy
           assertion, engage message-level security for protecting messages and use headers such
-            as <code>wss:Security</code> in SOAP Envelopes.</p><p>To allow the use of either transport- or message-level security, Contoso uses the
+            as <code>wss:Security</code> in SOAP Envelopes.</p><p>To allow the use of either transport- or message-level security, <span class="diff-chg"><span>Company-X </span></span>uses the
             <code>ExactlyOne</code> policy operator. Policy assertions combined using the
             <code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
           the assertions. The policy expression in the example below requires the use of either
@@ -322,7 +325,7 @@
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-8. </span>Transport- or Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre>&lt;ExactlyOne&gt;
   &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
   &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
-&lt;/ExactlyOne&gt;</pre></div></div><p>Contoso requires the use of addressing and requires the use of either transport- or
+&lt;/ExactlyOne&gt;</pre></div></div><p><span class="diff-chg"><span>Company-X </span></span>requires the use of addressing and requires the use of either transport- or
           message-level security for protecting messages. They represent this combination using
             the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
           to represent different combinations of behaviors (capabilities and requirements). The
@@ -334,13 +337,13 @@
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
     &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
   &lt;/ExactlyOne&gt;
-&lt;/All&gt;</pre></div></div><p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
+&lt;/All&gt;</pre></div></div><p>Using this policy expression, <span class="diff-chg"><span>Company-X </span></span>gives the choice of mechanisms for protecting
           messages to clients (or requesters).</p></div><div class="div2">
-<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, Contoso learns that a significant number of their
+<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, <span class="diff-chg"><span>Company-X </span></span>learns that a significant number of their
           customers prefer to use the Optimized MIME Serialization (as defined in the MTOM
-          specification) for sending and receiving messages. Contoso adds optional support for the
+          specification) for sending and receiving messages. <span class="diff-chg"><span>Company-X </span></span>adds optional support for the
           Optimized MIME Serialization and expresses this optional behavior in a machine-readable
-          form.</p><p>To indicate the use of optimization using the Optimized MIME Serialization, Contoso uses
+          form.</p><p>To indicate the use of optimization using the Optimized MIME Serialization, <span class="diff-chg"><span>Company-X </span></span>uses
           the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 2-10. </span>Optimized MIME Serialization Policy Assertion</i></p><div class="exampleInner"><pre>&lt;mtom:OptimizedMimeSerialization /&gt;</pre></div></div><p>The <code>mtom:OptimizedMimeSerialization</code> element is a policy assertion. (The
           prefix <code>mtom</code> is used here to denote the Optimized MIME Serialization Policy
@@ -348,7 +351,7 @@
           as required for request and response 
           messages. Policy-aware clients can recognize this policy assertion and engage Optimized
           MIME Serialization for messages. The semantics of this assertion are reflected in
-          messages: they use an optimized wire format (MIME Multipart/Related serialization).</p><p>Like Contoso’s optional support for Optimized MIME Serialization, there are behaviors
+          messages: they use an optimized wire format (MIME Multipart/Related serialization).</p><p>Like <span class="diff-chg"><span>Company-X’s </span></span>optional support for Optimized MIME Serialization, there are behaviors
           that may be engaged (in contrast to must be engaged) for a Web service interaction. A
           service provider will not fault if these behaviors are not engaged. Policy assertions can
           be marked optional to represent behaviors that may be engaged for an interaction. A policy
@@ -371,7 +374,7 @@
     &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
     &lt;sp:AsymmetricBinding&gt;…&lt;/sp:AsymmetricBinding&gt;
   &lt;/ExactlyOne&gt;
-&lt;/All&gt;</pre></div></div><p>Contoso is able to meet their customer needs by adding optional support for the Optimized
+&lt;/All&gt;</pre></div></div><p><span class="diff-chg"><span>Company-X </span></span>is able to meet their customer needs by adding optional support for the Optimized
           <span class="diff-del"><span>MIME </span></span><span class="diff-add"><span>MIME 
         </span></span>Serialization. <span class="diff-add"><span>Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and 
         detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization. 
@@ -381,12 +384,12 @@
         about the absence of that policy assertion. See section 
         </span></span><span class="diff-add"><a href="#attaching-policy-expressions-to-wsdl"><b>2.11 Attaching Policy Expressions to WSDL</b></a></span> <span class="diff-add"><span>on the absence of policy expressions.</span></span></p></div><div class="diff-add"><div class="div2">
 <h3><a name="ignorable-policy-assertions" id="ignorable-policy-assertions"></a>2.7 <span class="diff-add"><span>Ignorable Policy Expressions</span></span></h3><p>
-          <span class="diff-add"><span>Suppose Contoso decides that it will log SOAP messages sent and received in an exchange. 
+          <span class="diff-add"><span>Suppose Company-X decides that it will log SOAP messages sent and received in an exchange. 
           This behavior has no direct impact on the messages sent on the wire, and does not affect interoperability. 
-          Some parties might have a concern about such logging and might decide not to interact with Contoso knowing 
-          that such logging is performed.  To address this concern, Contoso includes a Logging assertion in its policy to enable 
+          Some parties might have a concern about such logging and might decide not to interact with Company-X knowing 
+          that such logging is performed.  To address this concern, Company-X includes a Logging assertion in its policy to enable 
           such parties to be aware of logging. By marking the Logging assertion with the </span></span><code><span class="diff-add"><span>wsp:Ignorable</span></span></code> <span class="diff-add"><span>attribute with a
-           value of "true" Contoso indicates that a requester may choose to either ignore such assertions or to consider 
+           value of "true" Company-X indicates that a requester may choose to either ignore such assertions or to consider 
            them as part of policy intersection.  An assertion that may be ignored for policy intersection is called an 
            ignorable assertion.
           </span></span></p><p>
@@ -418,10 +421,10 @@
         two alternatives; one where the assertion A exists with @wsp:Ignorable=true and the 
         second where the assertion A does not exist.</span></span></p></div></div><div class="div2">
 <h3><a name="nested-policy-expressions" id="nested-policy-expressions"></a>2.9 Nested Policy Expressions</h3><p>In the previous sections, we considered two security policy assertions. In this section,
-          let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Contoso uses the
+          let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. <span class="diff-chg"><span>Company-X </span></span>uses the
             <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
+          protecting messages is not sufficient. To successfully interact with <span class="diff-chg"><span>Company-X’s </span></span>Web
           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
@@ -429,7 +432,7 @@
           machine-readable form.</p><p>A policy assertion – like the <code>sp:TransportBinding</code> - identifies a visible
           domain specific behavior that is a requirement. Given an assertion, there may be other
           dependent behaviors that need to be enumerated for a Web Service interaction. In the case
-          of the <code>sp:TransportBinding</code> policy assertion, Contoso needs to identify the
+          of the <code>sp:TransportBinding</code> policy assertion, <span class="diff-chg"><span>Company-X </span></span>needs to identify the
           use of a transport token, a secure transport, an algorithm suite for performing
           cryptographic operations, etc. A nested policy expression can be used to enumerate such
           dependent behaviors.</p><p>What is a nested policy expression? A nested policy expression is a policy expression
@@ -464,12 +467,27 @@
         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">
-<h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>2.10 Referencing Policy Expressions</h3><p>Contoso has numerous Web service offerings that provide different kinds of real-time
+          Web service developers.</p><div class="diff-add"><p class="diff-add"> <span class="diff-add"><span>In another example, WS-Security Policy defines a sp:HttpToken assertion to 
+          contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication 
+          and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a
+          policy expression by a provider, it will indicate that none of the dependent behaviors namely 
+          authentication or client certificate is required. A non-anonymous client who requires authentication 
+          or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.
+</span></span><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span> <span class="diff-add"><span>Empty Nested Assertion </span></span></i></p><div class="exampleInner"><pre>&lt;sp:TransportToken&gt;
+    &lt;wsp:Policy&gt;
+      &lt;sp:HttpsToken&gt; 
+       &lt;wsp:Policy/&gt; 
+      &lt;/sp:HttpsToken&gt; 
+    &lt;/wsp:Policy&gt;
+&lt;/sp:TransportToken&gt;
+</pre></div></div>
+ 	  </p></div></div><div class="div2">
+<h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>2.10 Referencing Policy Expressions</h3><p><span class="diff-chg"><span>Company-X </span></span>has numerous Web service offerings that provide different kinds of real-time
           quotes and book information on securities such as
             <code>GetRealQuote</code>, <code>GetRealQuotes</code> and
-          <code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
-          Contoso supports multiple WSDL bindings for these Web services. Contoso provides
+          <code>GetExtendedRealQuote</code>. To accommodate the diversity of <span class="diff-chg"><span>Company-X’s </span></span>customers,
+          <span class="diff-chg"><span>Company-X </span></span>supports multiple WSDL bindings for these Web services. <span class="diff-chg"><span>Company-X </span></span>provides
           consistent ways to interact with their services and wants to represent these capabilities
           and requirements consistently across all of their offerings without duplicating policy
           expressions multiple times. How? It is simple - a policy expression can be named and
@@ -488,19 +506,19 @@
           expression: the <code>wsu:Id</code> <code><span class="diff-add"><span>xml:id</span></span></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><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span>Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”common”&gt;
+<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;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsap:UsingAddressing /&gt;
 &lt;/Policy&gt;</pre></div></div><p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
           expression. The value of the <code>wsu:Id</code> attribute is an XML ID. The relative IRI
           for referencing this policy expression (within the same document) is <code>#common</code>.
-          If the policy document IRI is <code>http://real.contoso.com/policy.xml</code> then the
+          If the policy document IRI is <code><span class="diff-chg"><span>http://x.example.com/policy.xml</span></span></code> then the
           absolute IRI for referencing this policy expression is
-            <code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
+            <code><span class="diff-chg"><span>http://x.example.com/policy.xml#common. </span></span>(</code>The absolute IRI is formed by
           combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
-          attribute.)</p><p> <span class="diff-add"><span>In addition to the Example 2-12, Contoso could have used either the xml:id or wsu:Id.
+          attribute.)</p><p> <span class="diff-add"><span>In addition to the Example 2-12, Company-X could have used either the xml:id or wsu:Id.
           An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </span></span></p><div class="diff-add"><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span><span class="diff-add"><span>Common Policy Expression [xml:id]</span></span></i></p><div class="exampleInner"><pre>&lt;Policy xml:id=”common”&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span><span class="diff-add"><span>Common Policy Expression [xml:id]</span></span></i></p><div class="exampleInner"><pre>&lt;Policy xml:id=”common”&gt;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsap:UsingAddressing /&gt;
 &lt;/Policy&gt;</pre></div></div></div><div class="diff-add"><p class="diff-add"> <span class="diff-add"><span>Conditions and constraints on the use of the |xml:id| attribute in conjunction with Canonical
@@ -515,13 +533,13 @@
           </span></span></p></div></div><div class="diff-add"><p class="diff-add">For re-use, a <code>PolicyReference</code> element can be used to reference a policy
           expression as a standalone policy or within another policy expression. The example below
           is a policy expression that re-uses the common policy expression above.</p></div><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;PolicyReference URI="#common"/&gt;</pre></div></div><p>For referencing a policy expression within the same XML document, Contoso uses the
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;PolicyReference URI="#common"/&gt;</pre></div></div><p>For referencing a policy expression within the same XML document, <span class="diff-chg"><span>Company-X </span></span>uses the
             <code>wsu:Id</code> attribute for identifying a policy expression and an IRI to this ID
           value for referencing this policy expression using a <code>PolicyReference</code> element.</p><p>The example below is a policy expression that re-uses the common policy expression within
           another policy expression. This policy expression requires the use of addressing, one of
           transport- or message-level security for protecting messages and allows the use of
           optimization.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”secure”&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”secure”&gt;
   &lt;All&gt;
     &lt;PolicyReference URI="#common"/&gt;
     &lt;ExactlyOne&gt;     
@@ -535,12 +553,12 @@
           resides in. As such, referencing a policy expression using the <code>Name</code> attribute
           relies on additional out of band information. In the example below, the <code>Name</code>
           attribute identifies the policy expression. The IRI of this policy expression is
-            <code>http://real.contoso.com/policy/common</code>.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy Name=”http://real.contoso.com/policy/common”&gt;
+            <code><span class="diff-chg"><span>http://x.example.com/policy/common</span></span></code>.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;Policy Name=”http://x.example.com/policy/common”&gt;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsap:UsingAddressing /&gt;
-&lt;/Policy&gt;</pre></div></div><p>The example below is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre>&lt;PolicyReference URI="http://real.contoso.com/policy/common"/&gt;</pre></div></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>As policy expressions are composed from other policy expressions and
+&lt;/Policy&gt;</span></span></pre></div></div><p>The example below is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;PolicyReference URI="http://x.example.com/policy/common"/&gt;</span></span></pre></div></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>As policy expressions are composed from other policy expressions and
           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
@@ -551,38 +569,38 @@
           developed. Note that when a named expression has assertions that
           contains parametrized expressions, care must be given to ensure that the
           parameterized content is statically available to enable reuse.</span></span></p></div></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 Contoso’s customers use WSDL for building their client applications.
-          Contoso leverages this usage by attaching policy expressions to the WSDL binding
+<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 <span class="diff-chg"><span>Company-X’s </span></span>customers use WSDL for building their client applications.
+          <span class="diff-chg"><span>Company-X </span></span>leverages this usage by attaching policy expressions to the WSDL binding
           descriptions.</p><p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
           binding for an interface that provides real-time quotes and book information on
           securities. (The prefixes <code>wsdl</code> and <code>tns</code> are used here to denote
           the Web Services Description language XML namespace and target namespace of this WSDL
-          document.) To require the use of security for these offerings, Contoso attaches the secure
+          document.) To require the use of security for these offerings, <span class="diff-chg"><span>Company-X </span></span>attaches the secure
           policy expression in the previous section to this binding description. The WSDL
             <code>binding</code> element is a common policy attachment point. The secure policy
           expression attached to the <code>SecureBinding</code> WSDL binding description applies to
           any message exchange associated with any <code>port</code> that supports this binding
           description. This includes all the message exchanges described by operations in the
             <code>RealTimeDataInterface</code>.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-21. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
   &lt;PolicyReference URI="#secure" /&gt;
   &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
   …
-&lt;/wsdl:binding&gt;</pre></div></div><p>In addition to providing real-time quotes and book information on securities, Contoso
-          provides other kinds of data through Web services such as quotes delayed by 20 minutes and
+&lt;/wsdl:binding&gt;</pre></div></div><p>In addition to providing real-time quotes and book information on securities, <span class="diff-chg"><span>Company-X
+          </span></span>provides other kinds of data through Web services such as quotes delayed by 20 minutes and
           security symbols through Web services (for example <code>GetDelayedQuote</code>,
             <code>GetDelayedQuotes,</code>
-          <code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
+          <code>GetSymbol</code> and <code>GetSymbols</code>). <span class="diff-chg"><span>Company-X </span></span>does not require the use of
           security for these services, but requires the use of addressing and allows the use of
           optimization.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-21. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" &gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-22. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" &gt;
   &lt;PolicyReference URI="#common" /&gt;
   &lt;wsdl:operation name="GetDelayedQuote"&gt;…&lt;/wsdl:operation&gt;
   …
 &lt;/wsdl:binding&gt;</pre></div></div><p>In the example above, the <code>OpenBinding</code> WSDL binding description defines a
           binding for an interface that provides other kinds of data such as quotes delayed by 20
           minutes and security symbols. To require the use of addressing and allow the use of
-          optimization, Contoso attaches the common policy expression in the previous section to
+          optimization, <span class="diff-chg"><span>Company-X </span></span>attaches the common policy expression in the previous section to
           this binding description. As we have seen in the <code>SecureBinding</code> case, the
           common policy expression attached to the <code>OpenBinding</code> WSDL binding description
           applies to any message exchange associated with any <code>port</code> that supports this
@@ -594,7 +612,7 @@
           requirements that can be expressed as policy expressions, such as the use of addressing,
           security and optimization. Or, the service may not have such capabilities and
           requirements. A policy aware client should not conclude anything <span class="diff-del"><span>(other than ‘no claims’)
-          </span></span>about the absence of policy expressions.</p><p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
+          </span></span>about the absence of policy expressions.</p><p>Service providers, like <span class="diff-chg"><span>Company-X, </span></span>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
           can use a policy-aware client that recognizes these policy expressions in WSDL
@@ -603,8 +621,8 @@
           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 Contoso,
-          use policy expressions to represent combinations of capabilities and requirements. Web
+          one attribute - <code>wsp:Optional</code>. In practice, service providers, like <span class="diff-chg"><span>Company-X,
+          </span></span>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
           complexity is absorbed by policy-aware clients (or tools) and is invisible to these Web
@@ -624,9 +642,9 @@
           element plays two roles: wrapper element and operator.) Policy assertions can contain a
           nested policy expression. Policy assertions can also be marked optional to represent
           behaviors that may be engaged (capabilities) for an interaction. The optional marker is
-          the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p><p>Let us take a closer look at Contoso’s policy expression (see below) from the previous
+          the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p><p>Let us take a closer look at <span class="diff-chg"><span>Company-X’s </span></span>policy expression (see below) from the previous
           section.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Contoso’s Secure Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span><span class="diff-chg"><span>Company-X’s </span></span>Secure Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;All&gt;
     &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
     &lt;wsap:UsingAddressing /&gt;
@@ -678,11 +696,11 @@
     &lt;/All&gt;
   &lt;/ExactlyOne&gt;
 &lt;/Policy&gt;</pre></div></div><p>A policy expression in the compact form can be converted to the normal form. Web Services
-          Policy language describes the algorithm for this conversion.</p><p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
+          Policy language describes the algorithm for this conversion.</p><p>Let us re-consider <span class="diff-chg"><span>Company-X’s </span></span>policy expression (see the example below). <span class="diff-chg"><span>Company-X </span></span>requires
           the use of addressing and either transport- or message-level security and allows the use
           of optimization. This policy expression is in the compact form and has four policy
           alternatives for requesters:</p><ol class="enumar"><li><p>Requires the use of addressing and transport-level security</p></li><li><p>Requires the use of addressing and message-level security</p></li><li><p>Requires the use of optimization, addressing and transport-level security and</p></li><li><p>Requires the use of optimization, addressing and message-level security.</p></li></ol><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span>Contoso’s Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”secure”&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span><span class="diff-chg"><span>Company-X’s </span></span>Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre>&lt;Policy wsu:Id=”secure”&gt;
   &lt;All&gt;
     &lt;PolicyReference URI=”#common”/&gt;
     &lt;ExactlyOne&gt;
@@ -695,13 +713,13 @@
 &lt;Policy wsu:Id=”common”&gt;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsap:UsingAddressing /&gt;
-&lt;/Policy&gt;</pre></div></div><p>Let us look at the normal form for this policy expression. The example below is Contoso’s
-          policy expression in the normal form. As you can see, the compact form is less verbose
+&lt;/Policy&gt;</pre></div></div><p>Let us look at the normal form for this policy expression. The example below is <span class="diff-chg"><span>Company-X’s
+          </span></span>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">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Contoso’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span><span class="diff-chg"><span>Company-X’s </span></span>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;
        &lt;wsap:UsingAddressing/&gt;
@@ -733,7 +751,7 @@
           retrieve referenced policy expressions.</p></div><div class="div2">
 <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>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
+          this section, let us look at the policy data model.</p><p><span class="diff-chg"><span>Company-X </span></span>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
           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
@@ -773,16 +791,16 @@
               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" id="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
+<h3><a name="compatible-policies" id="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like <span class="diff-chg"><span>Company-X, </span></span>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
-          more policies.</p><p>The example below is a copy of Contoso’s policy expression (from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal Form for Policy Expressions</b></a>). As we saw before, Contoso offers four
+          more policies.</p><p>The example below is a copy of <span class="diff-chg"><span>Company-X’s </span></span>policy expression (from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal Form for Policy Expressions</b></a>). As we saw before, <span class="diff-chg"><span>Company-X </span></span>offers four
           policy alternatives. Of them, one of the policy alternatives requires the use of
           addressing and transport-level security.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span>Contoso’s Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span><span class="diff-chg"><span>Company-X’s </span></span>Policy Expression</i></p><div class="exampleInner"><pre><span class="diff-chg"><span>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
-    &lt;All&gt; &lt;!-- - - - - - - - - -  Contoso’s Policy Alternative (a) --&gt;
+    &lt;All&gt; &lt;!-- - - - - - - - - -  Company-X’s Policy Alternative (a) --&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) --&gt;
        &lt;wsap:UsingAddressing/&gt;
        &lt;!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) --&gt;
@@ -790,8 +808,8 @@
     &lt;/All&gt;
     …
   &lt;/ExactlyOne&gt;
-&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
+&lt;/Policy&gt;</span></span></pre></div></div><p>The client application developer's organization requires the use of addressing and transport-level security for any
+          interaction with <span class="diff-chg"><span>Company-X’s </span></span>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">
@@ -804,10 +822,10 @@
       &lt;wsap:UsingAddressing/&gt;
     &lt;/All&gt;
   &lt;/ExactlyOne&gt;
-&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
+&lt;/Policy&gt;</pre></div></div><p>The developer lets her policy-aware client select a compatible policy alternative in <span class="diff-chg"><span>Company-X’s
+          </span></span>policy. How does this client select a compatible policy alternative? It is simple – it
           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
+          expressions (the client’s and <span class="diff-chg"><span>Company-X’s) </span></span>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
@@ -816,14 +834,14 @@
           assertions have compatible nested policies. These two assertions are compatible because
           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 tje client’s policy alternative. Contoso’s policy alternative (a)
+          assertions (c1) and (c2) in <span class="diff-chg"><span>Company-X’s </span></span>policy alternative are compatible with policy
+          assertions (t2) and (t1) in tje client’s policy alternative. <span class="diff-chg"><span>Company-X’s </span></span>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
-          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
+          alternative in the other. For example, <span class="diff-chg"><span>Company-X’s </span></span>policy alternative (a) is compatible with
+          the client’s policy alternative. <span class="diff-chg"><span>Company-X’s </span></span>policy and the client’s policy are compatible because one
+          of <span class="diff-chg"><span>Company-X’s </span></span>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 <span class="diff-chg"><span>Company-X’s </span></span>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 class="diff-add"><div class="div3">
 <h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 <span class="diff-add"><span>Strict and Lax Policy Intersection</span></span></h4><p>
@@ -852,7 +870,7 @@
           information from the policy data model, such as the ignorable property of a
           policy assertion.
           </span></span></p></div></div></div><div class="div2">
-<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Contoso attached
+<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how <span class="diff-chg"><span>Company-X </span></span>attached
           their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
             <code>binding</code> element, a policy expression can be attached to other WSDL elements
           such as <code>service</code>, <code>port</code>, <code>operation</code>
@@ -875,7 +893,7 @@
             <code>message</code> element collectively represent the message policy subject for the
           fault message. Policy expressions associated with a message policy subject apply only to
           that message.</p><p>In the example below, the policy expression is attached to an endpoint policy subject.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Contoso’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span><span class="diff-chg"><span>Company-X’s </span></span>Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
   &lt;PolicyReference URI="#secure" /&gt;
   &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
   …
@@ -911,7 +929,7 @@
           in <a href="#Referencing_Policy_Expressions"><b>2.10 Referencing Policy Expressions</b></a>.
         </p></div><div class="div2">
 <h3><a name="combine-policies" id="combine-policies"></a>3.7 Combine Policies</h3><p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
-          Contoso could have used multiple policy expressions in a WSDL document. In the example
+          <span class="diff-chg"><span>Company-X </span></span>could have used multiple policy expressions in a WSDL document. In the example
           below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
           attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
           WSDL port descriptions.</p><div class="exampleOuter">
@@ -950,7 +968,7 @@
           the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code> WSDL port
           descriptions. The <code>#common2</code> policy expression has two policy alternatives. The
           <code>#secure2</code> policy expression has two policy alternatives. The
-          combination of these two policies is equivalent to Contoso’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
+          combination of these two policies is equivalent to <span class="diff-chg"><span>Company-X’s </span></span>secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
           words, the combination of two policies is the cross product of alternatives in these two
           policies.</p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
@@ -985,27 +1003,27 @@
           elements as policy assertions. <span class="diff-add"><span>The child elements of </span></span><span class="diff-add"><code><span class="diff-add"><span>wsp:PolicyReference</span></span></code></span> <span class="diff-add"><span>are ignored. 
           </span></span></p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p><p>Web Services Policy language enables simple versioning practices that allow requesters to
           continue the use of any older policy alternatives in a backward compatible manner. This
-          allows service providers, like Contoso, to deploy new behaviors using additional policy
+          allows service providers, like <span class="diff-chg"><span>Company-X, </span></span>to deploy new behaviors using additional policy
           assertions without breaking compatibility with clients that rely on any older policy
-          alternatives.</p><p>The example below represents a Contoso version 1 policy expression. This expression
+          alternatives.</p><p>The example below represents a <span class="diff-chg"><span>Company-X </span></span>version 1 policy expression. This expression
           requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Contoso’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span><span class="diff-chg"><span>Company-X’s </span></span>Version 1 Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
       &lt;wsap:UsingAddressing/&gt;
      &lt;sp:TransportBinding&gt;…&lt;/sp:TransportBinding&gt;
     &lt;/All&gt;
   &lt;/ExactlyOne&gt;
-&lt;/Policy&gt;</pre></div></div><p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
+&lt;/Policy&gt;</pre></div></div><p>Over time, <span class="diff-chg"><span>Company-X </span></span>adds support for advanced behaviors: requiring the use of addressing
           and message-level security for protecting messages. They added this advanced support
           without breaking compatibility with requesters that rely on addressing and transport-level
-          security. The example below is Contoso’s version 2 policy expression. In this version,
-          Contoso’s adds a new policy alternative that requires the use of addressing and
+          security. The example below is <span class="diff-chg"><span>Company-X’s </span></span>version 2 policy expression. In this version,
+          <span class="diff-chg"><span>Company-X’s </span></span>adds a new policy alternative that requires the use of addressing and
           message-level security. The clients that rely on addressing and transport-level security
-          may continue to interact with Contoso’s using the old policy alternative. Of course, these
+          may continue to interact with <span class="diff-chg"><span>Company-X’s </span></span>using the old policy alternative. Of course, these
           clients have the option to migrate from using old policy alternatives to new policy
           alternatives.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Contoso’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span><span class="diff-chg"><span>Company-X’s </span></span>Version 2 Policy Expression</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
       &lt;wsap:UsingAddressing/&gt;
@@ -1016,7 +1034,7 @@
       &lt;sp:AsymmetricBinding&gt;…&lt;/sp: AsymmetricBinding &gt;
     &lt;/All&gt;
   &lt;/ExactlyOne&gt;
-&lt;/Policy&gt;</pre></div></div><p>When Contoso added support for advanced behaviors, they spent time to plan for the
+&lt;/Policy&gt;</pre></div></div><p>When <span class="diff-chg"><span>Company-X </span></span>added support for advanced behaviors, they spent time to plan for the
           continued support for existing clients, the smooth migration from using current to
           advanced behaviors, and the switch to use only the advanced behaviors in the near future
           (i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
@@ -1024,8 +1042,8 @@
           to existing clients are required and these clients can smoothly migrate to new
           functionality when they choose to. This level of versioning support in policy enables the
           same class of versioning best practices built into WSDL constructs such as service, port
-          and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
-          incrementally deploy advanced behaviors, some requesters may not recognize these new
+          and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like <span class="diff-chg"><span>Company-X,
+          </span></span>incrementally deploy advanced behaviors, some requesters may not recognize these new
           policy assertions. As discussed before, these requesters may continue to interact using
           old policy alternatives. New policy assertions will emerge to represent new behaviors and
           slowly become part of everyday interoperable interaction between requesters and providers.
@@ -1045,39 +1063,37 @@
           ignorable.   When an alternative does have an expiry, it is usually
           useful to convey this information to help smooth the versioning process.
           </span></span></p><p>
-          <span class="diff-add"><span>Contoso could specify that the older policy alternative will expire at a
-          certain point in time using a Contoso specific expiry assertion.  The example
-          below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+          <span class="diff-add"><span>Company-X could specify that the older policy alternative will expire at a
+          certain point in time using a Company-X specific expiry assertion.  The example
+          below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
           Assertion.
           </span></span></p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span><span class="diff-add"><span>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
-              Assertion</span></span></i></p><div class="exampleInner"><pre>
-              &lt;Policy&gt;
-                &lt;ExactlyOne&gt;
-                  &lt;All&gt;
-                   &lt;contoso:EndOfLife wsp:Ignorable="true"/&gt;Mar-31-2008&lt;/contoso:EndOfLife&gt;
-                   &lt;wsap:UsingAddressing/&gt;
-                   &lt;sp:TransportBinding&gt;...&lt;/sp:TransportBinding&gt;
-                  &lt;/All&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span><span class="diff-add"><span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+              Assertion</span></span></i></p><div class="exampleInner"><pre>&lt;Policy&gt;
+  &lt;ExactlyOne&gt;
+    &lt;All&gt;
+      &lt;company-x:EndOfLife wsp:Ignorable="true"/&gt;Mar-31-2008&lt;/company-x:EndOfLife&gt;
+      &lt;wsap:UsingAddressing/&gt;
+      &lt;sp:TransportBinding&gt;...&lt;/sp:TransportBinding&gt;
+    &lt;/All&gt;
                 
-                  &lt;!-- NEW Policy Alternative --&gt;
-                  &lt;All&gt; 
-                    &lt;contoso:EndOfLife wsp:Ignorable="true"&gt;Mar-31-2999&lt;/contoso:EndOfLife&gt;
-                    &lt;wsap:UsingAddressing/&gt;
-                    &lt;sp:AsymmetricBinding&gt;...&lt;/sp:AsymmetricBinding&gt;
-                  &lt;/All&gt;
-                &lt;/ExactlyOne&gt;
-              &lt;/Policy&gt;
-          </pre></div></div><p>
+    &lt;!-- NEW Policy Alternative --&gt;
+    &lt;All&gt; 
+      &lt;company-x:EndOfLife wsp:Ignorable="true"&gt;Mar-31-2999&lt;/company-x:EndOfLife&gt;
+        &lt;wsap:UsingAddressing/&gt;
+        &lt;sp:AsymmetricBinding&gt;...&lt;/sp:AsymmetricBinding&gt;
+      &lt;/All&gt;
+  &lt;/ExactlyOne&gt;
+&lt;/Policy&gt;</pre></div></div><p>
           <span class="diff-add"><span>In this variant of the versioning scenario, the use of ignorable allows
           versioning related information to be conveyed and used where understood.
           </span></span></p><p>
           <span class="diff-add"><span>In a scenario such as this, where an assertion type is used for ignorable
           information, the use of strict or lax mode and presence or absence of the
-          assertion type in the first version are important decisions.  If Contoso wishes
+          assertion type in the first version are important decisions.  If Company-X wishes
           clients to always be able to ignore the assertion, particularly those using
           strict intersection, the first policy alternative offered should contain the
-          policy assertion type.  If Contoso adds the policy assertion type to a
+          policy assertion type.  If Company-X adds the policy assertion type to a
           subsequent alternative, then requesters using strict mode will not understand
           the assertion type and the alternative with the ignorable information will not
           be compatible with the older version of the alternative as per the intersection
@@ -1128,21 +1144,21 @@
           Nested policy assertions affect the outcome of policy intersection.</p><p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
           specific behavior: the use of a security token – such as SAML token - issued by a third
           party for protecting messages. This behavior is relevant to a Web service interaction. For
-          the sake of discussion, let us assume that Contoso requires the use of a SAML token issued
-          by a third party. Service providers, like Contoso, must convey this usage and all the
+          the sake of discussion, let us assume that <span class="diff-chg"><span>Company-X </span></span>requires the use of a SAML token issued
+          by a third party. Service providers, like <span class="diff-chg"><span>Company-X, </span></span>must convey this usage and all the
           necessary information to obtain this security token for Web service developers. This is a
-          key piece of metadata for a successful interaction with Contoso’s Web services.</p></div><div class="div2">
-<h3><a name="versioning-policy-language" id="versioning-policy-language"></a>3.10 Versioning Policy Language</h3><p> 
+          key piece of metadata for a successful interaction with <span class="diff-chg"><span>Company-X’s </span></span>Web services.</p></div></div><div class="diff-add"><div class="div1">
+<h2><a name="versioning-policy-language" id="versioning-policy-language"></a>4. Versioning Policy Language</h2><p> 
           <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">
               The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document.  User feedback is solicited
             </td></tr></table>
         </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new or modified constructs.  These constructs may be compatible or incompatible with previous versions.  Some of the possible new constructs that have been mentioned previously are: new operators, operator cardinality, policy identification, compact syntax, Policy Inclusion, security, referencing, attachment points, alternative
           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 with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element 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="div3">
-<h4><a name="versioning-policy-framework" id="versioning-policy-framework"></a>3.10.1 Policy Framework</h4><p>WS-Policy Framework 1.5 specifies that any <span class="diff-add"><span>child </span></span>element that is not known inside a Policy, 
+          The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element 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 <span class="diff-add"><span>child </span></span>element that is not known inside a Policy, 
           ExactlyOne or All will be treated as an assertion. The default value for <span class="diff-chg"><span>wsp:Optional="false". 
           After normalization, such an element </span></span>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 3-14. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<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;
     &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"&gt;
       ...
@@ -1152,7 +1168,7 @@
     &lt;/wsp:All&gt;
   &lt;/wsp:ExactlyOne&gt;
 &lt;/wsp:Policy&gt;</pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-2. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;wsp:ExactlyOne&gt;
     &lt;wsp:ExactlyOne&gt;
       &lt;wsp:All&gt;
@@ -1167,13 +1183,13 @@
   &lt;/wsp:ExactlyOne&gt;
 &lt;/wsp:Policy&gt;</pre></div></div><p>Alternatively, the wsp:Optional could be set to "true" on the choice, as
             in:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
 wsp:Optional="true"&gt;
       ...
   &lt;/wsp16:Choice&gt;
 &lt;/wsp:Policy&gt;</pre></div></div><p>The normalized form will be:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Normalized policy</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-4. </span>Normalized policy</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;wsp:ExactlyOne&gt;
      &lt;wsp:All&gt;
          &lt;wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"&gt;
@@ -1185,7 +1201,7 @@
 &lt;/wsp:Policy&gt;</pre></div></div><p>Because the wsp16:Choice alternative isn't understood in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored.  Policy intersection may be more difficult with such compatible extensions.  For example, the previous will "look"
             like it has a wsp16:Choice typed assertion.  To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done.  However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expected result.
           </p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-5. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;wsp:ExactlyOne&gt;
     &lt;wsp:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
       ...
@@ -1196,7 +1212,7 @@
   &lt;/wsp:ExactlyOne&gt;
 &lt;/wsp:Policy&gt;</pre></div></div><p>Notice that using a new namespace can result in backwards and forwards compatibility if normalization results in an optional alternative. </p><p>Best practice: insert new elements in an optional alternative or mark with wsp:Optional="true". </p><p>Incompatible versions of the Policy language may be indicated by a new namespace name for at least the new and/or incompatible elements or attributes.  Imagine that the Choice operator is required by a future version of Policy, then there will be a new namespace for the Policy element.  We use the wsp20 prefix to indicate a hypothetical Policy Language 2.0 that is intended to be incompatible with Policy Language
             1.5:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre>&lt;wsp20:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-6. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre>&lt;wsp20:Policy&gt;
   &lt;wsp20:ExactlyOne&gt;
     &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
       ...
@@ -1205,23 +1221,23 @@
   &lt;/wsp20:ExactlyOne&gt;
 &lt;/wsp20:Policy&gt; </pre></div></div><p>The new Policy operator could be embedded inside an existing Policy
             element:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-7. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
     &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
       ...
     &lt;/wsp20:Choice&gt;
     ...
 &lt;/wsp20:Policy&gt; </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation.  This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre>&lt;wsp20:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-8. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre>&lt;wsp20:Policy&gt;
   &lt;wsp:ExactlyOne&gt;
     &lt;wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2"&gt;
       ...
     &lt;/wsp20:Choice&gt;
     ...
   &lt;/wsp:ExactlyOne&gt;
-&lt;/wsp20:Policy&gt; </pre></div></div><p>It is difficult to predict whether this functionality would be useful.  The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div3">
-<h4><a name="versioning-policy-attachment" id="versioning-policy-attachment"></a>3.10.2 Policy Attachment</h4><p>Policy attachment provides WSDL 1.1 and UDDI attachment points.  It appears that exchange of Policy will be in the context of WSDL or UDDI.
+&lt;/wsp20:Policy&gt; </pre></div></div><p>It is difficult to predict whether this functionality would be useful.  The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div2">
+<h3><a name="versioning-policy-attachment" id="versioning-policy-attachment"></a>4.2 Policy Attachment</h3><p>Policy attachment provides WSDL 1.1 and UDDI attachment points.  It appears that exchange of Policy will be in the context of WSDL or UDDI.
             WRT WSDL, the policy model is an extension of the WSDL definition.  As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL.  One alternative is that there would be a separate WSDL for each version of Policy.  The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL.  </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre>&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-9. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre>&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
        &lt;wsoap12:binding style="document"
           transport="http://schemas.xmlsoap.org/soap/http" /&gt;
 	&lt;wsp:Policy&gt;
@@ -1243,7 +1259,7 @@
   &lt;wsdl11:operation name="GetLastTradePrice" &gt; ....
   ...</pre></div></div><p>The PolicyReference element is <span class="diff-add"><span>element or </span></span>attribute extensible.  
           One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-23. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre>&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-10. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre>&lt;wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" &gt;
        &lt;wsoap12:binding style="document"
           transport="http://schemas.xmlsoap.org/soap/http" /&gt;
 	&lt;wsp:Policy&gt;
@@ -1258,7 +1274,7 @@
 	&lt;/wsp:Policy&gt;
   &lt;wsdl11:operation name="GetLastTradePrice" &gt; ....
   ...</pre></div></div><p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored.  A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p><p>PolicyAttachment and AppliesTo also have extensibility points.  We choose not to illustrate these at this time.</p></div></div></div><div class="div1">
-<h2><a name="conclusion" id="conclusion"></a>4. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
+<h2><a name="conclusion" id="conclusion"></a>5. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
         (capabilities and requirements). Web service developers use policy-aware clients that
         understand policy expressions and engage the behaviors represented by providers
         automatically. These behaviors may include security, reliability, transaction, message
@@ -1438,14 +1454,14 @@
     on public-ws-policy@w3.org</a> are also gratefully
     acknowledged.
   </p></div><div class="div1">
-<h2><a name="change-description" id="change-description"></a>E. Changes in this Version of the Document (Non-Normative)</h2><p>A list of substantive changes since the Working Draft dated <span class="diff-chg"><span>21 December, </span></span>2006 is below:</p><ul><li><p><span class="diff-add"><span>TBD.</span></span><span class="diff-del"><span>Moved 
+<h2><a name="change-description" id="change-description"></a>E. Changes in this Version of the Document (Non-Normative)</h2><p>A list of <span class="diff-add"><span>major editorial</span></span><span class="diff-del"><span>substantive </span></span>changes since the Working Draft dated <span class="diff-chg"><span>21 December, </span></span>2006 is below:</p><ul><li><p><span class="diff-add"><span>Added</span></span><span class="diff-del"><span>Moved 
           Sections 
-            4.2 Parts of a Policy Assertion and 
+            4.2 Parts of </span></span>a <span class="diff-add"><span>new</span></span><span class="diff-del"><span>Policy Assertion and 
           
-            4.4.8 Versioning Policy Language into Section ; 
-          moved Section
+            4.4.8 Versioning Policy Language </span></span><span class="diff-chg"><span>section: </span></span><span class="diff-add"><a href="#ignorable-policy-assertions"><b>2.7 Ignorable Policy Expressions</b></a></span><span class="diff-add"><span>.</span></span></p></li><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Added</span></span><span class="diff-del"><span>Section </span></span><span class="diff-add"><span>a</span></span><span class="diff-del"><span>; 
+          moved </span></span><span class="diff-add"><span>new</span></span><span class="diff-del"><span>Section
           
-            4 Advanced Concepts II: Policy Assertion Design into the Guidelines document.</span></span></p></li></ul></div><div class="div1">
+            4 </span></span><span class="diff-chg"><span>section: </span></span><a href="#Both-Optional-Ignorable"><b>2.8 Marking Assertions both Optional and Ignorable</b></a><span class="diff-add"><span>.</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Added</span></span><span class="diff-del"><span>Concepts </span></span><span class="diff-chg"><span>a new section: </span></span><a href="#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy Intersection</b></a><span class="diff-add"><span>.</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Added</span></span><span class="diff-del"><span>Design </span></span><span class="diff-chg"><span>a new section: </span></span><a href="#ignorable-and-versioning"><b>3.8.1 Ignorable and Versioning</b></a><span class="diff-add"><span>.</span></span><span class="diff-del"><span>document.</span></span></p></li></div></ul></div><div class="div1">
 <h2><a name="change-log" id="change-log"></a>F. Web Services Policy 1.5 - Primer Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><tr><td colspan="1" rowspan="1">20060816</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Created first draft per action item <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02">2</a> from the
               Austin F2F. This draft is based on a <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0001.html">contribution</a> from Microsoft.</td></tr><tr><td colspan="1" rowspan="1">20060829</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Implemented the 
               <a href="http://www.w3.org/2006/08/23-ws-policy-minutes.html#action06">resolution</a> 
@@ -1556,4 +1572,16 @@
               to <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4253"><span class="diff-add"><span>issue 4253</span></span></a>
               (editors action 
               <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191"><span class="diff-add"><span>191</span></span></a>).
-            </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
+            </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070319</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">MH</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the resolution for
+              <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4213"><span class="diff-add"><span>issue 4213</span></span></a>   
+              <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html"><span class="diff-add"><span>as outlined.</span></span></a> 
+              Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189"><span class="diff-add"><span>189</span></span></a>.
+            </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070319</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">PY</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the resolution for
+              <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103"><span class="diff-add"><span>issue 4103</span></span></a>   
+              <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html"><span class="diff-add"><span>as outlined.</span></span></a> 
+              Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193"><span class="diff-add"><span>193</span></span></a>.
+            </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070320</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300#c1"><span class="diff-add"><span>resolution</span></span></a> 
+              for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300"><span class="diff-add"><span>issue 4300</span></span></a>.
+              Editors' action 
+              <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190"><span class="diff-add"><span>190</span></span></a>.
+            </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070321</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Updated section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>. </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070321</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Formatted the example in <a href="#ignorable-and-versioning"><b>3.8.1 Ignorable and Versioning</b></a>. </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: ws-policy-framework-diff20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework-diff20070228.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-framework-diff20070228.xml	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-framework-diff20070228.xml	22 Mar 2007 07:11:39 -0000	1.2
@@ -7,9 +7,9 @@
 <!ENTITY status SYSTEM "status.xml">
 <!ENTITY document.status "Editors' copy $Date$">
 <!ENTITY framework-title "&framework.title;">
-<!ENTITY prevloc "http://www.w3.org/TR/2006/WD-ws-policy-20061117">
+<!ENTITY prevloc "http://www.w3.org/TR/2007/CR-ws-policy-20070228">
 <!ENTITY hellip "&#8230;">
-]><spec role="editors-copy" w3c-doctype="cr">
+]><spec role="editors-copy" w3c-doctype="wd">
     <header>
         <title>Web Services Policy 1.5 - Framework</title>
         <w3c-designation>ws-policy-framework.html</w3c-designation>
@@ -22,7 +22,7 @@
         <publoc>
             <loc href="ws-policy-framework.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ws-policy-framework.html</loc>
         </publoc>  <prevlocs>
-            <loc href="http://www.w3.org/TR/2006/WD-ws-policy-20061117" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://www.w3.org/TR/2006/WD-ws-policy-20061117</loc>
+            <loc diff="chg" href="http://www.w3.org/TR/2007/CR-ws-policy-20070228" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="chg">http://www.w3.org/TR/2007/CR-ws-policy-20070228</phrase></loc>
         </prevlocs>
         <latestloc>
             <loc href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8</loc>
@@ -343,10 +343,10 @@
          <loc href="#ignorable_policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ignorable policy assertion</loc>
       </label>
       <def>
-         <p>An 
-	    <term>ignorable policy assertion</term> is 
-	    an assertion that may be ignored for policy intersection (as defined in 
-	        <xspecref href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection" xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">4.5 Policy Intersection</xspecref>).</p>
+         <p>An
+                            <term>ignorable policy assertion</term> is an assertion that may be
+                        ignored for policy intersection (as defined in <xspecref href="http://www.w3.org/TR/ws-policy#Policy_Intersection" xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">4.5 Policy
+                            Intersection</xspecref>).</p>
       </def>
    </gitem>
    <gitem>
@@ -354,7 +354,9 @@
          <loc href="#nested_policy_expression" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">nested policy expression</loc>
       </label>
       <def>
-         <p>A <term>nested policy expression</term> is a <termref def="policy_expression">policy expression</termref> that is an Element Information Item in the <emph role="infoset-property">children</emph> property of a <termref def="policy_assertion">policy assertion</termref>.</p>
+         <p>A <term>nested policy expression</term>
+                            is a <termref def="policy_expression">policy expression</termref> that
+                            is an Element Information Item in the <emph role="infoset-property">children</emph> property of a <termref def="policy_assertion">policy assertion</termref>.</p>
       </def>
    </gitem>
    <gitem>
@@ -362,8 +364,9 @@
          <loc href="#policy" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy</loc>
       </label>
       <def>
-         <p>A <term>policy</term> is a potentially empty collection of 
-	    <termref def="policy_alternative">policy alternatives</termref>. </p>
+         <p>A <term>policy</term> is a potentially empty
+                        collection of <termref def="policy_alternative">policy
+                        alternatives</termref>. </p>
       </def>
    </gitem>
    <gitem>
@@ -371,8 +374,8 @@
          <loc href="#policy_alternative" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy alternative</loc>
       </label>
       <def>
-         <p>A <term>policy alternative</term> 
-	    is a potentially empty collection of <termref def="policy_assertion">policy assertions</termref>.</p>
+         <p>A <term>policy
+                            alternative</term> is a potentially empty collection of <termref def="policy_assertion">policy assertions</termref>.</p>
       </def>
    </gitem>
    <gitem>
@@ -380,10 +383,9 @@
          <loc href="#policy_alternative_vocabulary" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy alternative vocabulary</loc>
       </label>
       <def>
-         <p>A <term>policy alternative vocabulary</term> is the set of
-	    all <termref def="policy_assertion_type">policy assertion
-	    types</termref> within the <termref def="policy_alternative">policy
-	    alternative</termref>.</p>
+         <p>A <term>policy alternative vocabulary</term> is the set of all <termref def="policy_assertion_type">policy assertion types</termref> within the
+                            <termref def="policy_alternative">policy
+                    alternative</termref>.</p>
       </def>
    </gitem>
    <gitem>
@@ -391,8 +393,9 @@
          <loc href="#policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy assertion</loc>
       </label>
       <def>
-         <p>A <term>policy assertion</term> 
-		represents a requirement, a capability, or other property of a behavior.</p>
+         <p>A <term>policy
+                        assertion</term> represents a requirement, a capability, or other property
+                        of a behavior.</p>
       </def>
    </gitem>
    <gitem>
@@ -400,8 +403,9 @@
          <loc href="#policy_assertion_parameter" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy assertion parameter</loc>
       </label>
       <def>
-         <p>A <term>policy assertion parameter</term> 
-	    qualifies the behavior indicated by a <termref def="policy_assertion">policy assertion</termref>.</p>
+         <p>A <term>policy assertion parameter</term>
+                        qualifies the behavior indicated by a <termref def="policy_assertion">policy
+                            assertion</termref>.</p>
       </def>
    </gitem>
    <gitem>
@@ -409,9 +413,9 @@
          <loc href="#policy_assertion_type" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy assertion type</loc>
       </label>
       <def>
-         <p>A <term>policy assertion type</term> 
-	    represents a class of <termref def="policy_assertion">policy assertions</termref> and implies a 
-	    schema for the assertion and assertion-specific semantics.</p>
+         <p>A <term>policy
+                            assertion type</term> represents a class of <termref def="policy_assertion">policy assertions</termref> and implies a schema
+                        for the assertion and assertion-specific semantics.</p>
       </def>
    </gitem>
    <gitem>
@@ -419,9 +423,8 @@
          <loc href="#policy_attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy attachment</loc>
       </label>
       <def>
-         <p>A 
-	    <term>policy attachment</term> is a mechanism for associating 
-	    <termref def="policy">policy</termref> with one or more <termref def="policy_scope">policy scopes</termref>.</p>
+         <p>A <term>policy
+                                        attachment</term> is a mechanism for associating <termref def="policy">policy</termref> with one or more <termref def="policy_scope">policy scopes</termref>.</p>
       </def>
    </gitem>
    <gitem>
@@ -429,9 +432,9 @@
          <loc href="#policy_expression" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy expression</loc>
       </label>
       <def>
-         <p>A <term>policy expression</term> 
-		is an XML Infoset representation of a <termref def="policy">policy</termref>, 
-		either in a normal form or in an equivalent compact form.</p>
+         <p>A <term>policy expression</term>
+                    is an XML Infoset representation of a <termref def="policy">policy</termref>,
+                    either in a normal form or in an equivalent compact form.</p>
       </def>
    </gitem>
    <gitem>
@@ -439,8 +442,9 @@
          <loc href="#policy_scope" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy scope</loc>
       </label>
       <def>
-         <p>A <term>policy scope</term> is a collection of 
-	    <termref def="policy_subject">policy subjects</termref> to which a policy may apply.</p>
+         <p>A <term>policy
+                                    scope</term> is a collection of <termref def="policy_subject">policy subjects</termref> to which a policy may
+                                apply.</p>
       </def>
    </gitem>
    <gitem>
@@ -448,9 +452,9 @@
          <loc href="#policy_subject" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy subject</loc>
       </label>
       <def>
-         <p>A <term>policy subject</term> is an entity 
-	    (e.g., an endpoint, message, resource, operation) with which a 
-	    <termref def="policy">policy</termref> can be associated. </p>
+         <p>A <term>policy subject</term> is
+                        an entity (e.g., an endpoint, message, resource, operation) with which a
+                            <termref def="policy">policy</termref> can be associated. </p>
       </def>
    </gitem>
    <gitem>
@@ -458,8 +462,9 @@
          <loc href="#policy_vocabulary" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy vocabulary</loc>
       </label>
       <def>
-         <p>A <term>policy vocabulary</term> is the set of all 
-	    <termref def="policy_assertion_type">policy assertion types</termref> used in a policy.</p>
+         <p>A
+                            <term>policy vocabulary</term> is the set of all <termref def="policy_assertion_type">policy assertion types</termref> used in a
+                        policy.</p>
       </def>
    </gitem>
 </glist> </div2>
@@ -1570,7 +1575,8 @@
                                     </phrase>resolvable; retrieval mechanisms are beyond the scope of this
                                     specification. After retrieval, there is no requirement to check
                                     that the retrieved policy expression is associated (Section
-                                        <specref ref="Policy_Identification"></specref>) with this IRI. <phrase diff="chg">  </phrase><phrase diff="add">The
+                                        <specref ref="Policy_Identification"></specref>) with this IRI.  
+<phrase diff="del">The </phrase><phrase diff="add">  The
                                     </phrase>IRI included in the retrieved policy expression, if any,
                                         <rfc2119>MAY</rfc2119> be different than the IRI used to
                                     retrieve the policy expression. </p>
@@ -2424,21 +2430,19 @@
 </inform-div1>
  <inform-div1 id="change-description">
             <head>Changes in this Version of the Document</head>
-            <p>A list of major editorial changes since the Working Draft dated 17 November, 2006
-    <phrase diff="del">is </phrase><phrase diff="add">is
+            <p>A list of major editorial changes since the Working Draft dated <phrase diff="chg">28 February, </phrase><phrase diff="add">2007</phrase><phrase diff="del">2006
+    is </phrase><phrase diff="add">is
                 </phrase>below:</p>
             <ulist>
-                <item>
-                    <p>Reorganized the content in Section <specref ref="Compact_Policy_Expression"></specref>.</p>
-                </item>
-                <item>
-                    <p>Documented the schema outline &amp; description for policy operators
-                            (<el>wsp:Policy</el>, <el>wsp:All</el> and <el>wsp:ExactlyOne</el>
-                        elements) in Section <specref ref="Policy_Operators"></specref>.</p>
-                </item>
-                <item>
-                    <p>Explicitly described the interaction between Web Services Policy and XML Base
-                        in Section <specref ref="IRI_Policy_Expressions"></specref>.</p>
+                
+        <phrase diff="del">Reorganized the content in Section 
+        .
+        Documented the schema outline &amp; description for policy operators 
+        (wsp:Policy, wsp:All and wsp:ExactlyOne elements)
+        in Section .
+        </phrase><item>
+                    <p><phrase diff="add">None.</phrase><phrase diff="del">Explicitly described the interaction between Web Services Policy and XML Base in
+        Section .</phrase></p>
                 </item>
             </ulist>
         </inform-div1>
@@ -2936,7 +2940,12 @@
                             </td>
                         
                     </tr>
-                                     
+                    <tr diff="add">
+                        <td colspan="1" diff="add" rowspan="1">20070321</td>
+                        <td colspan="1" diff="add" rowspan="1">ASV</td>
+                        <td colspan="1" diff="add" rowspan="1">Reset Section <specref ref="change-description"></specref>. </td>
+                    </tr>
+                    
                 </tbody>
             </table>
         </inform-div1>

Index: ws-policy-attachment-diff20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment-diff20070228.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-attachment-diff20070228.xml	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-attachment-diff20070228.xml	22 Mar 2007 07:11:39 -0000	1.2
@@ -7,9 +7,9 @@
 <!ENTITY status SYSTEM "status-attachment.xml">
 <!ENTITY document.status "Editors' copy $Date$">
 <!ENTITY attachment-title "&attachment.title;">
-<!ENTITY prevloc "http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117">
+<!ENTITY prevloc "http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/">
 <!ENTITY hellip "&#8230;">
-]><spec role="editors-copy" w3c-doctype="cr">
+]><spec role="editors-copy" w3c-doctype="wd">
 <header>
 <title>Web Services Policy 1.5 - Attachment</title>
 <w3c-designation>ws-policy-attachment.html</w3c-designation>
@@ -24,7 +24,7 @@
 </publoc>
     
 	<prevlocs>
-            <loc href="http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117</loc>
+            <loc diff="chg" href="http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="chg">http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/</phrase></loc>
         </prevlocs>
 <latestloc>
 <loc href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;charset=utf-8" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;charset=utf-8</loc>
@@ -377,13 +377,13 @@
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#ignorable_policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ignorable policy assertion</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#ignorable_policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ignorable policy assertion</loc>
       </label>
       <def>
-         <p id="ignorable_policy_assertion">An 
-	    <term>ignorable policy assertion</term> is 
-	    an assertion that may be ignored for policy intersection (as defined in 
-	        <xspecref href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection" xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">4.5 Policy Intersection</xspecref>).</p>
+         <p id="ignorable_policy_assertion">An
+                            <term>ignorable policy assertion</term> is an assertion that may be
+                        ignored for policy intersection (as defined in <xspecref href="http://www.w3.org/TR/ws-policy#Policy_Intersection" xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">4.5 Policy
+                            Intersection</xspecref>).</p>
       </def>
    </gitem>
    <gitem>
@@ -402,68 +402,70 @@
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy</loc>
       </label>
       <def>
-         <p id="policy">A <term>policy</term> is a potentially empty collection of 
-	    <termref def="policy_alternative">policy alternatives</termref>. </p>
+         <p id="policy">A <term>policy</term> is a potentially empty
+                        collection of <termref def="policy_alternative">policy
+                        alternatives</termref>. </p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_alternative" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy alternative</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_alternative" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy alternative</loc>
       </label>
       <def>
-         <p id="policy_alternative">A <term>policy alternative</term> 
-	    is a potentially empty collection of <termref def="policy_assertion">policy assertions</termref>.</p>
+         <p id="policy_alternative">A <term>policy
+                            alternative</term> is a potentially empty collection of <termref def="policy_assertion">policy assertions</termref>.</p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy assertion</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy assertion</loc>
       </label>
       <def>
-         <p id="policy_assertion">A <term>policy assertion</term> 
-		represents a requirement, a capability, or other property of a behavior.</p>
+         <p id="policy_assertion">A <term>policy
+                        assertion</term> represents a requirement, a capability, or other property
+                        of a behavior.</p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy attachment</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy attachment</loc>
       </label>
       <def>
-         <p id="policy_attachment">A 
-	    <term>policy attachment</term> is a mechanism for associating 
-	    <termref def="policy">policy</termref> with one or more <termref def="policy_scope">policy scopes</termref>.</p>
+         <p id="policy_attachment">A <term>policy
+                                        attachment</term> is a mechanism for associating <termref def="policy">policy</termref> with one or more <termref def="policy_scope">policy scopes</termref>.</p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_expression" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy expression</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_expression" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy expression</loc>
       </label>
       <def>
-         <p id="policy_expression">A <term>policy expression</term> 
-		is an XML Infoset representation of a <termref def="policy">policy</termref>, 
-		either in a normal form or in an equivalent compact form.</p>
+         <p id="policy_expression">A <term>policy expression</term>
+                    is an XML Infoset representation of a <termref def="policy">policy</termref>,
+                    either in a normal form or in an equivalent compact form.</p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_scope" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy scope</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_scope" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy scope</loc>
       </label>
       <def>
-         <p id="policy_scope">A <term>policy scope</term> is a collection of 
-	    <termref def="policy_subject">policy subjects</termref> to which a policy may apply.</p>
+         <p id="policy_scope">A <term>policy
+                                    scope</term> is a collection of <termref def="policy_subject">policy subjects</termref> to which a policy may
+                                apply.</p>
       </def>
    </gitem>
    <gitem>
       <label>
-         <loc href="ws-policy-framework.html#policy_subject" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy subject</loc>
+         <loc href="http://www.w3.org/TR/2007/CR-ws-policy-20070330#policy_subject" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">policy subject</loc>
       </label>
       <def>
-         <p id="policy_subject">A <term>policy subject</term> is an entity 
-	    (e.g., an endpoint, message, resource, operation) with which a 
-	    <termref def="policy">policy</termref> can be associated. </p>
+         <p id="policy_subject">A <term>policy subject</term> is
+                        an entity (e.g., an endpoint, message, resource, operation) with which a
+                            <termref def="policy">policy</termref> can be associated. </p>
       </def>
    </gitem>
 </glist>
@@ -2205,7 +2207,7 @@
 <p>This new tModel is called the remote policy reference category
 system and is defined in Appendix <specref ref="RemotePolicyReferenceCategorySystem"></specref>.</p>
 <p>UDDI registries <rfc2119>MUST</rfc2119> use the (UDDI V2 [<bibref ref="UDDIDataStructure20"></bibref>]) <att>tModelKey</att>
-<code>uuid:a27078e4-fd38-320a-806f-6749e84f8005</code> to uniquely identify this
+<code><phrase diff="chg">uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1</phrase></code> to uniquely identify this
 tModel so that UDDI registry users can expect the same behavior across
 different UDDI registries.</p>
 <p>The tModel's valid values are those IRIs that identify external
@@ -2226,7 +2228,7 @@
     &lt;keyedReference
        keyName="Policy Expression for example's Web services"
        keyValue="http://www.example.com/myservice/policy"
-       tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /&gt;
+       tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" /&gt;
   &lt;/categoryBag&gt;
 &lt;/businessService&gt;</phrase></eg>
 <p>The <att>tModelKey</att> of the <el>keyedReference</el>
@@ -2244,7 +2246,7 @@
   &lt;accessPoint&gt;…&lt;/accessPoint&gt;
   &lt;tModelInstanceDetails&gt;
     &lt;tModelInstanceInfo
-       tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" &gt;
+       tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" &gt;
       &lt;instanceDetails&gt;
         &lt;instanceParms&gt;
           http://www.example.com/myservice/policy
@@ -2284,11 +2286,11 @@
     &lt;keyedReference
        keyName="Reusable policy Expression"
        keyValue="policy"
-       tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" /&gt;
+       tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" /&gt;
     &lt;keyedReference
        keyName="Policy Expression for example's Web services"
        keyValue="http://www.example.com/myservice/policy"
-       tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /&gt;
+       tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" /&gt;
   &lt;/categoryBag&gt;
 &lt;/tModel&gt;</phrase></eg>
 <p>The first <el>keyedReference</el> specifies that the tModel represents a
@@ -2309,7 +2311,7 @@
 <p>This new tModel is called the local policy reference category
 system and is defined in Appendix <specref ref="LocalPolicyReferenceCategorySystem"></specref>.</p>
 <p>UDDI registries <rfc2119>MUST</rfc2119> use the <att>tModelKey</att>
-<code>uuid:a27f7d45-ec90-31f7-a655-efe91433527c</code> to uniquely identify this
+<code><phrase diff="chg">uuid:5da4fc61-a302-35ad-91d3-775150429035</phrase></code> to uniquely identify this
 tModel so that UDDI registry users can expect the same behavior across
 different UDDI registries.</p>
 <p>The local policy reference category system is based on
@@ -2340,7 +2342,7 @@
     &lt;keyedReference
        keyName="Policy Expression for example's Web services"
        keyValue="uuid:04cfa…"
-       tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" /&gt;
+       tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" /&gt;
   &lt;/categoryBag&gt;
 &lt;/businessService&gt;</phrase></eg>
 <p>The <att>tModelKey</att> of the <el>keyedReference</el>
@@ -2357,7 +2359,7 @@
   &lt;accessPoint&gt;…&lt;/accessPoint&gt;
   &lt;tModelInstanceDetails&gt;
     &lt;tModelInstanceInfo
-       tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" &gt;
+       tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" &gt;
       &lt;instanceDetails&gt;
         &lt;instanceParms&gt;uuid:04cfa…&lt;/instanceParms&gt;
       &lt;/instanceDetails&gt;
@@ -2383,10 +2385,10 @@
 from the Version 3 keys given below.</p>
 <p>The <att>tModelKey</att> for the remote policy reference tModel changes
 from
-<code>"uuid:a27078e4-fd38-320a-806f-6749e84f8005"</code> to
-<code>"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"</code>.</p>
-<p>The <att>tModelKey</att> for the Web Services Policy Types tModel changes from <code>"uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993"</code> to <code>"uddi:schemas.xmlsoap.org:policytypes:2003_03"</code>.</p>
-<p>The <att>tModelKey</att> for the local policy reference tModel changes from <code>"uuid:a27f7d45-ec90-31f7-a655-efe91433527c"</code> to <code>"uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"</code>.</p>
+<code><phrase diff="chg">"uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1"</phrase></code> to
+<code><phrase diff="chg">"uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"</phrase></code>.</p>
+<p>The <att>tModelKey</att> for the Web Services Policy Types tModel changes from <code><phrase diff="chg">"uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941"</phrase></code> to <code><phrase diff="chg">"uddi:w3.org:ws-policy:v1.5:attachment:policytypes"</phrase></code>.</p>
+<p>The <att>tModelKey</att> for the local policy reference tModel changes from <code><phrase diff="chg">"uuid:5da4fc61-a302-35ad-91d3-775150429035"</phrase></code> to <code><phrase diff="chg">"uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference"</phrase></code>.</p>
 <p>Second, rather than putting <termref def="policy_expression">policy expression</termref> references in a
 <el>bindingTemplate</el>'s <el>tModelInstanceInfo</el>, they are added to the
 <el>bindingTemplate</el>'s <el>categoryBag</el>, analogous to the mechanism described
@@ -2400,7 +2402,7 @@
     &lt;keyedReference
        keyName="Policy Expression for example's Web services"
        keyValue="http://www.example.com/myservice/policy"
-       tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+       tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
     /&gt;
   &lt;/categoryBag&gt;
 &lt;/bindingTemplate&gt;</phrase></eg>
@@ -2416,7 +2418,7 @@
   &lt;categoryBag&gt;
     &lt;keyedReference
        keyValue="http://www.example.com/"
-       tModelKey="uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
+       tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
     /&gt;
   &lt;/categoryBag&gt;
   &lt;findQualifiers&gt;
@@ -2703,7 +2705,7 @@
 <bibl href="http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/" id="WSDL11BindingforSOAP12" key="WSDL 1.1 Binding for SOAP 1.2" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
 <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">WSDL 1.1 Binding for SOAP 1.2</titleref>,
 	D. Angelov, et al, Authors. World Wide Web Consortium, 5 April
-	2006.  <phrase diff="del">Available </phrase><phrase diff="add"> Available </phrase>at
+	2006. <phrase diff="chg"> Available </phrase>at
 	http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.
       </bibl>
 <bibl href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" id="XML-Signature" key="XML-Signature" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
@@ -2739,8 +2741,8 @@
 <head>UDDI tModel Definitions</head>
 <p>This section contains the UDDI tModel definitions for the canonical
 tModels used in Section <specref ref="AttachingPoliciesUsingUDDI"></specref>. The tModelKeys shown in the tModel
-structure sections are valid UDDI Version 2 keys. When using UDDI
-Version 3, the corresponding derived UDDI Version 2 keys must be
+structure sections are valid UDDI Version <phrase diff="chg">3 </phrase>keys. When using UDDI
+Version <phrase diff="chg">2, </phrase>the corresponding derived UDDI Version 2 keys must be
 used.</p>
 <div2 id="RemotePolicyReferenceCategorySystem">
 <head>Remote Policy Reference Category System</head>
@@ -2755,7 +2757,7 @@
 <tr>
 <th colspan="1" rowspan="1">Name:</th>
 <td colspan="1" rowspan="1">
-<loc href="http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference</loc>
+  <loc diff="chg" href="http://www.w3.org/ns/ws-policy/remotepolicyreference/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="chg">http://www.w3.org/ns/ws-policy/remotepolicyreference</phrase></loc>
 </td>
 </tr>
 <tr>
@@ -2768,13 +2770,13 @@
 <tr>
 <th colspan="1" rowspan="1">UDDI Key (V3):</th>
 <td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03</code>
+<code><phrase diff="chg">uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference</phrase></code>
 </td>
 </tr>
 <tr>
 <th colspan="1" rowspan="1">UDDI V1,V2 format key:</th>
 <td colspan="1" rowspan="1">
-<code>uuid:a27078e4-fd38-320a-806f-6749e84f8005</code>
+<code><phrase diff="chg">uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1</phrase></code>
 </td>
 </tr>
 <tr>
@@ -2790,8 +2792,8 @@
 </div3>
 <div3 id="ModelStructure1">
 <head>tModel Structure</head>
-<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" &gt;
-  &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/remotepolicyreference&lt;/name&gt;
+<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" &gt;
+    &lt;name&gt;http://www.w3.org/ns/ws-policy/remotepolicyreference&lt;/name&gt;
   &lt;description xml:lang="EN"&gt;Category system used for UDDI entities to point to an external
    Web Services Policy Attachment policy expression that describes their characteristics.
    See Web Services Policy 1.5 - Attachment specification for further details.&lt;/description&gt;
@@ -2822,7 +2824,7 @@
 <tr>
 <th colspan="1" rowspan="1">Name:</th>
 <td colspan="1" rowspan="1">
-<loc href="http://schemas.xmlsoap.org/ws/2003/03/policytypes/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://schemas.xmlsoap.org/ws/2003/03/policytypes</loc>
+<loc diff="chg" href="http://www.w3.org/ns/ws-policy/policytypes/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="chg">http://www.w3.org/ns/ws-policy/policytypes</phrase></loc>
 </td>
 </tr>
 <tr>
@@ -2833,13 +2835,13 @@
 <tr>
 <th colspan="1" rowspan="1">UDDI Key (V3):</th>
 <td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:policytypes:2003_03</code>
+<code><phrase diff="chg">uddi:w3.org:ws-policy:v1.5:attachment:policytypes</phrase></code>
 </td>
 </tr>
 <tr>
 <th colspan="1" rowspan="1">UDDI V1,V2 format key:</th>
 <td colspan="1" rowspan="1">
-<code>uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993</code>
+<code><phrase diff="chg">uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941</phrase></code>
 </td>
 </tr>
 <tr>
@@ -2855,8 +2857,8 @@
 </div3>
 <div3 id="ModelStructure2">
 <head>tModel Structure</head>
-<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" &gt;
-  &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/policytypes&lt;/name&gt;
+<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" &gt;
+  &lt;name&gt;http://www.w3.org/ns/ws-policy/policytypes&lt;/name&gt;
   &lt;description xml:lang="EN"&gt;Web Services Policy Types category system used for UDDI tModels
    to characterize them as Web Services Policy – based policy expressions.&lt;/description&gt;
   &lt;categoryBag&gt;
@@ -2887,7 +2889,7 @@
 <tr>
 <th colspan="1" rowspan="1">Name:</th>
 <td colspan="1" rowspan="1">
-<loc href="http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference</loc>
+<loc diff="chg" href="http://www.w3.org/ns/ws-policy/localpolicyreference/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="chg">http://www.w3.org/ns/ws-policy/localpolicyreference</phrase></loc>
 </td>
 </tr>
 <tr>
@@ -2900,13 +2902,13 @@
 <tr>
 <th colspan="1" rowspan="1">UDDI Key (V3):</th>
 <td colspan="1" rowspan="1">
-<code>uddi:schemas.xmlsoap.org:localpolicyreference:2003_03</code>
+<code><phrase diff="chg">uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference</phrase></code>
 </td>
 </tr>
 <tr>
 <th colspan="1" rowspan="1">UDDI V1,V2 format key:</th>
 <td colspan="1" rowspan="1">
-<code>uuid:a27f7d45-ec90-31f7-a655-efe91433527c</code>
+<code><phrase diff="chg">uuid:5da4fc61-a302-35ad-91d3-775150429035</phrase></code>
 </td>
 </tr>
 <tr>
@@ -2922,8 +2924,8 @@
 </div3>
 <div3 id="ModelStructure3">
 <head>tModel Structure</head>
-<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" &gt;
-  &lt;name&gt;http://schemas.xmlsoap.org/ws/2003/03/localpolicyreference&lt;/name&gt;
+<eg role="needs-numbering" xml:space="preserve"><phrase diff="chg">&lt;tModel tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" &gt;
+  &lt;name&gt;http://www.w3.org/ns/ws-policy/localpolicyreference&lt;/name&gt;
   &lt;description xml:lang="en"&gt;Category system used for UDDI entities to point to a
    Web Services Policy policy expression tModel that describes their characteristics.
    See Web Services Policy 1.5 - Attachment specification for further details.&lt;/description&gt;
@@ -2972,16 +2974,18 @@
 
   <inform-div1 id="change-description">
 <head>Changes in this Version of the Document</head>
-<p>A list of major editorial changes since the Working Draft dated 17 November, 2006
-      is below:</p>
+<p>A list of major editorial changes since the Working Draft dated <phrase diff="chg">28 February, 2007
+      </phrase>is below:</p>
      <ulist>
         <item>
-          <p>Clarified the relationship between URI domain expression and 
-          WSDL 1.1 Element Identifiers 
-            [<bibref ref="WSDL11EI"></bibref>] in Section <specref ref="uri-domain-expression"></specref>.</p>         
+          <p><phrase diff="chg">Aligned </phrase>the <phrase diff="add">UDDI</phrase><phrase diff="del">relationship between URI domain </phrase><phrase diff="chg">names </phrase>and 
+          <phrase diff="del">WSDL 1.1 Element Identifiers 
+            [] in Section </phrase><phrase diff="add">keys</phrase><phrase diff="del">.         
+        
+       Explicitly </phrase><phrase diff="chg">with </phrase>the <phrase diff="add">XML</phrase><phrase diff="del">interaction between policy </phrase><phrase diff="chg">namespace name of </phrase><phrase diff="add">the
+          Web</phrase><phrase diff="del">XML </phrase><phrase diff="chg">Services </phrase><phrase diff="add">Policy</phrase><phrase diff="del">in
+         Section </phrase><phrase diff="add">language.</phrase><phrase diff="del">.</phrase></p>         
         </item>
-       <item><p>Explicitly described the interaction between policy attachment mechanisms and XML Base in
-         Section <specref ref="IRI_Policy_Attachment"></specref>.</p></item>
       </ulist>
 </inform-div1>
 <inform-div1 id="change-log">
@@ -3422,6 +3426,19 @@
       <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4391" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4391</phrase></loc>.
       Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/200" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">200</phrase></loc>.
     </td>
+  </tr>
+  <tr diff="add">
+    <td colspan="1" diff="add" rowspan="1">20070316</td>
+    <td colspan="1" diff="add" rowspan="1">PY</td>
+    <td colspan="1" diff="add" rowspan="1">Implemented part of the resolution as it applies to the Attachment spec, for issue
+      <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4389" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4389</phrase></loc>.
+      Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/209" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">209</phrase></loc>.
+    </td>
+  </tr>
+  <tr diff="add">
+    <td colspan="1" diff="add" rowspan="1">20070321</td>
+    <td colspan="1" diff="add" rowspan="1">ASV</td>
+    <td colspan="1" diff="add" rowspan="1">Reset Section <specref ref="change-description"></specref>. </td>
   </tr>                                             
                                               
 </tbody>

--- NEW FILE: wsdl11elementidentifiers-tr20070131.xml ---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.2+WSDL//EN" "xmlspec.dtd" [
	<!ENTITY % entities SYSTEM "entities.dtd">
	%entities;
	<!ENTITY status SYSTEM "status-wsdl11ei.xml">
	<!ENTITY document.status "Editors' copy $Date: 2007/03/22 07:11:40 $">
	<!ENTITY wsdl-ns "http://schemas.xmlsoap.org/wsdl/">
]>
<spec w3c-doctype="wd" role="&document.role;">
	<header>
		<title>&wsdl11ei.title;</title>
		<w3c-designation>&w3c-designation-wsdl11ei;</w3c-designation>
		<w3c-doctype>&document.status;</w3c-doctype>
		<pubdate>
			<day>&draft.day;</day>
			<month>&draft.month;</month>
			<year>&draft.year;</year>
		</pubdate>
		<publoc>
			<loc href="&w3c-designation-wsdl11ei;">&w3c-designation-wsdl11ei;</loc>
		</publoc>
	    &altlocs;
		<latestloc>
			<loc href="&wsdl11ei.latest;">&wsdl11ei.latest;</loc>
		</latestloc>
<!-- <prevlocs>

		</prevlocs> -->
		<authlist>
			<author>
				<name>David Orchard</name>
				<affiliation>BEA Systems</affiliation>
			</author>
			<author role="editor">
				<name>Asir S Vedamuthu</name>
				<affiliation>Microsoft Corporation</affiliation>
			</author>
			<author role="editor">
				<name>Frederick Hirsch</name>
				<affiliation>Nokia</affiliation>
			</author>
			<author role="editor">
				<name>Maryann Hondo</name>
				<affiliation>IBM Corporation</affiliation>
			</author>
			<author role="editor">
				<name>Prasad Yendluri</name>
				<affiliation>webMethods, Inc.</affiliation>
			</author>
			<author role="editor">
				<name>Toufic Boubez</name>
				<affiliation>Layer 7 Technologies</affiliation>
			</author>
			<author role="editor">
				<name>Ümit Yalçinalp</name>
				<affiliation>SAP AG.</affiliation>
			</author>
		</authlist>
		<abstract>
			<p>&wsdl11ei.title; defines a syntax to identify individual elements in a WSDL 1.1 document.</p>
		</abstract>
		&status;
		<langusage>
			<language id="en">English</language>
		</langusage>
		<revisiondesc>
			<p>Last Modified: $Date: 2007/03/22 07:11:40 $ CET</p>
		</revisiondesc>
	</header>
	<body>
		<div1 id="intro">
			<head>Introduction</head>
			<p>This document defines an element identifier syntax for WSDL 1.1 elements.
			</p>
			<div2 id="notcon">
				<head>Notational Conventions</head>
				<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in RFC 2119 [<bibref ref="RFC2119"/>].</p>
				<p>With the exception of examples and sections explicitly marked
    	as "Non-Normative", all parts of this specification are
    	normative.</p>
			</div2>
		</div1>
			<div1 id="frag-ids">
	<head>Fragment Identifiers</head>
	<p>
	This section defines a fragment identifier syntax for identifying elements of a WSDL 1.1 document.
	This fragment identifier syntax is compliant with the
	[<bibref ref="XPTR"/>].  This document is primarily based upon [<bibref ref="WSDL-PART1"/>].  There is a substantial difference between the WSDL 1.1 and WSDL 2.0 fragment identifiers.WSDL 2.0 defines fragment identifiers with respect to the WSDL 2.0 component model, whereas WSDL 1.1 defines XML element and attribute syntax only.  Because there is no WSDL 1.1 component model, the WSDL 1.1 fragment identifiers are to the WSDL 1.1 elements.  Further, the fragment identifers are to the WSDL 1.1 elements prior to any processing of the WSDL document, such as validation, inclusion, imports, schema type validation, etc.  
	</p>
	<p>
	A WSDL 1.1 fragment identifier is an XPointer [<bibref ref="XPTR"/>], 
 augmented with WSDL 1.1 pointer parts as defined below. Note that many 
 of these parts require the pre-appearance of one or more <code>xmlns</code> pointer 
 parts (see 3.4 Namespace Binding Context in [<bibref ref="XPTR"/>]).
	The pointer parts have a scheme name that corresponds to one
	of the standard WSDL 1.1 element names, and scheme data that is a path composed
	of names that identify the elements. 
	The scheme names all begin with the prefix "wsdl11." to avoid
	name conflicts with other schemes.
	The names in the path are of type either QName, NCName,
	IRI, URI, or Pointer Part depending on the context.
	The scheme data for WSDL 1.1 extension elements is defined by the 
	corresponding extension specification.
	</p>
	<p>
	For QNames, any prefix
	MUST be defined by a preceding xmlns pointer part.
	If a QName does not have a prefix then its namespace
	name is the target namespace of the WSDL 1.1 document.
	</p>

	<p>
		The fragment identifier is typically constructed from the <code>name</code>
		property of the element and the <code>name</code> properties of its
		ancestors as a path according to
		<specref ref="frag-ids-table" />.
	    The first column of this table gives the name of the WSDL 1.1
		element. Columns labeled 1 through 3 specify the identifiers that
		uniquely identify the element within its context. Identifiers
		are typically formed from the <code>name</code> property, although in
		several cases references to other elements are used. These
		identifiers are then used to construct the pointer part in
		the last column.
		The fragment identifier in a WSDL 1.1 element IRI-reference
		MUST resolve to some element as defined by the construction rules
		in <specref ref="frag-ids-table" />.
	</p>

	<table id="frag-ids-table" border="1">
	  <caption>Rules for determining pointer parts for WSDL 1.1 elements</caption>
	    <col width="19%" />
	    <col width="12%" />
	    <col width="12%" />
	    <col width="12%" />
	    <col width="45%" />
	<tbody>
	<tr>
	  <th>element</th>
          <th>1</th>
          <th>2</th>
          <th>3</th>
          <th>Pointer Part</th>
	</tr>
	<tr>
	  	  <td>Definitions</td>
          <td>n/a</td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.definitions()</code></td>
	</tr>
	<tr>
	  	  <td>Type Definition</td>
          <td><code>types</code> QName </td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.types(</code><code role="code-emph">types</code><code>)</code></td>
	</tr>
		<tr>
	  	  <td>Element Declaration</td>
          <td><code>element</code> QName </td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.elementDeclaration(</code><code role="code-emph">element</code><code>)</code></td>
	</tr>
	<tr>
          <td>Message</td>
          <td><code>message</code> NCName</td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.message(</code><code role="code-emph">message</code><code>)</code></td>
	</tr>
		<tr>
          <td>Message Part</td>
          <td><code>message</code> NCName</td>
          <td><code>part</code> NCName</td>
          <td>n/a</td>
          <td><code>wsdl11.messagePart(</code><code role="code-emph">message/part</code><code>)</code></td>
	</tr>
<tr>
	  	  <td>portType</td>
          <td><code>portType</code> NCName </td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.portType(</code><code role="code-emph">portType</code><code>)</code></td>
	</tr>
	<tr>
	      <td>portType Operation</td>
          <td><code>portType</code> NCName</td>
          <td><code>operation</code> NCName</td>
          <td>n/a</td>
          <td><code>wsdl11.portTypeOperation(</code><code role="code-emph">portType/operation</code><code>)</code></td>
	</tr>
	<tr>
          <td>portType Message Reference</td>
          <td><code>portType</code> NCName</td>
          <td><code>operation</code> NCName</td>
          <td><code>message</code> NCName</td>
          <td><code>wsdl11.portTypeMessageReference(</code><code role="code-emph">portType/operation/message</code><code>)</code></td>
	</tr>
	<tr>
          <td>portType Operation Fault</td>
          <td><code>portType</code> NCName</td>
          <td><code>operation</code> NCName</td>
           <td><code>fault</code> QName</td>
          <td><code>wsdl11.portTypeOperationFault(</code><code role="code-emph">portType/operation/fault</code><code>)</code></td>
	</tr>
	<tr>
	  	  <td>Binding</td>
          <td><code>binding</code> NCName</td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.binding(</code><code role="code-emph">binding</code><code>)</code></td>
	</tr>
	<tr>
	  <td>Binding Operation</td>
          <td><code>binding</code> NCName</td>
          <td><code>operation</code> QName</td>
          <td>n/a</td>
          <td><code>wsdl11.bindingOperation(</code><code role="code-emph">binding/operation</code><code>)</code></td>
	</tr>
	<tr>
	  <td>Binding Message Reference</td>
          <td><code>binding</code> NCName</td>
          <td><code>operation</code> QName</td>
          <td><code>message</code> NCName</td>
          <td><code>wsdl11.bindingMessageReference(</code><code role="code-emph">binding/operation/message</code><code>)</code></td>
	</tr>
		<tr>
	  <td>Binding Operation Fault</td>
          <td><code>binding</code> NCName</td>
          <td><code>operation</code> QName</td>
          <td><code>fault</code> NCName</td>
          <td><code>wsdl11.bindingOperationFault(</code><code role="code-emph">binding/operation/fault</code><code>)</code></td>
	</tr>

	<tr>
	  <td>Service</td>
          <td><code>service</code> NCName</td>
          <td>n/a</td>
          <td>n/a</td>
          <td><code>wsdl11.service(</code><code role="code-emph">service</code><code>)</code></td>
	</tr>
	<tr>
	  <td>port</td>
          <td><code>service</code> NCName</td>
          <td><code>port</code> NCName</td>
          <td>n/a</td>
          <td><code>wsdl11.port(</code><code role="code-emph">service/port</code><code>)</code></td>
	</tr>
		<tr>
	  <td>Extensions</td>
          <td><code>namespace</code> URI</td>
          <td><code>identifier</code> extension-specific-syntax</td>
          <td>n/a</td>
          <td><code>wsdl11.extension(</code><code role="code-emph">namespace,identifier</code><code>)</code></td>
	</tr>
	
      </tbody>
      </table>

      </div1>
<div1 id="wsdl-iri-references">
	<head>IRI-References for WSDL 1.1 Elements</head>

	<p>
		This section provides a syntax for IRI-references for all
		elements found in a [<bibref ref="WSDL11"/>] document. The IRI-references are easy
		to understand and compare, while imposing no burden on the WSDL 1.1
		author.
	</p>

	<div2 id="wsdl-iris">
	<head>WSDL 1.1 IRIs</head>
	<p>There are two main cases for WSDL 1.1 IRIs:</p>
	<ulist>
	<item><p>the IRI of a WSDL 1.1 document</p></item>
	<item><p>the IRI of a WSDL 1.1 namespace</p></item>
	</ulist>
	<p>
		The IRI of a WSDL 1.1 document can be dereferenced to give a
		resource representation that contributes elements
		to a single WSDL 1.1 namespace. If the media type is set to the WSDL 1.1
		media type i.e. application/xml, then the fragment identifiers can be used to
		identify the main elements that are defined in the document.
	</p>

	<p>
		In keeping with WSDL 1.1, which has a recommendation that 
		that the namespace URI be dereferencible to a WSDL 1.1 document,
		this section specifies the use of the namespace IRI with the
		WSDL 1.1 fragment identifiers to form an IRI-reference.
	</p>

	<p>
		The IRI in an IRI-reference for a WSDL 1.1 element is the
		namespace name of the
		<code>name</code>
		property of either the element itself, in the case of
		<code>portType</code>
		,
		<code>Binding</code>
		, and
		<code>Service</code>
		elements, or the
		<code>name</code>
		property of the ancestor top-level element. The IRI provided
		by the namespace name of the
		<code>name</code>
		property is combined with a zero or more
		<code>xmlns</code>
		pointer parts (see
		3.4 Namespace Binding Context
		in
		[<bibref ref="XPTR" />]
		) followed by a single WSDL 1.1 pointer part, following the same rules as defined for WSDL 1.1 fragment ids
		<specref ref="frag-ids" />
		.
	</p>

	</div2>
	
	<div2 id="soap-binding-decl-fragid">
          <head>IRI Identification Of SOAP Binding elements</head>

	  <p><code>SOAP Binding</code> elements (binding, operation, body, header, fault, headerfault, and address) can be identified using the
	  <emph>wsdl11.extension</emph>
	  XPointer Framework scheme according to the following rules:</p>

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.binding(</code><code role="code-emph">parent</code><code>)</code>), where: </p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Binding's parent</code> element
	    </p>
	    </item>
	  </ulist>	  

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.operation(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Operation's parent</code> element
	    </p>
	    </item>
	  </ulist>	  

	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.body(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Body's parent</code> element
	    </p>
	    </item>
	  </ulist>	  
	  
	  	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.header(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Header's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	 <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.headerfault(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP HeaderFault's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.fault(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Fault's parent</code> element
	    </p>
	    </item>
	  </ulist>	 
	  
	  <p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.address(</code><code role="code-emph">parent</code><code>)</code>)</p>
	  <ulist>
	    <item><p>
	      <emph>
		<code>parent</code>
	      </emph>
	      is the pointer part of the <code>SOAP Address's parent</code> element
	    </p>
	    </item>
	  </ulist>	 

	</div2>
	<div2 id="element-designator-canonical-form">
		<head>Canonical Form for WSDL 1.1 element identifiers</head>
		<p>
			The IRI-references described above MAY be used as WSDL 1.1
			element identifiers. For ease of comparison, the fragment
			identifier of WSDL 1.1 element identifiers SHOULD conform
			to the following canonicalization rules:
		</p>
		<ulist>
			<item>
				<p>
						The fragment identifier consists of a sequence
						zero or more
						<code>xmlns()</code>
						pointer parts followed by exactly one
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						Each
						<code>xmlns()</code>
						pointer part that appears in the fragment
						identifier defines a namespace that is
						referenced by the
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						Each
						<code>xmlns()</code>
						pointer part defines a unique namespace.
				</p>
			</item>
			<item>
				<p>
						The
						<code>xmlns()</code>
						pointer parts define namespaces in the same
						order as they are referenced in the
						<code>wsd11.*()</code>
						pointer part.
				</p>
			</item>
			<item>
				<p>
						The namespace prefixes defined by the
						<code>xmlns()</code>
						pointer parts are named
						<code>ns1</code>
						,
						<code>ns2</code>
						, etc., in the order of their appearance.
				</p>
			</item>
			<item>
				<p>
						The fragment identifier contains no optional
						whitespace.
				</p>
			</item>
		</ulist>
	</div2>

	<div2 id="Iri-ref-ex">
	<head>Example</head>
	<p>Consider WSDL 1.1 document located at
	http://example.org/TicketAgent.wsdl.  Each WSDL 1.1 Element Identifier is shown in comments above the WSDL 1.1 element
	</p>
	<example id="iri-ref-example-wsdl">
	<head>IRI-References - Example WSDL 1.1 Document</head>
	<eg xml:space="preserve"><![CDATA[<?xml version="1.0" encoding="UTF-8"?> 

<wsdl:definitions targetNamespace="http://example.org/TicketAgent.wsdl11"
    xmlns:tns="http://example.org/TicketAgent.wsdl11" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ http://www.w3.org/TR/2001/NOTE-wsdl-20010315/wsdl11.xsd">

    <!-- http://example.org/TicketAgent.wsdl11#wsd11.definitions() -->

    <wsdl:types>
        <xs:schema xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd"
            targetNamespace="http://example.org/TicketAgent.xsd">
            <xs:element name="listFlightsRequest" type="xsTicketAgent:tListFlights"/>
            <!-- Starting from here, http://example.org/TicketAgent.wsdl11 will be shortened to http://...
         http://...#xmlns(ns1=http://example.org/TicketAgent.xsd)
        wsdl11.elementDeclaration(ns1:listFlightsRequest) -->
            <xs:complexType name="tListFlights">
                <xs:sequence>
                    <xs:element name="travelDate" type="xs:date"/>
                    <xs:element name="startCity" type="xs:string"/>
                    <xs:element name="endCity" type="xs:string"/>
                </xs:sequence>
            </xs:complexType>
            <xs:element name="listFlightsResponse" type="xsTicketAgent:tFlightsResponse"/>
            <!-- http://...#xmlns(ns1=http://example.org/TicketAgent.xsd)
         wsdl11.elementDeclaration(ns1:listFlightsResponse) -->
            <xs:complexType name="tFlightsResponse">
                <xs:sequence>
                    <xs:element name="flightNumber" type="xs:integer" minOccurs="0"
                        maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:complexType>
        </xs:schema>
    </wsdl:types>

    <wsdl:message name="listFlightsRequest">
        <!-- http://...#wsdl11.message(listFlightsRequest) -->
        <wsdl:part name="body" element="xsTicketAgent:listFlightsRequest"/>
        <!-- http://...#wsdl11.messagePart(listFlightsRequest/body) -->
    </wsdl:message>

    <wsdl:message name="listFlightsResponse">
        <!-- http://...#wsdl11.message(listFlightsResponse) -->
        <wsdl:part name="body" element="xsTicketAgent:listFlightsResponse"/>
        <!-- http://...#wsdl11.messagePart(listFlightsResponse/body) -->
    </wsdl:message>

    <wsdl:portType name="TicketAgent">
        <!-- http://...#wsdl11.portType(TicketAgent) -->
        <wsdl:operation name="listFlights">
            <!-- http://...#wsdl11.portTypeOperation(TicketAgent/listFlights) -->
            <wsdl:input message="tns:listFlightsRequest"/>
            <!-- http://...#wsdl11.portTypeMessageReference(TicketAgent/listFlights/input) -->
            <wsdl:output message="tns:listFlightsResponse"/>
            <!-- http://...#wsdl11.portTypeMessageReference(TicketAgent/listFlights/output) -->
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="TicketAgentSoap" type="tns:TicketAgent">
        <!-- http://...#wsdl11.binding(TicketAgentSoap) -->
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
             w11soap.binding( wsdl11.binding(TicketAgentSoap)) -->
        <wsdl:operation name="listFlights">
            <!-- http://...#wsdl11.bindingOperation(TicketAgentSoap/listFlights) -->
            <wsdl:input>
                <!-- http://...#wsdl11.bindingOperationMessageReference(TicketAgentSoap/listFlights/input) -->
                <soap:body parts="body" use="literal"/>
                <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperationMessageReference
                                           (TicketAgentSoap/listFlights/input)) -->
            </wsdl:input>
            <wsdl:output>
                <!-- http://...#wsdl11.bindingOperationMessageReference(TicketAgentSoap/listFlights/output) -->
                <soap:body parts="body" use="literal"/>
                <!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperationMessageReference
                                           (TicketAgentSoap/listFlights/output)) -->
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>

</wsdl:definitions>]]></eg>
</example>
	</div2>
    </div1>		
		
		<div1 id="refs">
			<head>References</head>
			<div2 id="refs-norm">
				<head>Normative References</head>
				<blist>

<bibl key="RFC 3023"	 
	  href="http://www.ietf.org/rfc/rfc3023.txt" id="RFC3023">IETF
	  "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July
	  1998.</bibl>
	  
	  <bibl key="WSDL 2.0 Core" href="http://www.w3.org/TR/2006/CR-wsdl20-20060327"
	  	id="WSDL-PART1">
	  	<titleref>
		 Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language
	  	</titleref>, R. Chinnici, J-J.
	  	Moreau, A. Ryman, S. Weerawarana, Editors. W3C Candidate Recommendation 27 March 2006. The current version of <loc href="http://www.w3.org/TR/2006/CR-wsdl20-20060327">Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language</loc> is available at
	  	http://www.w3.org/TR/2006/CR-wsdl20-20060327 . The
	  	<loc href="http://www.w3.org/TR/wsdl20">
	  		latest version of "Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language"
	  	</loc>
	  	is available at
	  	http://www.w3.org/TR/wsdl20.
	  </bibl>


	  <bibl key="WSDL 1.1"
	    href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315"
	    id="WSDL11">
	  <titleref>Web Services definitions Language (WSDL)
	  1.1</titleref>, E. Christensen, F. Curbera, G. Meredith, and
	  S. Weerawarana, Authors. W3C Note 15 March
	  2002. The current version of <loc href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</loc> is available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315 . The <loc
	  href="http://www.w3.org/TR/wsdl">latest version of Web
	  Services definitions Language 1.1</loc> is available at
	  http://www.w3.org/TR/wsdl11.
	</bibl>
	
<bibl key="XPointer Framework"
	    href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"
	    id="XPTR">
	    <titleref>XPointer Framework</titleref>,Paul Grosso, Eve
	    Maler, Jonathan Marsh, Norman Walsh, Editors. W3C Recommendation 25 March 2003.  The current version of <loc href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">XPointer Framework</loc> is available at 
	    http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . The
	    <loc href='http://www.w3.org/TR/xptr-framework/'>latest
	    version of XPointer Framework</loc> is available at
	    http://www.w3.org/TR/xptr-framework/.
	  </bibl>
					<bibl key="RFC 2119" id="RFC2119" href="http://www.ietf.org/rfc/rfc2119.txt">IETF "RFC 2119:
	  Key words for use in RFCs to Indicate Requirement Levels",
	  S. Bradner, March 1997.</bibl>
					<bibl key="RFC 3986" id="RFC3986" href="http://www.ietf.org/rfc/rfc3986.txt">IETF "RFC 3986:
	  Uniform Resource Identifiers (URI): Generic Syntax",
	  T. Berners-Lee, R. Fielding, L. Masinter, January 2005. </bibl>
				</blist>
			</div2>
			<!--<div2 id="refs-inform">
				<head>Informative References</head>

			</div2> -->
		</div1>
	</body>
	<back>
		<inform-div1 id="changelog">
			<head>Change Log</head>
			<table border="1">
				<caption>Changes</caption>
				<thead>
					<tr>
						<th>Who</th>
						<th>When</th>
						<th>What</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td>DBO</td>
						<td>20061108</td>
						<td>Initial Revision</td>
					</tr>
					
					<tr>
						<td>DBO</td>
						<td>20061212</td>
						<td>Uncommented canonical section, fixed editorial items</td>
					</tr>
					<tr>
<td>DBO</td>
<td>20070122</td>
<td>Resolution of bug <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4208">4208</loc>, AI is <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/145">145</loc>
</td>
</tr>
				    <tr>
				        <td>FS</td>
				        <td>20070127</td>
				        <td>Editorial fixes for publication preparation</td>
				    </tr>				
				</tbody>
			</table>
		</inform-div1>
	</back>
</spec>

Index: ws-policy-guidelines-diff20061221.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20061221.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20061221.xml	16 Mar 2007 13:15:02 -0000	1.2
+++ ws-policy-guidelines-diff20061221.xml	22 Mar 2007 07:11:39 -0000	1.3
@@ -5,8 +5,8 @@
 %entities;
 <!ENTITY status SYSTEM "status-guidelines.xml">
 <!ENTITY prefix "ws-policy-guidelines" >
-<!ENTITY document.status "Editors' copy $Date$">
-<!ENTITY prevloc "">
+<!ENTITY document.status.guidelines "Editors' copy $Date$">
+<!ENTITY prevloc "http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221">
 <!ENTITY hellip "&#8230;">
 ]><spec role="editors-copy" w3c-doctype="wd">
   <header>
@@ -21,11 +21,10 @@
     <publoc>
       <loc href="ws-policy-guidelines.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">ws-policy-guidelines.html</loc>
     </publoc> 
-    <!--
-	<prevlocs>
-            <loc href="&prevloc;">&prevloc;</loc>
-        </prevlocs>
--->
+	<prevlocs diff="add">
+            <loc href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221</phrase></loc>
+        </prevlocs> 
+    
     <latestloc>
       <loc href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</loc>
     </latestloc>
@@ -229,7 +228,7 @@
            		 for </phrase><phrase diff="chg">be marked as ignorable (indicating it does not impact interoperability). An </phrase><phrase diff="add">ignorable</phrase><phrase diff="del">behavior
             	then </phrase><phrase diff="chg">policy </phrase>assertion <phrase diff="add">is 
           		ignored</phrase><phrase diff="del">will </phrase><phrase diff="chg">for lax policy intersection. If an assertion is not an </phrase><phrase diff="add">ignorable</phrase><phrase diff="del">policy
-            	intersection </phrase><phrase diff="chg">assertion then it is </phrase><phrase diff="add">deemed important for agreement 
+            	intersection </phrase><phrase diff="add">assertion then</phrase><phrase diff="del">will </phrase><phrase diff="chg">it is deemed </phrase><phrase diff="add">important for agreement 
           		between both parties.
           	</phrase><phrase diff="del">negatives.
             	</phrase></p>
@@ -248,7 +247,7 @@
           	</item>
         </ulist>
 		
-		<p>There are already many examples in the industry that adhere to <phrase diff="chg">the </phrase><phrase diff="add">above practices,</phrase><phrase diff="del">practice, </phrase>such as <bibref ref="WS-RM-Policy"></bibref>
+		<p>There are already many examples in the industry that adhere to <phrase diff="add">the above</phrase><phrase diff="del">this </phrase><phrase diff="chg">practices, </phrase>such as <bibref ref="WS-RM-Policy"></bibref>
       	and <bibref ref="WS-SecurityPolicy"></bibref>. Some common characteristics from these documents may be considered as <emph>best practices</emph> for new <phrase diff="chg">Assertion Authors:
       	</phrase></p> 
 			<ulist>
@@ -302,8 +301,8 @@
 				<div3 id="domain-owners">
 				
 				<head> <phrase diff="chg">Assertion </phrase>Authors</head>
-				<p><phrase diff="add">Assertion </phrase><phrase diff="del">WS-Policy Domain owners or WS-Policy </phrase><phrase diff="chg">Authors </phrase>are defined
-       			 by the WS-Policy Framework to be a community that chooses to
+				<p><phrase diff="add">Assertion </phrase><phrase diff="del">WS-Policy Domain owners or WS-Policy </phrase><phrase diff="chg">Authors </phrase>are <phrase diff="del">defined
+       			 by the WS-Policy Framework to be </phrase>a community that chooses to
         		exploit the WS-Policy Framework by creating their own
         		specification to define a set of assertions that express the
         		capabilities and constraints of that target domain. The
@@ -321,10 +320,10 @@
     	    	must adhere to the MUST's and SHOULD's in the specification
     	    	and should review the conformance section of the specification. 
     	    	</p>
-    	   		 <p><phrase diff="add">Assertion</phrase><phrase diff="del">WS-Policy Domain </phrase><phrase diff="chg">Authors </phrase>must also specify how to associate
-				the assertions they have defined with the policy subjects
-				identified by the WS-PolicyAttachment specification.
-				</p>
+    	   		 <p><phrase diff="chg">An assertion author should </phrase>also specify <phrase diff="chg">a policy </phrase><phrase diff="add">subject. For</phrase><phrase diff="del">associate
+				</phrase><phrase diff="chg">instance, if a policy </phrase><phrase diff="add">assertion were to be used</phrase><phrase diff="del">defined </phrase>with <phrase diff="chg">WSDL, an assertion
+				description should specify a </phrase><phrase diff="add">WSDL policy subject.</phrase><phrase diff="del">specification.
+				</phrase></p>
         		<p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
         		specification [<bibref ref="WS-SecurityPolicy"></bibref>]. The
         		WS-SecurityPolicy authors have defined their scope as follows:
@@ -382,14 +381,14 @@
 				</phrase>expression that conforms to the <phrase diff="add">Web Services Policy 1.5 - Framework</phrase><phrase diff="del">WS-PolicyFramework </phrase><phrase diff="add">[</phrase><bibref diff="add" ref="WS-Policy"></bibref><phrase diff="add">]
 				</phrase>and <phrase diff="add">Web Services Policy 1.5 -
 	   			</phrase><phrase diff="del">WS-Policy </phrase>Attachment <phrase diff="add">[</phrase><bibref diff="add" ref="WS-PolicyAttachment"></bibref><phrase diff="add">]</phrase><phrase diff="del">specifications. </phrase><phrase diff="add">specifications.
-				</phrase>The <phrase diff="add">Web Services Policy 1.5 - Attachment
-	   			</phrase><phrase diff="del">WS-PolicyAttachment </phrase>specification has defined a set of
+				</phrase>The <phrase diff="chg">Web </phrase><phrase diff="add">Services Policy 1.5 - Attachment </phrase>specification has defined a set of
 	   			subjects and an extensible mechanism for attaching policies
-	   			to web services subjects. When a web service provider
+	   			to web services subjects. 
+           		 <phrase diff="del">When a web service provider
 	   			chooses to make its capabilities and constraints available,
-	   			<phrase diff="add">the provider</phrase><phrase diff="del">it </phrase>may also need to conform to requirements of other policy
-	   			<phrase diff="add">assertion </phrase>specifications it utilizes ( i.e., WS-SecurityPolicy).
-           		</p>
+	   			it may also need to conform to requirements of other policy
+	   			specifications it utilizes ( i.e., WS-SecurityPolicy).
+           		</phrase></p>
 				<p>When deploying services with policies it is useful for providers to anticipate how
            		to evolve their services capabilities over time.  If
            		forward compatibility is a concern in order to accommodate
@@ -406,7 +405,7 @@
 		<head>General Guidelines for <phrase diff="del">WS-Policy </phrase>Assertion Authors</head>
 		<p> As <phrase diff="add">Assertion Authors</phrase><phrase diff="del">authors </phrase>begin the task of inventing XML dialects to represent policy  assertions they can take
 		advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy 
-		relies on the QName of a policy assertion being an XML element but allows <phrase diff="chg">Assertion </phrase><phrase diff="add">Authors </phrase>to optionally  
+		relies on the QName of a policy assertion being an XML element but allows <phrase diff="add">Assertion Authors</phrase><phrase diff="del">authors </phrase>to optionally  
 		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>
       		<ulist>
@@ -433,7 +432,7 @@
 			<div2 id="assertion-target">
 			<head>Assertions and Their Target Use</head>
 				<p>
-				<phrase diff="add">Assertion</phrase><phrase diff="del">WS-Policy </phrase><phrase diff="chg">Authors </phrase>need to have <phrase diff="add">a</phrase><phrase diff="del">some definition of what </phrase><phrase diff="chg">specific </phrase>goal <phrase diff="chg">in </phrase><phrase diff="add">mind </phrase>for the assertions 
+				<phrase diff="add">Assertion</phrase><phrase diff="del">WS-Policy </phrase><phrase diff="chg">Authors </phrase>need to have <phrase diff="add">a</phrase><phrase diff="del">some definition of what </phrase><phrase diff="chg">specific </phrase>goal <phrase diff="add">in mind</phrase><phrase diff="del">is </phrase>for the assertions 
 				<phrase diff="add">that 
 			</phrase>they author. <phrase diff="chg">Assertion Authors </phrase>should also understand the 
 				functionality <phrase diff="add">that </phrase>the WS-Policy framework provides and apply the 
@@ -446,9 +445,9 @@
            	assertions </phrase>or they may choose to specify <phrase diff="add">assertions</phrase><phrase diff="del">many assertion
            	elements </phrase>that 
 				<phrase diff="add">contains </phrase><phrase diff="chg">assertion </phrase>parameters <phrase diff="add">and/or</phrase><phrase diff="del">or other </phrase>nested <phrase diff="add">policy expression (nested 
-				assertions), each of which relate to an aspect of the behavior,
-           	</phrase><phrase diff="del">assertions. </phrase><phrase diff="add">yet 
-				encapsulated within a single assertion. </phrase>There are advantages to 
+				assertions), each of which relate to an aspect of the behavior, yet 
+				encapsulated
+           	</phrase><phrase diff="del">assertions. </phrase><phrase diff="add">within a single assertion. </phrase>There are advantages to 
 				simplifying the set of assertions. The ultimate goal of policy <phrase diff="del">assertions </phrase>is to 
 				enable <phrase diff="add">interoperability.</phrase><phrase diff="del">interoperability and assertions that </phrase><phrase diff="chg">By </phrase><phrase diff="add">keeping</phrase><phrase diff="del">behavior
            	for </phrase><phrase diff="chg">assertion design as simple </phrase><phrase diff="add">as 
@@ -465,9 +464,8 @@
 			<p>
 				The <phrase diff="add">WS-Policy Attachment specification defines a </phrase>number of different 
 				<phrase diff="add">policy </phrase>subjects to which an assertion can be <phrase diff="chg">attached. For attaching </phrase><phrase diff="add">to 
-					WSDL</phrase><phrase diff="del">a </phrase><phrase diff="chg">subjects see </phrase><specref diff="add" ref="levels-of-abstraction"></specref><phrase diff="del">defining </phrase><phrase diff="add">for</phrase><phrase diff="del">an
-           	assertion. </phrase><phrase diff="chg">more </phrase><phrase diff="add">detail. 
-				Additionally,</phrase><phrase diff="del">the </phrase><phrase diff="chg">the framework provides for </phrase><phrase diff="add">the</phrase><phrase diff="del">sometimes
+					WSDL</phrase><phrase diff="del">a </phrase><phrase diff="chg">subjects see </phrase><specref diff="add" ref="levels-of-abstraction"></specref><phrase diff="del">defining </phrase><phrase diff="chg">for more </phrase><phrase diff="add">detail. 
+				Additionally,</phrase><phrase diff="del">Determining </phrase>the <phrase diff="add">framework</phrase><phrase diff="del">appropriate policy </phrase><phrase diff="chg">provides for </phrase><phrase diff="add">the</phrase><phrase diff="del">sometimes
            	involve </phrase><phrase diff="chg">means to extend </phrase><phrase diff="add">the</phrase><phrase diff="del">of  wide </phrase><phrase diff="chg">set </phrase>of 
 				<phrase diff="add">policy </phrase><phrase diff="chg">subjects beyond </phrase><phrase diff="add">the</phrase><phrase diff="del">from
            	stand </phrase><phrase diff="chg">set of subjects defined in the WS-Policy 
@@ -486,7 +484,7 @@
 				subject.</phrase><phrase diff="del">assertion </phrase><phrase diff="chg">For instance, an </phrase><phrase diff="add">assertion</phrase><phrase diff="del">it
 			in </phrase><phrase diff="chg">"Foo" has the same </phrase><phrase diff="add">semantic</phrase><phrase diff="del">different
 			alternatives) </phrase><phrase diff="add">when 
-				attached to</phrase><phrase diff="del">via </phrase><phrase diff="chg">an operation </phrase>policy <phrase diff="chg">subject regardless </phrase><phrase diff="add">of</phrase><phrase diff="del">be
+				attached</phrase><phrase diff="del">via </phrase><phrase diff="chg">to </phrase><phrase diff="add">an operation</phrase><phrase diff="del">a </phrase>policy <phrase diff="chg">subject regardless </phrase><phrase diff="add">of</phrase><phrase diff="del">be
 			associated </phrase><phrase diff="chg">whether it </phrase><phrase diff="add">was 
 				attached</phrase><phrase diff="del">alternatives </phrase><phrase diff="chg">using XML </phrase><phrase diff="add">element</phrase><phrase diff="del">A
 			referencing </phrase><phrase diff="chg">policy attachment or the external </phrase><phrase diff="add">URI 
@@ -495,9 +493,8 @@
 			<phrase diff="del">attachment </phrase><phrase diff="chg">attachment </phrase><phrase diff="add">mechanism 
 				allows</phrase><phrase diff="del">multiple </phrase><phrase diff="chg">policy tools to </phrase><phrase diff="add">choose</phrase><phrase diff="del">Endpoint
 			References </phrase><phrase diff="chg">the most appropriate mechanism to attach </phrase><phrase diff="add">a 
-				policy</phrase><phrase diff="del">policies </phrase><phrase diff="chg">without having </phrase>to <phrase diff="add">analyze the</phrase><phrase diff="del">be </phrase><phrase diff="add">contents of the policy. 
-				</phrase><phrase diff="del">applied. 
-	   		</phrase></p>
+				policy</phrase><phrase diff="del">policies </phrase><phrase diff="chg">without having </phrase>to <phrase diff="add">analyze the contents of the</phrase><phrase diff="del">be </phrase><phrase diff="chg">policy. 
+				</phrase></p>
 	   		<p>
 				Best practice: <phrase diff="chg">Assertion Authors </phrase>should include the following items in <phrase diff="chg">an 
 				assertion </phrase>specification: 
@@ -505,8 +502,8 @@
 				<ulist>
 					<item>
 						<p><emph>The definition of the
-            			<phrase diff="del">assertion. Does the assertion pertain to a specific
-           				behavior that is tied </phrase><phrase diff="chg">assertion's </phrase><phrase diff="add">semantic.</phrase></emph><phrase diff="del">a </phrase></p></item>
+            			<phrase diff="del">assertion. Does the assertion pertain to a </phrase><phrase diff="add">assertion's</phrase><phrase diff="del">specific
+           				behavior that is tied to </phrase><phrase diff="add">semantic.</phrase></emph><phrase diff="del">a </phrase></p></item>
 						<item><p><emph><phrase diff="add">The</phrase><phrase diff="del">context </phrase><phrase diff="chg">specification of </phrase>the <phrase diff="add">set</phrase><phrase diff="del">behavior
           				different </phrase><phrase diff="chg">of valid policy subjects to which </phrase>an 
 						assertion <phrase diff="del">that </phrase>may <phrase diff="del">have different semantics for a single
@@ -620,20 +617,20 @@
             depending </phrase><phrase diff="chg">same policy expression are </phrase><phrase diff="add">semantically
 					equivalent.</phrase><phrase diff="del">example, </phrase><phrase diff="chg">When </phrase>multiple alternatives are present in a policy, the
 					normal form may express the choices more explicitly. On the other hand,
-					the compact form <phrase diff="chg">may </phrase><phrase diff="add">be </phrase>more readable for humans when an assertion is
+					the compact form <phrase diff="add">may be</phrase><phrase diff="del">is </phrase>more readable for humans when an assertion is
 					marked as optional using the <code>wsp:optional</code> attribute as our example
 					illustrates above. 
            	</p> 
 			    <p><phrase diff="chg">A policy </phrase><phrase diff="add">processor may normalize a policy expression originally authored
-					in compact form at</phrase><phrase diff="del">use </phrase><phrase diff="add">any time without changing </phrase>the <phrase diff="chg">semantics of </phrase><phrase diff="add">the
+					in</phrase><phrase diff="del">use </phrase><phrase diff="add">compact form at any time without changing </phrase>the <phrase diff="chg">semantics of </phrase><phrase diff="add">the
 					policy.</phrase><phrase diff="del">most </phrase><phrase diff="add">In general, it is not possible to guarantee in what form a
-					policy expression would be when it is processed. As a</phrase><phrase diff="del">appropriate </phrase><phrase diff="add">result, the
+					policy expression would be when it is processed. As a result,</phrase><phrase diff="del">appropriate </phrase><phrase diff="add">the
 					description </phrase>for <phrase diff="add">a policy assertion should not depend on </phrase>the <phrase diff="add">style used
 					to author a policy expression that contains the assertion.
 				</phrase></p>
            	
 				<p diff="add"><phrase diff="add">Best practice: the semantics of an assertion should be independent of
-					the form (compact or normal form) of policy expressions that</phrase><phrase diff="del">target </phrase><phrase diff="chg">contain </phrase><phrase diff="add">the
+					the form (compact or normal form) of</phrase><phrase diff="del">target </phrase><phrase diff="add">policy expressions that</phrase><phrase diff="del">audience </phrase><phrase diff="add">contain the
 					assertion.</phrase></p>
 			</div2>
 			
@@ -658,7 +655,7 @@
          			</p>
          			<p>If grouping is utilized, choices between alternatives can be indicated by
          			an "exactly one" operator. This basic set of operators allows
-         			<phrase diff="add">Assertion Authors</phrase><phrase diff="del">authors </phrase>a wide range of options for expressing the possible combinations of assertions within their domain.
+         			<phrase diff="chg">Assertion </phrase><phrase diff="add">Authors </phrase>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
@@ -698,7 +695,7 @@
         		</div3>	
         		<div3 id="self-describing">
 					<head> Self Describing Messages </head>
-        			<p> WS-Policy is intended to communicate the requirements, capabilities, preferences and
+        			<p> WS-Policy is intended to communicate the requirements, <phrase diff="add">capabilities</phrase><phrase diff="del">capabilities, preferences </phrase>and
     	 			behaviors of nodes that provide the message's path, not specifically to declare properties of the message semantics. One
     	 			of the advantages of Web services is that an XML message can be stored and later examined (e.g. as a record of a business
      				transaction) or interpreted by an intermediary; however, if information that is necessary to understand a message is not
@@ -793,24 +790,24 @@
                                         <phrase diff="chg">policy assertion parameters </phrase>to qualify an assertion. 
                                         <phrase diff="chg">Policy assertion parameters are defined </phrase><bibref diff="add" ref="WS-Policy"></bibref><phrase diff="add">.   
                                         Policy</phrase><phrase diff="del">be </phrase><phrase diff="add">assertion</phrase><phrase diff="del">appropriate
-        			to </phrase><phrase diff="chg">parameters </phrase><phrase diff="add">are the opaque payload of</phrase><phrase diff="del">these </phrase><phrase diff="add">an assertion.  
+        			to </phrase><phrase diff="chg">parameters </phrase><phrase diff="add">are the opaque payload</phrase><phrase diff="del">these </phrase><phrase diff="add">of an assertion.  
                                         Assertion </phrase>parameters <phrase diff="add">carry additional useful pieces</phrase><phrase diff="del">instead </phrase>of <phrase diff="add">information 
                                         necessary</phrase><phrase diff="del">nesting </phrase><phrase diff="chg">for </phrase><phrase diff="add">engaging</phrase><phrase diff="del">elements. 
         			
-					 </phrase><phrase diff="chg">the </phrase><phrase diff="add">behavior described by an assertion.  
-                                        Assertion</phrase><phrase diff="del">that </phrase>parameters <phrase diff="chg">are not </phrase><phrase diff="add">considered when performing policy 
-                                        intersection unless domain specific compatibility processing
-                                        semantics are specified by</phrase><phrase diff="del">include </phrase>the <phrase diff="add">assertion.  
-                                        In the XML</phrase><phrase diff="del">following:
+					 </phrase><phrase diff="chg">the </phrase><phrase diff="add">behavior described by</phrase><phrase diff="del">that </phrase><phrase diff="add">an assertion.  
+                                        Assertion </phrase>parameters <phrase diff="chg">are not </phrase><phrase diff="add">considered when performing policy 
+                                        intersection unless domain</phrase><phrase diff="del">include </phrase><phrase diff="add">specific compatibility processing
+                                        semantics are specified by </phrase>the <phrase diff="add">assertion.  
+                                        In the XML representation of a policy assertion the</phrase><phrase diff="del">following:
 					
 						
-						 </phrase><phrase diff="add">representation of a policy</phrase><phrase diff="del">Complex </phrase><phrase diff="add">assertion the child </phrase>elements 
-                                        <phrase diff="add">and </phrase><phrase diff="chg">attributes of the assertion excluding </phrase><phrase diff="add">child elements and</phrase><phrase diff="del">be </phrase><phrase diff="add">attributes 
-                                        from the </phrase>policy <phrase diff="add">xml language</phrase><phrase diff="del">assertions.  
+						 </phrase><phrase diff="chg">child </phrase>elements 
+                                        <phrase diff="add">and </phrase><phrase diff="chg">attributes of the assertion excluding </phrase><phrase diff="add">child elements and attributes 
+                                        from the</phrase><phrase diff="del">be </phrase>policy <phrase diff="add">xml</phrase><phrase diff="del">assertions.  
 						 
 						
 						
-						 </phrase><phrase diff="chg">namespace are the assertion </phrase><phrase diff="add">parameters.
+						 </phrase><phrase diff="chg">language namespace are the </phrase><phrase diff="add">assertion parameters.
                                         </phrase></p>
 
 					
@@ -914,6 +911,45 @@
         				security usage is absorbed by a policy-aware client and hidden
         				from Web service application developers.
         				</p>
+        				
+					<p diff="add"><phrase diff="add">Assertion authors should note the effect of nested policy expressions
+						on policy intersection in their nested policy design. The result of
+						intersecting an assertion that contains an empty nested policy
+						expression with an assertion of the same type without a nested policy
+						expression is that the assertions are not compatible. Therefore, when
+						providers require dependent behaviors these behaviors should be
+						explicitly specified as assertions in a nested policy expression. When
+						the definition of an assertion allows for nested dependent behaviors,
+						but the use of the assertion only contains an empty nested policy
+						expression, this specific use indicates the specification of no nested
+						dependent behaviors. This use must not be interpreted as being
+						compatible with "any" of the nested dependent behaviors that are
+						allowed by the assertion, unless otherwise specified by the assertion
+						definition.</phrase></p>
+					
+					<p diff="add"><phrase diff="add">As an example, WS-Security Policy defines </phrase><code><phrase diff="add">sp:HttpToken</phrase></code> <phrase diff="add">assertion to
+						contain three possible nested elements, </phrase><code><phrase diff="add">sp:HttpBasicAuthentication</phrase></code><phrase diff="add">,
+						</phrase><code><phrase diff="add">sp:HttpDigestAuthentication</phrase></code> <phrase diff="add">and </phrase><code><phrase diff="add">sp:RequireClientCertificate</phrase></code><phrase diff="add">. When the
+						</phrase><code><phrase diff="add">HttpToken</phrase></code> <phrase diff="add">is used with an empty nested policy in a policy expression
+						by a provider, it will indicate that none of the dependent behaviors
+						namely authentication or client certificate is required.</phrase></p>
+					
+					<example diff="add">
+						<head><phrase diff="add">Empty Nested Policy Expression</phrase></head>
+						<eg xml:space="preserve">&lt;sp:TransportToken&gt; 
+  &lt;wsp:Policy&gt; 
+	&lt;sp:HttpsToken&gt; 
+	  &lt;wsp:Policy/&gt; 
+	&lt;/sp:HttpsToken&gt; 
+  &lt;/wsp:Policy&gt; 
+&lt;/sp:TransportToken&gt;</eg>
+					</example> 
+					
+					<p diff="add"><phrase diff="add">A non-anonymous client who requires authentication or client
+						certificate will not be able to use this provider solely on the basis
+						of intersection algorithm alone.</phrase></p>
+					
+				
 				</div3>
 					
 				<div3 id="which-one-to-use">
@@ -956,7 +992,7 @@
         			<p>Best practice: If the <phrase diff="chg">assertion
         			</phrase>authors want to delegate the processing to the framework,
         			utilizing nesting should be considered. Otherwise, domain
-        			specific comparison algorithms will need to be devised and be
+        			specific comparison algorithms <phrase diff="chg">may </phrase>need to be devised and be
         			delegated to the specific domain handlers that are not visible
         			to the WS-Policy framework.
         			</p>
@@ -1082,68 +1118,70 @@
           			</p>
           		</div3>
 			</div2>
-			<div2 id="typing-assertions">
-				<head>Typing Assertions</head>
-				<p>Since a <emph>QName</emph> is the central mechanism for
-	  			identifying a policy assertion, <phrase diff="chg">Assertion Authors </phrase>should be
+			
+			
+			
+			
+				<p diff="del">Typing Assertions
+				Since a QName is the central mechanism for
+	  			identifying a policy assertion, assertion authors should be
 	  			aware of the possible evolution of their assertions and how
 	  			this would impact the semantics of the assertion overtime. A namespace
 	 			 associated with the assertion may be used to indicate a
-	  			specific version of an assertion but this has its limitations. 
-	  			See <phrase diff="add">section</phrase><phrase diff="del">Lifecycle material </phrase><specref diff="chg" ref="versioning-policy-assertions"></specref> for more detail.
-          		</p>
-				<p>The typing must be done in combination with the scoping
+	  			specific version of an assertion but this has its limitations. See Lifecycle material  for more detail.
+          		
+				The typing must be done in combination with the scoping
 				of the semantics to a policy subject. WS-PolicyAttachment provides a means of associating an
           		assertion with arbitrary subjects, regardless of their
           		nature. This flexibility can lead to ambiguity in the
           		interpretation of policy; for example, if one attaches an
           		assertion with the semantic "must be encrypted" to a SOAP
           		endpoint, it's unclear what must be encrypted.
-          		</p>
-		  		<p> One way to disambiguate the semantic is to generally determine
+          		
+		  		 One way to disambiguate the semantic is to generally determine
           		if an assertion is specific to a policy attachment
           		mechanism. An example could be identifying whether the
           		assertion expressed is associated with behaviors
           		(endpoints) or artifacts (messages) and then constraining
           		the use of an assertion to one of these subjects.
-          		</p>
-				<p>Thus our example encryption assertion would have a
+          		
+				Thus our example encryption assertion would have a
           		subject of "message", and could only be attached to
-          		messages, where the assertion is valid. However, <phrase diff="add">Assertion Authors</phrase><phrase diff="del">authors
-          		</phrase>need to be aware that <emph>policy attachment subjects are
-          		not limited to the subjects defined in WSDL</emph>.  The
+          		messages, where the assertion is valid. However, authors
+          		need to be aware that policy attachment subjects are
+          		not limited to the subjects defined in WSDL.  The
           		external attachment model in WS-PolicyAttachment allows for
           		the definition of other domain expressions to be policy
-          		subjects. More of this topic is covered in the <bibref ref="WS-Policy-Primer"></bibref>
-				</p>        
-				<p>Best Practice- To avoid confusion, assertion definitions should be
+          		subjects. More of this topic is covered in the 
+				        
+				Best Practice- To avoid confusion, assertion definitions should be
           		precise about their semantics and include information that
           		restricts their set of permissible policy subjects
           		appropriately and indicates which QNames are associated with
-          		which subjects.</p>        
-          		<olist>
-          <item>
-            <p>Description must clearly and completely specify the syntax (plus an XML Schema
-              document) and semantics of a policy assertion.</p>
-          </item>
-          <item>
-            <p>If there is a nested policy expression, description must declare it and enumerate the
-              nested policy assertions that are allowed. </p>
-          </item>
-          <item>
-            <p>A policy alternative may contain multiple instances of the same policy assertion.
+          		which subjects.        
+          		
+          
+            Description must clearly and completely specify the syntax (plus an XML Schema
+              document) and semantics of a policy assertion.
+          
+          
+            If there is a nested policy expression, description must declare it and enumerate the
+              nested policy assertions that are allowed. 
+          
+          
+            A policy alternative may contain multiple instances of the same policy assertion.
               Description must specify the semantics of parameters and nested policy (if any) when
               there are multiple instances of a policy assertion in the same policy alternative.
-            </p>
-          </item>
-          <item>
-            <p>If a policy assertion is to be used with WSDL, description must specify a WSDL policy
-              subject – such as service, endpoint, operation and message.</p>
-          </item>
-        </olist>
-			</div2>
+            
+          
+          
+            If a policy assertion is to be used with WSDL, description must specify a WSDL policy
+              subject – such as service, endpoint, operation and message.
+          
+        
 			
-			<div2 id="levels-of-abstraction">
+			
+			</p><div2 id="levels-of-abstraction">
 				<head>Levels of Abstraction in WSDL </head>
 				<p>A behavior identified by a policy assertion applies to the
         		associated policy subject. If a policy assertion is to be used
@@ -1293,7 +1331,7 @@
 			</item>
 			<item>
 				<p><phrase diff="add">Supporting </phrase><phrase diff="del">Subject attachment Extensibility 
-			PolicyAttachment and AppliesTo </phrase><phrase diff="add">New</phrase><phrase diff="del">also have </phrase><phrase diff="chg">Policy Subjects</phrase></p>
+			PolicyAttachment and AppliesTo also </phrase><phrase diff="chg">New Policy Subjects</phrase></p>
 			</item>
 		</ulist>
 		
@@ -1316,9 +1354,9 @@
 					As an example, in </phrase><bibref diff="add" ref="WS-Policy-Primer"></bibref>
 					<phrase diff="add">Section</phrase><phrase diff="del">their </phrase><phrase diff="chg">4.2, the </phrase><code diff="add"><phrase diff="add">sp:issuedToken</phrase></code><phrase diff="del">common
         			policy </phrase><phrase diff="add">assertion utilizes the
-					</phrase><code diff="add"><phrase diff="add">sp:RequestSecurityTokenTemplate</phrase></code><phrase diff="del">expressions </phrase><phrase diff="add">parameter </phrase>that <phrase diff="add">contains necessary
-					information</phrase><phrase diff="del">are </phrase><phrase diff="chg">to request a </phrase><phrase diff="add">security token. The</phrase><phrase diff="del">promotes
-        			manageability </phrase><phrase diff="add">contents </phrase>of the <phrase diff="add">parameter
+					</phrase><code diff="add"><phrase diff="add">sp:RequestSecurityTokenTemplate</phrase></code> <phrase diff="add">parameter</phrase><phrase diff="del">expressions </phrase>that <phrase diff="chg">contains </phrase><phrase diff="add">necessary
+					information</phrase><phrase diff="del">identified. </phrase><phrase diff="chg">to request </phrase><phrase diff="add">a</phrase><phrase diff="del">promotes
+        			manageability </phrase><phrase diff="add">security token. The contents </phrase>of the <phrase diff="add">parameter
 					are</phrase><phrase diff="del">expressions </phrase><phrase diff="chg">static and allows </phrase><phrase diff="add">reuse in different security scenerios.</phrase><phrase diff="del">uniquely
         			identified.
         			</phrase></p>
@@ -1353,12 +1391,12 @@
 		
 		
 		
-			<head><phrase diff="chg">Supporting </phrase><phrase diff="add">New</phrase><phrase diff="del">Policy and </phrase><phrase diff="chg">Policy Subjects</phrase></head>
+			<head><phrase diff="add">Supporting</phrase><phrase diff="del">Inter-domain Policy </phrase><phrase diff="chg">New Policy Subjects</phrase></head>
 			<p>
 				<loc href="#Assertions" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">Section</phrase><phrase diff="del">Domain </phrase><phrase diff="add">2</phrase></loc><phrase diff="del">authors </phrase><phrase diff="chg">identifies that it is a best practice </phrase><phrase diff="add">for</phrase><phrase diff="del">their
 			domain </phrase><phrase diff="chg">policy authors </phrase><phrase diff="add">to 
 				define</phrase><phrase diff="del">domains. </phrase><phrase diff="chg">the set of policy </phrase><phrase diff="add">subjects</phrase><phrase diff="del">interact
-         with </phrase><phrase diff="chg">to </phrase><phrase diff="add">which policy</phrase><phrase diff="del">protocol </phrase>assertions <phrase diff="chg">can </phrase><phrase diff="add">be 
+         with </phrase><phrase diff="chg">to which </phrase><phrase diff="add">policy </phrase>assertions <phrase diff="chg">can </phrase><phrase diff="add">be 
 				attached.  Over</phrase><phrase diff="del">a </phrase><phrase diff="chg">time, </phrase><phrase diff="add">new</phrase><phrase diff="del">Although
          modeling </phrase><phrase diff="chg">policy subjects </phrase>may <phrase diff="chg">need </phrase>to be <phrase diff="add">defined.  When 
 				this occurs, a policy assertion author may update the list of policy 
@@ -1367,18 +1405,18 @@
 			<p>
 				<phrase diff="add">When</phrase><phrase diff="del">independent </phrase><phrase diff="add">the</phrase><phrase diff="del">behavior,
          protocol </phrase><phrase diff="chg">assertion's semantics do not change </phrase><phrase diff="add">to</phrase><phrase diff="del">transport
-         bindings </phrase><phrase diff="chg">invalidate </phrase><phrase diff="add">any of</phrase><phrase diff="del">their </phrase><phrase diff="add">the 
-				original</phrase><phrase diff="del">interactions </phrase><phrase diff="add">policy subjects but new policy subjects need to</phrase><phrase diff="del">must </phrase>be <phrase diff="add">added, it may 
-				be possible</phrase><phrase diff="del">considered. </phrase><phrase diff="add">to use the same assertion to designate the additional policy 
+         bindings </phrase><phrase diff="chg">invalidate any of </phrase><phrase diff="add">the 
+				original</phrase><phrase diff="del">must </phrase><phrase diff="add">policy subjects but new policy subjects need to </phrase>be <phrase diff="add">added, it may 
+				be possible to use the same assertion to designate the additional</phrase><phrase diff="del">considered. </phrase><phrase diff="add">policy 
 				subjects without a namespace change.  </phrase>For
          <phrase diff="del">example </phrase><phrase diff="chg">example, a policy assertion </phrase><phrase diff="add">for 
 				a</phrase><phrase diff="del">with </phrase><phrase diff="add">protocol</phrase><phrase diff="del">other
          protocols </phrase><phrase diff="chg">that is originally designed for </phrase><phrase diff="add">endpoint policy subject may add 
 				message policy subject to</phrase><phrase diff="del">result </phrase><phrase diff="add">indicate finer granularity </phrase>in <phrase diff="add">the attachment 
 				provided that endpoint </phrase><phrase diff="del">nested
-         </phrase>policy <phrase diff="chg">subject is also </phrase><phrase diff="add">retained in its design. When 
-				new</phrase><phrase diff="del">protocols </phrase><phrase diff="add">policy subjects </phrase>are <phrase diff="chg">added </phrase><phrase diff="add">it</phrase><phrase diff="del">with
-         . </phrase><phrase diff="chg">is </phrase><phrase diff="add">incumbent on the</phrase><phrase diff="del">domain </phrase>authors <phrase diff="add">to</phrase><phrase diff="del">should
+         </phrase>policy <phrase diff="chg">subject is also </phrase><phrase diff="add">retained in its design.</phrase><phrase diff="del">protocols </phrase><phrase diff="add">When 
+				new policy subjects </phrase>are <phrase diff="chg">added </phrase><phrase diff="add">it</phrase><phrase diff="del">with
+         . </phrase><phrase diff="chg">is </phrase><phrase diff="add">incumbent on</phrase><phrase diff="del">domain </phrase><phrase diff="add">the </phrase>authors <phrase diff="add">to</phrase><phrase diff="del">should
          be </phrase><phrase diff="add">retain the 
 				semantic</phrase><phrase diff="del">aware </phrase>of the <phrase diff="chg">policy </phrase><phrase diff="add">assertion. 
 			</phrase></p>
@@ -1388,7 +1426,7 @@
 			<p><phrase diff="add">Best</phrase><phrase diff="del">require </phrase><phrase diff="add">Practice:</phrase><phrase diff="del">composition
          with </phrase><phrase diff="chg">If the policy subjects change over </phrase><phrase diff="add">time, 
 				</phrase>the <phrase diff="add">assertion</phrase><phrase diff="del">nesting
-         requirements </phrase><phrase diff="chg">description should also be versioned to </phrase><phrase diff="add">reflect this 
+         requirements </phrase><phrase diff="add">description should</phrase><phrase diff="del">on </phrase><phrase diff="chg">also be versioned to reflect </phrase><phrase diff="add">this 
 				change.
 			</phrase></p>
 		
@@ -1402,10 +1440,10 @@
 				<p>Policy attachment should not affect the interpretation of
          Policy alternatives. If it did, each policy assertion would
          need to be written with different (and possibly unknown)
-         attachment mechanisms in mind. In particular, the timing of a
+         attachment mechanisms in mind.   <phrase diff="del">In particular, the timing of a
          policy attachment or the role that a party who attaches
          policy should have no bearing on the evaluation of the policy
-         assertion </p>
+         assertion </phrase></p>
 				<!-- EDS TO DO: [CLARIFY SUBJECT RELATIONSHIP] in the paragraph above -->
 			</div2>
 			<div2 id="appropriate-attachment-assertion-subjects">
@@ -1673,8 +1711,10 @@
   will be intersected and merged with other assertions in the
   calculation of an effective policy and this also indicates they need
   to consider policy subjects.</p>
-			<p>The policy framework only defines an algorithm for calculating
-  effective policies for WSDL 1.1 based subjects. </p>
+			<p> The <phrase diff="chg">WS-Policy 1.5 - Attachment specification </phrase><phrase diff="add">defines algorithms</phrase><phrase diff="del">algorithm </phrase>for calculating <phrase diff="add">the 
+ effective policy for a given policy subject and 
+  </phrase>effective policies for
+ <phrase diff="add">WSDL 1.1, </phrase>WSDL <phrase diff="chg">2.0 and </phrase><phrase diff="add">UDDI policy</phrase><phrase diff="del">subjects. </phrase><phrase diff="add">subjects.</phrase></p>
 		</div1>
 	</body>
 	<back>
@@ -1835,15 +1875,17 @@
 					<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Policy 1.5 - Primer</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,  
 					P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, Draft. </bibl>
 				<bibl href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html" id="WS-RM" key="Web Services Reliable Messaging" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
-					<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Reliable Messaging (WS-ReliableMessaging)</titleref>, Doug Davis (IBM), Anish Karmarkar (Oracle),
-					Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
-          (SAP), August 7th, 2006, available at:
+					<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Reliable Messaging (WS-ReliableMessaging)</titleref>, <phrase diff="add">D.</phrase><phrase diff="del">Doug Davis </phrase><phrase diff="chg">Davis, A. </phrase>Karmarkar <phrase diff="del">(Oracle),
+					</phrase><phrase diff="add">G. Pilz,</phrase><phrase diff="del">Gilbert </phrase><phrase diff="chg">S. Winkler, Ü. Yalçinalp, Editors. Organization </phrase><phrase diff="add">for the Advancement of
+					Structured Information Standards,</phrase><phrase diff="del">Yalçinalp
+          (SAP), </phrase>August 7th, 2006, available at:
           http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html
           </bibl>
 				<bibl href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html" id="WS-RM-Policy" key="Web Services Reliable Messaging Policy" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
-					<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Reliable Messaging Policy Assertion v1.1</titleref>, Doug Davis (IBM), Anish Karmarkar (Oracle),
-					Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
-          (SAP), August 4, 2006, available at:
+					<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">Web Services Reliable Messaging Policy Assertion v1.1</titleref>, <phrase diff="chg">D. </phrase><phrase diff="add">Davis, 
+					A.</phrase><phrase diff="del">Davis </phrase><phrase diff="chg">Karmarkar, G. Pilz, </phrase><phrase diff="add">S. Winkler, Ü. Yalçinalp,</phrase><phrase diff="del">(Oracle),
+					Gilbert </phrase><phrase diff="chg">Editors. Organization for the Advancement </phrase><phrase diff="add">of
+					Structured</phrase><phrase diff="del">Ü. </phrase><phrase diff="chg">Information Standards, </phrase>August 4, 2006, available at:
           http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
           </bibl>
 				<bibl href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf" id="WS-Security2004" key="WS-Security 2004" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink">
@@ -1928,12 +1970,27 @@
  <inform-div1 id="change-description">
 			<head>Changes in this Version of
           the Document</head>
-			<p>A list of substantive changes since the <phrase diff="add">Working Draft</phrase><phrase diff="del">previous </phrase><phrase diff="chg">dated </phrase><phrase diff="add">21 December, 
+			<p>A list of substantive changes since the <phrase diff="add">Working Draft dated</phrase><phrase diff="del">previous </phrase><phrase diff="chg">21 </phrase><phrase diff="add">December, 
 			2006 </phrase>is below:</p>
 			<ulist>
 				<item>
-					<p>TBD</p>
+					<p><phrase diff="add">Rewrote section </phrase><specref diff="add" ref="supporting-new-policy-subjects"></specref> <phrase diff="add">and added two new best practices:
+					</phrase><ulist diff="add">
+						<item><p><phrase diff="add">An assertion description should specify a policy subject.</phrase></p></item>
+						<item><p><phrase diff="add">If the policy subjects change over time, the assertion description 
+							should also be versioned to reflect this change.</phrase></p></item>
+					</ulist></p>
 				</item>
+				<item diff="add"><p><phrase diff="add">Rewrote section </phrase><specref ref="compact-full"></specref> <phrase diff="add">and added a new best practice: 
+				the semantics of an assertion should be independent of the form (compact or normal form) 
+				of policy expressions that contain the assertion.</phrase></p></item>
+				<item diff="add"><p><phrase diff="add">Rewrote section </phrase><specref ref="Referencing_Policy_Expressions"></specref><phrase diff="add">.</phrase></p></item>
+				<item diff="add"><p><phrase diff="add">Rewrote section </phrase><specref ref="assertion-target"></specref> <phrase diff="add">and added a new best practice:
+					the semantics a policy assertion should not depend on the attachment mechanism used.</phrase></p></item>
+				<item diff="add"><p><phrase diff="add">Dropped section  
+				</phrase><loc href="http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221/#typing-assertions" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4.6 Typing
+				 Assertions</phrase></loc><phrase diff="add">.</phrase><phrase diff="del">TBD</phrase></p></item>
+				<item diff="add"><p><phrase diff="add">Clarified the semantics of an empty nested policy expression in </phrase><specref ref="nested-assertions"></specref><phrase diff="add">.</phrase></p></item>
 			</ulist>
 		</inform-div1>
 		<inform-div1 id="change-log">
@@ -2194,7 +2251,50 @@
 							as outlined in 
 							<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">proposal</phrase></loc>.
 							Editorial action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">197</phrase></loc>.	</td>
-					</tr>  
+					</tr>
+					<tr diff="add">
+						<td colspan="1" diff="add" rowspan="1">20070319</td>
+						<td colspan="1" diff="add" rowspan="1">MH</td>
+						<td colspan="1" diff="add" rowspan="1"> Implemented resolution for issue 
+							<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4073" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">4073</phrase></loc>
+							in response to editor's action 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/199" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">199 </phrase></loc>
+							as outlined in 
+							<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">proposal </phrase></loc>.
+							</td>
+					</tr>
+					<tr diff="add">
+						<td colspan="1" diff="add" rowspan="1">20070320</td>
+						<td colspan="1" diff="add" rowspan="1">ASV</td>
+						<td colspan="1" diff="add" rowspan="1">Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">resolution</phrase></loc> 
+							for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 4319</phrase></loc>.
+							Editors' action 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">206</phrase></loc>.
+						</td>            
+					</tr>
+					<tr diff="add">
+						<td colspan="1" diff="add" rowspan="1">20070320</td>
+						<td colspan="1" diff="add" rowspan="1">ASV</td>
+						<td colspan="1" diff="add" rowspan="1">Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">resolution</phrase></loc> 
+							for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 3990</phrase></loc>.
+							Editors' action 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">210</phrase></loc>.
+						</td>            
+					</tr>
+					<tr diff="add">
+						<td colspan="1" diff="add" rowspan="1">20070320</td>
+						<td colspan="1" diff="add" rowspan="1">ASV</td>
+						<td colspan="1" diff="add" rowspan="1">Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">resolution</phrase></loc> 
+							for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">issue 4212</phrase></loc>.
+							Editors' action 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink"><phrase diff="add">207</phrase></loc>.
+						</td>            
+					</tr>
+					<tr diff="add">
+						<td colspan="1" diff="add" rowspan="1">20070321</td>
+						<td colspan="1" diff="add" rowspan="1">ASV</td>
+						<td colspan="1" diff="add" rowspan="1">Updated section <specref ref="change-description"></specref>. </td>
+					</tr>     
 													
 				</tbody>
 			</table>

--- NEW FILE: wsdl11elementidentifiers-diff20070131.html ---
<!DOCTYPE html
  PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>WSDL 1.1 Element Identifiers -- Review Version</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

.diff-chg	{ background-color: yellow; }
.diff-del	{ background-color: red; text-decoration: line-through;}
.diff-add	{ background-color: lime; }

table          { empty-cells: show; }

table caption {
	font-weight: normal;
	font-style: italic;
	text-align: left;
	margin-bottom: .5em;
}

div.issue {
  color: red;
}
.rfc2119 {
  font-variant: small-caps;
}

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

div.diff-add  { background-color: #FFFF99; }
div.diff-del  { text-decoration: line-through; }
div.diff-chg  { background-color: #99FF99; }
div.diff-off  {  }

span.diff-add { background-color: #FFFF99; }
span.diff-del { text-decoration: line-through; }
span.diff-chg { background-color: #99FF99; }
span.diff-off {  }

td.diff-add   { background-color: #FFFF99; }
td.diff-del   { text-decoration: line-through }
td.diff-chg   { background-color: #99FF99; }
td.diff-off   {  }
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"></head><body><div><p>The presentation of this document has been augmented to
            identify changes from a previous version. Three kinds of changes
            are highlighted: <span class="diff-add">new, added text</span>,
            <span class="diff-chg">changed text</span>, and
            <span class="diff-del">deleted text</span>.</p><hr></div><div class="head">
<h1><a name="title" id="title"></a>WSDL 1.1 Element Identifiers</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date: 2007/03/22 07:11:39 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
			<a href="wsdl11elementidentifiers.html">wsdl11elementidentifiers.html</a>
		</dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html?content-type=text/html;charset=utf-8</a></dd><div class="diff-add"><dt>Previous version:</dt><dd>
            <a href="http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131"><span class="diff-add"><span>http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070131</span></span></a>
        </dd></div><dt>Editors:</dt><dd>David Orchard, BEA Systems</dd><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark<a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>WSDL 1.1 Element Identifiers defines a syntax to identify individual elements in a WSDL 1.1 document.</p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</h2><p><strong>This document is an editors' copy that has
        no official standing.</strong></p><p></p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#intro">Introduction</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#notcon">Notational Conventions</a><br>
2. <a href="#frag-ids">Fragment Identifiers</a><br>
3. <a href="#wsdl-iri-references">IRI-References for WSDL 1.1 Elements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#wsdl-iris">WSDL 1.1 IRIs</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#soap-binding-decl-fragid">IRI Identification Of SOAP Binding elements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.3 <a href="#element-designator-canonical-form">Canonical Form for WSDL 1.1 element identifiers</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.4 <a href="#Iri-ref-ex">Example</a><br>
4. <a href="#refs">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#refs-norm">Normative References</a><br>
</p>
<h3><a name="appendices" id="appendices"></a>Appendix</h3><p class="toc">A. <a href="#changelog">Change Log</a> (Non-Normative)<br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="intro" id="intro"></a>1. Introduction</h2><p>This document defines an element identifier syntax for WSDL 1.1 elements.
			</p><div class="div2">
<h3><a name="notcon" id="notcon"></a>1.1 Notational Conventions</h3><p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
	  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	  and "OPTIONAL" in this document are to be interpreted as
	  described in RFC 2119 [<a href="#RFC2119">[RFC 2119]</a>].</p><p>With the exception of examples and sections explicitly marked
    	as "Non-Normative", all parts of this specification are
    	normative.</p></div></div><div class="div1">
<h2><a name="frag-ids" id="frag-ids"></a>2. Fragment Identifiers</h2><p>
	This section defines a fragment identifier syntax for identifying elements of a WSDL 1.1 document.
	This fragment identifier syntax is compliant with the
	[<a href="#XPTR">[XPointer Framework]</a>].  This document is primarily based upon [<a href="#WSDL-PART1">[WSDL 2.0 Core]</a>].  There is a substantial difference between the WSDL 1.1 and WSDL 2.0 fragment identifiers.WSDL 2.0 defines fragment identifiers with respect to the WSDL 2.0 component model, whereas WSDL 1.1 defines XML element and attribute syntax only.  Because there is no WSDL 1.1 component model, the WSDL 1.1 fragment identifiers <span class="diff-add"><span>identify</span></span><span class="diff-del"><span>are to the </span></span>WSDL 1.1 elements.  <span class="diff-chg"><span>Note: </span></span>the fragment identifers <span class="diff-add"><span>identify</span></span><span class="diff-del"><span>are to </span></span>the WSDL 1.1 elements prior to any processing of the WSDL document, such as validation, inclusion, imports, schema type validation, etc.  <span class="diff-add"><span>Note further: WSDL 1.1 fragment identifiers require a targetNamespace so WSDL 1.1 documents without a targetamespace will not have fragment identifiers. 
	  
	</span></span></p><p>
	A WSDL 1.1 fragment identifier is an XPointer [<a href="#XPTR">[XPointer Framework]</a>], 
 augmented with WSDL 1.1 pointer parts as defined below. Note that many 
 of these parts require the pre-appearance of one or more <code>xmlns</code> pointer 
 parts (see 3.4 Namespace Binding Context in [<a href="#XPTR">[XPointer Framework]</a>]).
	The pointer parts have a scheme name that corresponds to one
	of the standard WSDL 1.1 element names, and scheme data that is a path composed
	of names that identify the elements. 
	The scheme names all begin with the prefix "wsdl11." to avoid
	name conflicts with other schemes.
	The names in the path are of type either QName, NCName,
	IRI, URI, or Pointer Part depending on the context.
	The scheme data for WSDL 1.1 extension elements is defined by the 
	corresponding extension specification.
	</p><p>
	For QNames, any prefix
	MUST be defined by a preceding xmlns pointer part.
	If a QName does not have a prefix then its namespace
	name is the target namespace of the WSDL 1.1 document.
	</p><p>
		The fragment identifier is typically constructed from the <code>name</code>
		property of the element and the <code>name</code> properties of its
		ancestors as a path according to
		<a href="#frag-ids-table">Table 2-1</a>.
	    The first column of this table gives the name of the WSDL 1.1
		element. Columns labeled 1 through 3 specify the identifiers that
		uniquely identify the element within its context. Identifiers
		are typically formed from the <code>name</code> property, although in
		several cases references to other elements are used. These
		identifiers are then used to construct the pointer part in
		the last column.
		The fragment identifier in a WSDL 1.1 element IRI-reference
		MUST resolve to some element as defined by the construction rules
		in <a href="#frag-ids-table">Table 2-1</a>.
	</p><a name="frag-ids-table"></a><table border="1"><caption>Table 2-1. Rules for determining pointer parts for WSDL 1.1 elements</caption><col span="1" width="19%"><col span="1" width="12%"><col span="1" width="12%"><col span="1" width="12%"><col span="1" width="45%"><tbody><tr><th colspan="1" rowspan="1">element</th><th colspan="1" rowspan="1">1</th><th colspan="1" rowspan="1">2</th><th colspan="1" rowspan="1">3</th><th colspan="1" rowspan="1">Pointer Part</th></tr><tr><td colspan="1" rowspan="1">Definitions</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code>wsdl11.definitions()</code></td></tr><tr><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1">MessageType Definition</td></div><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1"><code><span class="diff-chg"><span>message</span></span></code> NCNameQName </td></div><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1">na</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.message(</span></span></code><code><span class="diff-chg"><span>message</span></span></code><code>)</code></td></tr><tr><div class="diff-chg"><td colspan="1" class="diff-chg" rowspan="1">Message Part</td></div><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1"><code><span class="diff-chg"><span>message</span></span></code> NCNameQName </td></div><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1"><div class="diff-add"><code><span class="diff-add"><span>part</span></span></code></div> NCNamen/a</td></div><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.messagePart(</span></span></code><code><span class="diff-chg"><span>message/part</span></span></code><code>)</code></td></tr><tr><div class="diff-chg"><td colspan="1" class="diff-chg" rowspan="1">portType</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>portType</span></span>/code> NCName </td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.portType(</span></span></code><code><span class="diff-chg"><span>portType</span></span></code><code>)</code></td></tr><tr><div class="diff-chg"><td colspan="1" class="diff-chg" rowspan="1">portType Operation</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>portType</span></span></code> NCName</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>operation</span></span></code> NCName</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.portTypeOperation(</span></span></code><code><span class="diff-chg"><span>portType/operation</span></span></code><code>)</code></td></tr><tr><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">portType Operation Input</td></div><td colspan="1" rowspan="1"><code>portType</code> NCName </td><div class="diff-del"><d colspan="1" class="diff-del" rowspan="1"><div class="diff-add"><code><span class="diff-add"><span>operation</span></span></code></div> NCNamen/a</td></div><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.portTypeOperation.input(</span></span></code><code><span class="diff-chg"><span>portType/operation</span></span></code><code>)</code></td></tr><tr><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">portType Operation Output</td></div><td colspan="1" rowspan="1"><code>portType</code> NCName</td><td colspan="1" rowspan="1"><code>operation</code> NCName</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.portTypeOperation.output(</span></span></code><code>portType/operation</code><code>)</code></td></tr><tr><div class="diff-chg"><td colspan="1" class="diff-chg" rowspan="1">portType Operation Fault</td></div><td colspan="1" rowspan="1"><code>portType</code> NCName</td><td colspan=1" rowspan="1"><code>operation</code> NCName</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>fault</span></span></code> NCName</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.portTypeOperation.fault(</span></span></code><code><span class="diff-chg"><span>portType/operation/fault</span></span></code><code>)</code></td></tr><tr><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1">BindingportType Operation Fault</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>binding</span></span></code> NCName</td><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1">n/aoperation NCName</td></div><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1">n/afault QName</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.binding(</span></span></code><code><span class="diff-chg"><span>binding</span></span></code><code>)</code></td></tr><tr><div class="diff-add"><td colspan="1" class="diff-add" rowpan="1">Binding Operation</td></div><td colspan="1" rowspan="1"><code>binding</code> NCName</td><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1"><div class="diff-add"><code><span class="diff-add"><span>operation</span></span></code></div> QNamen/a</td></div><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.bindingOperation(</span></span></code><code><span class="diff-chg"><span>binding/operation</span></span></code><code>)</code></td></tr><tr><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Binding Operation Input</td></div><td colspan="1" rowspan="1"><code>binding</code> NCName</td><td colspan="1" rowspan="1"><code>operation</code> QName</td><div class="diff-chg"><td colspan="1" class="diff-chg" rowspan="1">na/</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.bindingOperation.input(</span></span></code><code>binding/operation</code><code>)</code></td></tr><tr><div class="diff-chg"><td olspan="1" class="diff-chg" rowspan="1">Binding Operation Output</td></div><td colspan="1" rowspan="1"><code>binding</code> NCName</td><td colspan="1" rowspan="1"><code>operation</code> QName</td><div class="diff-del"><td colspan="1" class="diff-del" rowspan="1">na/message NCName</td></div><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.bindingOperation.output(</span></span></code><code><span class="diff-chg"><span>binding/operation</span></span></code><code>)</code></td></tr><tr><td colspan="1" rowspan="1">Binding Operation Fault</td><td colspan="1" rowspan="1"><code>binding</code> NCName</td><td colspan="1" rowspan="1"><code>operation</code> QName</td><td colspan="1" rowspan="1"><code>fault</code> NCName</td><td colspan="1" rowspan="1"><code><span class="diff-chg"><span>wsdl11.bindingOperation.fault(</span></span></code><code>binding/operation/fault</code><code>)</code></td></tr><tr><td colspan="1" rowspan="1">Service</td><td colspan="1" rowspan="1"><code>service</code> NCName</td><t colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code>wsdl11.service(</code><code>service</code><code>)</code></td></tr><tr><td colspan="1" rowspan="1">port</td><td colspan="1" rowspan="1"><code>service</code> NCName</td><td colspan="1" rowspan="1"><code>port</code> NCName</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code>wsdl11.port(</code><code>service/port</code><code>)</code></td></tr><tr><td colspan="1" rowspan="1">Extensions</td><td colspan="1" rowspan="1"><code>namespace</code> URI</td><td colspan="1" rowspan="1"><code>identifier</code> extension-specific-syntax</td><td colspan="1" rowspan="1">n/a</td><td colspan="1" rowspan="1"><code>wsdl11.extension(</code><code>namespace,identifier</code><code>)</code></td></tr></tbody></table><br></div><div class="div1">
<h2><a name="wsdl-iri-references" id="wsdl-iri-references"></a>3. IRI-References for WSDL 1.1 Elements</h2><p>
		This section provides a syntax for IRI-references for all
		elements found in a [<a href="#WSDL11">[WSDL 1.1]</a>] document. The IRI-references are easy
		to understand and compare, while imposing no burden on the WSDL 1.1
		author.
	</p><div class="div2">
<h3><a name="wsdl-iris" id="wsdl-iris"></a>3.1 WSDL 1.1 IRIs</h3><p>There are two main cases for WSDL 1.1 IRIs:</p><ul><li><p>the IRI of a WSDL 1.1 document</p></li><li><p>the IRI of a WSDL 1.1 namespace</p></li></ul><p>
		The IRI of a WSDL 1.1 document can be dereferenced to give a
		resource representation that contributes elements
		to a single WSDL 1.1 namespace. If the media type is set to the WSDL 1.1
		media type i.e. application/xml, then the fragment identifiers can be used to
		identify the main elements that are defined in the document.
	</p><p>
		In keeping with WSDL 1.1, which has a recommendation that 
		that the namespace URI be dereferencible to a WSDL 1.1 document,
		this section specifies the use of the namespace IRI with the
		WSDL 1.1 fragment identifiers to form an IRI-reference.
	</p><p>
		The IRI in an IRI-reference for a WSDL 1.1 element is the
		namespace name of the
		<code>name</code>
		property of either the element itself, in the case of
		<code>portType</code>
		,
		<code>Binding</code>
		, and
		<code>Service</code>
		elements, or the
		<code>name</code>
		property of the ancestor top-level element. The IRI provided
		by the namespace name of the
		<code>name</code>
		property is combined with a zero or more
		<code>xmlns</code>
		pointer parts (see
		3.4 Namespace Binding Context
		in
		[<a href="#XPTR">[XPointer Framework]</a>]
		) followed by a single WSDL 1.1 pointer part, following the same rules as defined for WSDL 1.1 fragment ids
		<a href="#frag-ids"><b>2. Fragment Identifiers</b></a>
		.
	</p></div><div class="div2">
<h3><a name="soap-binding-decl-fragid" id="soap-binding-decl-fragid"></a>3.2 IRI Identification Of SOAP Binding elements</h3><p><code>SOAP Binding</code> elements (binding, operation, body, header, fault, headerfault, and address) can be identified using the
	  <em>wsdl11.extension</em>
	  XPointer Framework scheme according to the following rules:</p><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.binding(</code><code>parent</code><code>)</code>), where: </p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Binding's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.operation(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Operation's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.body(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Body's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.header(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Header's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.headerfault(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP HeaderFault's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.fault(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Fault's parent</code> element
	    </p></li></ul><p><code>wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/,
	  w11soap.address(</code><code>parent</code><code>)</code>)</p><ul><li><p>
	      <em>
		<code>parent</code>
	      </em>
	      is the pointer part of the <code>SOAP Address's parent</code> element
	    </p></li></ul></div><div class="div2">
<h3><a name="element-designator-canonical-form" id="element-designator-canonical-form"></a>3.3 Canonical Form for WSDL 1.1 element identifiers</h3><p>
			The IRI-references described above MAY be used as WSDL 1.1
			element identifiers. For ease of comparison, the fragment
			identifier of WSDL 1.1 element identifiers SHOULD conform
			to the following canonicalization rules:
		</p><ul><li><p>
						The fragment identifier consists of a sequence
						zero or more
						<code>xmlns()</code>
						pointer parts followed by exactly one
						<code>wsd11.*()</code>
						pointer part.
				</p></li><li><p>
						Each
						<code>xmlns()</code>
						pointer part that appears in the fragment
						identifier defines a namespace that is
						referenced by the
						<code>wsd11.*()</code>
						pointer part.
				</p></li><li><p>
						Each
						<code>xmlns()</code>
						pointer part defines a unique namespace.
				</p></li><li><p>
						The
						<code>xmlns()</code>
						pointer parts define namespaces in the same
						order as they are referenced in the
						<code>wsd11.*()</code>
						pointer part.
				</p></li><li><p>
						The namespace prefixes defined by the
						<code>xmlns()</code>
						pointer parts are named
						<code>ns1</code>
						,
						<code>ns2</code>
						, etc., in the order of their appearance.
				</p></li><li><p>
						The fragment identifier contains no optional
						whitespace.
				</p></li></ul></div><div class="div2">
<h3><a name="Iri-ref-ex" id="Iri-ref-ex"></a>3.4 Example</h3><p>Consider WSDL 1.1 document located at
	http://example.org/TicketAgent.wsdl.  Each WSDL 1.1 Element Identifier is shown in comments above the WSDL 1.1 element
	</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name="iri-ref-example-wsdl" id="iri-ref-example-wsdl"></a><i><span>Example 3-1. </span>IRI-References - Example WSDL 1.1 Document</i></p><div class="exampleInner"><pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt; 

&lt;wsdl:definitions targetNamespace="http://example.org/TicketAgent.wsdl11"
    xmlns:tns="http://example.org/TicketAgent.wsdl11" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ http://www.w3.org/TR/2001/NOTE-wsdl-20010315/wsdl11.xsd"&gt;

    &lt;!-- http://example.org/TicketAgent.wsdl11#wsd11.definitions() --&gt;

    &lt;wsdl:types&gt;
        &lt;xs:schema xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd"
            targetNamespace="http://example.org/TicketAgent.xsd"&gt;
            &lt;xs:element name="listFlightsRequest" type="xsTicketAgent:tListFlights"/&gt;
            &lt;xs:complexType name="tListFlights"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="travelDate" type="xs:date"/&gt;
                    &lt;xs:element name="startCity" type="xs:string"/&gt;
                    &lt;xs:element name="endCity" type="xs:string"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:complexType&gt;
            &lt;xs:element name="listFlightsResponse" type="xsTicketAgent:tFlightsResponse"/&gt;
            &lt;xs:complexType name="tFlightsResponse"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="flightNumber" type="xs:integer" minOccurs="0"
                        maxOccurs="unbounded"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:complexType&gt;
        &lt;/xs:schema&gt;
    &lt;/wsdl:types&gt;

    &lt;wsdl:message name="listFlightsRequest"&gt;
        &lt;!-- Starting from here, http://example.org/TicketAgent.wsdl11 will be shortened to http://... --&gt;
        &lt;!-- http://...#wsdl11.message(listFlightsRequest) --&gt;
        &lt;wsdl:part name="body" element="xsTicketAgent:listFlightsRequest"/&gt;
        &lt;!-- http://...#wsdl11.messagePart(listFlightsRequest/body) --&gt;
    &lt;/wsdl:message&gt;

    &lt;wsdl:message name="listFlightsResponse"&gt;
        &lt;!-- http://...#wsdl11.message(listFlightsResponse) --&gt;
        &lt;wsdl:part name="body" element="xsTicketAgent:listFlightsResponse"/&gt;
        &lt;!-- http://...#wsdl11.messagePart(listFlightsResponse/body) --&gt;
    &lt;/wsdl:message&gt;

    &lt;wsdl:portType name="TicketAgent"&gt;
        &lt;!-- http://...#wsdl11.portType(TicketAgent) --&gt;
        &lt;wsdl:operation name="listFlights"&gt;
            &lt;!-- http://...#wsdl11.portTypeOperation(TicketAgent/listFlights) --&gt;
            &lt;wsdl:input message="tns:listFlightsRequest"/&gt;
            &lt;!-- http://...#wsdl11.portTypeOperation.input(TicketAgent/listFlights) --&gt;
            &lt;wsdl:output message="tns:listFlightsResponse"/&gt;
            &lt;!-- http://...#wsdl11.portTypeOperation.output(TicketAgent/listFlights) --&gt;
        &lt;/wsdl:operation&gt;
    &lt;/wsdl:portType&gt;

    &lt;wsdl:binding name="TicketAgentSoap" type="tns:TicketAgent"&gt;
        &lt;!-- http://...#wsdl11.binding(TicketAgentSoap) --&gt;
        &lt;soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/&gt;
        &lt;!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
             w11soap.binding( wsdl11.binding(TicketAgentSoap)) --&gt;
        &lt;wsdl:operation name="listFlights"&gt;
            &lt;!-- http://...#wsdl11.bindingOperation(TicketAgentSoap/listFlights) --&gt;
            &lt;wsdl:input&gt;
                &lt;!-- http://...#wsdl11.bindingOperation.input(TicketAgentSoap/listFlights) --&gt;
                &lt;soap:body parts="body" use="literal"/&gt;
                &lt;!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperation.input
                                           (TicketAgentSoap/listFlights)) --&gt;
            &lt;/wsdl:input&gt;
            &lt;wsdl:output&gt;
                &lt;!-- http://...#wsdl11.bindingOperation.output(TicketAgentSoap/listFlights) --&gt;
                &lt;soap:body parts="body" use="literal"/&gt;
                &lt;!-- http://...#wsdl11.extension(http://schemas.xmlsoap.org/wsdl/soap/, 
                               w11soap.body(wsdl11.bindingOperation.output
                                           (TicketAgentSoap/listFlights)) --&gt;
            &lt;/wsdl:output&gt;
        &lt;/wsdl:operation&gt;
    &lt;/wsdl:binding&gt;

&lt;/wsdl:definitions&gt;</pre></div></div></div></div><div class="div1">
<h2><a name="refs" id="refs"></a>4. References</h2><div class="div2">
<h3><a name="refs-norm" id="refs-norm"></a>4.1 Normative References</h3><dl><dt class="label"><a name="RFC3023" id="RFC3023"></a>[RFC 3023] </dt><dd>IETF
	  "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July
	  1998.  (See http://www.ietf.org/rfc/rfc3023.txt.)</dd><dt class="label"><a name="WSDL-PART1" id="WSDL-PART1"></a>[WSDL 2.0 Core] </dt><dd>
	  	<a href="http://www.w3.org/TR/2006/CR-wsdl20-20060327"><cite>
		 Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language
	  	</cite></a>, R. Chinnici, J-J.
	  	Moreau, A. Ryman, S. Weerawarana, Editors. W3C Candidate Recommendation 27 March 2006. The current version of <a href="http://www.w3.org/TR/2006/CR-wsdl20-20060327">Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language</a> is available at
	  	http://www.w3.org/TR/2006/CR-wsdl20-20060327 . The
	  	<a href="http://www.w3.org/TR/wsdl20">
	  		latest version of "Web Services definitions Language (WSDL) Version 2.0 Part 1: Core Language"
	  	</a>
	  	is available at
	  	http://www.w3.org/TR/wsdl20.
	    (See http://www.w3.org/TR/2006/CR-wsdl20-20060327.)</dd><dt class="label"><a name="WSDL11" id="WSDL11"></a>[WSDL 1.1] </dt><dd>
	  <a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315"><cite>Web Services definitions Language (WSDL)
	  1.1</cite></a>, E. Christensen, F. Curbera, G. Meredith, and
	  S. Weerawarana, Authors. W3C Note 15 March
	  2002. The current version of <a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</a> is available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315 . The <a href="http://www.w3.org/TR/wsdl">latest version of Web
	  Services definitions Language 1.1</a> is available at
	  http://www.w3.org/TR/wsdl11.
	  (See http://www.w3.org/TR/2001/NOTE-wsdl-20010315.)</dd><dt class="label"><a name="XPTR" id="XPTR"></a>[XPointer Framework] </dt><dd>
	    <a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"><cite>XPointer Framework</cite></a>,Paul Grosso, Eve
	    Maler, Jonathan Marsh, Norman Walsh, Editors. W3C Recommendation 25 March 2003.  The current version of <a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">XPointer Framework</a> is available at 
	    http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . The
	    <a href="http://www.w3.org/TR/xptr-framework/">latest
	    version of XPointer Framework</a> is available at
	    http://www.w3.org/TR/xptr-framework/.
	    (See http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.)</dd><dt class="label"><a name="RFC2119" id="RFC2119"></a>[RFC 2119] </dt><dd>IETF "RFC 2119:
	  Key words for use in RFCs to Indicate Requirement Levels",
	  S. Bradner, March 1997.  (See http://www.ietf.org/rfc/rfc2119.txt.)</dd><dt class="label"><a name="RFC3986" id="RFC3986"></a>[RFC 3986] </dt><dd>IETF "RFC 3986:
	  Uniform Resource Identifiers (URI): Generic Syntax",
	  T. Berners-Lee, R. Fielding, L. Masinter, January 2005.   (See http://www.ietf.org/rfc/rfc3986.txt.)</dd></dl></div></div></div><div class="back"><div class="div1">
<h2><a name="changelog" id="changelog"></a>A. Change Log (Non-Normative)</h2><table border="1"><caption>Table A-1. Changes</caption><thead><tr><th colspan="1" rowspan="1">Who</th><th colspan="1" rowspan="1">When</th><th colspan="1" rowspan="1">What</th></tr></thead><tbody><tr><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">20061108</td><td colspan="1" rowspan="1">Initial Revision</td></tr><tr><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">20061212</td><td colspan="1" rowspan="1">Uncommented canonical section, fixed editorial items</td></tr><tr><td colspan="1" rowspan="1">DBO</td><td colspan="1" rowspan="1">20070122</td><td colspan="1" rowspan="1">Resolution of bug <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4208">4208</a>, AI is <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/145">145</a>
</td></tr><tr><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">20070127</td><td colspan="1" rowspan="1">Editorial fixes for publication preparation</td></tr><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">DBO</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070219</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Changed MessageReference to .input and .output, resolution of bug <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4251"><span class="diff-add"><span>4251</span></span></a>, AI is <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/150"><span class="diff-add"><span>150</span></span></a>
</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">DBO</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070308</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Added note about targetnamespace being required. <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4331"><span class="diff-add"><span>4331</span></span></a>, AI is <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/177"><span class="diff-add"><span>177</span></span></a>
</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">DBO</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070308</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Removed Schema element and type defs. <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4332"><span class="diff-add"><span>4332</span></span></a>, AI is <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/178"><span class="diff-add"><span>178</span></span></a>
</td></div></tr></div></tbody></table><br></div></div></body></html>
Index: entities.dtd
===================================================================
RCS file: /sources/public/2006/ws/policy/entities.dtd,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- entities.dtd	22 Mar 2007 03:33:41 -0000	1.18
+++ entities.dtd	22 Mar 2007 07:11:39 -0000	1.19
@@ -7,7 +7,7 @@
 <!--
  uncomment the following entity for publication, and change the date
  in entitieswd.dtd
-
+ 
 <!ENTITY % sub.entities SYSTEM "entitieswd.dtd" >-->
 
 
@@ -28,7 +28,6 @@
 <!-- Misc entities. Feel free to add more -->
 
 
-<!ENTITY frameworkdoc "&w3c-designation-framework;">
 <!ENTITY EII "<emph>element information item</emph>">
 <!ENTITY AII "<emph>attribute information item</emph>">
 <!ENTITY glossary-framework SYSTEM "glossary-framework.xml">

Index: ws-policy-guidelines-diff20061221.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20061221.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20061221.html	16 Mar 2007 13:15:02 -0000	1.2
+++ ws-policy-guidelines-diff20061221.html	22 Mar 2007 07:11:39 -0000	1.3
@@ -77,7 +77,9 @@
 <h1><a name="title" id="title"></a>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</h1>
 <h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
       <a href="ws-policy-guidelines.html">ws-policy-guidelines.html</a>
-    </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mthematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
+    </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><div class="diff-add"><dt>Previous version:</dt><dd>
+            <a href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221"><span class="diff-add"><span>http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221</span></span></a>
+        </dd></div><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;@@@@&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">traemark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
 <h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
         <em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is intended to provide guidance for assertion
         authors that will work with the Web Services Policy 1.5 - Framework [<a href="#WS-Policy">[Web Services Policy Framework]</a>] and Web Services Policy 1.5 - Attachment [<a href="#WS-PolicyAttachment">[Web Services Policy Attachment]</a>] specifications to create domain
@@ -90,7 +92,7 @@
         no official standing.</strong></p><p></p></div><div class="toc">
 <h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
 2. <a href="#Assertions">What is an Assertion? </a><br>
-3. <a href="#d2e368">Who is involved in authoring Assertions? </a><br>
+3. <a href="#d2e377">Who is involved in authoring Assertions? </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#roles"> Roles and Responsibilities </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2 <a href="#consumers">Consumers</a><br>
@@ -108,15 +110,14 @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.5.1 <a href="#d2e1452">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.5.2 <a href="#d2e1460">Optional behavior at runtime</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;4.6 <a href="#typing-assertions">Typing Assertions</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;4.8 <a href="#interrelated-domains">Interrelated domains</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.5.1 <a href="#d2e1532">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.5.2 <a href="#d2e1540">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;4.6 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;4.7 <a href="#interrelated-domains">Interrelated domains</a><br>
 5. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#supporting-new-policy-subjects">Supporting NewPolicy and Policy Subjects</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#supporting-new-policy-subjects">SupportingInter-domain Policy New Policy Subjects</a><br>
 6. <a href="#best-practices-attachment">Applying Best Practices for  Policy Attachment</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>
@@ -237,13 +238,13 @@
            		 for </span></span><span class="diff-chg"><span>be marked as ignorable (indicating it does not impact interoperability). An </span></span><span class="diff-add"><span>ignorable</span></span><span class="diff-del"><span>behavior
             	then </span></span><span class="diff-chg"><span>policy </span></span>assertion <span class="diff-add"><span>is 
           		ignored</span></span><span class="diff-del"><span>will </span></span><span class="diff-chg"><span>for lax policy intersection. If an assertion is not an </span></span><span class="diff-add"><span>ignorable</span></span><span class="diff-del"><span>policy
-            	intersection </span></span><span class="diff-chg"><span>assertion then it is </span></span><span class="diff-add"><span>deemed important for agreement 
+            	intersection </span></span><span class="diff-add"><span>assertion then</span></span><span class="diff-del"><span>will </span></span><span class="diff-chg"><span>it is deemed </span></span><span class="diff-add"><span>important for agreement 
           		between both parties.
           	</span></span><span class="diff-del"><span>negatives.
             	</span></span></p></li><li><p>Does the behavior have an implied scoping to a policy subject such as service, endpoint, operation and message?
             	</p></li><li><p>Is there a requirement that a choice must be made for successful interaction?</p><p>Sometimes providers and requesters are required to engage in certain behaviors. 
           			The use of optimization and reliable messaging are two examples.
-          		</p></li></ul><p>There are already many examples in the industry that adhere to <span class="diff-chg"><span>the </span></span><span class="diff-add"><span>above practices,</span></span><span class="diff-del"><span>practice, </span></span>such as <a href="#WS-RM-Policy">[Web Services Reliable Messaging Policy]</a>
+          		</p></li></ul><p>There are already many examples in the industry that adhere to <span class="diff-add"><span>the above</span></span><span class="diff-del"><span>this </span></span><span class="diff-chg"><span>practices, </span></span>such as <a href="#WS-RM-Policy">[Web Services Reliable Messaging Policy]</a>
       	and <a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a>. Some common characteristics from these documents may be considered as <em>best practices</em> for new <span class="diff-chg"><span>Assertion Authors:
       	</span></span></p><ul><li><p>Specify both the syntax and the semantics of the assertions
                		</p></li><li><p>If nested or parameterized assertions are defined, be clear about their usage
@@ -258,7 +259,7 @@
       	best practices will be an assertion specification that describes
       	a contract for the consumers and providers of the capabilities and constraints of the domain.
       	</p></div><div class="div1">
-<h2><a name="d2e368" id="d2e368"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="d2e377" id="d2e377"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
 		express their own domain knowledge, it is necessary to provide basic
 		functionality that all domains could exploit and then allow
 		points of extension where authors of the various WS-Policy
@@ -273,8 +274,8 @@
 <h3><a name="roles" id="roles"></a>3.1  Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
         	and responsibilities for the authors, consumers and providers.
         	</p><div class="div3">
-<h4><a name="domain-owners" id="domain-owners"></a>3.1.1  <span class="diff-chg"><span>Assertion </span></span>Authors</h4><p><span class="diff-add"><span>Assertion </span></span><span class="diff-del"><span>WS-Policy Domain owners or WS-Policy </span></span><span class="diff-chg"><span>Authors </span></span>are defined
-       			 by the WS-Policy Framework to be a community that chooses to
+<h4><a name="domain-owners" id="domain-owners"></a>3.1.1  <span class="diff-chg"><span>Assertion </span></span>Authors</h4><p><span class="diff-add"><span>Assertion </span></span><span class="diff-del"><span>WS-Policy Domain owners or WS-Policy </span></span><span class="diff-chg"><span>Authors </span></span>are <span class="diff-del"><span>defined
+       			 by the WS-Policy Framework to be </span></span>a community that chooses to
         		exploit the WS-Policy Framework by creating their own
         		specification to define a set of assertions that express the
         		capabilities and constraints of that target domain. The
@@ -290,10 +291,10 @@
     	    	<span class="diff-chg"><span>Assertion Authors </span></span>defining new WS-Policy assertions
     	    	must adhere to the MUST's and SHOULD's in the specification
     	    	and should review the conformance section of the specification. 
-    	    	</p><p><span class="diff-add"><span>Assertion</span></span><span class="diff-del"><span>WS-Policy Domain </span></span><span class="diff-chg"><span>Authors </span></span>must also specify how to associate
-				the assertions they have defined with the policy subjects
-				identified by the WS-PolicyAttachment specification.
-				</p><p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
+    	    	</p><p><span class="diff-chg"><span>An assertion author should </span></span>also specify <span class="diff-chg"><span>a policy </span></span><span class="diff-add"><span>subject. For</span></span><span class="diff-del"><span>associate
+				</span></span><span class="diff-chg"><span>instance, if a policy </span></span><span class="diff-add"><span>assertion were to be used</span></span><span class="diff-del"><span>defined </span></span>with <span class="diff-chg"><span>WSDL, an assertion
+				description should specify a </span></span><span class="diff-add"><span>WSDL policy subject.</span></span><span class="diff-del"><span>specification.
+				</span></span></p><p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
         		specification [<a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a>]. The
         		WS-SecurityPolicy authors have defined their scope as follows:
         		</p><p><em>"This document [WS-SecurityPolicy] defines a set of
@@ -338,14 +339,14 @@
 				</span></span>expression that conforms to the <span class="diff-add"><span>Web Services Policy 1.5 - Framework</span></span><span class="diff-del"><span>WS-PolicyFramework </span></span><span class="diff-add"><span>[</span></span><span class="diff-add"><a href="#WS-Policy">[Web Services Policy Framework]</a></span><span class="diff-add"><span>]
 				</span></span>and <span class="diff-add"><span>Web Services Policy 1.5 -
 	   			</span></span><span class="diff-del"><span>WS-Policy </span></span>Attachment <span class="diff-add"><span>[</span></span><span class="diff-add"><a href="#WS-PolicyAttachment">[Web Services Policy Attachment]</a></span><span class="diff-add"><span>]</span></span><span class="diff-del"><span>specifications. </span></span><span class="diff-add"><span>specifications.
-				</span></span>The <span class="diff-add"><span>Web Services Policy 1.5 - Attachment
-	   			</span></span><span class="diff-del"><span>WS-PolicyAttachment </span></span>specification has defined a set of
+				</span></span>The <span class="diff-chg"><span>Web </span></span><span class="diff-add"><span>Services Policy 1.5 - Attachment </span></span>specification has defined a set of
 	   			subjects and an extensible mechanism for attaching policies
-	   			to web services subjects. When a web service provider
+	   			to web services subjects. 
+           		 <span class="diff-del"><span>When a web service provider
 	   			chooses to make its capabilities and constraints available,
-	   			<span class="diff-add"><span>the provider</span></span><span class="diff-del"><span>it </span></span>may also need to conform to requirements of other policy
-	   			<span class="diff-add"><span>assertion </span></span>specifications it utilizes ( i.e., WS-SecurityPolicy).
-           		</p><p>When deploying services with policies it is useful for providers to anticipate how
+	   			it may also need to conform to requirements of other policy
+	   			specifications it utilizes ( i.e., WS-SecurityPolicy).
+           		</span></span></p><p>When deploying services with policies it is useful for providers to anticipate how
            		to evolve their services capabilities over time.  If
            		forward compatibility is a concern in order to accommodate
            		compatibility with different and potentially new clients,
@@ -355,11 +356,11 @@
 	   			</p></div></div></div><div class="div1">
 <h2><a name="general-guidelines" id="general-guidelines"></a>4. General Guidelines for <span class="diff-del"><span>WS-Policy </span></span>Assertion Authors</h2><p> As <span class="diff-add"><span>Assertion Authors</span></span><span class="diff-del"><span>authors </span></span>begin the task of inventing XML dialects to represent policy  assertions they can take
 		advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy 
-		relies on the QName of a policy assertion being an XML element but allows <span class="diff-chg"><span>Assertion </span></span><span class="diff-add"><span>Authors </span></span>to optionally  
+		relies on the QName of a policy assertion being an XML element but allows <span class="diff-add"><span>Assertion Authors</span></span><span class="diff-del"><span>authors </span></span>to optionally  
 		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>4.1 Assertions and Their Target Use</h3><p>
-				<span class="diff-add"><span>Assertion</span></span><span class="diff-del"><span>WS-Policy </span></span><span class="diff-chg"><span>Authors </span></span>need to have <span class="diff-add"><span>a</span></span><span class="diff-del"><span>some definition of what </span></span><span class="diff-chg"><span>specific </span></span>goal <span class="diff-chg"><span>in </span></span><span class="diff-add"><span>mind </span></span>for the assertions 
+				<span class="diff-add"><span>Assertion</span></span><span class="diff-del"><span>WS-Policy </span></span><span class="diff-chg"><span>Authors </span></span>need to have <span class="diff-add"><span>a</span></span><span class="diff-del"><span>some definition of what </span></span><span class="diff-chg"><span>specific </span></span>goal <span class="diff-add"><span>in mind</span></span><span class="diff-del"><span>is </span></span>for the assertions 
 				<span class="diff-add"><span>that 
 			</span></span>they author. <span class="diff-chg"><span>Assertion Authors </span></span>should also understand the 
 				functionality <span class="diff-add"><span>that </span></span>the WS-Policy framework provides and apply the 
@@ -371,9 +372,9 @@
            	assertions </span></span>or they may choose to specify <span class="diff-add"><span>assertions</span></span><span class="diff-del"><span>many assertion
            	elements </span></span>that 
 				<span class="diff-add"><span>contains </span></span><span class="diff-chg"><span>assertion </span></span>parameters <span class="diff-add"><span>and/or</span></span><span class="diff-del"><span>or other </span></span>nested <span class="diff-add"><span>policy expression (nested 
-				assertions), each of which relate to an aspect of the behavior,
-           	</span></span><span class="diff-del"><span>assertions. </span></span><span class="diff-add"><span>yet 
-				encapsulated within a single assertion. </span></span>There are advantages to 
+				assertions), each of which relate to an aspect of the behavior, yet 
+				encapsulated
+           	</span></span><span class="diff-del"><span>assertions. </span></span><span class="diff-add"><span>within a single assertion. </span></span>There are advantages to 
 				simplifying the set of assertions. The ultimate goal of policy <span class="diff-del"><span>assertions </span></span>is to 
 				enable <span class="diff-add"><span>interoperability.</span></span><span class="diff-del"><span>interoperability and assertions that </span></span><span class="diff-chg"><span>By </span></span><span class="diff-add"><span>keeping</span></span><span class="diff-del"><span>behavior
            	for </span></span><span class="diff-chg"><span>assertion design as simple </span></span><span class="diff-add"><span>as 
@@ -388,9 +389,8 @@
 				</p><p>
 				The <span class="diff-add"><span>WS-Policy Attachment specification defines a </span></span>number of different 
 				<span class="diff-add"><span>policy </span></span>subjects to which an assertion can be <span class="diff-chg"><span>attached. For attaching </span></span><span class="diff-add"><span>to 
-					WSDL</span></span><span class="diff-del"><span>a </span></span><span class="diff-chg"><span>subjects see </span></span><span class="diff-add"><a href="#levels-of-abstraction"><b>4.7 Levels of Abstraction in WSDL </b></a></span><span class="diff-del"><span>defining </span></span><span class="diff-add"><span>for</span></span><span class="diff-del"><span>an
-           	assertion. </span></span><span class="diff-chg"><span>more </span></span><span class="diff-add"><span>detail. 
-				Additionally,</span></span><span class="diff-del"><span>the </span></span><span class="diff-chg"><span>the framework provides for </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>sometimes
+					WSDL</span></span><span class="diff-del"><span>a </span></span><span class="diff-chg"><span>subjects see </span></span><span class="diff-add"><a href="#levels-of-abstraction"><b>4.6 Levels of Abstraction in WSDL </b></a></span><span class="diff-del"><span>defining </span></span><span class="diff-chg"><span>for more </span></span><span class="diff-add"><span>detail. 
+				Additionally,</span></span><span class="diff-del"><span>Determining </span></span>the <span class="diff-add"><span>framework</span></span><span class="diff-del"><span>appropriate policy </span></span><span class="diff-chg"><span>provides for </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>sometimes
            	involve </span></span><span class="diff-chg"><span>means to extend </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>of  wide </span></span><span class="diff-chg"><span>set </span></span>of 
 				<span class="diff-add"><span>policy </span></span><span class="diff-chg"><span>subjects beyond </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>from
            	stand </span></span><span class="diff-chg"><span>set of subjects defined in the WS-Policy 
@@ -408,7 +408,7 @@
 				subject.</span></span><span class="diff-del"><span>assertion </span></span><span class="diff-chg"><span>For instance, an </span></span><span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>it
 			in </span></span><span class="diff-chg"><span>"Foo" has the same </span></span><span class="diff-add"><span>semantic</span></span><span class="diff-del"><span>different
 			alternatives) </span></span><span class="diff-add"><span>when 
-				attached to</span></span><span class="diff-del"><span>via </span></span><span class="diff-chg"><span>an operation </span></span>policy <span class="diff-chg"><span>subject regardless </span></span><span class="diff-add"><span>of</span></span><span class="diff-del"><span>be
+				attached</span></span><span class="diff-del"><span>via </span></span><span class="diff-chg"><span>to </span></span><span class="diff-add"><span>an operation</span></span><span class="diff-del"><span>a </span></span>policy <span class="diff-chg"><span>subject regardless </span></span><span class="diff-add"><span>of</span></span><span class="diff-del"><span>be
 			associated </span></span><span class="diff-chg"><span>whether it </span></span><span class="diff-add"><span>was 
 				attached</span></span><span class="diff-del"><span>alternatives </span></span><span class="diff-chg"><span>using XML </span></span><span class="diff-add"><span>element</span></span><span class="diff-del"><span>A
 			referencing </span></span><span class="diff-chg"><span>policy attachment or the external </span></span><span class="diff-add"><span>URI 
@@ -417,15 +417,14 @@
 			<span class="diff-del"><span>attachment </span></span><span class="diff-chg"><span>attachment </span></span><span class="diff-add"><span>mechanism 
 				allows</span></span><span class="diff-del"><span>multiple </span></span><span class="diff-chg"><span>policy tools to </span></span><span class="diff-add"><span>choose</span></span><span class="diff-del"><span>Endpoint
 			References </span></span><span class="diff-chg"><span>the most appropriate mechanism to attach </span></span><span class="diff-add"><span>a 
-				policy</span></span><span class="diff-del"><span>policies </span></span><span class="diff-chg"><span>without having </span></span>to <span class="diff-add"><span>analyze the</span></span><span class="diff-del"><span>be </span></span><span class="diff-add"><span>contents of the policy. 
-				</span></span><span class="diff-del"><span>applied. 
-	   		</span></span></p></div><p>
+				policy</span></span><span class="diff-del"><span>policies </span></span><span class="diff-chg"><span>without having </span></span>to <span class="diff-add"><span>analyze the contents of the</span></span><span class="diff-del"><span>be </span></span><span class="diff-chg"><span>policy. 
+				</span></span></p></div><p>
 				Best practice: <span class="diff-chg"><span>Assertion Authors </span></span>should include the following items in <span class="diff-chg"><span>an 
 				assertion </span></span>specification: 
 				</p><div class="diff-add"><p class="diff-add">
 				<ul><li><p><em>The definition of the
-            			<span class="diff-del"><span>assertion. Does the assertion pertain to a specific
-           				behavior that is tied </span></span><span class="diff-chg"><span>assertion's </span></span><span class="diff-add"><span>semantic.</span></span></em><span class="diff-del"><span>a </span></span></p></li><li><p><em><span class="diff-add"><span>The</span></span><span class="diff-del"><span>context </span></span><span class="diff-chg"><span>specification of </span></span>the <span class="diff-add"><span>set</span></span><span class="diff-del"><span>behavior
+            			<span class="diff-del"><span>assertion. Does the assertion pertain to a </span></span><span class="diff-add"><span>assertion's</span></span><span class="diff-del"><span>specific
+           				behavior that is tied to </span></span><span class="diff-add"><span>semantic.</span></span></em><span class="diff-del"><span>a </span></span></p></li><li><p><em><span class="diff-add"><span>The</span></span><span class="diff-del"><span>context </span></span><span class="diff-chg"><span>specification of </span></span>the <span class="diff-add"><span>set</span></span><span class="diff-del"><span>behavior
           				different </span></span><span class="diff-chg"><span>of valid policy subjects to which </span></span>an 
 						assertion <span class="diff-del"><span>that </span></span>may <span class="diff-del"><span>have different semantics for a single
             			message exchange or for all message exchanges that pertain
@@ -513,17 +512,17 @@
             depending </span></span><span class="diff-chg"><span>same policy expression are </span></span><span class="diff-add"><span>semantically
 					equivalent.</span></span><span class="diff-del"><span>example, </span></span><span class="diff-chg"><span>When </span></span>multiple alternatives are present in a policy, the
 					normal form may express the choices more explicitly. On the other hand,
-					the compact form <span class="diff-chg"><span>may </span></span><span class="diff-add"><span>be </span></span>more readable for humans when an assertion is
+					the compact form <span class="diff-add"><span>may be</span></span><span class="diff-del"><span>is </span></span>more readable for humans when an assertion is
 					marked as optional using the <code>wsp:optional</code> attribute as our example
 					illustrates above. 
            	</p><p><span class="diff-chg"><span>A policy </span></span><span class="diff-add"><span>processor may normalize a policy expression originally authored
-					in compact form at</span></span><span class="diff-del"><span>use </span></span><span class="diff-add"><span>any time without changing </span></span>the <span class="diff-chg"><span>semantics of </span></span><span class="diff-add"><span>the
+					in</span></span><span class="diff-del"><span>use </span></span><span class="diff-add"><span>compact form at any time without changing </span></span>the <span class="diff-chg"><span>semantics of </span></span><span class="diff-add"><span>the
 					policy.</span></span><span class="diff-del"><span>most </span></span><span class="diff-add"><span>In general, it is not possible to guarantee in what form a
-					policy expression would be when it is processed. As a</span></span><span class="diff-del"><span>appropriate </span></span><span class="diff-add"><span>result, the
+					policy expression would be when it is processed. As a result,</span></span><span class="diff-del"><span>appropriate </span></span><span class="diff-add"><span>the
 					description </span></span>for <span class="diff-add"><span>a policy assertion should not depend on </span></span>the <span class="diff-add"><span>style used
 					to author a policy expression that contains the assertion.
 				</span></span></p><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>Best practice: the semantics of an assertion should be independent of
-					the form (compact or normal form) of policy expressions that</span></span><span class="diff-del"><span>target </span></span><span class="diff-chg"><span>contain </span></span><span class="diff-add"><span>the
+					the form (compact or normal form) of</span></span><span class="diff-del"><span>target </span></span><span class="diff-add"><span>policy expressions that</span></span><span class="diff-del"><span>audience </span></span><span class="diff-add"><span>contain the
 					assertion.</span></span></p></div></div><div class="div2">
 <h3><a name="new-guidelines-domains" id="new-guidelines-domains"></a>4.3 Considerations when Modeling New Assertions</h3><p>When creating a new policy domain, it is important to
          		understand how policy expressions are used by a
@@ -540,7 +539,7 @@
          			the assertions and they now constitute a policy alternative. 
          			</p><p>If grouping is utilized, choices between alternatives can be indicated by
          			an "exactly one" operator. This basic set of operators allows
-         			<span class="diff-add"><span>Assertion Authors</span></span><span class="diff-del"><span>authors </span></span>a wide range of options for expressing the possible combinations of assertions within their domain.
+         			<span class="diff-chg"><span>Assertion </span></span><span class="diff-add"><span>Authors </span></span>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
          			reflects the options of the domain if the domain has a lot of
@@ -568,7 +567,7 @@
             		</p><p>Best practice: Use a unique QName to identify the behavior and provide an XML outline
             		(plus an XML schema document) to specify the syntax of an assertion.
             		</p></div><div class="div3">
-<h4><a name="self-describing" id="self-describing"></a>4.3.3  Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities, preferences and
+<h4><a name="self-describing" id="self-describing"></a>4.3.3  Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, <span class="diff-add"><span>capabilities</span></span><span class="diff-del"><span>capabilities, preferences </span></span>and
     	 			behaviors of nodes that provide the message's path, not specifically to declare properties of the message semantics. One
     	 			of the advantages of Web services is that an XML message can be stored and later examined (e.g. as a record of a business
      				transaction) or interpreted by an intermediary; however, if information that is necessary to understand a message is not
@@ -642,24 +641,24 @@
                                         <span class="diff-chg"><span>policy assertion parameters </span></span>to qualify an assertion. 
                                         <span class="diff-chg"><span>Policy assertion parameters are defined </span></span><span class="diff-add"><a href="#WS-Policy">[Web Services Policy Framework]</a></span><span class="diff-add"><span>.   
                                         Policy</span></span><span class="diff-del"><span>be </span></span><span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>appropriate
-        			to </span></span><span class="diff-chg"><span>parameters </span></span><span class="diff-add"><span>are the opaque payload of</span></span><span class="diff-del"><span>these </span></span><span class="diff-add"><span>an assertion.  
+        			to </span></span><span class="diff-chg"><span>parameters </span></span><span class="diff-add"><span>are the opaque payload</span></span><span class="diff-del"><span>these </span></span><span class="diff-add"><span>of an assertion.  
                                         Assertion </span></span>parameters <span class="diff-add"><span>carry additional useful pieces</span></span><span class="diff-del"><span>instead </span></span>of <span class="diff-add"><span>information 
                                         necessary</span></span><span class="diff-del"><span>nesting </span></span><span class="diff-chg"><span>for </span></span><span class="diff-add"><span>engaging</span></span><span class="diff-del"><span>elements. 
         			
-					 </span></span><span class="diff-chg"><span>the </span></span><span class="diff-add"><span>behavior described by an assertion.  
-                                        Assertion</span></span><span class="diff-del"><span>that </span></span>parameters <span class="diff-chg"><span>are not </span></span><span class="diff-add"><span>considered when performing policy 
-                                        intersection unless domain specific compatibility processing
-                                        semantics are specified by</span></span><span class="diff-del"><span>include </span></span>the <span class="diff-add"><span>assertion.  
-                                        In the XML</span></span><span class="diff-del"><span>following:
+					 </span></span><span class="diff-chg"><span>the </span></span><span class="diff-add"><span>behavior described by</span></span><span class="diff-del"><span>that </span></span><span class="diff-add"><span>an assertion.  
+                                        Assertion </span></span>parameters <span class="diff-chg"><span>are not </span></span><span class="diff-add"><span>considered when performing policy 
+                                        intersection unless domain</span></span><span class="diff-del"><span>include </span></span><span class="diff-add"><span>specific compatibility processing
+                                        semantics are specified by </span></span>the <span class="diff-add"><span>assertion.  
+                                        In the XML representation of a policy assertion the</span></span><span class="diff-del"><span>following:
 					
 						
-						 </span></span><span class="diff-add"><span>representation of a policy</span></span><span class="diff-del"><span>Complex </span></span><span class="diff-add"><span>assertion the child </span></span>elements 
-                                        <span class="diff-add"><span>and </span></span><span class="diff-chg"><span>attributes of the assertion excluding </span></span><span class="diff-add"><span>child elements and</span></span><span class="diff-del"><span>be </span></span><span class="diff-add"><span>attributes 
-                                        from the </span></span>policy <span class="diff-add"><span>xml language</span></span><span class="diff-del"><span>assertions.  
+						 </span></span><span class="diff-chg"><span>child </span></span>elements 
+                                        <span class="diff-add"><span>and </span></span><span class="diff-chg"><span>attributes of the assertion excluding </span></span><span class="diff-add"><span>child elements and attributes 
+                                        from the</span></span><span class="diff-del"><span>be </span></span>policy <span class="diff-add"><span>xml</span></span><span class="diff-del"><span>assertions.  
 						 
 						
 						
-						 </span></span><span class="diff-chg"><span>namespace are the assertion </span></span><span class="diff-add"><span>parameters.
+						 </span></span><span class="diff-chg"><span>language namespace are the </span></span><span class="diff-add"><span>assertion parameters.
                                         </span></span></p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> 
                                         elements are the two assertion parameters of the 
                                         <code>sp:SignedParts</code> policy assertion 
@@ -736,7 +735,34 @@
        					dependent behaviors automatically. This means the complexity of
         				security usage is absorbed by a policy-aware client and hidden
         				from Web service application developers.
-        				</p></div><div class="div3">
+        				</p><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>Assertion authors should note the effect of nested policy expressions
+						on policy intersection in their nested policy design. The result of
+						intersecting an assertion that contains an empty nested policy
+						expression with an assertion of the same type without a nested policy
+						expression is that the assertions are not compatible. Therefore, when
+						providers require dependent behaviors these behaviors should be
+						explicitly specified as assertions in a nested policy expression. When
+						the definition of an assertion allows for nested dependent behaviors,
+						but the use of the assertion only contains an empty nested policy
+						expression, this specific use indicates the specification of no nested
+						dependent behaviors. This use must not be interpreted as being
+						compatible with "any" of the nested dependent behaviors that are
+						allowed by the assertion, unless otherwise specified by the assertion
+						definition.</span></span></p></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>As an example, WS-Security Policy defines </span></span><code><span class="diff-add"><span>sp:HttpToken</span></span></code> <span class="diff-add"><span>assertion to
+						contain three possible nested elements, </span></span><code><span class="diff-add"><span>sp:HttpBasicAuthentication</span></span></code><span class="diff-add"><span>,
+						</span></span><code><span class="diff-add"><span>sp:HttpDigestAuthentication</span></span></code> <span class="diff-add"><span>and </span></span><code><span class="diff-add"><span>sp:RequireClientCertificate</span></span></code><span class="diff-add"><span>. When the
+						</span></span><code><span class="diff-add"><span>HttpToken</span></span></code> <span class="diff-add"><span>is used with an empty nested policy in a policy expression
+						by a provider, it will indicate that none of the dependent behaviors
+						namely authentication or client certificate is required.</span></span></p></div><div class="diff-add"><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-5. </span><span class="diff-add"><span>Empty Nested Policy Expression</span></span></i></p><div class="exampleInner"><pre>&lt;sp:TransportToken&gt; 
+  &lt;wsp:Policy&gt; 
+	&lt;sp:HttpsToken&gt; 
+	  &lt;wsp:Policy/&gt; 
+	&lt;/sp:HttpsToken&gt; 
+  &lt;/wsp:Policy&gt; 
+&lt;/sp:TransportToken&gt;</pre></div></div></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>A non-anonymous client who requires authentication or client
+						certificate will not be able to use this provider solely on the basis
+						of intersection algorithm alone.</span></span></p></div></div><div class="div3">
 <h4><a name="which-one-to-use" id="which-one-to-use"></a>4.4.3 Considerations for choosing parameters vs nesting</h4><p>The main consideration for selecting parameters or nesting
 					of assertions is that <em>the framework intersection
 					algorithm processes nested alternatives, but does not consider
@@ -762,12 +788,12 @@
             		avoided when they are not needed.</p><p>Best practice: If the <span class="diff-chg"><span>assertion
         			</span></span>authors want to delegate the processing to the framework,
         			utilizing nesting should be considered. Otherwise, domain
-        			specific comparison algorithms will need to be devised and be
+        			specific comparison algorithms <span class="diff-chg"><span>may </span></span>need to be devised and be
         			delegated to the specific domain handlers that are not visible
         			to the WS-Policy framework.
         			</p></div></div><div class="div2">
 <h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d2e1452" id="d2e1452"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h4><a name="d2e1532" id="d2e1532"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
         			compact authoring form for assertions, behaviors are marked by
         			using <code>wsp:Optional</code> attribute that has a value,
         			"true". During the process of normalization, the runtime
@@ -778,7 +804,7 @@
         			runtime behavior. In order to simplify reference to such
         			assertions, we just use the term optional assertions in this section. 
         			</p></div><div class="div3">
-<h4><a name="d2e1460" id="d2e1460"></a>4.5.2 Optional behavior at runtime</h4><p>The <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a> document contains an
+<h4><a name="d2e1540" id="d2e1540"></a>4.5.2 Optional behavior at runtime</h4><p>The <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a> document contains an
         			example that proposes the use of <a href="#MTOM">[MTOM]</a> as an
         			optional behavior that can be engaged by a consumer. The
         			primer proposes that an assertion that identifies the use of
@@ -855,47 +881,67 @@
           			how the behavior that is enabled by the assertion would be
           			engaged when they are designing their assertion, whether by
           			specific headers or some other means. See also <a href="#self-describing"><b>4.3.3  Self Describing Messages </b></a>.
-          			</p></div></div><div class="div2">
-<h3><a name="typing-assertions" id="typing-assertions"></a>4.6 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
-	  			identifying a policy assertion, <span class="diff-chg"><span>Assertion Authors </span></span>should be
+          			</p></div></div><div class="diff-del"><p class="diff-del">Typing Assertions
+				Since a QName is the central mechanism for
+	  			identifying a policy assertion, assertion authors should be
 	  			aware of the possible evolution of their assertions and how
 	  			this would impact the semantics of the assertion overtime. A namespace
 	 			 associated with the assertion may be used to indicate a
-	  			specific version of an assertion but this has its limitations. 
-	  			See <span class="diff-add"><span>section</span></span><span class="diff-del"><span>Lifecycle material </span></span><span class="diff-chg"><a href="#versioning-policy-assertions"><b>5. Versioning Policy Assertions</b></a></span> for more detail.
-          		</p><p>The typing must be done in combination with the scoping
+	  			specific version of an assertion but this has its limitations. See Lifecycle material  for more detail.
+          		
+				The typing must be done in combination with the scoping
 				of the semantics to a policy subject. WS-PolicyAttachment provides a means of associating an
           		assertion with arbitrary subjects, regardless of their
           		nature. This flexibility can lead to ambiguity in the
           		interpretation of policy; for example, if one attaches an
           		assertion with the semantic "must be encrypted" to a SOAP
           		endpoint, it's unclear what must be encrypted.
-          		</p><p> One way to disambiguate the semantic is to generally determine
+          		
+		  		 One way to disambiguate the semantic is to generally determine
           		if an assertion is specific to a policy attachment
           		mechanism. An example could be identifying whether the
           		assertion expressed is associated with behaviors
           		(endpoints) or artifacts (messages) and then constraining
           		the use of an assertion to one of these subjects.
-          		</p><p>Thus our example encryption assertion would have a
+          		
+				Thus our example encryption assertion would have a
           		subject of "message", and could only be attached to
-          		messages, where the assertion is valid. However, <span class="diff-add"><span>Assertion Authors</span></span><span class="diff-del"><span>authors
-          		</span></span>need to be aware that <em>policy attachment subjects are
-          		not limited to the subjects defined in WSDL</em>.  The
+          		messages, where the assertion is valid. However, authors
+          		need to be aware that policy attachment subjects are
+          		not limited to the subjects defined in WSDL.  The
           		external attachment model in WS-PolicyAttachment allows for
           		the definition of other domain expressions to be policy
-          		subjects. More of this topic is covered in the <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a>
-				</p><p>Best Practice- To avoid confusion, assertion definitions should be
+          		subjects. More of this topic is covered in the 
+				        
+				Best Practice- To avoid confusion, assertion definitions should be
           		precise about their semantics and include information that
           		restricts their set of permissible policy subjects
           		appropriately and indicates which QNames are associated with
-          		which subjects.</p><ol class="enumar"><li><p>Description must clearly and completely specify the syntax (plus an XML Schema
-              document) and semantics of a policy assertion.</p></li><li><p>If there is a nested policy expression, description must declare it and enumerate the
-              nested policy assertions that are allowed. </p></li><li><p>A policy alternative may contain multiple instances of the same policy assertion.
+          		which subjects.        
+          		
+          
+            Description must clearly and completely specify the syntax (plus an XML Schema
+              document) and semantics of a policy assertion.
+          
+          
+            If there is a nested policy expression, description must declare it and enumerate the
+              nested policy assertions that are allowed. 
+          
+          
+            A policy alternative may contain multiple instances of the same policy assertion.
               Description must specify the semantics of parameters and nested policy (if any) when
               there are multiple instances of a policy assertion in the same policy alternative.
-            </p></li><li><p>If a policy assertion is to be used with WSDL, description must specify a WSDL policy
-              subject – such as service, endpoint, operation and message.</p></li></ol></div><div class="div2">
-<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>4.7 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+            
+          
+          
+            If a policy assertion is to be used with WSDL, description must specify a WSDL policy
+              subject – such as service, endpoint, operation and message.
+          
+        
+			
+			
+			</p></div><div class="div2">
+<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>4.6 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
         		associated policy subject. If a policy assertion is to be used
         		within WSDL, <span class="diff-add"><span>Assertion</span></span><span class="diff-del"><span>policy assertion </span></span><span class="diff-chg"><span>Authors </span></span>must specify a WSDL
         		policy subject. The policy subject is determined with respect
@@ -965,7 +1011,7 @@
 				policy assertions do not target wire-level behaviors but
 				rather abstract requirements, this technique does not apply. 
 				</p></div><div class="diff-add"><div class="div2">
-<h3><a name="interrelated-domains" id="interrelated-domains"></a>4.8 <span class="diff-add"><span>Interrelated domains</span></span></h3><p><span class="diff-add"><span>Assertion authors need to be clear about how assertions defined in  
+<h3><a name="interrelated-domains" id="interrelated-domains"></a>4.7 <span class="diff-add"><span>Interrelated domains</span></span></h3><p><span class="diff-add"><span>Assertion authors need to be clear about how assertions defined in  
 				their domain may fit with assertions for interrelated domains. A  
 				classic example of such an interrelated domain is security, because  
 				security tends to
@@ -985,7 +1031,7 @@
 				for details on extensibility.
 				</p><p> The current WS-Policy language <a href="#WS-Policy">[Web Services Policy Framework]</a> provides extensibility points 
 				on 6 elements with a combination of attribute and/or element extensibility:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p><span class="diff-del"><span>PolicyReference: any attribute and a proposal to add any element </span></span>ExactlyOne, All: element from ##other <span class="diff-chg"><span>namespace; </span></span>no attribute extensibility</p></li><li><p><span class="diff-add"><span>PolicyReference: any element and any attribute</span></span></p></li><div class="diff-add"><li class="diff-add"><p>PolicyAttachment: element from ##other namespace and any attribute</p></li></div><li><p>AppliesTo: any element and any attribute</p></li><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>URI: any attribute</span></span></p></li></div></ol></li><li><p><span class="diff-add"><span>Supporting </span></span><span class="diff-del"><span>Subject attachment Extensibility 
-			PolicyAttachment and AppliesTo </span></span><span class="diff-add"><span>New</span></span><span class="diff-del"><span>also have </span></span><span class="diff-chg"><span>Policy Subjects</span></span></p></li></ul><div class="div2">
+			PolicyAttachment and AppliesTo also </span></span><span class="diff-chg"><span>New Policy Subjects</span></span></p></li></ul><div class="div2">
 <h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>5.1 Referencing Policy Expressions</h3><p>The <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a> illustrates how providers can utilize
 					the identification mechanism defined in the Policy specification
         			<span class="diff-del"><span>to </span></span><span class="diff-add"><span>to
@@ -1003,9 +1049,9 @@
 					As an example, in </span></span><span class="diff-add"><a href="#WS-Policy-Primer">[Web Services Policy Primer]</a></span>
 					<span class="diff-add"><span>Section</span></span><span class="diff-del"><span>their </span></span><span class="diff-chg"><span>4.2, the </span></span><span class="diff-add"><code><span class="diff-add"><span>sp:issuedToken</span></span></code></span><span class="diff-del"><span>common
         			policy </span></span><span class="diff-add"><span>assertion utilizes the
-					</span></span><span class="diff-add"><code><span class="diff-add"><span>sp:RequestSecurityTokenTemplate</span></span></code></span><span class="diff-del"><span>expressions </span></span><span class="diff-add"><span>parameter </span></span>that <span class="diff-add"><span>contains necessary
-					information</span></span><span class="diff-del"><span>are </span></span><span class="diff-chg"><span>to request a </span></span><span class="diff-add"><span>security token. The</span></span><span class="diff-del"><span>promotes
-        			manageability </span></span><span class="diff-add"><span>contents </span></span>of the <span class="diff-add"><span>parameter
+					</span></span><span class="diff-add"><code><span class="diff-add"><span>sp:RequestSecurityTokenTemplate</span></span></code></span> <span class="diff-add"><span>parameter</span></span><span class="diff-del"><span>expressions </span></span>that <span class="diff-chg"><span>contains </span></span><span class="diff-add"><span>necessary
+					information</span></span><span class="diff-del"><span>identified. </span></span><span class="diff-chg"><span>to request </span></span><span class="diff-add"><span>a</span></span><span class="diff-del"><span>promotes
+        			manageability </span></span><span class="diff-add"><span>security token. The contents </span></span>of the <span class="diff-add"><span>parameter
 					are</span></span><span class="diff-del"><span>expressions </span></span><span class="diff-chg"><span>static and allows </span></span><span class="diff-add"><span>reuse in different security scenerios.</span></span><span class="diff-del"><span>uniquely
         			identified.
         			</span></span></p></div><div class="div2">
@@ -1026,11 +1072,11 @@
   &lt;sp:Wss11&gt;…&lt;/sp:Wss11&gt;
 &lt;/Policy&gt;</pre></div></div><p>Best practice: use independent assertions for modeling multiple equivalent
            						behaviors.</p></div><div class="diff-add"><div class="div2">
-<h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>5.3 <span class="diff-chg"><span>Supporting </span></span><span class="diff-add"><span>New</span></span><span class="diff-del"><span>Policy and </span></span><span class="diff-chg"><span>Policy Subjects</span></span></h3><p>
+<h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>5.3 <span class="diff-add"><span>Supporting</span></span><span class="diff-del"><span>Inter-domain Policy </span></span><span class="diff-chg"><span>New Policy Subjects</span></span></h3><p>
 				<a href="#Assertions"><span class="diff-add"><span>Section</span></span><span class="diff-del"><span>Domain </span></span><span class="diff-add"><span>2</span></span></a><span class="diff-del"><span>authors </span></span><span class="diff-chg"><span>identifies that it is a best practice </span></span><span class="diff-add"><span>for</span></span><span class="diff-del"><span>their
 			domain </span></span><span class="diff-chg"><span>policy authors </span></span><span class="diff-add"><span>to 
 				define</span></span><span class="diff-del"><span>domains. </span></span><span class="diff-chg"><span>the set of policy </span></span><span class="diff-add"><span>subjects</span></span><span class="diff-del"><span>interact
-         with </span></span><span class="diff-chg"><span>to </span></span><span class="diff-add"><span>which policy</span></span><span class="diff-del"><span>protocol </span></span>assertions <span class="diff-chg"><span>can </span></span><span class="diff-add"><span>be 
+         with </span></span><span class="diff-chg"><span>to which </span></span><span class="diff-add"><span>policy </span></span>assertions <span class="diff-chg"><span>can </span></span><span class="diff-add"><span>be 
 				attached.  Over</span></span><span class="diff-del"><span>a </span></span><span class="diff-chg"><span>time, </span></span><span class="diff-add"><span>new</span></span><span class="diff-del"><span>Although
          modeling </span></span><span class="diff-chg"><span>policy subjects </span></span>may <span class="diff-chg"><span>need </span></span>to be <span class="diff-add"><span>defined.  When 
 				this occurs, a policy assertion author may update the list of policy 
@@ -1038,18 +1084,18 @@
 			</span></span></p><p>
 				<span class="diff-add"><span>When</span></span><span class="diff-del"><span>independent </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>behavior,
          protocol </span></span><span class="diff-chg"><span>assertion's semantics do not change </span></span><span class="diff-add"><span>to</span></span><span class="diff-del"><span>transport
-         bindings </span></span><span class="diff-chg"><span>invalidate </span></span><span class="diff-add"><span>any of</span></span><span class="diff-del"><span>their </span></span><span class="diff-add"><span>the 
-				original</span></span><span class="diff-del"><span>interactions </span></span><span class="diff-add"><span>policy subjects but new policy subjects need to</span></span><span class="diff-del"><span>must </span></span>be <span class="diff-add"><span>added, it may 
-				be possible</span></span><span class="diff-del"><span>considered. </span></span><span class="diff-add"><span>to use the same assertion to designate the additional policy 
+         bindings </span></span><span class="diff-chg"><span>invalidate any of </span></span><span class="diff-add"><span>the 
+				original</span></span><span class="diff-del"><span>must </span></span><span class="diff-add"><span>policy subjects but new policy subjects need to </span></span>be <span class="diff-add"><span>added, it may 
+				be possible to use the same assertion to designate the additional</span></span><span class="diff-del"><span>considered. </span></span><span class="diff-add"><span>policy 
 				subjects without a namespace change.  </span></span>For
          <span class="diff-del"><span>example </span></span><span class="diff-chg"><span>example, a policy assertion </span></span><span class="diff-add"><span>for 
 				a</span></span><span class="diff-del"><span>with </span></span><span class="diff-add"><span>protocol</span></span><span class="diff-del"><span>other
          protocols </span></span><span class="diff-chg"><span>that is originally designed for </span></span><span class="diff-add"><span>endpoint policy subject may add 
 				message policy subject to</span></span><span class="diff-del"><span>result </span></span><span class="diff-add"><span>indicate finer granularity </span></span>in <span class="diff-add"><span>the attachment 
 				provided that endpoint </span></span><span class="diff-del"><span>nested
-         </span></span>policy <span class="diff-chg"><span>subject is also </span></span><span class="diff-add"><span>retained in its design. When 
-				new</span></span><span class="diff-del"><span>protocols </span></span><span class="diff-add"><span>policy subjects </span></span>are <span class="diff-chg"><span>added </span></span><span class="diff-add"><span>it</span></span><span class="diff-del"><span>with
-         . </span></span><span class="diff-chg"><span>is </span></span><span class="diff-add"><span>incumbent on the</span></span><span class="diff-del"><span>domain </span></span>authors <span class="diff-add"><span>to</span></span><span class="diff-del"><span>should
+         </span></span>policy <span class="diff-chg"><span>subject is also </span></span><span class="diff-add"><span>retained in its design.</span></span><span class="diff-del"><span>protocols </span></span><span class="diff-add"><span>When 
+				new policy subjects </span></span>are <span class="diff-chg"><span>added </span></span><span class="diff-add"><span>it</span></span><span class="diff-del"><span>with
+         . </span></span><span class="diff-chg"><span>is </span></span><span class="diff-add"><span>incumbent on</span></span><span class="diff-del"><span>domain </span></span><span class="diff-add"><span>the </span></span>authors <span class="diff-add"><span>to</span></span><span class="diff-del"><span>should
          be </span></span><span class="diff-add"><span>retain the 
 				semantic</span></span><span class="diff-del"><span>aware </span></span>of the <span class="diff-chg"><span>policy </span></span><span class="diff-add"><span>assertion. 
 			</span></span></p><p><span class="diff-add"><span>Best</span></span><span class="diff-del"><span>semantics </span></span><span class="diff-chg"><span>Practice: An </span></span><span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>related
@@ -1057,17 +1103,17 @@
 				subject.</span></span></p><p><span class="diff-add"><span>Best</span></span><span class="diff-del"><span>require </span></span><span class="diff-add"><span>Practice:</span></span><span class="diff-del"><span>composition
          with </span></span><span class="diff-chg"><span>If the policy subjects change over </span></span><span class="diff-add"><span>time, 
 				</span></span>the <span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>nesting
-         requirements </span></span><span class="diff-chg"><span>description should also be versioned to </span></span><span class="diff-add"><span>reflect this 
+         requirements </span></span><span class="diff-add"><span>description should</span></span><span class="diff-del"><span>on </span></span><span class="diff-chg"><span>also be versioned to reflect </span></span><span class="diff-add"><span>this 
 				change.
 			</span></span></p></div></div></div></div><div class="div1">
 <h2><a name="best-practices-attachment" id="best-practices-attachment"></a>6. Applying Best Practices for  Policy Attachment</h2><div class="div2">
 <h3><a name="context-free-policies" id="context-free-policies"></a>6.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect the interpretation of
          Policy alternatives. If it did, each policy assertion would
          need to be written with different (and possibly unknown)
-         attachment mechanisms in mind. In particular, the timing of a
+         attachment mechanisms in mind.   <span class="diff-del"><span>In particular, the timing of a
          policy attachment or the role that a party who attaches
          policy should have no bearing on the evaluation of the policy
-         assertion </p></div><div class="div2">
+         assertion </span></span></p></div><div class="div2">
 <h3><a name="appropriate-attachment-assertion-subjects" id="appropriate-attachment-assertion-subjects"></a>6.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
         identify the subject of the attached assertions. Generally,
         this should be a specific SOAP node or a specific message
@@ -1274,8 +1320,10 @@
   assertion represents but they need to consider how new assertions
   will be intersected and merged with other assertions in the
   calculation of an effective policy and this also indicates they need
-  to consider policy subjects.</p><p>The policy framework only defines an algorithm for calculating
-  effective policies for WSDL 1.1 based subjects. </p></div></div><div class="back"><div class="div1">
+  to consider policy subjects.</p><p> The <span class="diff-chg"><span>WS-Policy 1.5 - Attachment specification </span></span><span class="diff-add"><span>defines algorithms</span></span><span class="diff-del"><span>algorithm </span></span>for calculating <span class="diff-add"><span>the 
+ effective policy for a given policy subject and 
+  </span></span>effective policies for
+ <span class="diff-add"><span>WSDL 1.1, </span></span>WSDL <span class="diff-chg"><span>2.0 and </span></span><span class="diff-add"><span>UDDI policy</span></span><span class="diff-del"><span>subjects. </span></span><span class="diff-add"><span>subjects.</span></span></p></div></div><div class="back"><div class="div1">
 <h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <a href="#WS-Policy">[Web Services Policy Framework]</a> document.</p></div><div class="div1">
 <h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
         namespace prefix is arbitrary and not semantically significant.</p><a name="nsprefix"></a><table border="1" cellpadding="5" cellspacing="0" summary="Prefixes and XML Namespaces used in this specification"><caption>Table B-1. Prefixes and XML Namespaces used in this specification.</caption><thead><tr><th colspan="1" rowspan="1">Prefix</th><th colspan="1" rowspan="1">XML Namespace</th><th colspan="1" rowspan="1">Specifications</th></tr></thead><tbody><tr><td colspan="1" rowspan="1">
@@ -1359,14 +1407,16 @@
           http://www.w3.org/TR/ws-policy-attach/.   (See http://www.w3.org/TR/ws-policy-attach/.)</dd><dt class="label"><a name="WS-Policy-Primer" id="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd>
 					<a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8"><cite>Web Services Policy 1.5 - Primer</cite></a>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,  
 					P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, Draft.   (See http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8.)</dd><dt class="label"><a name="WS-RM" id="WS-RM"></a>[Web Services Reliable Messaging] </dt><dd>
-					<a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html"><cite>Web Services Reliable Messaging (WS-ReliableMessaging)</cite></a>, Doug Davis (IBM), Anish Karmarkar (Oracle),
-					Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
-          (SAP), August 7th, 2006, available at:
+					<a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html"><cite>Web Services Reliable Messaging (WS-ReliableMessaging)</cite></a>, <span class="diff-add"><span>D.</span></span><span class="diff-del"><span>Doug Davis </span></span><span class="diff-chg"><span>Davis, A. </span></span>Karmarkar <span class="diff-del"><span>(Oracle),
+					</span></span><span class="diff-add"><span>G. Pilz,</span></span><span class="diff-del"><span>Gilbert </span></span><span class="diff-chg"><span>S. Winkler, Ü. Yalçinalp, Editors. Organization </span></span><span class="diff-add"><span>for the Advancement of
+					Structured Information Standards,</span></span><span class="diff-del"><span>Yalçinalp
+          (SAP), </span></span>August 7th, 2006, available at:
           http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html
             (See http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html.)</dd><dt class="label"><a name="WS-RM-Policy" id="WS-RM-Policy"></a>[Web Services Reliable Messaging Policy] </dt><dd>
-					<a href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html"><cite>Web Services Reliable Messaging Policy Assertion v1.1</cite></a>, Doug Davis (IBM), Anish Karmarkar (Oracle),
-					Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
-          (SAP), August 4, 2006, available at:
+					<a href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html"><cite>Web Services Reliable Messaging Policy Assertion v1.1</cite></a>, <span class="diff-chg"><span>D. </span></span><span class="diff-add"><span>Davis, 
+					A.</span></span><span class="diff-del"><span>Davis </span></span><span class="diff-chg"><span>Karmarkar, G. Pilz, </span></span><span class="diff-add"><span>S. Winkler, Ü. Yalçinalp,</span></span><span class="diff-del"><span>(Oracle),
+					Gilbert </span></span><span class="diff-chg"><span>Editors. Organization for the Advancement </span></span><span class="diff-add"><span>of
+					Structured</span></span><span class="diff-del"><span>Ü. </span></span><span class="diff-chg"><span>Information Standards, </span></span>August 4, 2006, available at:
           http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
             (See http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html.)</dd><dt class="label"><a name="WS-Security2004" id="WS-Security2004"></a>[WS-Security 2004] </dt><dd>
 					<a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"><cite>Web Services Security: SOAP Message Security
@@ -1430,8 +1480,15 @@
     acknowledged.
   </p></div><div class="div1">
 <h2><a name="change-description" id="change-description"></a>E. Changes in this Version of
-          the Document (Non-Normative)</h2><p>A list of substantive changes since the <span class="diff-add"><span>Working Draft</span></span><span class="diff-del"><span>previous </span></span><span class="diff-chg"><span>dated </span></span><span class="diff-add"><span>21 December, 
-			2006 </span></span>is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
+          the Document (Non-Normative)</h2><p>A list of substantive changes since the <span class="diff-add"><span>Working Draft dated</span></span><span class="diff-del"><span>previous </span></span><span class="diff-chg"><span>21 </span></span><span class="diff-add"><span>December, 
+			2006 </span></span>is below:</p><ul><li><p><span class="diff-add"><span>Rewrote section </span></span><span class="diff-add"><a href="#supporting-new-policy-subjects"><b>5.3 SupportingInter-domain Policy New Policy Subjects</b></a></span> <span class="diff-add"><span>and added two new best practices:
+					</span></span><span class="diff-add"><ul><li><p><span class="diff-add"><span>An assertion description should specify a policy subject.</span></span></p></li><li><p><span class="diff-add"><span>If the policy subjects change over time, the assertion description 
+							should also be versioned to reflect this change.</span></span></p></li></ul></span></p></li><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Rewrote section </span></span><a href="#compact-full"><b>4.2 Authoring Styles </b></a> <span class="diff-add"><span>and added a new best practice: 
+				the semantics of an assertion should be independent of the form (compact or normal form) 
+				of policy expressions that contain the assertion.</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Rewrote section </span></span><a href="#Referencing_Policy_Expressions"><b>5.1 Referencing Policy Expressions</b></a><span class="diff-add"><span>.</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Rewrote section </span></span><a href="#assertion-target"><b>4.1 Assertions and Their Target Use</b></a> <span class="diff-add"><span>and added a new best practice:
+					the semantics a policy assertion should not depend on the attachment mechanism used.</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Dropped section  
+				</span></span><a href="http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221/#typing-assertions"><span class="diff-add"><span>4.6 Typing
+				 Assertions</span></span></a><span class="diff-add"><span>.</span></span><span class="diff-del"><span>TBD</span></span></p></li></div><div class="diff-add"><li class="diff-add"><p><span class="diff-add"><span>Clarified the semantics of an empty nested policy expression in </span></span><a href="#nested-assertions"><b>4.4.2 Nested Assertions</b></a><span class="diff-add"><span>.</span></span></p></li></div></ul></div><div class="div1">
 <h2><a name="change-log" id="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><tr><td colspan="1" rowspan="1">20060829</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Created first draft based on agreed outline and content</td></tr><tr><td colspan="1" rowspan="1">20061013</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td colspan="1" rowspan="1">20061018</td><td colspan="1" rowspan="1">MH</td><td colspan="1" rowspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td colspan="1" rowspan="1">20061030</td><td colspan="1" rowspan="1">UY</td><td cospan="1" rowspan="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td colspan="1" rowspan="1">20061031</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr><tr><td colspan="1" rowspan="1">20061031</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Optionality discussion feedback integration</td></tr><tr><td colspan="1" rowspan="1">20061115</td><td colspan="1" rowspan="1">MH</td><td colspan="1" rowspan="1">First attempt at restructuring to include primer content</td></tr><tr><td colspan="1" rowspan="1">20061120</td><td colspan="1" rowspan="1">MH</td><td colspan="1" rowspan="1">Restructure to address action items 64,77, which refer to bugzilla 3705 and F2F RESOLUTION 3792 </td></tr><tr><td colspan="1" rowspan="1">20061127</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated the list of editors. Added 
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">Frederick</a> and 
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</a> to the list of editors.
@@ -1505,4 +1562,23 @@
 							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035"><span class="diff-add"><span>4035</span></span></a> 
 							as outlined in 
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html"><span class="diff-add"><span>proposal</span></span></a>.
-							Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197"><span class="diff-add"><span>197</span></span></a>.	</td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
+							Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197"><span class="diff-add"><span>197</span></span></a>.	</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070319</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">MH</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1"> Implemented resolution for issue 
+							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4073"><span class="diff-add"><span>4073</span></span></a>
+							in response to editor's action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/199"><span class="diff-add"><span>199 </span></span></a>
+							as outlined in 
+							<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html"><span class="diff-add"><span>proposal </span></span></a>.
+							</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070320</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1"><span class="diff-add"><span>resolution</span></span></a> 
+							for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319"><span class="diff-add"><span>issue 4319</span></span></a>.
+							Editors' action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206"><span class="diff-add"><span>206</span></span></a>.
+						</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070320</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1"><span class="diff-add"><span>resolution</span></span></a> 
+							for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990"><span class="diff-add"><span>issue 3990</span></span></a>.
+							Editors' action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210"><span class="diff-add"><span>210</span></span></a>.
+						</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070320</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1"><span class="diff-add"><span>resolution</span></span></a> 
+							for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212"><span class="diff-add"><span>issue 4212</span></span></a>.
+							Editors' action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207"><span class="diff-add"><span>207</span></span></a>.
+						</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070321</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Updated section <a href="#change-description"><b>E. Changes in this Version of
+          the Document</b></a>. </td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: ws-policy-attachment-tr20070228.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment-tr20070228.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-attachment-tr20070228.xml	16 Mar 2007 13:15:02 -0000	1.1
+++ ws-policy-attachment-tr20070228.xml	22 Mar 2007 07:11:39 -0000	1.2
@@ -11,7 +11,7 @@
 <!ENTITY hellip "&#8230;">
 ]>
 <?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
-<spec w3c-doctype="cr" role="&document.role;">
+<spec w3c-doctype="&doctype.attachment;" role="&document.role;">
 <header>
 <title>&attachment.title;</title>
 <w3c-designation>&w3c-designation-attachment;</w3c-designation>

Received on Thursday, 22 March 2007 16:54:42 UTC