- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 07 May 2007 21:42:34 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv16588
Modified Files:
ws-policy-primer-diff20070330.html
Log Message:
Checkin in the latest diff of primer for CVS tagging & sending to the WG
Index: ws-policy-primer-diff20070330.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20070330.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-primer-diff20070330.html 1 May 2007 23:30:36 -0000 1.2
+++ ws-policy-primer-diff20070330.html 7 May 2007 21:42:31 -0000 1.3
@@ -112,7 +112,10 @@
3.6 <a href="#policy-retrieval">Policy Retrieval</a><br>
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="#ignorable-and-versioning">Ignorable and Versioning</a><br>
+ 3.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
+ 3.8.2 <a href="#d2e1431">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>
4. <a href="#versioning-policy-language">Versioning Policy Language</a><br>
4.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
@@ -855,11 +858,14 @@
</p><p>
In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an
assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary.
- The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
- When using the strict intersection mode ignorable assertions are part of the policy alternative vocabulary, so the
- <code>wsp:Ignorable</code> attribute does not impact the intersection result even when the <code>wsp:Ignorable</code>
- attribute value is “true”.
- </p><p>
+ The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
+ </p><div class="diff-add"><p class="diff-add">
+
+ When using the strict intersection mode <span class="diff-chg"><span>all </span></span>assertions are part of the policy alternative vocabulary,
+ <span class="diff-add"><span>including those marked with </span></span><code><span class="diff-add"><span>wsp:Ignorable</span></span></code><span class="diff-add"><span>. Thus</span></span><span class="diff-del"><span>so </span></span>the <code>wsp:Ignorable</code> attribute
+ does not impact the intersection result even when <span class="diff-chg"><span>its </span></span><span class="diff-del"><span>wsp:Ignorable
+ </span></span>attribute value is “true”.
+ </p></div><p>
If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax
intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the
<code>wsp:Ignorable</code> attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode
@@ -876,7 +882,19 @@
Domain-specific processing could take advantage of any
information from the policy data model, such as the ignorable property of a
policy assertion.
- </p></div></div></div><div class="div2">
+ </p></div><div class="diff-add"><p class="diff-add">
+ <span class="diff-add"><span>A requester can decide how to process a provider's policy to determine
+ if and how the requester will interact with the provider. The requester
+ can have its own policy that expresses its own capabilities and
+ requirements, and can make one or more attempts at policy intersection
+ in order to determine a compatible alternative and/or isolate the cause
+ of an empty intersection result. The requester can use and analyze the
+ result(s) of policy intersection to select a compatible alternative or
+ trigger other domain-specific processing options. For example, a
+ requester can at first attempt strict mode intersection, and then lax
+ mode as another choice, if the previous attempt returns an empty
+ intersection result.
+ </span></span></p></div></div></div><div class="div2">
<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Company-X attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
<code>binding</code> element, a policy expression can be attached to other WSDL elements
@@ -996,7 +1014,8 @@
unordered collection of policy alternatives. That is, the order of policy alternatives is
insignificant. Therefore, the order of combining these policy expressions is
insignificant.</p></div><div class="div2">
-<h3><a name="extensibility-and-versioning" id="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><p>Web Services Policy language is an extensible language by design. The
+<h3><a name="extensibility-and-versioning" id="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><div class="diff-add"><div class="div3">
+<h4><a name="ext-vers-policylanguage" id="ext-vers-policylanguage"></a>3.8.1 <span class="diff-add"><span>Policy Language</span></span></h4><p>Web Services Policy language is an extensible language by design. The
<code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
and <code>wsp:PolicyReference</code> elements are extensible. The <code>Policy</code>
element allows child element and attribute extensibility, while the
@@ -1006,11 +1025,12 @@
A consuming processor processes known attributes and elements, ignores unknown attributes
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><p>Web Services Policy language enables simple versioning practices that allow requesters to
- continue the use of any older policy alternatives in a backward compatible manner. This
- allows service providers, like Company-X, to deploy new behaviors using additional policy
+ </p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p></div></div><div class="diff-add"><div class="div3">
+<h4><a name="d2e1431" id="d2e1431"></a>3.8.2 <span class="diff-add"><span>Policy Expressions</span></span></h4><p><span class="diff-add"><span>Services that use the </span></span>Web Services Policy language <span class="diff-add"><span>for policy expression enable</span></span><span class="diff-del"><span>enables </span></span>simple versioning practices that allow requesters to
+ continue the use of <span class="diff-del"><span>any </span></span>older policy alternatives in a backward compatible manner. This
+ <span class="diff-add"><span>versioning practice </span></span>allows service providers, like Company-X, to deploy new behaviors using additional <span class="diff-add"><span>(or new) </span></span>policy
assertions without breaking compatibility with clients that rely on any older policy
- alternatives.</p><p>The example below represents a Company-X version 1 policy expression. This expression
+ alternatives. <span class="diff-add"><span>We use examples below to illustrate how versioning might be done.</span></span></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>
<ExactlyOne>
@@ -1020,10 +1040,10 @@
</All>
</ExactlyOne>
</Policy></pre></div></div><p>Over time, Company-X adds support for advanced behaviors: requiring the use of addressing
- and message-level security for protecting messages. They added this advanced support
+ and message-level security for protecting messages. They <span class="diff-add"><span>would like to add</span></span><span class="diff-del"><span>added </span></span>this advanced support
without breaking compatibility with requesters that rely on addressing and transport-level
security. The example below is Company-X’s version 2 policy expression. In this version,
- Company-X’s adds a new policy alternative that requires the use of addressing and
+ <span class="diff-chg"><span>Company-X </span></span>adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
may continue to interact with 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
@@ -1042,10 +1062,10 @@
</Policy></pre></div></div><p>When Company-X added support for advanced behaviors, they spent time to plan for the
continued support for existing clients, the smooth migration from using current to
advanced behaviors, and the switch to use only the advanced behaviors in the near future
- (i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
+ (i.e. sun-setting current behaviors). In this versioning scenario, <span class="diff-add"><span>a </span></span>policy <span class="diff-chg"><span>expression </span></span><span class="diff-add"><span>with multiple alternatives was</span></span><span class="diff-del"><span>be </span></span>used to
represent current and advanced behaviors in a non-disruptive manner: no immediate changes
to existing clients are required and these clients can smoothly migrate to new
- functionality when they choose to. This level of versioning support in policy enables the
+ functionality when they choose to. This level of versioning support in <span class="diff-add"><span>a </span></span>policy <span class="diff-add"><span>expression </span></span>enables the
same class of versioning best practices built into WSDL constructs such as service, port
and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like Company-X,
incrementally deploy advanced behaviors, some requesters may not recognize these new
@@ -1058,21 +1078,19 @@
similar to how a proxy generator that generates code from WSDL creates code for all the
known WSDL constructs and allows Web service developers to fill in code for custom or
unknown constructs in the WSDL.
- </p><div class="div3">
-<h4><a name="ignorable-and-versioning" id="ignorable-and-versioning"></a>3.8.1 Ignorable and Versioning</h4><p>
+ </p></div></div><div class="div3">
+<h4><a name="ignorable-and-versioning" id="ignorable-and-versioning"></a>3.8.3 <span class="diff-add"><span>Use of </span></span>Ignorable <span class="diff-add"><span>attribute </span></span>and <span class="diff-add"><span>an alternative </span></span>Versioning <span class="diff-add"><span>Scenario</span></span></h4><p>
One potential use of the wsp:Ignorable attribute is to mark versioning related
- information. One scenario is that a service will support a particular version
+ <span class="diff-add"><span>information by creating a new policy assertion within a policy expression.</span></span><span class="diff-del"><span>information. </span></span><span class="diff-chg"><span>The </span></span><span class="diff-add"><span>new assertion</span></span><span class="diff-del"><span>scenario </span></span>is <span class="diff-add"><span>added to the original policy expression and then the service can update the assertion parameter values when the service expires.</span></span></p><div class="diff-add"><p class="diff-add"> <span class="diff-add"><span>One scenario </span></span>that <span class="diff-add"><span>illustrates this is </span></span>a service <span class="diff-add"><span>which </span></span>will support a particular version
of a service until a certain point in time. After that time, the service will
- not be supported. The expiry date and time of the service would be a domain
- expression, but it could be marked as
- ignorable. When an alternative does have an expiry, it is usually
- useful to convey this information to help smooth the versioning process.
- </p><p>
- Company-X could specify that the older policy alternative will expire at a
- certain point in time using a Company-X specific expiry assertion. The example
- below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
- Assertion.
- </p><div class="exampleOuter">
+ not be supported. <span class="diff-add"><span>In this scenario, the</span></span><span class="diff-del"><span>The </span></span>expiry date and time of the service would be a <span class="diff-add"><span>new policy assertion [see Guidelines section 4] that the service provider defines . This hypothetical EndOfLife policy assertion is then included in the original policy </span></span><span class="diff-del"><span>domain
+ </span></span>expression, but it could be marked as ignorable. <span class="diff-del"><span>When </span></span><span class="diff-chg"><span>The </span></span><span class="diff-add"><span>service, in this case, wants to inform the consumers it</span></span><span class="diff-del"><span>alternative </span></span>does have an <span class="diff-add"><span>expiry time, and so</span></span><span class="diff-del"><span>expiry, </span></span>it is <span class="diff-del"><span>usually
+ </span></span>useful to convey this information <span class="diff-add"><span>from the beginning </span></span>to help smooth the versioning process.
+ </p></div><p>
+Company-X could specify that <span class="diff-add"><span>one</span></span><span class="diff-del"><span>the older </span></span>policy alternative will expire at a certain point in time using <span class="diff-chg"><span>the hypothetical ignorable </span></span><span class="diff-add"><span>Company-X </span></span>expiry assertion. The example below shows <span class="diff-add"><span>how </span></span>Company-X <span class="diff-add"><span>can create a new </span></span>version 2 policy expression with a <span class="diff-add"><span>second </span></span>hypothetical ignorable EndOfLife <span class="diff-add"><span>Assertion with a different date and time.
+
+ </span></span><span class="diff-del"><span>Assertion.
+ </span></span></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
Assertion</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
@@ -1093,28 +1111,26 @@
In this variant of the versioning scenario, the use of ignorable allows
versioning related information to be conveyed and used where understood.
</p><p>
- In a scenario such as this, where an assertion type is used for ignorable
- information, the use of strict or lax mode and presence or absence of the
- assertion type in the first version are important decisions. If Company-X wishes
- clients to always be able to ignore the assertion, particularly those using
- strict intersection, the first policy alternative offered should contain the
- policy assertion type. If Company-X adds the policy assertion type to a
- subsequent alternative, then requesters using strict mode will not understand
- the assertion type and the alternative with the ignorable information will not
- be compatible with the older version of the alternative as per the intersection
- rules. Thus the widest possible alternative compatibility will be to have the
- ignorable policy assertion type in the very first version of the alternative.
- The second alternative shown also contains the hypothetical EndOfLife policy
- Assertion type.
- Because the actual value is not known, a value that is roughly infinitely in
- the future is used. A subsequent policy alternative could refine the value.
- </p><p>
- The advantage of adding the end of life information is that some clients will have a
- machine processable way of knowing when the alternative will no longer be
- supported. Without this information, the information must be conveyed in some
- other way or it will not be conveyed at all. This can usefully smooth the
- transition between versions.
- </p></div></div><div class="div2">
+ In a scenario such as this, <span class="diff-add"><span>CompanyX is acting as both a policy assertion author and a policy expression author. As a</span></span><span class="diff-del"><span>where </span></span><span class="diff-add"><span>policy expression author, when </span></span>an assertion type is <span class="diff-chg"><span>tagged as </span></span>ignorable information, the use of strict or lax mode and presence or absence of the assertion type in the first version are important decisions.
+ </p></div><div class="diff-add"><div class="div3">
+<h4><a name="ignorable-and-optional-and-versioning" id="ignorable-and-optional-and-versioning"></a>3.8.4 <span class="diff-add"><span>Use of Ignorable and Optional attributes</span></span></h4><p> If Company-X <span class="diff-add"><span>knows</span></span><span class="diff-del"><span>wishes
+ clients </span></span><span class="diff-chg"><span>about the hypothetical EndOfLife Policy </span></span><span class="diff-add"><span>assertion, it may or may not mark that assertion with wsp:Optional="true" in the first version. If it does include</span></span><span class="diff-del"><span>ignore </span></span>the assertion, <span class="diff-chg"><span>marks </span></span><span class="diff-add"><span>the assertion with wsp:Ignorable="true" and wsp:Optional="false", then a client that:</span></span></p><ul><li><p><span class="diff-add"><span>does not know about the assertion and</span></span><span class="diff-del"><span>those </span></span>using <span class="diff-add"><span>lax intersection will produce an intersection.</span></span></p></li><li><p><span class="diff-add"><span>does not know about the assertion and using
+ </span></span>strict <span class="diff-add"><span>intersection will not produce an intersection. </span></span></p></li><li><p><span class="diff-add"><span>does know about</span></span><span class="diff-del"><span>intersection, </span></span>the <span class="diff-chg"><span>assertion and using strict or </span></span><span class="diff-add"><span>lax intersection will produce an intersection. </span></span></p></li></ul><p>
+<span class="diff-add"><span>If it does include</span></span><span class="diff-del"><span>contain </span></span>the <span class="diff-add"><span>assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="true", then a client that:</span></span></p><ul><li><p><span class="diff-add"><span>does or
+ </span></span><span class="diff-del"><span>policy </span></span><span class="diff-add"><span>does not know about the </span></span>assertion <span class="diff-add"><span>and using lax or strict intersection will produce an intersection.</span></span><span class="diff-del"><span>type. </span></span></p></li></ul><p><span class="diff-add"><span>The following table summarizes the requester assertion knowledge and intersection mode on the left vs provider ignorable and optional on the top</span></span></p><table summary="Requester assertion knowledge and intersection mode vs provider ignorable and optional" border="true"><tbody><tr><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Requester \ Provider</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">wsp:Ignorable="false", wsp:Optional="false"</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">wsp:Ignorable="true", wsp:Optional="false"</td></div><div class="diff-add"><td rowspan="" colspan="1" class="diff-add">wsp:Ignorable="false", wsp:Optional="true"</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">wsp:Ignorable="true", wsp:Optional="true"</td></div></tr><tr><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">does not know, lax</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">No</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div></tr><tr><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">does not know, strict</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">No</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">No</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colsan="1" class="diff-add">Yes</td></div></tr><tr><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">does know, lax</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div></tr><tr><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">does know, strict</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Yes</td></div></tr></tbody></table><br><p>If Company-X adds the <span class="diff-add"><span>hypothetical EndOfLife </span></span>policy assertio type to a subsequent <span class="diff-add"><span>Alternative and does not mark the assertion with wsp:Optional="true",</span></span><span class="diff-del"><span>alternative, </span></span>then <span class="diff-add"><span>after the policy expression has been deployed/used the same algorithm holds</span></span><span class="diff-del"><span>requesters </span></span><span class="diff-add"><span>true, notably that a client </span></span>using strict mode <span class="diff-add"><span>that does</span></span>not understand the assertion <span class="diff-add"><span>will not intersect
+with the alternative. If CompanyX adds the hypothetical EndOfLife policy assertion with an ignorable attribute</span></span><span class="diff-del"><span>type </span></span>and <span class="diff-add"><span>does mark </span></span>the <span class="diff-add"><span>assertion with wsp:Optional="true", then clients using strict mode who do not understand the hypothetical EndOfLife assertion</span></span><span class="diff-del"><span>alternative </span></span>with the ignorable information will <span class="diff-chg"><span>still </span></span>be compatible with the <span class="diff-chg"><span>alternative that </span></span><span class="diff-add"><span>does not</span></span><span class="diff-del"><span>of </span></span><span class="diff-add"><span>contain </span></span>the <span class="diff-add"><span>hypothetical EndOfLife policy</span></span><span class="diff-del"><span>alternative </span></span><span class="diff-add"><span>assertion </span></span>as per the intersection <span class="diff-chg"><span>rules and /span></span>the <span class="diff-chg"><span>server can return an error if the </span></span><span class="diff-add"><span>request is</span></span><span class="diff-del"><span>have </span></span><span class="diff-add"><span>received after </span></span>the
+ <span class="diff-del"><span>ignorable </span></span><span class="diff-add"><span>expiry date.</span></span></p><p><span class="diff-add"><span>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under</span></span><span class="diff-del"><span>policy </span></span><span class="diff-add"><span>any mode by marking the </span></span>assertion <span class="diff-chg"><span>with </span></span><span class="diff-add"><span>wsp:Optional="true". Clients</span></span><span class="diff-del"><span>in </span></span><span class="diff-add"><span>that know about </span></span>the <span class="diff-chg"><span>hypothetical EndOfLife Policy </span></span><span class="diff-add"><span>assertion and</span></span><span class="diff-del"><span>of </span></span><span class="diff-add"><span>performing strict intersection can guarantee interaction with services that know or don't know abou </span></span>the <span class="diff-add"><span>hypothetical</span></span><span class="diff-del"><span>alternative.
+ The </span></span><span class="diff-chg"><span>EndOfLife Policy assertion by </span></span><span class="diff-add"><span>marking the assertion with wsp:Optional="true". Clients that know about</span></span><span class="diff-del"><span>contains </span></span>the hypothetical EndOfLife <span class="diff-add"><span>Policy</span></span><span class="diff-del"><span>policy
+ Assertion </span></span><span class="diff-add"><span>assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
+</span></span></p><p><span class="diff-del"><span>type.
+ </span></span>Because the actual value <span class="diff-add"><span>of the</span></span><span class="diff-del"><span>is </span></span><span class="diff-add"><span>date/time may </span></span>not <span class="diff-add"><span>be known when the policy expression is first created,</span></span><span class="diff-del"><span>known, </span></span>a value that is roughly infinitely in the future is used. A subsequent policy alternative could refine the <span class="diff-add"><span>value and domain specific processing of the assertion can differentiate the </span></span>value.
+
+
+
+ The advantage of adding the end of life information <span class="diff-add"><span>through a domain specific assertion </span></span>is that some clients will have a machine processable way of knowing when the alternative will no longer be <span class="diff-add"><span>supported by evaluating the policy assertions in a policy expression.
+ </span></span><span class="diff-del"><span>supported. </span></span>Without this <span class="diff-add"><span>information in a policy expression,</span></span><span class="diff-del"><span>information, </span></span>the information must be conveyed in some other way or it will not be conveyed at all. This can usefully smooth the transition between <span class="diff-add"><span>versions of a service. </span></span></p><p><span class="diff-add"><span>The disadvantage of adding the end of life information through a domain specific assertion is that clients need to understand the semantics of the hypothetical EndOfLife assertion in order to know whether a particular alternative is still valid. For example, a client that doesn’t know what the parameter “Mar-31-2008” means, will not know that the service is no longer available on April 1, and may send messages to this service in April, and if the service enforces “end of life”, these messages may fail.
+</span></span><span class="diff-del"><span>versions.
+ </span></span></p></div></div></div><div class="div2">
<h3><a name="parts-of-a-policy-assertion" id="parts-of-a-policy-assertion"></a>3.9 Parts of a Policy Assertion</h3><p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
or condition. A policy assertion has a QName that identifies its behavior or requirement
or condition. A policy assertion may contain assertion parameters and a nested policy.</p><p>Let us look at the anatomy of a policy assertion from the security domain. The policy
@@ -1574,7 +1590,7 @@
for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue 4300</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</a>.
- </td></tr><tr><td rowspan="1" colspan="1">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Formatted the example in <a href="#ignorable-and-versioning"><b>3.8.1 Ignorable and Versioning</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070322</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Deleted residual text in <a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a>; <code>s/The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:/The possible extensibility points are:/</code> ; <code>s/PolicyReference: any attribute and a proposal to add any element/PolicyReference: any attribute and any element/</code>.</td></tr><div class="iff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070426</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">PY</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Editorial changes to align with the OASIS WS-SecurityPolicy specification.
+ </td></tr><tr><td rowspan="1" colspan="1">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070321</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Formatted the example in <a href="#ignorable-and-versioning"><b>3.8.3 Use of Ignorable attribute and an alternative Versioning Scenario</b></a>. </td></tr><tr><td rowspan="1" colspan="1">20070322</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Deleted residual text in <a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a>; <code>s/The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:/The possible extensibility points are:/</code> ; <code>s/PolicyReference: any attribute and a proposal to add any element/PolicyReference: any attribute and ay element/</code>.</td></tr><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070426</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">PY</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Editorial changes to align with the OASIS WS-SecurityPolicy specification.
For <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4318"><span class="diff-add"><span>issue 4318</span></span></a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/244"><span class="diff-add"><span>244</span></span></a>.
@@ -1582,4 +1598,10 @@
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239"><span class="diff-add"><span>239</span></span></a>.
</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070501</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Reset Section <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070502</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">TIB</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Further changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393"><span class="diff-add"><span>issue 4393</span></span></a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239"><span class="diff-add"><span>239</span></span></a>.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20070502</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">DBO</td></div><div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Finished changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414"><span class="diff-add"><span>issue 4414</span></span></a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239"><span class="diff-add"><span>239</span></span></a>.
</td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Monday, 7 May 2007 21:42:37 UTC