- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 22 Sep 2007 02:01:03 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv16383
Modified Files:
ws-policy-primer-diff20070810.xml
ws-policy-guidelines-diff20070810.html
ws-policy-primer-diff20070810.html
ws-policy-guidelines-diff20070810.xml
Log Message:
Regenerated DIFF docs ...
Index: ws-policy-primer-diff20070810.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20070810.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-primer-diff20070810.html 22 Aug 2007 05:24:55 -0000 1.2
+++ ws-policy-primer-diff20070810.html 22 Sep 2007 02:01:01 -0000 1.3
@@ -1,6 +1,6 @@
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title> -- Review Version</title><style type="text/css">
+<html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Policy 1.5 - Primer -- Review Version</title><style type="text/css">
/**/
code { font-family: monospace; }
@@ -55,6 +55,38 @@
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
+
+div.boxedtext {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+ }
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+ }
+
+span.practicelab { background: #dfffff; }
+
+ span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+ }
+p.practice
+{
+ margin: 1.5em 0.5em 1em 1em;
+ }
+
+@media screen {
+ p.practice, {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+}
+}
/**/
div.diff-add { background-color: #FFFF99; }
@@ -77,12 +109,12 @@
<span class="diff-chg">changed text</span>, and
<span class="diff-del">deleted text</span>. NOTE: the status section of the document has not been augmented to
identify changes from a previous version.</p><hr></div><div class="head">
-<h1><a name="title" id="title"></a></h1>
+<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>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2007/WD-ws-policy-primer-20070605">http://www.w3.org/TR/2007/WD-ws-policy-primer-20070605</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> © @@@@ <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>
+ </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, <span class="diff-chg"><span>webMethods </span></span><span class="diff-add"><span>(A subsidiary of Software AG)</span></span><span class="diff-del"><span>Inc.</span></span></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> © @@@@ <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="htp://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>
<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
@@ -115,7 +147,7 @@
3.7 <a href="#combine-policies">Combine Policies</a><br>
3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
3.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
- 3.8.2 <a href="#d4e1409">Policy Expressions</a><br>
+ 3.8.2 <a href="#d4e1492">Policy Expressions</a><br>
3.8.3 <a href="#ignorable-and-versioning">Use of Ignorable attribute and an alternative Versioning Scenario</a><br>
3.8.4 <a href="#ignorable-and-optional-and-versioning">Use of Ignorable and Optional attributes</a><br>
3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
@@ -184,8 +216,8 @@
determine the compatibility of policies, to name and reference policies and to associate
policies with Web service metadata constructs such as service, endpoint and operation. Web
Services Policy is a simple language that has four elements - <code>Policy, All</code>,
- <code>ExactlyOne</code> and <code>PolicyReference</code> - and one attribute -
- <code>wsp:Optional</code>.</p></div><div class="div2">
+ <code>ExactlyOne</code> and <code>PolicyReference</code> - and <span class="diff-chg"><span>two attributes </span></span>-
+ <code>wsp:Optional</code> <span class="diff-add"><span>and </span></span><span class="diff-add"><code><span class="diff-add"><span>wsp:Ignorable</span></span></code></span>.</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><soap:Envelope>
<soap:Header>
@@ -223,7 +255,7 @@
</Policy></pre></div></div><p>
The policy expression in the above example consists of a Policy main
element and a child element wsam:Addressing. Child elements of
- the Policy element are policy assertions. Company-X attaches the above
+ the Policy element <span class="diff-add"><span>that are not from the Policy namespace </span></span>are policy assertions. Company-X attaches the above
policy expression to a WSDL binding description.
</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Policy Expression Attached to Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" >
@@ -417,8 +449,8 @@
</p></div><div class="div2">
<h3><a name="Both-Optional-Ignorable" id="Both-Optional-Ignorable"></a>2.8 Marking Assertions both Optional and Ignorable</h3><p>As described in the sections above and in Section <a href="#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy Intersection</b></a>,
the WS-Policy 1.5 specification defines two
- attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both "optional"
- and "Ignorable" attributes simultaneously. The presence of "@wsp:optional=true" on an assertion
+ attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both <span class="diff-chg"><span>"Optional"
+ </span></span>and "Ignorable" attributes simultaneously. The presence of "@wsp:optional=true" on an assertion
is a syntactic compact form for two alternatives in normal form, one with the assertion
and the other without the assertion. Hence syntactically marking an assertion "A" with both the
@wsp:Optional and @wsp:Ignorable with the value of "true" for both, is equivalent to
@@ -511,7 +543,7 @@
inline the policy expression.
</p><p>A policy expression may be identified by an IRI and referenced for re-use as a standalone
policy or within another policy expression. There are three mechanisms to identify a policy
- expression: the <code>wsu:Id</code> <code>xml:id</code> and <code>Name</code> attributes. A
+ expression: the <code>wsu:Id</code><span class="diff-add"><span>, </span></span><code>xml:id</code> and <code>Name</code> attributes. A
<code>PolicyReference</code> element can be used to reference a policy expression
identified using either of these mechanisms.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”common”>
@@ -570,12 +602,12 @@
assertions from different domains are used in a policy expression,
complex expressions will emerge. Naming parts of complex expressions for
reuse and building more complex policies through referencing enables
- building more complicated policy scenerios easily. This approach enables
+ building more complicated policy <span class="diff-chg"><span>scenarios </span></span>easily. This approach enables
the association of additional policy subjects to identified policy
expressions. It also promotes manageability of the expressions as they
- are uniquely identified and allows profiles for common scenerios to be
+ are uniquely identified and allows profiles for common <span class="diff-chg"><span>scenarios </span></span>to be
developed. Note that when a named expression has assertions that
- contains parametrized expressions, care must be given to ensure that the
+ contains <span class="diff-chg"><span>parameterized </span></span>expressions, care must be given to ensure that the
parameterized content is statically available to enable reuse.</p></div><div class="div2">
<h3><a name="attaching-policy-expressions-to-wsdl" id="attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy Expressions to WSDL</h3><p>A majority of Company-X’s customers use WSDL for building their client applications.
Company-X leverages this usage by attaching policy expressions to the WSDL binding
@@ -629,7 +661,7 @@
tool and hidden from these Web service developers.</p></div><div class="div2">
<h3><a name="policy-automates-web-services-interaction" id="policy-automates-web-services-interaction"></a>2.12 Policy Automates Web Services Interaction</h3><p>As you have seen, Web Services Policy is a simple language that has four elements -
<code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
- one attribute - <code>wsp:Optional</code>. In practice, service providers, like Company-X,
+ <span class="diff-chg"><span>two attributes </span></span>- <code>wsp:Optional</code> <span class="diff-add"><span>and </span></span><span class="diff-add"><code><span class="diff-add"><span>wsp:Ignorable</span></span></code></span>. In practice, service providers, like Company-X,
use policy expressions to represent combinations of capabilities and requirements. Web
service developers use policy-aware clients that understand policy expressions
and engage the behaviors represented by providers automatically. A sizable amount of
@@ -725,8 +757,8 @@
policy expression in the normal form. As you can see, the compact form is less verbose
than the normal form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy alternative. There are
- four policy alternatives in the normal form. These alternatives map to bullets (a) through
- (d) above.</p><div class="exampleOuter">
+ four policy alternatives in the normal form. These alternatives map to <span class="diff-add"><span>list items</span></span><span class="diff-del"><span>bullets </span></span><span class="diff-chg"><span>(1) </span></span>through
+ <span class="diff-chg"><span>(4) </span></span>above.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Company-X’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
@@ -760,7 +792,7 @@
<h3><a name="policy-data-model" id="policy-data-model"></a>3.3 Policy Data Model</h3><p>In the previous section, we considered the normal form for policy expressions. As we
discussed, the normal form represents a policy as a collection of policy alternatives. In
this section, let us look at the policy data model.</p><p>Company-X uses a policy to convey the conditions for an interaction. Policy-aware clients,
- like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view policy as an unordered collection of
+ like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view <span class="diff-add"><span>a </span></span>policy as an unordered collection of
zero or more policy alternatives. A policy alternative is an unordered collection of zero
or more policy assertions. A policy alternative represents a collection of behaviors or
requirements or conditions for an interaction. In simple words, each policy alternative
@@ -843,7 +875,7 @@
QName, <code>sp:TransportBinding</code>. For this discussion, let us assume that these two
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
+ compatible with a policy assertion in the other and vice-versa. For <span class="diff-add"><span>instance in Examples 3.6 and</span></span><span class="diff-del"><span>example, </span></span><span class="diff-add"><span>3.7, </span></span>policy
assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
assertions (t2) and (t1) in the client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
@@ -853,9 +885,56 @@
of Company-X’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 Company-X’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
- supplier endpoints to be compatible with an agreed upon policy.</p><div class="div3">
+ supplier endpoints to be compatible with an agreed upon policy.</p><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>Consider a similar scenario between Company X and the client where nested policy expressions exist in the policy alternatives.
+ The nested policy expressions are compared for compatibility in the context of
+ their parent policy assertions during policy intersection. For example, take these two incompatible policies in Examples 3.8 and 3.9:
+ </span></span></p></div><div class="diff-add"><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span><span class="diff-add"><span>Company X Nested incompatible policy example</span></span></i></p><div class="exampleInner"><pre>Company X
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:EndorsingSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion a -->
+(P006) <wsp:Policy> <!-- nested policy a1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:EndorsingSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy></pre></div></div></div><div class="diff-add"><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span><span class="diff-add"><span>Client Nested incompatible policy example</span></span></i></p><div class="exampleInner"><pre>Client
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:SignedSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion b -->
+(P006) <wsp:Policy> <!-- nested policy b1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:SignedSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy>
+ </pre></div></div></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>In this scenario as illustrated in Examples 3.8 and 3.9, the EndorsingSupportingTokens and
+ SignedSupportingTokens
+ assertions
+ are incompatible even though their nested policy expressions are compatible.
+ This is because the parent policy
+ assertions EndorsingSupportingTokens and SignedSupportingTokens have different
+ QNames.
+ </span></span></p></div><div class="div3">
<h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
- The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the
+ The previous sections outlined how the normal-form of a policy expression <span class="diff-chg"><span>relates </span></span>to the policy data model and how the
compatibility of requester and provider policies may be determined.
This section outlines how ignorable assertions may impact the process of determining compatibility.
</p><p>
@@ -922,7 +1001,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>Company-X’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Company-X’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
@@ -962,7 +1041,7 @@
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">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsam:Addressing>…</wsam:Addressing>
</Policy>
@@ -1000,7 +1079,7 @@
combination of these two policies is equivalent to Company-X’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
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><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
<All>
<Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
@@ -1030,13 +1109,13 @@
and treats unknown children of the <code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
elements as policy assertions. The child elements of <code>wsp:PolicyReference</code> are ignored.
</p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p></div><div class="div3">
-<h4><a name="d4e1409" id="d4e1409"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
+<h4><a name="d4e1492" id="d4e1492"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
continue the use of older policy alternatives in a backward compatible manner. This
versioning practice allows service providers, like Company-X, to deploy new behaviors using additional (or new) policy
assertions without breaking compatibility with clients that rely on any older policy
alternatives. We use examples below to illustrate how versioning might be done.</p><p>The example below represents a Company-X 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>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsam:Addressing>…</wsam:Addressing>
@@ -1052,7 +1131,7 @@
may continue to interact with Company-X’s 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>Company-X’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Company-X’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsam:Addressing>…</wsam:Addressing>
@@ -1091,7 +1170,7 @@
</p><p>
Company-X could specify that one policy alternative will expire at a certain point in time using the hypothetical ignorable Company-X expiry assertion. The example below shows how Company-X can create a new version 2 policy expression with a second hypothetical ignorable EndOfLife Assertion with a different date and time.
</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
@@ -1169,15 +1248,18 @@
necessary information to obtain this security token for Web service developers. This is a
key piece of metadata for a successful interaction with Company-X’s Web services.</p></div></div><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%"> </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
+
+
+ <span class="diff-del"><span>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
+
+
+
+ </span></span>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 are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and any element</p></li><li><p>ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div2">
<h3><a name="versioning-policy-framework" id="versioning-policy-framework"></a>4.1 Policy Framework</h3><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
- ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
- After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter">
+ ExactlyOne or All will be treated as an assertion. The default value for <span class="diff-add"><span>wsp:Optional is "false".</span></span><span class="diff-del"><span>wsp:Optional="false".
+ </span></span>After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 4-1. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
@@ -1322,7 +1404,7 @@
</td><td colspan="1" rowspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsam</code>
</td><td colspan="1" rowspan="1">
- <code>http://www.w3.org/2007/05/addressing/metadata</code>
+ <code><span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/</span></span></code>
</td><td colspan="1" rowspan="1">[<cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsdl</code>
</td><td colspan="1" rowspan="1">
@@ -1373,12 +1455,12 @@
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WS-AddressingMetadata"></a>[WS-Addressing Metadata] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 31 July 2007. This is a work in progress. This version of
- the Web Services Addressing 1.0 - Metadata is
- http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/. The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
- Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. </dd><dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
+ - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><span class="diff-chg"><a name="WS-AddressingMetadata"></a>WS-Addressing Metadata</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This <span class="diff-del"><span>is a work in progress. This </span></span>version of
+ the Web Services Addressing 1.0 - Metadata <span class="diff-add"><span>W3C Recommendation </span></span>is
+ <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
+ Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. (See http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/.)</div></dd><dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
<cite><a href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic Transaction</a></cite>, L. P. Cabrera, et al, Authors.
Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
International Business Machines Corporation, and Microsoft Corporation,
@@ -1393,16 +1475,16 @@
<cite><a href="http://schemas.xmlsoap.org/ws/2004/09/mex/">Web Services Metadata Exchange (WS-MetadataExchange)</a></cite>, K. Ballinger,
et al, Authors. BEA Systems Inc., Computer Associates International, Inc., International
Business Machines Corporation, Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and
- webMethods, August 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/mex/ </dd><dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-policy-20070706/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/2007/PR-ws-policy-20070706/. The <a href="http://www.w3.org/TR/ws-policy/">latest version of
- Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. </dd><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/. The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
+ webMethods, August 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/mex/ </dd><dt class="label"><span class="diff-chg"><a name="WS-Policy"></a>Web Services Policy Framework</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-policy-20070904/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This version of the
+ Web Services Policy 1.5 - Framework specification is at <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-policy-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-policy/">latest version of
+ Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. (See http://www.w3.org/TR/2007/REC-ws-policy-20070904/.)</div></dd><dt class="label"><span class="diff-chg"><a name="WS-PolicyAttachment"></a>Web Services Policy Attachment</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This version of the
+ Web Services Policy 1.5 - Attachment specification is at <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
- http://www.w3.org/TR/ws-policy-attach/. </dd><dt class="label"><a name="WS-RM-Policy"></a>[Web Services Reliable Messaging Policy Assertion] </dt><dd>
+ http://www.w3.org/TR/ws-policy-attach/. (See http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/.)</div></dd><dt class="label"><a name="WS-RM-Policy"></a>[Web Services Reliable Messaging Policy Assertion] </dt><dd>
<cite><a href="http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf">Web Services Reliable Messaging Policy Assertion
(WS-RM Policy) Version 1.1</a></cite>, D. David, A. Kamarkar, G. Pilz, and
Ü. Yalçinalp, Editors.
@@ -1457,7 +1539,7 @@
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).
</p><p>
Previous members of the Working Group were:
Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.
@@ -1466,8 +1548,7 @@
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 major editorial changes since the Working Draft dated 05 June, 2007 is below:</p><ul><li><p>Updated references - [<cite><a href="#C14N11">C14N11</a></cite>], [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] and
- [<cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>].</p></li></ul></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 <span class="diff-del"><span>major </span></span>editorial changes since the Working Draft dated <span class="diff-chg"><span>10 August, </span></span>2007 is below:</p><ul><li><p><span class="diff-chg"><span>Added another </span></span><span class="diff-add"><span>example to </span></span><span class="diff-add"><a href="#compatible-policies"><b>3.4 Compatible Policies</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>Dropped the editorial note in </span></span><a href="#versioning-policy-language"><b>4. Versioning Policy Language</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>Updated</span></span><span class="diff-del"><span>- </span></span><span class="diff-add"><span>references: </span>/span>[<span class="diff-chg"><cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite></span>], [<span class="diff-chg"><cite><a href="#WS-Policy">Web Services Policy Framework</a></cite></span>] and [<span class="diff-chg"><cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite></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>
@@ -1622,4 +1703,14 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857">4857</a>. Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</a>.
</td></tr><tr><td colspan="1" rowspan="1">20070727</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated Section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
- </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070912</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=5036"><span class="diff-add"><span>5036</span></span></a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355"><span class="diff-add"><span>355</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">20070912</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">FJH</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=4943"><span class="diff-add"><span>4943</span></span></a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354"><span class="diff-add"><span>354</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">20070919</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 Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355"><span class="diff-add"><span>362</span></span></a> to drop the ed-note.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070921</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 references [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>].
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070921</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>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-primer-diff20070810.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20070810.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-primer-diff20070810.xml 22 Aug 2007 05:24:55 -0000 1.2
+++ ws-policy-primer-diff20070810.xml 22 Sep 2007 02:01:01 -0000 1.3
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?><!-- $Id$ -->
<!DOCTYPE spec
PUBLIC "-//W3C//DTD Specification V2.10//EN" "xmlspec.dtd">
-<spec role="editors-copy" w3c-doctype="wd"><header>Web Services Policy 1.5 - Primer<w3c-designation>ws-policy-primer.html</w3c-designation><w3c-doctype>Editors' copy $Date$</w3c-doctype><pubdate><day>@@</day><month>@@@@</month><year>@@@@</year></pubdate><publoc>
+<spec role="editors-copy" w3c-doctype="wd"><header><title>Web Services Policy 1.5 - Primer</title><w3c-designation>ws-policy-primer.html</w3c-designation><w3c-doctype>Editors' copy $Date$</w3c-doctype><pubdate><day>@@</day><month>@@@@</month><year>@@@@</year></pubdate><publoc>
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="ws-policy-primer.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">ws-policy-primer.html</loc>
</publoc><prevlocs>
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/WD-ws-policy-primer-20070605" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">http://www.w3.org/TR/2007/WD-ws-policy-primer-20070605</loc>
- </prevlocs><latestloc><loc xmlns:xlink="http://www.w3.org/1999/xlink" 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">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</loc></latestloc><authlist><author role="editor"><name>Asir S Vedamuthu</name><affiliation>Microsoft Corporation</affiliation></author><author role="editor"><name>David Orchard</name><affiliation>BEA Systems, Inc.</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="edtor"><name>Ümit Yalçinalp</name><affiliation>SAP AG.</affiliation></author></authlist><abstract><p>
+ </prevlocs><latestloc><loc xmlns:xlink="http://www.w3.org/1999/xlink" 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">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</loc></latestloc><authlist><author role="editor"><name>Asir S Vedamuthu</name><affiliation>Microsoft Corporation</affiliation></author><author role="editor"><name>David Orchard</name><affiliation>BEA Systems, Inc.</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><phrase diff="chg">webMethods </phrase><phrase diff="add">(A subsidiary of Software AG)</phrase><phrase diff="del">Inc.</phrase></affiliation></author><author ole="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>
<emph>Web Services Policy 1.5 - Primer</emph> is an introductory description of the Web Services Policy
language. This document describes the policy language features using numerous examples. The
associated Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment specifications provide the
@@ -60,8 +60,8 @@
determine the compatibility of policies, to name and reference policies and to associate
policies with Web service metadata constructs such as service, endpoint and operation. Web
Services Policy is a simple language that has four elements - <code>Policy, All</code>,
- <code>ExactlyOne</code> and <code>PolicyReference</code> - and one attribute -
- <code>wsp:Optional</code>.</p></div2><div2 id="simple-message"><head>Simple Message</head><p>Let us start by considering a SOAP Message in the example below.</p><example><head>SOAP Message</head><eg xml:space="preserve"><soap:Envelope>
+ <code>ExactlyOne</code> and <code>PolicyReference</code> - and <phrase diff="chg">two attributes </phrase>-
+ <code>wsp:Optional</code> <phrase diff="add">and </phrase><code diff="add"><phrase diff="add">wsp:Ignorable</phrase></code>.</p></div2><div2 id="simple-message"><head>Simple Message</head><p>Let us start by considering a SOAP Message in the example below.</p><example><head>SOAP Message</head><eg xml:space="preserve"><soap:Envelope>
<soap:Header>
<wsa:To>http://x.example.com/realquote</wsa:To>
<wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
@@ -96,7 +96,7 @@
</Policy></eg></example><p>
The policy expression in the above example consists of a Policy main
element and a child element wsam:Addressing. Child elements of
- the Policy element are policy assertions. Company-X attaches the above
+ the Policy element <phrase diff="add">that are not from the Policy namespace </phrase>are policy assertions. Company-X attaches the above
policy expression to a WSDL binding description.
</p><example><head>Policy Expression Attached to Binding</head><eg xml:space="preserve"><wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" >
<Policy>
@@ -274,8 +274,8 @@
Therefore ignorable assertions may have an effect on determining compatibility of provider and consumer policies.
</p></div2><div2 id="Both-Optional-Ignorable"><head>Marking Assertions both Optional and Ignorable</head><p>As described in the sections above and in Section <specref ref="strict-lax-policy-intersection"/>,
the WS-Policy 1.5 specification defines two
- attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both "optional"
- and "Ignorable" attributes simultaneously. The presence of "@wsp:optional=true" on an assertion
+ attributes that can be used to mark an assertion: wsp:Optional and wsp:Ignorable.</p><p>The WS-Policy Framework allows a policy assertion to be marked with both <phrase diff="chg">"Optional"
+ </phrase>and "Ignorable" attributes simultaneously. The presence of "@wsp:optional=true" on an assertion
is a syntactic compact form for two alternatives in normal form, one with the assertion
and the other without the assertion. Hence syntactically marking an assertion "A" with both the
@wsp:Optional and @wsp:Ignorable with the value of "true" for both, is equivalent to
@@ -364,7 +364,7 @@
inline the policy expression.
</p><p>A policy expression may be identified by an IRI and referenced for re-use as a standalone
policy or within another policy expression. There are three mechanisms to identify a policy
- expression: the <code>wsu:Id</code> <code>xml:id</code> and <code>Name</code> attributes. A
+ expression: the <code>wsu:Id</code><phrase diff="add">, </phrase><code>xml:id</code> and <code>Name</code> attributes. A
<code>PolicyReference</code> element can be used to reference a policy expression
identified using either of these mechanisms.</p><example><head>Common Policy Expression</head><eg xml:space="preserve"><Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
@@ -417,12 +417,12 @@
assertions from different domains are used in a policy expression,
complex expressions will emerge. Naming parts of complex expressions for
reuse and building more complex policies through referencing enables
- building more complicated policy scenerios easily. This approach enables
+ building more complicated policy <phrase diff="chg">scenarios </phrase>easily. This approach enables
the association of additional policy subjects to identified policy
expressions. It also promotes manageability of the expressions as they
- are uniquely identified and allows profiles for common scenerios to be
+ are uniquely identified and allows profiles for common <phrase diff="chg">scenarios </phrase>to be
developed. Note that when a named expression has assertions that
- contains parametrized expressions, care must be given to ensure that the
+ contains <phrase diff="chg">parameterized </phrase>expressions, care must be given to ensure that the
parameterized content is statically available to enable reuse.</p></div2><div2 id="attaching-policy-expressions-to-wsdl"><head>Attaching Policy Expressions to WSDL</head><p>A majority of Company-X’s customers use WSDL for building their client applications.
Company-X leverages this usage by attaching policy expressions to the WSDL binding
descriptions.</p><p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
@@ -472,7 +472,7 @@
of varying behaviors across Web service endpoints is absorbed by a policy-aware client or
tool and hidden from these Web service developers.</p></div2><div2 id="policy-automates-web-services-interaction"><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 Company-X,
+ <phrase diff="chg">two attributes </phrase>- <code>wsp:Optional</code> <phrase diff="add">and </phrase><code diff="add"><phrase diff="add">wsp:Ignorable</phrase></code>. In practice, service providers, like Company-X,
use policy expressions to represent combinations of capabilities and requirements. Web
service developers use policy-aware clients that understand policy expressions
and engage the behaviors represented by providers automatically. A sizable amount of
@@ -561,8 +561,8 @@
policy expression in the normal form. As you can see, the compact form is less verbose
than the normal form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy alternative. There are
- four policy alternatives in the normal form. These alternatives map to bullets (a) through
- (d) above.</p><example><head>Company-X’s Policy Expression in Normal Form</head><eg xml:space="preserve"><Policy>
+ four policy alternatives in the normal form. These alternatives map to <phrase diff="add">list items</phrase><phrase diff="del">bullets </phrase><phrase diff="chg">(1) </phrase>through
+ <phrase diff="chg">(4) </phrase>above.</p><example><head>Company-X’s Policy Expression in Normal Form</head><eg xml:space="preserve"><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
<wsam:Addressing>…</wsam:Addressing>
@@ -594,7 +594,7 @@
retrieve referenced policy expressions.</p></div2><div2 id="policy-data-model"><head>Policy Data Model</head><p>In the previous section, we considered the normal form for policy expressions. As we
discussed, the normal form represents a policy as a collection of policy alternatives. In
this section, let us look at the policy data model.</p><p>Company-X uses a policy to convey the conditions for an interaction. Policy-aware clients,
- like the one used by the developer in our example (as explained earlier in <specref ref="basic-concepts-policy-expression"/>), view policy as an unordered collection of
+ like the one used by the developer in our example (as explained earlier in <specref ref="basic-concepts-policy-expression"/>), view <phrase diff="add">a </phrase>policy as an unordered collection of
zero or more policy alternatives. A policy alternative is an unordered collection of zero
or more policy assertions. A policy alternative represents a collection of behaviors or
requirements or conditions for an interaction. In simple words, each policy alternative
@@ -674,7 +674,7 @@
QName, <code>sp:TransportBinding</code>. For this discussion, let us assume that these two
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
+ compatible with a policy assertion in the other and vice-versa. For <phrase diff="add">instance in Examples 3.6 and</phrase><phrase diff="del">example, </phrase><phrase diff="add">3.7, </phrase>policy
assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
assertions (t2) and (t1) in the client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
@@ -684,8 +684,53 @@
of Company-X’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 Company-X’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
- supplier endpoints to be compatible with an agreed upon policy.</p><div3 id="strict-lax-policy-intersection"><head>Strict and Lax Policy Intersection</head><p>
- The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the
+ supplier endpoints to be compatible with an agreed upon policy.</p><p diff="add"><phrase diff="add">Consider a similar scenario between Company X and the client where nested policy expressions exist in the policy alternatives.
+ The nested policy expressions are compared for compatibility in the context of
+ their parent policy assertions during policy intersection. For example, take these two incompatible policies in Examples 3.8 and 3.9:
+ </phrase></p><example diff="add"><head><phrase diff="add">Company X Nested incompatible policy example</phrase></head><eg xml:space="preserve">Company X
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:EndorsingSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion a -->
+(P006) <wsp:Policy> <!-- nested policy a1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:EndorsingSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy></eg></example><example diff="add"><head><phrase diff="add">Client Nested incompatible policy example</phrase></head><eg xml:space="preserve">Client
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:SignedSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion b -->
+(P006) <wsp:Policy> <!-- nested policy b1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:SignedSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy>
+ </eg></example><p diff="add"><phrase diff="add">In this scenario as illustrated in Examples 3.8 and 3.9, the EndorsingSupportingTokens and
+ SignedSupportingTokens
+ assertions
+ are incompatible even though their nested policy expressions are compatible.
+ This is because the parent policy
+ assertions EndorsingSupportingTokens and SignedSupportingTokens have different
+ QNames.
+ </phrase></p><div3 id="strict-lax-policy-intersection"><head>Strict and Lax Policy Intersection</head><p>
+ The previous sections outlined how the normal-form of a policy expression <phrase diff="chg">relates </phrase>to the policy data model and how the
compatibility of requester and provider policies may be determined.
This section outlines how ignorable assertions may impact the process of determining compatibility.
</p><p>
@@ -983,14 +1028,17 @@
by a third party. Service providers, like Company-X, 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 Company-X’s Web services.</p></div2></div1><div1 id="versioning-policy-language"><head>Versioning Policy Language</head><p>
- <ednote><edtext>
- 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
- </edtext></ednote>
- </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
+
+
+ <phrase diff="del">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
+
+
+
+ </phrase>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 are:</p><olist><item><p>Policy: element from ##other namespace and any attribute</p></item><item><p>PolicyReference: any attribute and any element</p></item><item><p>ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></item><item><p>PolicyAttachment: element from ##other namespace and any attribute</p></item><item><p>AppliesTo: any element and any attribute</p></item></olist><div2 id="versioning-policy-framework"><head>Policy Framework</head><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
- ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
- After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><example><head>Policy containing 1.5 and 1.6 Policies.</head><eg xml:space="preserve"><wsp:Policy>
+ ExactlyOne or All will be treated as an assertion. The default value for <phrase diff="add">wsp:Optional is "false".</phrase><phrase diff="del">wsp:Optional="false".
+ </phrase>After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><example><head>Policy containing 1.5 and 1.6 Policies.</head><eg xml:space="preserve"><wsp:Policy>
<wsp:ExactlyOne>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
...
@@ -1121,7 +1169,7 @@
</td><td colspan="1" rowspan="1">[<bibref ref="WS-Addressing"/>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsam</code>
</td><td colspan="1" rowspan="1">
- <code>http://www.w3.org/2007/05/addressing/metadata</code>
+ <code><phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/</phrase></code>
</td><td colspan="1" rowspan="1">[<bibref ref="WS-AddressingMetadata"/>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsdl</code>
</td><td colspan="1" rowspan="1">
@@ -1171,11 +1219,11 @@
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <loc href="http://www.w3.org/TR/ws-addr-core/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0
- - Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/" id="WS-AddressingMetadata" key="WS-Addressing Metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ - Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/" id="WS-AddressingMetadata" key="WS-Addressing Metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Addressing 1.0 - Metadata</titleref>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 31 July 2007. This is a work in progress. This version of
- the Web Services Addressing 1.0 - Metadata is
- http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/. The <loc href="http://www.w3.org/TR/ws-addr-metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0 -
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This <phrase diff="del">is a work in progress. This </phrase>version of
+ the Web Services Addressing 1.0 - Metadata <phrase diff="add">W3C Recommendation </phrase>is
+ <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-addr-metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0 -
Metadata</loc> is available at http://www.w3.org/TR/ws-addr-metadata. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://schemas.xmlsoap.org/ws/2004/10/wsat/" id="WS-Atomic" key="Web Services Atomic Transaction" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Atomic Transaction</titleref>, L. P. Cabrera, et al, Authors.
Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
@@ -1191,14 +1239,14 @@
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Metadata Exchange (WS-MetadataExchange)</titleref>, K. Ballinger,
et al, Authors. BEA Systems Inc., Computer Associates International, Inc., International
Business Machines Corporation, Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and
- webMethods, August 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/mex/ </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-policy-20070706/" id="WS-Policy" key="Web Services Policy Framework" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ webMethods, August 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/mex/ </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-policy-20070904/" id="WS-Policy" key="Web Services Policy Framework" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Policy 1.5 - Framework</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/2007/PR-ws-policy-20070706/. The <loc href="http://www.w3.org/TR/ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
- Web Services Policy 1.5 - Framework</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/" id="WS-PolicyAttachment" key="Web Services Policy Attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This version of the
+ Web Services Policy 1.5 - Framework specification is at <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-policy-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
+ Web Services Policy 1.5 - Framework</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/" id="WS-PolicyAttachment" key="Web Services Policy Attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Policy 1.5 - Attachment</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/. The <loc href="http://www.w3.org/TR/ws-policy-attach/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This version of the
+ Web Services Policy 1.5 - Attachment specification is at <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-policy-attach/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
Web Services Policy 1.5 - Attachment</loc> is available at
http://www.w3.org/TR/ws-policy-attach/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf" id="WS-RM-Policy" key="Web Services Reliable Messaging Policy Assertion" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Reliable Messaging Policy Assertion
@@ -1254,7 +1302,7 @@
Working Group</loc>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).
</p><p>
Previous members of the Working Group were:
Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.
@@ -1262,8 +1310,7 @@
The people who have contributed to <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">discussions
on public-ws-policy@w3.org</loc> are also gratefully
acknowledged.
- </p></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 05 June, 2007 is below:</p><ulist><item><p>Updated references - [<bibref ref="C14N11"/>], [<bibref ref="WS-RM-Policy"/>] and
- [<bibref ref="WS-AddressingMetadata"/>].</p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Primer Change Log</head><table border="1" id="ws-policy-primer-changelog-table"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><!-- template
+ </p></inform-div1><inform-div1 id="change-description"><head>Changes in this Version of the Document</head><p>A list of <phrase diff="del">major </phrase>editorial changes since the Working Draft dated <phrase diff="chg">10 August, </phrase>2007 is below:</p><ulist><item><p><phrase diff="chg">Added another </phrase><phrase diff="add">example to </phrase><specref diff="add" ref="compatible-policies"/><phrase diff="add">.</phrase></p></item><item diff="add"><p><phrase diff="add">Dropped the editorial note in </phrase><specref ref="versioning-policy-language"/><phrase diff="add">.</phrase></p></item><item diff="add"><p><phrase diff="add">Updated</phrase><phrase diff="del">- </phrase><phrase diff="add">references: </phrase>[<bibref diff="chg" ref="WS-AddressingMetadata"/>], [<bibref diff="chg" ref="WS-Policy"/>] and [<bibref diff="chg" ref="WS-PolicyAttachment"/>].</p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Primer Change Log</head><table border="1" id="ws-polcy-primer-changelog-table"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><!-- template
<tr>
<td>200505</td>
<td></td>
@@ -1423,4 +1470,14 @@
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">4857</loc>. Editors' action
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">350</loc>.
</td></tr><tr><td colspan="1" rowspan="1">20070727</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated Section <specref ref="change-description"/>.
- </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
+ </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070912</td><td colspan="1" diff="add" rowspan="1">PY</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5036" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">5036</phrase></loc>. Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">355</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070912</td><td colspan="1" diff="add" rowspan="1">FJH</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4943" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">4943</phrase></loc>. Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">354</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070919</td><td colspan="1" diff="add" rowspan="1">PY</td><td colspan="1" diff="add" rowspan="1">Implemented the Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">362</phrase></loc> to drop the ed-note.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070921</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Updated references [<bibref ref="WS-Policy"/>] and [<bibref ref="WS-PolicyAttachment"/>].
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070921</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Reset Section <specref ref="change-description"/>.
+ </td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
Index: ws-policy-guidelines-diff20070810.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070810.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20070810.html 22 Aug 2007 05:24:55 -0000 1.2
+++ ws-policy-guidelines-diff20070810.html 22 Sep 2007 02:01:01 -0000 1.3
@@ -1,6 +1,6 @@
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title> -- Review Version</title><style type="text/css">
+<html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors -- Review Version</title><style type="text/css">
/**/
code { font-family: monospace; }
@@ -55,6 +55,38 @@
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
+
+div.boxedtext {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+ }
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+ }
+
+span.practicelab { background: #dfffff; }
+
+ span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+ }
+p.practice
+{
+ margin: 1.5em 0.5em 1em 1em;
+ }
+
+@media screen {
+ p.practice, {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+}
+}
/**/
div.diff-add { background-color: #FFFF99; }
@@ -77,12 +109,12 @@
<span class="diff-chg">changed text</span>, and
<span class="diff-del">deleted text</span>. NOTE: the status section of the document has not been augmented to
identify changes from a previous version.</p><hr></div><div class="head">
-<h1><a name="title" id="title"></a></h1>
+<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>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330">http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330</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> © @@@@ <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>
+ </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, <span class="diff-chg"><span>webMethods </span></span><span class="diff-add"><span>(A subsidiary of Software AG)</span></span><span class="diff-del"><span>Inc.</span></span></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> © @@@@ <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="htp://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>
<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 [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>] specifications to create domain
@@ -113,13 +145,14 @@
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
- 5.5.1 <a href="#d4e807">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d4e820">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d4e857">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d4e873">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d4e835">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d4e888">Optional behavior at runtime</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
5.7.1 <a href="#general-attachment-guidelines">General Guidelines</a><br>
5.7.2 <a href="#wsdl-attachment-guidelines">Considerations for Policy Attachment in WSDL</a><br>
+ 5.7.3 <a href="#UDDI-attachment-guidelines">ConsiderationsDescribe for Policy Attachment in UDDI</a><br>
5.8 <a href="#interrelated-domains">Interrelated domains</a><br>
6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
6.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
@@ -134,7 +167,7 @@
F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>The WS-Policy specification defines a policy to be a collection
- of policy alternatives. Each policy alternative a
+ of policy alternatives. Each policy alternative <span class="diff-add"><span>is </span></span>a
collection of policy assertions. The Web Services Policy 1.5 - Framework provides a flexible framework to
represent
consistent combinations of behaviors from a variety of domains.
@@ -181,10 +214,11 @@
</p></div><div class="div1">
<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practice Statements</h2><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-semantics"><b>1. Semantics Independent of
Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
-Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>21. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Identiy Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26. Define Rules for Attachment of an Assertion
- type to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Independent Assertions for Different Versions of a
- Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Document changes to policy
+Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Assertion Authors should allowAllow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-reusableAssertions"><b>21. Reusable Assertions</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>22. Describe Semantics of Multiple Assertions of Same TypeMechanisms</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms">b>23. Leverage Defined Attachmentencouraged Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>24. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>25. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>27. Consider Scope of Attachment Points</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>28. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>29. Define Rules for Attachment of an Assertion
+ type to Multiple WSDL policy subjectsSubjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>30. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-UDDI-tmodels"><b>31. Use defined tModels any)
+ when appropriate</b></a></p></li><li><p><a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>33. Independent Assertions for Different Versions of a
+ Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>34. Document changes to policy
subject</b></a></p></li></ul></div><div class="div1">
<h2><a name="Assertions" id="Assertions"></a>3. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
@@ -303,7 +337,7 @@
policy. This selected alternative is then used to govern the creation of a message
to send to the subject to which the policy alternative was
attached. The WS-Policy Attachment specification defines a
- set of attachment models for use with common web service
+ set of attachment <span class="diff-chg"><span>mechanisms </span></span>for use with common web service
subjects: WSDL definitions [<cite><a href="#WSDL11">WSDL 1.1</a></cite>, <cite><a href="#WSDL20">WSDL 2.0 Core Language</a></cite>], and UDDI directory entries [<cite><a href="#UDDIAPI20">UDDI API 2.0</a></cite>, <cite><a href="#UDDIDataStructure20">UDDI Data Structure 2.0</a></cite>,
<cite><a href="#UDDI30">UDDI 3.0</a></cite>].
</p><p>
@@ -354,7 +388,7 @@
</p><p>
Assertion Authors need to have a specific goal in mind for the assertions
that they author. Assertion specifications should include a detailed specification
- of the assertion’s semantics and, a set of valid policy subjects to which the assertion
+ of the assertion’s semantics <span class="diff-chg"><span>and </span></span>a set of valid policy subjects to which the assertion
maybe attached. The specification should also include the scope of the assertion
in the context of a particular policy subject. For example, an assertion with
Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
@@ -371,10 +405,10 @@
<ul><li><p>The definition of the assertion's semantic
(See best practice <a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a>).</p></li><li><p>The specification of the set of valid policy subjects to which an
assertion may be attached
- (See best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
+ (See best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
subject (See best practices in Section <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment</b></a>).</p></li><li><p>Any composition considerations if the assertion is used with
other assertions in a context
- (See best practice <a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a>).</p></li></ul>
+ (See best practice <a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a>).</p></li></ul>
</p><p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
@@ -386,7 +420,7 @@
assertion may be constrained to a specific set of policy subjects by
Assertion Authors, its semantics should not be dependent upon the
mechanism by which the policy expression is attached to a given policy
- subject. For instance, an assertion "Foo" has the same semantic when
+ subject. For instance, an assertion "Foo" has the same <span class="diff-chg"><span>semantics </span></span>when
attached to an operation policy subject regardless of whether it was
attached using XML element policy attachment or the external URI
attachment mechanism. Independence from a specific attachment mechanism
@@ -505,10 +539,10 @@
and capabilities at runtime.
</p><div class="div3">
<h4><a name="minimal-approach" id="minimal-approach"></a>5.3.1 Minimal approach</h4><p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
- behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
+ behavior. Sets of assertions can by grouped by an operator <span class="diff-chg"><span>"All". </span></span>This indicates that there is a relationship between
the assertions.
</p><p>If grouping is utilized, choices between such groupings can be indicated by
- an "exactly one" operator. This basic set of operators allows
+ an <span class="diff-chg"><span>"ExactlyOne" </span></span><span class="diff-del"><span>one" </span></span>operator. This basic set of operators allows
Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.
</p><p>It requires a good deal of effort to evaluate the
capabilities of a domain and capture them in a way that
@@ -592,11 +626,11 @@
</pre></div></div><p> The Policy Framework provides two modes of authoring policy expressions:
compact and normal form. One of the mechanisms that the Policy Framework
provides to policy authors for purposes of writing compact policy
-expressions is the wsp:Optional attribute. Assertion Authors should allow
-for the use of the wsp:Optional attribute in the XML outline and/or schema
+ expressions is the <span class="diff-add"><code>wsp:Optional</code></span> attribute. Assertion Authors should allow
+for the use of the <span class="diff-add"><code>wsp:Optional</code></span> attribute in the XML outline and/or schema
definition of an assertion as this will allow policy expression authors to
compose compact policy expressions.</p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
-Practice 11: Allow use of wsp:Optional</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use
+Practice 11: Assertion Authors should allowAllow use of wsp:Optional</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use
of the wsp:Optional attribute so as to enable policy authors to compose
compact policy expressions.</p></div><p>For example, consider the following two equivalent policy expressions:</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 5-6. </span>Normal form expression:</i></p><div class="exampleInner"><pre><wsp:Policy>
@@ -615,7 +649,11 @@
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy></pre></div></div><p>
-If the assertion author had not provided for the wsp:Optional attribute to be included on the assertion, then policy expression authors would be forced to express the optionality of a behavior as two explicit policy alternatives, one with and one without that assertion when including assertions of that type in their policies.</p></div><div class="div3">
+If the assertion author had not provided for the <span class="diff-add"><code>wsp:Optional</code></span> attribute
+to be included on the assertion, then policy expression authors would be forced to
+express the optionality of a behavior as two explicit policy alternatives,
+one with and one without that assertion when including assertions of that type in their
+policies.</p></div><div class="div3">
<h4><a name="self-describing" id="self-describing"></a>5.3.3 Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities 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
@@ -835,16 +873,18 @@
certificate will not be able to use this provider solely on the basis
of intersection algorithm alone.</p></div></div><div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
-<h4><a name="d4e807" id="d4e807"></a>5.5.1 Ignorable behavior in authoring</h4><p>
- The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
+<h4><a name="d4e857" id="d4e857"></a>5.5.1 Ignorable behavior in authoring</h4><p>
+ The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the <span class="diff-chg"><span>compatibility </span></span>assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
-<h4><a name="d4e820" id="d4e820"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d4e873" id="d4e873"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
indicate the semantic of the runtime behavior in the description of the assertion.
</p><p>
As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d4e835" id="d4e835"></a>5.6.1 Optional behavior at runtime</h4><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><p>Since optional behaviors indicate optionality for
+<h4><a name="d4e888" id="d4e888"></a>5.6.1 Optional behavior at runtime</h4><div class="diff-del"><p class="diff-del">This section does not have Working Group consensus and there is an outstanding action item to revise it
+
+ </p></div><p>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since this would allow the
@@ -930,34 +970,57 @@
communicate the policy assertions should not affect or imply additional
semantics in 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.
- </p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
-Practice 21: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+ unknown) attachment mechanisms in mind. <span class="diff-add"><span>Since multiple attachment mechanisms
+ may be used, a policy alternative created during the process of calculating
+ an effective policy can contain multiple instances of the same policy
+ assertion type ( i.e., the SignedParts assertion). It is therefore also
+ important for the policy authors to define what it means if multiple
+ assertions are present.
+ </span></span></p><div class="diff-add"><div class="boxedtext"><p><a name="bp-reusableAssertions" id="bp-reusableAssertions"></a><span class="practicelab">Best
+Practice 21: Reusable Assertions</span></p><p class="practice">
+ Assertion Authors are encouraged to create policy assertions that
+ can be used regardless of attachment mechanism.</p></div></div><div class="diff-add"><p class="diff-add"><span class="diff-add"><span>For example, a security policy expression can be assigned a key reference and
+ be attached to a UDDI binding or can be embedded in a WSDL document. </span></span></p></div><div class="diff-chg"><div class="boxedtext"><p><a name="bp-semantics-multiple-same-type" id="bp-semantics-multiple-same-type"></a><span class="practicelab">Best
+Practice 22: Describe Semantics of Multiple Assertions of Same TypeMechanisms</span></p><p class="practice">
+ Assertion Authors should specify the semantics of multiple instanceswhen
+ of the same policyextend assertion type in the same policy alternativedeployment and the
+ semantics of parameters and nestedtheir policy (if any) when there are
+ multiple instances of a policy assertion type in the same policyensure
+ alternative regardless of the mechanism used to attach them to
+ a policy subject.that If there are multiple instances of a policy
+ assertionby type in the same policy alternative without parameterstheir
+ and nested policies, these have the same meaning as a single
+ assertion of the type within the policy alternative.assertions.</p></div></div><p> Assertion authors <span class="diff-chg"><span>should review </span></span><span class="diff-add"><span>sections 3.2 and 4.5 of the Policy Framework
+ </span></span><span class="diff-add"><cite><a href="#WS-Policy">Web Services Policy Framework</a></cite></span> <span class="diff-add"><span>for more detail
+ on the processing for multiple assertions of the same type.</span></span></p><div class="diff-add"><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
+Practice 23: Leverage Defined Attachmentencouraged Mechanisms</span></p><p class="practice">
Assertion Authors should leverage defined attachment models when
- possible to extend the deployment of their policy assertions and ensure
- that there are no additional semantics implied by their
- assertions.</p></div><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
- specification when possible. </p><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
-Practice 22: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
- Authors should leverage defined policy subjects when possible to
+ possible to document the use of the policy assertions they author and ensure
+ that there are no additional semantics impliedby the defined
+ attachmentpolicy modelsattachments
+ specification for their assertions.</p></div></div><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
+Practice 24: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+ Assertion Authors should leverage defined policy subjects when possible to
facilitate the deployment of their policy assertions. Common Policy
subjects have been defined and used by other policy assertion authors
and new policy assertions that leverage these existing subjects will be
- easier to define and group. </p></div><p>
+ easier to define and group. </p></div><div class="diff-add"><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
+Practice 25: Identify Policy Subjects</span></p><p class="practice">
+
Policy assertion authors
should unambiguously identify the appropriate policy subjects for their
assertions. If the best practices are followed, and the assertions are
scoped according to their subject, then multiple policy domains may be
combined without conflict. Each domain should define any limitations at
- the policy subject level that might impact interoperability.
- </p><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
-Practice 23: Identify Policy Subjects</span></p><p class="practice">
- Assertion
- Authors should review the policy subjects defined in
- WS-PolicyAttachments and identify existing policy subjects when possible
- to facilitate the deployment of their policy assertions and include this
- information in the definition of the assertions.</p></div><p>
- An example of this is
+ the policy subject level that might impact interoperability.</p></div></div><div class="diff-add"><p class="diff-add">
+
+ <span class="diff-del"><span>Identify Policy Subjects
+ </span></span>Assertion Authors should review the policy subjects defined in
+ WS-PolicyAttachments
+ and identify <span class="diff-add"><span>which of the </span></span>existing policy subjects <span class="diff-chg"><span>can be used </span></span><span class="diff-add"><span>with the assertions
+ they define. That identification will </span></span>facilitate the deployment of their policy
+ assertions and include <span class="diff-chg"><span>such </span></span>information in the <span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>definition of the assertions. </span></span><span class="diff-add"><span>definition.
+ </span></span></p></div><p> An example of this <span class="diff-add"><span>practice </span></span>is
the Reliable Messaging Policy Assertion document [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
STR assertion defines the requirement that an RM Sequence MUST be bound
@@ -968,7 +1031,7 @@
assertion". This is illustrative of how the domain assertion author can
specify additional constraints and assumptions for attachment and
engagement of behavior in addition to the capabilities specified in
- WS-PolicyAttachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]. Such
+ <span class="diff-add"><span>Web Services Policy 1.5 - Attachment</span></span><span class="diff-del"><span>WS-PolicyAttachment </span></span>[<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]. Such
additional constraints must be clearly specified by the assertion
authors.
</p></div><div class="div3">
@@ -982,60 +1045,61 @@
subject is the service policy subject. </p></li><li><p>If the behavior applies to any message exchange
made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
- the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
-Practice 24: Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which
+ the subject is the message policy subject - similarly for output and fault message <span class="diff-add"><span>WSDL </span></span>policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
+Practice 26: Specify WSDL Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant WSDL policy subjects with which
the assertion may be associated. For instance, if a policy assertion is to be used with
- WSDL, the assertion description should specify a WSDL policy subject - such as service,
- endpoint, operation and message.
- </p></div><p>Assertion Authors that wish to utilize WSDL policy subjects need to
+ WSDL, the assertion description should specify a WSDL policy subject - such as service, endpoint, operation and message it should be stated.message.
+ </p></div><p>Assertion Authors that <span class="diff-del"><span>wish to </span></span>utilize WSDL policy subjects need to
understand how the assertions will be
- processed in an intersection and merging, and the implications of
- the processing for considering a specific attachment point and
- policy subject. This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
+ processed in <span class="diff-del"><span>an </span></span>intersection and merging, and the <span class="diff-add"><span>specific </span></span>implications of
+ the processing for <span class="diff-del"><span>considering </span></span>a specific attachment point and policy subject.
+ This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
</p><p> For a given WSDL policy subject, there may be several
attachment points. For example, there are three attachment
points for the endpoint policy subject: the port, binding and
portType element. Assertion Authors should identify the
- relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, Assertion Authors should
- consider the scope of the attachment point. For example, an
- assertion should only be allowed in the portType element if
+ relevant attachment point when defining a new assertion.
+ </p><div class="diff-add"><div class="boxedtext"><p><a name="bp-WSDL-consider-scope" id="bp-WSDL-consider-scope"></a><span class="practicelab">Best
+Practice 27: Consider Scope of Attachment Points</span></p><p class="practice">To determine the relevant attachment points, Assertion Authors should
+ consider the scope of the attachment point.
+ </p></div></div><div class="diff-add"><p class="diff-add">
+ For example, an assertion should only be allowed in the portType element if
the assertion reasonably applies to any endpoint that ever
references that portType. Most of the known policy assertions
are designed for the endpoint, operation or message policy subject.
- </p><p> In using WSDL attachment, it should be noted that the
+ </p></div><p> In using WSDL attachment, it should be noted that the
service policy subject is a collection of endpoint policy
subjects. The endpoint policy subject is a collection of
- operation policy subjects and so on. As a result, the WSDL
+ operation <span class="diff-add"><span>WSDL </span></span>policy subjects and so on. As a result, the WSDL
policy subjects compose naturally. It is quite tempting to
associate the identified behavior to a broader policy subject
than to a fine granular policy subject. For instance, it is
convenient to attach a supporting token assertion (defined by
the Web Services Security Policy specification) to an endpoint
policy subject instead of a message policy subject. However such
- policy attachments to policy subjects of broader scope and granularity
+ policy attachments to <span class="diff-add"><span>WSDL </span></span>policy subjects of broader scope and granularity
should be done only after careful evaluation.
</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
-Practice 25: Choose the Most Granular Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular policy subject
+Practice 28: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
to which the behavior represented by a policy assertion applies.
</p></div><p>
For authoring convenience, Assertion Authors may allow the
- association of an assertion to multiple policy subjects within the same context of
+ association of an assertion to multiple <span class="diff-add"><span>WSDL </span></span>policy subjects within the same context of
use (e.g in the same WSDL description). If an assertion is allowed to be
- associated with multiple policy subjects as is possible with WSDL, then
+ associated with multiple <span class="diff-add"><span>WSDL </span></span>policy subjects as is possible with WSDL, then
the Assertion Authors have the burden to describe the rules
when multiple instances of the same assertion are attached to different
- policy subjects in order to avoid non-interoperable behavior.
+ <span class="diff-add"><span>WSDL </span></span>policy subjects in order to avoid non-interoperable behavior.
</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Best
-Practice 26: Define Rules for Attachment of an Assertion
- type to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy subjects,
+Practice 29: Define Rules for Attachment of an Assertion
+ type to Multiple WSDL policy subjectsSubjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple WSDL policy subjects,
the assertion author should describe the rules for multiple
- instances of the same assertion attached to multiple policy subjects in
+ instances of the same assertion attached to multiple WSDL policy subjects in
the same context.
</p></div><p>
To give one example, section 2.3 of the
Web Services Reliable Messaging Policy Assertion specification
- [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] gives rules on which Policy Subjects may be associated with the RM
+ [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] gives rules on which <span class="diff-chg"><span>WSDL </span></span><span class="diff-add"><span>policy subjects</span></span><span class="diff-del"><span>Subjects </span></span>may be associated with the RM
Policy assertion, and which WSDL 1.1 elements may have RM Policy assertions attached.
</p><p>If the capability may imply
different semantics with respect to attachment points, the
@@ -1050,18 +1114,18 @@
the WS-RM Policy is a capability that governs a target endpoint's
capability to accept message sequences that are beyond single message
exchange. Therefore, its semantics encompass the cases when
- message level policy subjects may be used as attachment but
+ message level <span class="diff-add"><span>WSDL </span></span>policy subjects may be used as attachment but
also considers the case when sequences are present. In addition,
when the policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
-Practice 27: Specify Preferred Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points
+Practice 30: Specify Preferred WSDL Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points
within a policy subject, Assertion Authors should specify a
preferred attachment point for the chosen policy subject.
</p></div><p>Assertion Authors that utilize WSDL policy subjects need to
understand how the assertions will be processed in merging and
- the specify implications of ending up with multiple assertions of
- the same kind in an alternative, in the merged policy. For example,
+ the <span class="diff-chg"><span>specific </span></span>implications of <span class="diff-chg"><span>a result where </span></span>multiple assertions of
+ the <span class="diff-add"><span>assertion type</span></span><span class="diff-del"><span>same </span></span><span class="diff-chg"><span>are </span></span>in an alternative, in the merged policy. For example,
consider the SignedParts assertion defined in WS-SecurityPolicy 1.2.
The definition of SignedParts assertion explicitly permits multiple
SignedParts assertions to be present within a policy alternative,
@@ -1073,20 +1137,35 @@
at the endpoint could have more than one SignedParts assertion in the
same alternative. However, the clear semantics defined by the SignedParts
assertion enable processing of the multiple occurrences properly.
- </p><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Best
-Practice 28: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the same
- policy assertion type. Assertion authors should specify the semantics of
- multiple instances of same policy assertion type in the same policy
- alternative and the semantics of parameters and nested policy (if any)
- when there are multiple instances of a policy assertion type in the same
- policy alternative.
- </p></div></div></div><div class="div2">
+ </p></div><div class="diff-add"><div class="div3">
+<h4><a name="UDDI-attachment-guidelines" id="UDDI-attachment-guidelines"></a>5.7.3 <span class="diff-add"><span>Considerations</span></span><span class="diff-del"><span>Describe </span></span><span class="diff-chg"><span>for Policy Attachment in </span></span><span class="diff-add"><span>UDDI</span></span></h4><p><span class="diff-add"><span>In</span></span><span class="diff-del"><span>of </span></span><span class="diff-chg"><span>general, </span></span><span class="diff-add"><span>UDDI</span></span><span class="diff-del"><span>Type
+ A </span></span><span class="diff-chg"><span>protocol messages </span></span>can <span class="diff-chg"><span>be used to save TModel, businessEntity,
+ businessService and bindingTemplate definitions with policies attached. </span></span><span class="diff-add"><span>These
+ definitions can also be </span></span>the <span class="diff-chg"><span>target </span></span>of
+ <span class="diff-del"><span>multiple </span></span><span class="diff-chg"><span>a "find" </span></span><span class="diff-add"><span>protocol message, thus allowing
+ authors to store and retrieve</span></span><span class="diff-del"><span>same </span></span>policy <span class="diff-chg"><span>assertions. There are two ways </span></span><span class="diff-add"><span>to associate
+ </span></span>policy
+ <span class="diff-del"><span>alternative </span></span><span class="diff-chg"><span>expressions with UDDI definitions: </span></span><span class="diff-add"><span>direct referece,</span></span><span class="diff-del"><span>parameters </span></span>and <span class="diff-chg"><span>registering </span></span>policy
+ <span class="diff-add"><span>as </span></span><span class="diff-chg"><span>a </span></span><span class="diff-add"><span>UDDI TModel. Assertion Authors defining new assertions should consider each
+ approach.
+ </span></span></p><div class="boxedtext"><p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class="practicelab">Best
+Practice 31: Use defined tModels any)
+ when appropriate</span></p><p class="practice">UDDIthere defines the following policy subjects: Service Provider Policy,
+ Service Policy subject and Endpoint Policy subject.
+ </p></div><p>
+ <span class="diff-add"><span>When defining assertions and recommending a service provider</span></span><span class="diff-del"><span>of </span></span><span class="diff-add"><span>policy
+ subject [uddi:BusinessEntity], or </span></span>a <span class="diff-add"><span>service </span></span>policy <span class="diff-add"><span>subject [uddi:buisnessService],
+ </span></span>assertion <span class="diff-chg"><span>authors </span></span><span class="diff-add"><span>are scoping</span></span><span class="diff-del"><span>in </span></span>the <span class="diff-add"><span>behaviors to the service</span></span><span class="diff-del"><span>same
+ </span></span><span class="diff-add"><span>provider as a whole. When defining assertions and recommending an endpoint
+ </span></span>policy <span class="diff-add"><span>subject [uddi:bindingTemplate, uddi:tModel], assertion authors</span></span><span class="diff-del"><span>alternative.
+ </span></span><span class="diff-add"><span>are scoping behaviors to a deployed endpoint.
+ </span></span></p></div></div></div><div class="div2">
<h3><a name="interrelated-domains" id="interrelated-domains"></a>5.8 Interrelated domains</h3><p>Assertion Authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. Assertion Authors should not duplicate existing
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Best
-Practice 29: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion
+Practice 32: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion
may compose with other related assertions, if any.</p></div><p> A
classic example of such an interrelated domain is security, because
security tends to
@@ -1122,14 +1201,14 @@
Section 4.2, the <code>sp:issuedToken</code> assertion utilizes the
<code>sp:RequestSecurityTokenTemplate</code> parameter that contains necessary
information to request a security token. The contents of the parameter
- are static and allows reuse in different security scenerios.</p></div><div class="div2">
+ are static and <span class="diff-chg"><span>allow </span></span>reuse in different security <span class="diff-chg"><span>scenarios.</span></span></p></div><div class="div2">
<h3><a name="extending-assertions" id="extending-assertions"></a>6.2 Evolution of Assertions (Versioning and Compatibility)</h3><p>Over time, there may be multiple equivalent behaviors emerging in the Web
Service interaction space. Examples of such multiple equivalent behaviors are WSS: SOAP Message Security 1.0
vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Best
-Practice 30: Independent Assertions for Different Versions of a
+Practice 33: Independent Assertions for Different Versions of a
Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different
versions of a behavior.</p></div><p>The
policy expression in the example below requires the use of
@@ -1143,7 +1222,7 @@
<sp:Wss11>…</sp:Wss11>
</Policy></pre></div></div></div><div class="div2">
<h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>6.3 Supporting New Policy Subjects</h3><p>
- The best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a> specifies that policy authors should
+ The best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a> specifies that policy authors should
define the set of policy subjects to which policy assertions can be
attached. Over time, new policy subjects may need to be defined. When
this occurs, policy Assertion Authors may update the list of policy
@@ -1159,7 +1238,7 @@
new policy subjects are added it is incumbent on the authors to retain the
semantic of the policy assertion.
</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
-Practice 31: Document changes to policy
+Practice 34: Document changes to policy
subject</span></p><p class="practice">If the policy subjects change over time,
the assertion description should also be versioned to reflect this
change.</p></div></div></div></div><div class="back"><div class="div1">
@@ -1180,7 +1259,7 @@
</td><td colspan="1" rowspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsam</code>
</td><td colspan="1" rowspan="1">
- <code>http://www.w3.org/2007/05/addressing/metadata</code>
+ <code><span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/</span></span></code>
</td><td colspan="1" rowspan="1">[<cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsdl</code>
</td><td colspan="1" rowspan="1">
@@ -1230,11 +1309,11 @@
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WS-AddressingMetadata"></a>[WS-Addressing Metadata] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 31 July 2007. This version of Web Services Addressing 1.0 - Metadata is
- http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/. The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
- Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. </dd><dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>
+ - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><span class="diff-chg"><a name="WS-AddressingMetadata"></a>WS-Addressing Metadata</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This version of Web Services Addressing 1.0 - Metadata <span class="diff-add"><span>W3C Recommendation </span></span>is
+ <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
+ Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. (See http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/.)</div></dd><dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</a></cite>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
http://www.w3.org/TR/2001/NOTE-wsdl-20010315. </dd><dt class="label"><a name="WSDL20"></a>[WSDL 2.0 Core Language] </dt><dd>
@@ -1242,16 +1321,16 @@
Language</a></cite>, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World
Wide Web Consortium, 26 June 2007. This version of the WSDL 2.0 specification is
http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The <a href="http://www.w3.org/TR/wsdl20/">
- latest version of WSDL 2.0</a> is available at http://www.w3.org/TR/wsdl20. </dd><dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-policy-20070706/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/2007/PR-ws-policy-20070706/. The <a href="http://www.w3.org/TR/ws-policy/">latest version of
- Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. </dd><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/. The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
+ latest version of WSDL 2.0</a> is available at http://www.w3.org/TR/wsdl20. </dd><dt class="label"><span class="diff-chg"><a name="WS-Policy"></a>Web Services Policy Framework</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-policy-20070904/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This version of the
+ Web Services Policy 1.5 - Framework specification is at <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-policy-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-policy/">latest version of
+ Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. (See http://www.w3.org/TR/2007/REC-ws-policy-20070904/.)</div></dd><dt class="label"><span class="diff-chg"><a name="WS-PolicyAttachment"></a>Web Services Policy Attachment</span></dt><dd><div class="diff-chg">
+ <cite><a href="http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <span class="diff-chg"><span>4 September </span></span>2007. This version of the
+ Web Services Policy 1.5 - Attachment specification is at <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. </span></span>The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
- http://www.w3.org/TR/ws-policy-attach/. </dd><dt class="label"><a name="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd>
+ http://www.w3.org/TR/ws-policy-attach/. (See http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/.)</div></dd><dt class="label"><a name="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd>
<cite><a href="http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/">Web Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 10 August 2007. This version of Web Services Policy 1.5 - Primer specification is http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/. The <a href="http://www.w3.org/TR/ws-policy-primer/">latest version of Web Services Policy 1.5 - Primer</a> is available at http://www.w3.org/TR/ws-policy-primer/.</dd><dt class="label"><a name="WS-RM"></a>[Web Services Reliable Messaging] </dt><dd>
<cite><a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>, D. Davis, A. Karmarkar
@@ -1311,8 +1390,8 @@
the UDDI 3.0</a> specification is available at
http://uddi.org/pubs/uddi_v3.htm.
</dd><dt class="label"><a name="SAWSDL"></a>[SAWSDL] </dt><dd>
- <cite><a href="http://www.w3.org/TR/sawsdl/">Semantic Annotations for WSDL and XML Schema</a></cite> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, 26 January 2007. This version of the
- specification is at http://www.w3.org/TR/sawsdl. The <a href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</a> is available at
+ <cite><a href="http://www.w3.org/TR/sawsdl/">Semantic Annotations for WSDL and XML Schema</a></cite> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, <span class="diff-chg"><span>28 Augusty </span></span>2007. This <span class="diff-chg"><span>is </span></span><span class="diff-add"><span>a W3C recommendation and</span></span><span class="diff-del"><span>of </span></span>the
+ specification <span class="diff-add"><span>can be found</span></span><span class="diff-del"><span>is </span></span>at <span class="diff-chg"><span>http://www.w3.org/TR/2007/REC-sawsdl-20070828/. </span></span>The <a href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</a> is available at
http://www.w3.org/TR/sawsdl/.</dd><dt class="label"><a name="XMLSchemaPart2"></a>[XML Schema Datatypes] </dt><dd>
<cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second
Edition</a></cite>, P. Byron and A. Malhotra, Editors. World
@@ -1335,7 +1414,7 @@
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).
</p><p>
Previous members of the Working Group were:
Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.
@@ -1344,20 +1423,37 @@
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 (and major editorial) changes since the Working Draft dated 30 March,
- 2007 is below:</p><ul><li><p>Reformatted the document to follow the model of the
- <a href="http://www.w3.org/TR/webarch/">Architecture of the World Wide Web, Volume One
- </a> (issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">3989</a>).
- </p></li><li><p>Created a consolidated list of Best Practices at the beginning of the document
- (<a href="#best-practices-list"><b>2. List of Best Practice Statements</b></a>) (issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">3989</a>).
- </p></li><li><p>Incorporated the Best Practices from
- <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM and Microsoft
- Contribution</a> (issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">3989</a>).
- </p></li><li><p>Made editorial changes to align with the OASIS WS-SecurityPolicy specification.</p></li><li><p>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.</p></li><li><p>Reorganized the guidelines on XML Information Set representation.</p></li><li><p>Dropped <a href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#best-practices-attachment">Section
- 6 Applying Best Practices for Policy Attachment</a>
- (issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3978">3978</a>).</p></li><li><p>Dropped <a href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#scenario">Section
- 7 Scenario and a worked example</a>
- (issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3988">3988</a>).</p></li></ul></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 <span class="diff-del"><span>substantive (and </span></span>major <span class="diff-del"><span>editorial) </span></span>changes since the Working Draft dated <span class="diff-chg"><span>10 August,
+ </span></span>2007 is below:</p><ul><li><div class="diff-del"><p class="diff-del">Reformatted the document to follow the model of the
+ Architecture of the World Wide Web, Volume One
+ (issue 3989).
+
+
+
+ </p></div><p><span class="diff-chg"><span>Added </span></span>a <span class="diff-add"><span>new</span></span><span class="diff-del"><span>consolidated list of Best Practices at the beginning of the document
+ () (issue 3989).
+
+
+
+ Incorporated the Best Practices from
+ IBM and Microsoft
+ Contribution (issue 3989).
+
+
+ Made editorial changes to align with the OASIS </span></span><span class="diff-chg"><span>section: </span></span><span class="diff-add"><a href="#UDDI-attachment-guidelines"><b>5.7.3 ConsiderationsDescribe for Policy Attachment in UDDI</b></a></span><span class="diff-add"><span>.</span></span><span class="diff-del"><span>specification.</span></span></p></li><li><p><span class="diff-del"><span>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.
+
+Reorganized the guidelines on XML Information Set representation.
+
+
+ </span></span><p><span class="diff-add"><span>Updated</span></span><span class="diff-del"><span>Dropped Section
+ 6 Applying Best Practices for Policy Attachment
+ (issue </span></span><span class="diff-add"><span>references:</span></span><span class="diff-del"><span>3978).
+
+
+ Dropped </span></span><span class="diff-add"><span>[</span></span><span class="diff-add"><cite><a href="#SAWSDL">SAWSDL</a></cite></span><span class="diff-add"><span>],</span></span><span class="diff-del"><span>Section
+ 7 </span></span><span class="diff-add"><span>[</span></span><span class="diff-add"><cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite></span><span class="diff-add"><span>],</span></span><span class="diff-del"><span>Scenario </span></span><span class="diff-add"><span>[</span></span><span class="diff-add"><cite><a href="#WS-Policy">Web Services Policy Framework</a></cite></span><span class="diff-add"><span>]
+ </span></span>and <span class="diff-add"><span>[</span></span><span class="diff-add"><cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite></span><span class="diff-add"><span>].</span></span></p><span class="diff-del"><span>a worked example
+ (issue 3988).</span></span></p></li></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.
@@ -1508,7 +1604,7 @@
are reflected.
</td></tr><tr><td colspan="1" rowspan="1">20070518</td><td colspan="1" rowspan="1">PY</td><td colspan="1" rowspan="1">Updated Appendix E, Changes in this Version of the Document
(<a href="#change-description"><b>E. Changes in this Version of the Document</b></a>).
- </td></tr><tr><td colspan="1" rowspan="1">20070520</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Added Best Practice <a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a> (from
+ </td></tr><tr><td colspan="1" rowspan="1">20070520</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Added Best Practice <a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a> (from
the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM
and MS Contribution</a> to
<a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that
@@ -1624,4 +1720,21 @@
Editors' action:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</a>.
</td></tr><tr><td colspan="1" rowspan="1">20070727</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated Section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
- </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070912</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=5041"><span class="diff-add"><span>5041</span></span></a>.
+ Editors' action:
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347"><span class="diff-add"><span>356</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">20070912</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">FJH</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=5043"><span class="diff-add"><span>5043</span></span></a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/357"><span class="diff-add"><span>357</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">20070913</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">TIB</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=4861"><span class="diff-add"><span>4861</span></span></a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353"><span class="diff-add"><span>353</span></span></a>
+ with the caveats and clarifications expressed in message
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html"><span class="diff-add"><span>2007Sep-0002</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">20070921</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 issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044"><span class="diff-add"><span>5044</span></span></a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358"><span class="diff-add"><span>358</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">20070921</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 references [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>].
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20070921</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>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-guidelines-diff20070810.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070810.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20070810.xml 22 Aug 2007 05:24:55 -0000 1.2
+++ ws-policy-guidelines-diff20070810.xml 22 Sep 2007 02:01:01 -0000 1.3
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?><!-- $Id$ -->
<!DOCTYPE spec
PUBLIC "-//W3C//DTD Specification V2.10//EN" "xmlspec.dtd">
-<spec role="editors-copy" w3c-doctype="wd"><header>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors<w3c-designation>ws-policy-guidelines.html</w3c-designation><w3c-doctype>Editors' copy $Date$</w3c-doctype><pubdate><day>@@</day><month>@@@@</month><year>@@@@</year></pubdate><publoc>
+<spec role="editors-copy" w3c-doctype="wd"><header><title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</title><w3c-designation>ws-policy-guidelines.html</w3c-designation><w3c-doctype>Editors' copy $Date$</w3c-doctype><pubdate><day>@@</day><month>@@@@</month><year>@@@@</year></pubdate><publoc>
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="ws-policy-guidelines.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">ws-policy-guidelines.html</loc>
</publoc><prevlocs>
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330</loc>
- </prevlocs><latestloc><loc xmlns:xlink="http://www.w3.org/1999/xlink" 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">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</loc></latestloc><authlist><author role="editor"><name>Asir S Vedamuthu</name><affiliation>Microsoft Corporation</affiliation></author><author role="editor"><name>David Orchard</name><affiliation>BEA Systems, Inc.</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 ole="editor"><name>Ümit Yalçinalp</name><affiliation>SAP AG.</affiliation></author></authlist><abstract><p>
+ </prevlocs><latestloc><loc xmlns:xlink="http://www.w3.org/1999/xlink" 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">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</loc></latestloc><authlist><author role="editor"><name>Asir S Vedamuthu</name><affiliation>Microsoft Corporation</affiliation></author><author role="editor"><name>David Orchard</name><affiliation>BEA Systems, Inc.</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><phrase diff="chg">webMethods </phrase><phrase diff="add">(A subsidiary of Software AG)</phrase><phrase diff="del">Inc.</phrase></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>
<emph>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</emph> is intended to provide guidance for Assertion
Authors that will work with the Web Services Policy 1.5 - Framework [<bibref ref="WS-Policy"/>] and Web Services Policy 1.5 - Attachment [<bibref ref="WS-PolicyAttachment"/>] specifications to create domain
specific assertions. The focus of this document is to provide
@@ -13,7 +13,7 @@
the care needed in using WS-Policy to achieve the best
possible results for interoperability. It is a complementary
guide to using the specifications. </p></abstract><status><p/></status><langusage><language id="en-US">English</language></langusage><revisiondesc><p>Last Modified: $Date$</p></revisiondesc></header><body><div1 id="introduction"><head>Introduction</head><p>The WS-Policy specification defines a policy to be a collection
- of policy alternatives. Each policy alternative a
+ of policy alternatives. Each policy alternative <phrase diff="add">is </phrase>a
collection of policy assertions. The Web Services Policy 1.5 - Framework provides a flexible framework to
represent
consistent combinations of behaviors from a variety of domains.
@@ -57,7 +57,7 @@
</p><p> As a companion document to the primer, this document also follows
the Socratic style of beginning with a question, and then answering
the question.
- </p></div1><div1 id="best-practices-list"><head>List of Best Practice Statements</head><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ulist><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-compatibility-tests"/></p></item><item><p><specref ref="bp-ignorable-for-not-related-to-compatibility-tests"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></tem><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></item><item><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-leverage-defined-attachment-mechanisms"/></p></item><item><p><specref ref="bp-use-defined-policy-subjects"/></p></item><item><p><specref ref="bp-identify-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></ite><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist></div1><div1 id="Assertions"><head>What is an Assertion? </head><p>An assertion is a piece of metadata that describes a
+ </p></div1><div1 id="best-practices-list"><head>List of Best Practice Statements</head><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ulist><item><p><specref ref="bp-assertion-semantics"/></p></item><item><p><specref ref="bp-compatibility-tests"/></p></item><item><p><specref ref="bp-ignorable-for-not-related-to-compatibility-tests"/></p></item><item><p><specref ref="bp-semantics-and-form"/></p></item><item><p><specref ref="bp-assertion-start"/></p></item><item><p><specref ref="bp-unique-qnames"/></p></item><item><p><specref ref="XMLOutline"/></p></item><item><p><specref ref="AssertionDefinitions"/></p></item><item><p><specref ref="DefineIgnorable"/></p></item><item><p><specref ref="ignorableAssertions"/></p></item><item><p><specref ref="bp-assertion-xml-allow-optional"/></p></item><item><p><specref ref="bp-not-necessary-to-understand-a-message"/></p></item><item><p><specref ref="bp-assertion-duplication"/></p></tem><item><p><specref ref="bp-assertion-parameters"/></p></item><item><p><specref ref="bp-dependent-behaviors"/></p></item><item><p><specref ref="bp-declare-nested-assertions"/></p></item><item><p><specref ref="bp-discourage-domain-specific-intersection"/></p></item><item><p><specref ref="bp-limit-optional-assertions"/></p></item><item><p><specref ref="bp-entire-mep-for-optional"/></p></item><item><p><specref ref="bp-indicate-optional-assertion-use"/></p></item><item><p><specref ref="bp-reusableAssertions"/></p></item><item><p><specref ref="bp-semantics-multiple-same-type"/></p></item><item><p><specref ref="bp-leverage-defined-attachment-mechanisms"/></p></item><item><p><specref ref="bp-use-defined-policy-subjects"/></p></item><item><p><specref ref="bp-identify-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-consider-scope"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-mltiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-UDDI-tmodels"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist></div1><div1 id="Assertions"><head>What is an Assertion? </head><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
are typically defined in a dedicated specification that describes
their semantics, applicability and scoping requirements as well
@@ -170,7 +170,7 @@
policy. This selected alternative is then used to govern the creation of a message
to send to the subject to which the policy alternative was
attached. The WS-Policy Attachment specification defines a
- set of attachment models for use with common web service
+ set of attachment <phrase diff="chg">mechanisms </phrase>for use with common web service
subjects: WSDL definitions [<bibref ref="WSDL11"/>, <bibref ref="WSDL20"/>], and UDDI directory entries [<bibref ref="UDDIAPI20"/>, <bibref ref="UDDIDataStructure20"/>,
<bibref ref="UDDI30"/>].
</p><p>
@@ -218,7 +218,7 @@
</p><p>
Assertion Authors need to have a specific goal in mind for the assertions
that they author. Assertion specifications should include a detailed specification
- of the assertion’s semantics and, a set of valid policy subjects to which the assertion
+ of the assertion’s semantics <phrase diff="chg">and </phrase>a set of valid policy subjects to which the assertion
maybe attached. The specification should also include the scope of the assertion
in the context of a particular policy subject. For example, an assertion with
Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
@@ -250,7 +250,7 @@
assertion may be constrained to a specific set of policy subjects by
Assertion Authors, its semantics should not be dependent upon the
mechanism by which the policy expression is attached to a given policy
- subject. For instance, an assertion "Foo" has the same semantic when
+ subject. For instance, an assertion "Foo" has the same <phrase diff="chg">semantics </phrase>when
attached to an operation policy subject regardless of whether it was
attached using XML element policy attachment or the external URI
attachment mechanism. Independence from a specific attachment mechanism
@@ -370,10 +370,10 @@
order to enable dynamic negotiation of business requirements
and capabilities at runtime.
</p><div3 id="minimal-approach"><head>Minimal approach</head><p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
- behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
+ behavior. Sets of assertions can by grouped by an operator <phrase diff="chg">"All". </phrase>This indicates that there is a relationship between
the assertions.
</p><p>If grouping is utilized, choices between such groupings can be indicated by
- an "exactly one" operator. This basic set of operators allows
+ an <phrase diff="chg">"ExactlyOne" </phrase><phrase diff="del">one" </phrase>operator. This basic set of operators allows
Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.
</p><p>It requires a good deal of effort to evaluate the
capabilities of a domain and capture them in a way that
@@ -460,11 +460,11 @@
</eg></example><p> The Policy Framework provides two modes of authoring policy expressions:
compact and normal form. One of the mechanisms that the Policy Framework
provides to policy authors for purposes of writing compact policy
-expressions is the wsp:Optional attribute. Assertion Authors should allow
-for the use of the wsp:Optional attribute in the XML outline and/or schema
+ expressions is the <code diff="add">wsp:Optional</code> attribute. Assertion Authors should allow
+for the use of the <code diff="add">wsp:Optional</code> attribute in the XML outline and/or schema
definition of an assertion as this will allow policy expression authors to
compose compact policy expressions.</p><p id="bp-assertion-xml-allow-optional" role="practice">
- <quote>Allow use of wsp:Optional</quote>
+ <quote><phrase diff="add">Assertion Authors should allow</phrase><phrase diff="del">Allow </phrase>use of wsp:Optional</quote>
<quote>An assertion's XML outline and/or schema definition should allow the use
of the wsp:Optional attribute so as to enable policy authors to compose
compact policy expressions.</quote>
@@ -483,7 +483,11 @@
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy></eg></example><p>
-If the assertion author had not provided for the wsp:Optional attribute to be included on the assertion, then policy expression authors would be forced to express the optionality of a behavior as two explicit policy alternatives, one with and one without that assertion when including assertions of that type in their policies.</p></div3><div3 id="self-describing"><head> Self Describing Messages </head><p> WS-Policy is intended to communicate the requirements, capabilities and
+If the assertion author had not provided for the <code diff="add">wsp:Optional</code> attribute
+to be included on the assertion, then policy expression authors would be forced to
+express the optionality of a behavior as two explicit policy alternatives,
+one with and one without that assertion when including assertions of that type in their
+policies.</p></div3><div3 id="self-describing"><head> Self Describing Messages </head><p> WS-Policy is intended to communicate the requirements, capabilities 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
@@ -702,11 +706,13 @@
</sp:TransportToken></eg></example><p>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.</p></div3></div2><div2 id="Ignorable"><head>Designating Ignorable Behavior</head><div3><head>Ignorable behavior in authoring</head><p>
- The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <bibref ref="WS-Policy"/> and <bibref ref="WS-Policy-Primer"/>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <specref ref="DefineIgnorable"/> and <specref ref="ignorableAssertions"/> to include this guidance in the assertion's definition.</p></div3><div3><head>Ignorable behavior at runtime</head><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+ The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the <phrase diff="chg">compatibility </phrase>assessment between two alternatives. [see <bibref ref="WS-Policy"/> and <bibref ref="WS-Policy-Primer"/>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <specref ref="DefineIgnorable"/> and <specref ref="ignorableAssertions"/> to include this guidance in the assertion's definition.</p></div3><div3><head>Ignorable behavior at runtime</head><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
indicate the semantic of the runtime behavior in the description of the assertion.
</p><p>
As said in <xspecref xmlns:xlink="http://www.w3.org/1999/xlink" href="ws-policy-primer.html#strict-lax-policy-intersection" xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">section 3.4.1 Strict and Lax Policy Intersection</xspecref> in <bibref ref="WS-Policy-Primer"/>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
- </p></div3></div2><div2 id="optional-policy-assertion"><head>Designating Optional Behaviors</head><div3><head>Optional behavior at runtime</head><ednote><edtext>This section does not have Working Group consensus and there is an outstanding action item to revise it</edtext></ednote><p>Since optional behaviors indicate optionality for
+ </p></div3></div2><div2 id="optional-policy-assertion"><head>Designating Optional Behaviors</head><div3><head>Optional behavior at runtime</head><p diff="del">This section does not have Working Group consensus and there is an outstanding action item to revise it
+
+ </p><p>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since this would allow the
@@ -796,34 +802,57 @@
communicate the policy assertions should not affect or imply additional
semantics in 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.
- </p><p id="bp-leverage-defined-attachment-mechanisms" role="practice">
- <quote>Leverage Defined Attachment Mechanisms</quote><quote>
- Assertion Authors should leverage defined attachment models when
- possible to extend the deployment of their policy assertions and ensure
- that there are no additional semantics implied by their
- assertions.</quote> </p><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
- specification when possible. </p><p id="bp-use-defined-policy-subjects" role="practice">
+ unknown) attachment mechanisms in mind. <phrase diff="add">Since multiple attachment mechanisms
+ may be used, a policy alternative created during the process of calculating
+ an effective policy can contain multiple instances of the same policy
+ assertion type ( i.e., the SignedParts assertion). It is therefore also
+ important for the policy authors to define what it means if multiple
+ assertions are present.
+ </phrase></p><p diff="add" id="bp-reusableAssertions" role="practice">
+ <quote><phrase diff="add">Reusable Assertions</phrase></quote><quote>
+ <phrase diff="add">Assertion Authors are encouraged to create policy assertions that
+ can be used regardless of attachment mechanism.</phrase></quote> </p><p diff="add"><phrase diff="add">For example, a security policy expression can be assigned a key reference and
+ be attached to a UDDI binding or can be embedded in a WSDL document. </phrase></p><p diff="chg" id="bp-semantics-multiple-same-type" role="practice">
+ <quote><phrase diff="chg">Describe Semantics of </phrase><phrase diff="add">Multiple Assertions of Same Type</phrase><phrase diff="del">Mechanisms</phrase></quote><quote>
+ Assertion Authors should <phrase diff="chg">specify the semantics of </phrase><phrase diff="add">multiple instances</phrase><phrase diff="del">when
+ </phrase><phrase diff="chg">of the </phrase><phrase diff="add">same policy</phrase><phrase diff="del">extend </phrase><phrase diff="add">assertion type in </phrase>the <phrase diff="add">same policy alternative</phrase><phrase diff="del">deployment </phrase><phrase diff="add">and the
+ semantics </phrase>of <phrase diff="add">parameters and nested</phrase><phrase diff="del">their </phrase>policy <phrase diff="chg">(if any) </phrase><phrase diff="add">when there are
+ multiple instances of a policy assertion type in the same policy</phrase><phrase diff="del">ensure
+ </phrase><phrase diff="add">alternative regardless of the mechanism used to attach them to
+ a policy subject.</phrase><phrase diff="del">that </phrase><phrase diff="add">If </phrase>there are <phrase diff="chg">multiple instances of a </phrase><phrase diff="add">policy
+ assertion</phrase><phrase diff="del">by </phrase><phrase diff="add">type in the same policy alternative without parameters</phrase><phrase diff="del">their
+ </phrase><phrase diff="add">and nested policies, these have the same meaning as a single
+ assertion of the type within the policy alternative.</phrase><phrase diff="del">assertions.</phrase></quote> </p><p> Assertion authors <phrase diff="chg">should review </phrase><phrase diff="add">sections 3.2 and 4.5 of the Policy Framework
+ </phrase><bibref diff="add" ref="WS-Policy"/> <phrase diff="add">for more detail
+ on the processing for multiple assertions of the same type.</phrase></p><p diff="add" id="bp-leverage-defined-attachment-mechanisms" role="practice">
+ <quote><phrase diff="add">Leverage Defined Attachment</phrase><phrase diff="del">encouraged </phrase><phrase diff="add">Mechanisms</phrase></quote><quote>
+ <phrase diff="add">Assertion Authors should leverage defined attachment models when
+ possible </phrase>to <phrase diff="add">document the </phrase>use <phrase diff="add">of </phrase>the policy <phrase diff="chg">assertions they </phrase><phrase diff="add">author and ensure
+ that there are no additional semantics implied</phrase>by the <phrase diff="add">defined
+ attachment</phrase><phrase diff="del">policy </phrase><phrase diff="add">models</phrase><phrase diff="del">attachments
+ specification </phrase><phrase diff="chg">for their </phrase><phrase diff="add">assertions.</phrase></quote> </p><p id="bp-use-defined-policy-subjects" role="practice">
<quote>Use Defined Policy Subjects</quote><quote> Assertion
- Authors should leverage defined policy subjects when possible to
+ <phrase diff="add">Assertion </phrase>Authors should leverage defined policy subjects when possible to
facilitate the deployment of their policy assertions. Common Policy
subjects have been defined and used by other policy assertion authors
and new policy assertions that leverage these existing subjects will be
- easier to define and group. </quote> </p><p>
+ easier to define and group. </quote> </p><p diff="add" id="bp-identify-policy-subjects" role="practice">
+ <quote><phrase diff="add">Identify Policy Subjects</phrase></quote><quote>
+
Policy assertion authors
should unambiguously identify the appropriate policy subjects for their
assertions. If the best practices are followed, and the assertions are
scoped according to their subject, then multiple policy domains may be
combined without conflict. Each domain should define any limitations at
- the policy subject level that might impact interoperability.
- </p><p id="bp-identify-policy-subjects" role="practice">
- <quote>Identify Policy Subjects</quote><quote>
- Assertion
- Authors should review the policy subjects defined in
- WS-PolicyAttachments and identify existing policy subjects when possible
- to facilitate the deployment of their policy assertions and include this
- information in the definition of the assertions.</quote> </p><p>
- An example of this is
+ the policy subject level that might impact interoperability.</quote> </p><p diff="add">
+
+ <phrase diff="del">Identify Policy Subjects
+ </phrase>Assertion Authors should review the policy subjects defined in
+ WS-PolicyAttachments
+ and identify <phrase diff="add">which of the </phrase>existing policy subjects <phrase diff="chg">can be used </phrase><phrase diff="add">with the assertions
+ they define. That identification will </phrase>facilitate the deployment of their policy
+ assertions and include <phrase diff="chg">such </phrase>information in the <phrase diff="add">assertion</phrase><phrase diff="del">definition of the assertions. </phrase><phrase diff="add">definition.
+ </phrase></p><p> An example of this <phrase diff="add">practice </phrase>is
the Reliable Messaging Policy Assertion document [<bibref ref="WS-RM-Policy"/>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
STR assertion defines the requirement that an RM Sequence MUST be bound
@@ -834,7 +863,7 @@
assertion". This is illustrative of how the domain assertion author can
specify additional constraints and assumptions for attachment and
engagement of behavior in addition to the capabilities specified in
- WS-PolicyAttachment [<bibref ref="WS-PolicyAttachment"/>]. Such
+ <phrase diff="add">Web Services Policy 1.5 - Attachment</phrase><phrase diff="del">WS-PolicyAttachment </phrase>[<bibref ref="WS-PolicyAttachment"/>]. Such
additional constraints must be clearly specified by the assertion
authors.
</p></div3><div3 id="wsdl-attachment-guidelines"><head>Considerations for Policy Attachment in WSDL</head><p>A behavior identified by a policy assertion applies to the
@@ -847,66 +876,69 @@
subject is the service policy subject. </p></item><item><p>If the behavior applies to any message exchange
made using an endpoint then the subject is the endpoint policy subject. </p></item><item><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></item><item><p>If the behavior applies to an input message then
- the subject is the message policy subject - similarly for output and fault message policy subjects.</p></item></ulist><p id="bp-WSDL-policy-subject" role="practice">
- <quote>Specify Policy Subject(s)</quote>
- <quote>Assertion Authors should specify the set of relevant policy subjects with which
+ the subject is the message policy subject - similarly for output and fault message <phrase diff="add">WSDL </phrase>policy subjects.</p></item></ulist><p id="bp-WSDL-policy-subject" role="practice">
+ <quote>Specify <phrase diff="add">WSDL </phrase>Policy Subject(s)</quote>
+ <quote>Assertion Authors should specify the set of relevant <phrase diff="add">WSDL </phrase>policy subjects with which
the assertion may be associated. For instance, if a policy assertion is to be used with
- WSDL, the assertion description should specify a WSDL policy subject - such as service,
- endpoint, operation and message.
- </quote>
- </p><p>Assertion Authors that wish to utilize WSDL policy subjects need to
+ <phrase diff="del">WSDL, the assertion description should specify </phrase>a WSDL policy subject - such as service, endpoint, operation and <phrase diff="add">message it should be stated.</phrase><phrase diff="del">message.
+ </phrase></quote>
+ </p><p>Assertion Authors that <phrase diff="del">wish to </phrase>utilize WSDL policy subjects need to
understand how the assertions will be
- processed in an intersection and merging, and the implications of
- the processing for considering a specific attachment point and
- policy subject. This topic is considered in detail in <bibref ref="WS-Policy-Primer"/>
+ processed in <phrase diff="del">an </phrase>intersection and merging, and the <phrase diff="add">specific </phrase>implications of
+ the processing for <phrase diff="del">considering </phrase>a specific attachment point and policy subject.
+ This topic is considered in detail in <bibref ref="WS-Policy-Primer"/>
</p><p> For a given WSDL policy subject, there may be several
attachment points. For example, there are three attachment
points for the endpoint policy subject: the port, binding and
portType element. Assertion Authors should identify the
- relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, Assertion Authors should
- consider the scope of the attachment point. For example, an
- assertion should only be allowed in the portType element if
+ relevant attachment point when defining a new assertion.
+ </p><p diff="add" id="bp-WSDL-consider-scope" role="practice">
+ <quote><phrase diff="add">Consider Scope of Attachment Points</phrase></quote>
+ <quote>To determine the relevant attachment points, Assertion Authors should
+ consider the scope of the attachment point.
+ </quote>
+ </p><p diff="add">
+ For example, an assertion should only be allowed in the portType element if
the assertion reasonably applies to any endpoint that ever
references that portType. Most of the known policy assertions
are designed for the endpoint, operation or message policy subject.
</p><p> In using WSDL attachment, it should be noted that the
service policy subject is a collection of endpoint policy
subjects. The endpoint policy subject is a collection of
- operation policy subjects and so on. As a result, the WSDL
+ operation <phrase diff="add">WSDL </phrase>policy subjects and so on. As a result, the WSDL
policy subjects compose naturally. It is quite tempting to
associate the identified behavior to a broader policy subject
than to a fine granular policy subject. For instance, it is
convenient to attach a supporting token assertion (defined by
the Web Services Security Policy specification) to an endpoint
policy subject instead of a message policy subject. However such
- policy attachments to policy subjects of broader scope and granularity
+ policy attachments to <phrase diff="add">WSDL </phrase>policy subjects of broader scope and granularity
should be done only after careful evaluation.
</p><p id="bp-WSDL-policy-subject-Granularity" role="practice">
- <quote>Choose the Most Granular Policy Subject</quote>
- <quote>Assertion Authors should choose the most granular policy subject
+ <quote>Choose the Most Granular <phrase diff="add">WSDL </phrase>Policy Subject</quote>
+ <quote>Assertion Authors should choose the most granular <phrase diff="add">WSDL </phrase>policy subject
to which the behavior represented by a policy assertion applies.
</quote>
</p><p>
For authoring convenience, Assertion Authors may allow the
- association of an assertion to multiple policy subjects within the same context of
+ association of an assertion to multiple <phrase diff="add">WSDL </phrase>policy subjects within the same context of
use (e.g in the same WSDL description). If an assertion is allowed to be
- associated with multiple policy subjects as is possible with WSDL, then
+ associated with multiple <phrase diff="add">WSDL </phrase>policy subjects as is possible with WSDL, then
the Assertion Authors have the burden to describe the rules
when multiple instances of the same assertion are attached to different
- policy subjects in order to avoid non-interoperable behavior.
+ <phrase diff="add">WSDL </phrase>policy subjects in order to avoid non-interoperable behavior.
</p><p id="bp-WSDL-multiple-policy-subjects" role="practice">
<quote> Define Rules for Attachment of an Assertion
- type to Multiple Policy Subjects</quote>
- <quote>If an assertion is allowed to be associated with multiple policy subjects,
+ type to Multiple <phrase diff="chg">WSDL </phrase><phrase diff="add">policy subjects</phrase><phrase diff="del">Subjects</phrase></quote>
+ <quote>If an assertion is allowed to be associated with multiple <phrase diff="add">WSDL </phrase>policy subjects,
the assertion author should describe the rules for multiple
- instances of the same assertion attached to multiple policy subjects in
+ instances of the same assertion attached to multiple <phrase diff="add">WSDL </phrase>policy subjects in
the same context.
</quote>
</p><p>
To give one example, section 2.3 of the
Web Services Reliable Messaging Policy Assertion specification
- [<bibref ref="WS-RM-Policy"/>] gives rules on which Policy Subjects may be associated with the RM
+ [<bibref ref="WS-RM-Policy"/>] gives rules on which <phrase diff="chg">WSDL </phrase><phrase diff="add">policy subjects</phrase><phrase diff="del">Subjects </phrase>may be associated with the RM
Policy assertion, and which WSDL 1.1 elements may have RM Policy assertions attached.
</p><p>If the capability may imply
different semantics with respect to attachment points, the
@@ -921,20 +953,20 @@
the WS-RM Policy is a capability that governs a target endpoint's
capability to accept message sequences that are beyond single message
exchange. Therefore, its semantics encompass the cases when
- message level policy subjects may be used as attachment but
+ message level <phrase diff="add">WSDL </phrase>policy subjects may be used as attachment but
also considers the case when sequences are present. In addition,
when the policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p><p id="bp-WSDL-preferred-attachment-point" role="practice">
- <quote>Specify Preferred Attachment Point</quote>
+ <quote>Specify Preferred <phrase diff="add">WSDL </phrase>Attachment Point</quote>
<quote>If an assertion can be attached at multiple attachment points
within a policy subject, Assertion Authors should specify a
preferred attachment point for the chosen policy subject.
</quote>
</p><p>Assertion Authors that utilize WSDL policy subjects need to
understand how the assertions will be processed in merging and
- the specify implications of ending up with multiple assertions of
- the same kind in an alternative, in the merged policy. For example,
+ the <phrase diff="chg">specific </phrase>implications of <phrase diff="chg">a result where </phrase>multiple assertions of
+ the <phrase diff="add">assertion type</phrase><phrase diff="del">same </phrase><phrase diff="chg">are </phrase>in an alternative, in the merged policy. For example,
consider the SignedParts assertion defined in WS-SecurityPolicy 1.2.
The definition of SignedParts assertion explicitly permits multiple
SignedParts assertions to be present within a policy alternative,
@@ -946,16 +978,30 @@
at the endpoint could have more than one SignedParts assertion in the
same alternative. However, the clear semantics defined by the SignedParts
assertion enable processing of the multiple occurrences properly.
- </p><p id="bp-WSDL-policy-multiple-instance-semantics" role="practice">
- <quote>Describe Semantics of Multiple Assertions of Same Type</quote>
- <quote>A policy alternative can contain multiple instances of the same
- policy assertion type. Assertion authors should specify the semantics of
- multiple instances of same policy assertion type in the same policy
- alternative and the semantics of parameters and nested policy (if any)
- when there are multiple instances of a policy assertion type in the same
- policy alternative.
- </quote>
- </p></div3></div2><div2 id="interrelated-domains"><head>Interrelated domains</head><p>Assertion Authors need to be clear about how assertions defined in
+ </p></div3><div3 diff="add" id="UDDI-attachment-guidelines"><head><phrase diff="add">Considerations</phrase><phrase diff="del">Describe </phrase><phrase diff="chg">for Policy Attachment in </phrase><phrase diff="add">UDDI</phrase></head><p><phrase diff="add">In</phrase><phrase diff="del">of </phrase><phrase diff="chg">general, </phrase><phrase diff="add">UDDI</phrase><phrase diff="del">Type
+ A </phrase><phrase diff="chg">protocol messages </phrase>can <phrase diff="chg">be used to save TModel, businessEntity,
+ businessService and bindingTemplate definitions with policies attached. </phrase><phrase diff="add">These
+ definitions can also be </phrase>the <phrase diff="chg">target </phrase>of
+ <phrase diff="del">multiple </phrase><phrase diff="chg">a "find" </phrase><phrase diff="add">protocol message, thus allowing
+ authors to store and retrieve</phrase><phrase diff="del">same </phrase>policy <phrase diff="chg">assertions. There are two ways </phrase><phrase diff="add">to associate
+ </phrase>policy
+ <phrase diff="del">alternative </phrase><phrase diff="chg">expressions with UDDI definitions: </phrase><phrase diff="add">direct referece,</phrase><phrase diff="del">parameters </phrase>and <phrase diff="chg">registering </phrase>policy
+ <phrase diff="add">as </phrase><phrase diff="chg">a </phrase><phrase diff="add">UDDI TModel. Assertion Authors defining new assertions should consider each
+ approach.
+ </phrase></p><p id="bp-UDDI-tmodels" role="practice">
+ <quote><phrase diff="add">Use defined tModels </phrase><phrase diff="del">any)
+ </phrase>when <phrase diff="add">appropriate</phrase></quote>
+ <quote><phrase diff="add">UDDI</phrase><phrase diff="del">there </phrase><phrase diff="chg">defines the following </phrase><phrase diff="add">policy subjects: Service Provider Policy,
+ Service Policy subject and Endpoint Policy subject.
+ </phrase></quote>
+ </p><p>
+ <phrase diff="add">When defining assertions and recommending a service provider</phrase><phrase diff="del">of </phrase><phrase diff="add">policy
+ subject [uddi:BusinessEntity], or </phrase>a <phrase diff="add">service </phrase>policy <phrase diff="add">subject [uddi:buisnessService],
+ </phrase>assertion <phrase diff="chg">authors </phrase><phrase diff="add">are scoping</phrase><phrase diff="del">in </phrase>the <phrase diff="add">behaviors to the service</phrase><phrase diff="del">same
+ </phrase><phrase diff="add">provider as a whole. When defining assertions and recommending an endpoint
+ </phrase>policy <phrase diff="add">subject [uddi:bindingTemplate, uddi:tModel], assertion authors</phrase><phrase diff="del">alternative.
+ </phrase><phrase diff="add">are scoping behaviors to a deployed endpoint.
+ </phrase></p></div3></div2><div2 id="interrelated-domains"><head>Interrelated domains</head><p>Assertion Authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. Assertion Authors should not duplicate existing
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
@@ -995,7 +1041,7 @@
Section 4.2, the <code>sp:issuedToken</code> assertion utilizes the
<code>sp:RequestSecurityTokenTemplate</code> parameter that contains necessary
information to request a security token. The contents of the parameter
- are static and allows reuse in different security scenerios.</p></div2><div2 id="extending-assertions"><head> Evolution of Assertions (Versioning and Compatibility)</head><p>Over time, there may be multiple equivalent behaviors emerging in the Web
+ are static and <phrase diff="chg">allow </phrase>reuse in different security <phrase diff="chg">scenarios.</phrase></p></div2><div2 id="extending-assertions"><head> Evolution of Assertions (Versioning and Compatibility)</head><p>Over time, there may be multiple equivalent behaviors emerging in the Web
Service interaction space. Examples of such multiple equivalent behaviors are WSS: SOAP Message Security 1.0
vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
[<bibref ref="WS-Addressing"/>]. These equivalent behaviors
@@ -1048,7 +1094,7 @@
</td><td colspan="1" rowspan="1">[<bibref ref="WS-Addressing"/>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsam</code>
</td><td colspan="1" rowspan="1">
- <code>http://www.w3.org/2007/05/addressing/metadata</code>
+ <code><phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/</phrase></code>
</td><td colspan="1" rowspan="1">[<bibref ref="WS-AddressingMetadata"/>]</td></tr><tr><td colspan="1" rowspan="1">
<code>wsdl</code>
</td><td colspan="1" rowspan="1">
@@ -1097,10 +1143,10 @@
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <loc href="http://www.w3.org/TR/ws-addr-core/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0
- - Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/" id="WS-AddressingMetadata" key="WS-Addressing Metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ - Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/" id="WS-AddressingMetadata" key="WS-Addressing Metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Addressing 1.0 - Metadata</titleref>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 31 July 2007. This version of Web Services Addressing 1.0 - Metadata is
- http://www.w3.org/TR/2007/PR-ws-addr-metadata-20070731/. The <loc href="http://www.w3.org/TR/ws-addr-metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0 -
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This version of Web Services Addressing 1.0 - Metadata <phrase diff="add">W3C Recommendation </phrase>is
+ <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-addr-metadata" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of Web Services Addressing 1.0 -
Metadata</loc> is available at http://www.w3.org/TR/ws-addr-metadata. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" 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">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Description Language (WSDL) 1.1</titleref>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
@@ -1109,14 +1155,14 @@
Language</titleref>, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World
Wide Web Consortium, 26 June 2007. This version of the WSDL 2.0 specification is
http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The <loc href="http://www.w3.org/TR/wsdl20/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
- latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-policy-20070706/" id="WS-Policy" key="Web Services Policy Framework" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-policy-20070904/" id="WS-Policy" key="Web Services Policy Framework" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Policy 1.5 - Framework</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/2007/PR-ws-policy-20070706/. The <loc href="http://www.w3.org/TR/ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
- Web Services Policy 1.5 - Framework</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/" id="WS-PolicyAttachment" key="Web Services Policy Attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This version of the
+ Web Services Policy 1.5 - Framework specification is at <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-policy-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
+ Web Services Policy 1.5 - Framework</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/" id="WS-PolicyAttachment" key="Web Services Policy Attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Policy 1.5 - Attachment</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
- P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 6 July 2007. This version of the
- Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/. The <loc href="http://www.w3.org/TR/ws-policy-attach/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
+ P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, <phrase diff="chg">4 September </phrase>2007. This version of the
+ Web Services Policy 1.5 - Attachment specification is at <phrase diff="chg">http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. </phrase>The <loc href="http://www.w3.org/TR/ws-policy-attach/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">latest version of
Web Services Policy 1.5 - Attachment</loc> is available at
http://www.w3.org/TR/ws-policy-attach/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/" id="WS-Policy-Primer" key="Web Services Policy Primer" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services Policy 1.5 - Primer</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
@@ -1178,8 +1224,8 @@
the UDDI 3.0</loc> specification is available at
http://uddi.org/pubs/uddi_v3.htm.
</bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/sawsdl/" id="SAWSDL" key="SAWSDL" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
- <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Semantic Annotations for WSDL and XML Schema</titleref> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, 26 January 2007. This version of the
- specification is at http://www.w3.org/TR/sawsdl. The <loc href="http://www.w3.org/TR/sawsdl/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"> latest version of Semantic Annotations for WSDL and XML Schema</loc> is available at
+ <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Semantic Annotations for WSDL and XML Schema</titleref> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, <phrase diff="chg">28 Augusty </phrase>2007. This <phrase diff="chg">is </phrase><phrase diff="add">a W3C recommendation and</phrase><phrase diff="del">of </phrase>the
+ specification <phrase diff="add">can be found</phrase><phrase diff="del">is </phrase>at <phrase diff="chg">http://www.w3.org/TR/2007/REC-sawsdl-20070828/. </phrase>The <loc href="http://www.w3.org/TR/sawsdl/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"> latest version of Semantic Annotations for WSDL and XML Schema</loc> is available at
http://www.w3.org/TR/sawsdl/.</bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/" id="XMLSchemaPart2" key="XML Schema Datatypes" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">XML Schema Part 2: Datatypes Second
Edition</titleref>, P. Byron and A. Malhotra, Editors. World
@@ -1201,7 +1247,7 @@
Working Group</loc>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporaion), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).
</p><p>
Previous members of the Working Group were:
Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.
@@ -1209,20 +1255,37 @@
The people who have contributed to <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">discussions
on public-ws-policy@w3.org</loc> are also gratefully
acknowledged.
- </p></inform-div1><inform-div1 id="change-description"><head>Changes in this Version of the Document</head><p>A list of substantive (and major editorial) changes since the Working Draft dated 30 March,
- 2007 is below:</p><ulist><item><p>Reformatted the document to follow the model of the
- <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/webarch/" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">Architecture of the World Wide Web, Volume One
- </loc> (issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">3989</loc>).
- </p></item><item><p>Created a consolidated list of Best Practices at the beginning of the document
- (<specref ref="best-practices-list"/>) (issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">3989</loc>).
- </p></item><item><p>Incorporated the Best Practices from
- <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">IBM and Microsoft
- Contribution</loc> (issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">3989</loc>).
- </p></item><item><p>Made editorial changes to align with the OASIS WS-SecurityPolicy specification.</p></item><item><p>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.</p></item><item><p>Reorganized the guidelines on XML Information Set representation.</p></item><item><p>Dropped <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#best-practices-attachment" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">Section
- 6 Applying Best Practices for Policy Attachment</loc>
- (issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3978" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">3978</loc>).</p></item><item><p>Dropped <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#scenario" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">Section
- 7 Scenario and a worked example</loc>
- (issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3988" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">3988</loc>).</p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</head><table border="1" id="ws-policy-primer-changelog-table"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><!-- template
+ </p></inform-div1><inform-div1 id="change-description"><head>Changes in this Version of the Document</head><p>A list of <phrase diff="del">substantive (and </phrase>major <phrase diff="del">editorial) </phrase>changes since the Working Draft dated <phrase diff="chg">10 August,
+ </phrase>2007 is below:</p><ulist><item><p diff="del">Reformatted the document to follow the model of the
+ Architecture of the World Wide Web, Volume One
+ (issue 3989).
+
+
+
+ </p><p><phrase diff="chg">Added </phrase>a <phrase diff="add">new</phrase><phrase diff="del">consolidated list of Best Practices at the beginning of the document
+ () (issue 3989).
+
+
+
+ Incorporated the Best Practices from
+ IBM and Microsoft
+ Contribution (issue 3989).
+
+
+ Made editorial changes to align with the OASIS </phrase><phrase diff="chg">section: </phrase><specref diff="add" ref="UDDI-attachment-guidelines"/><phrase diff="add">.</phrase><phrase diff="del">specification.</phrase></p></item><item><p><phrase diff="del">Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.
+
+Reorganized the guidelines on XML Information Set representation.
+
+
+ </phrase><p><phrase diff="add">Updated</phrase><phrase diff="del">Dropped Section
+ 6 Applying Best Practices for Policy Attachment
+ (issue </phrase><phrase diff="add">references:</phrase><phrase diff="del">3978).
+
+
+ Dropped </phrase><phrase diff="add">[</phrase><bibref diff="add" ref="SAWSDL"/><phrase diff="add">],</phrase><phrase diff="del">Section
+ 7 </phrase><phrase diff="add">[</phrase><bibref diff="add" ref="WS-AddressingMetadata"/><phrase diff="add">],</phrase><phrase diff="del">Scenario </phrase><phrase diff="add">[</phrase><bibref diff="add" ref="WS-Policy"/><phrase diff="add">]
+ </phrase>and <phrase diff="add">[</phrase><bibref diff="add" ref="WS-PolicyAttachment"/><phrase diff="add">].</phrase></p><phrase diff="del">a worked example
+ (issue 3988).</phrase></p></item></ulist></inform-div1><inform-div1 id="change-log"><head>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</head><table border="1" id="ws-policy-primer-changelog-table"><tbody><tr><th colspan="1" rowspan="1">Date</th><th colspan="1" rowspan="1">Author</th><th colspan="1" rowspan="1">Description</th></tr><!-- template
<tr>
<td>200505</td>
<td></td>
@@ -1494,4 +1557,21 @@
Editors' action:
<loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">347</loc>.
</td></tr><tr><td colspan="1" rowspan="1">20070727</td><td colspan="1" rowspan="1">ASV</td><td colspan="1" rowspan="1">Updated Section <specref ref="change-description"/>.
- </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
+ </td></tr><tr><td colspan="1" rowspan="1">20070806</td><td colspan="1" rowspan="1">FS</td><td colspan="1" rowspan="1">Updated references for draft publication.</td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070912</td><td colspan="1" diff="add" rowspan="1">PY</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5041" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">5041</phrase></loc>.
+ Editors' action:
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">356</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070912</td><td colspan="1" diff="add" rowspan="1">FJH</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5043" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">5043</phrase></loc>. Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/357" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">357</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070913</td><td colspan="1" diff="add" rowspan="1">TIB</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4861" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">4861</phrase></loc>. Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">353</phrase></loc>
+ with the caveats and clarifications expressed in message
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">2007Sep-0002</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070921</td><td colspan="1" diff="add" rowspan="1">MH</td><td colspan="1" diff="add" rowspan="1">Implemented the resolution for issue
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">5044</phrase></loc>. Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">358</phrase></loc>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070921</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Updated references [<bibref ref="WS-Policy"/>] and [<bibref ref="WS-PolicyAttachment"/>].
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20070921</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Reset Section <specref ref="change-description"/>.
+ </td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
Received on Saturday, 22 September 2007 02:01:30 UTC