- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 17 Jun 2007 05:14:31 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv4024
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Implemented Editors' action 289.
Implemented the resolution for issue 4074. Editors' action 286.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -d -r1.75 -r1.76
--- ws-policy-guidelines.html 1 Jun 2007 19:01:27 -0000 1.75
+++ ws-policy-guidelines.html 17 Jun 2007 05:14:27 -0000 1.76
@@ -119,7 +119,7 @@
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
2. <a href="#best-practices-list">List of Best Practice Statements</a><br>
3. <a href="#Assertions">What is an Assertion? </a><br>
-4. <a href="#d3e265">Who is involved in authoring Assertions? </a><br>
+4. <a href="#assertion-authors">Who is involved in authoring Assertions? </a><br>
4.1 <a href="#roles"> Roles and Responsibilities </a><br>
4.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
4.1.2 <a href="#consumers">Consumers</a><br>
@@ -139,9 +139,9 @@
5.5.1 <a href="#doc-ignorable-assertions">Assertions and Ignorable Behavior</a><br>
5.5.2 <a href="#XML-ignorable-assertions">XML Outline for Ignorable </a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e767">Optional behavior in Compact authoring</a><br>
- 5.6.2 <a href="#d3e807">Optional behavior at runtime</a><br>
- 5.6.2.1 <a href="#d3e852">Example</a><br>
+ 5.6.1 <a href="#d3e768">Optional behavior in Compact authoring</a><br>
+ 5.6.2 <a href="#d3e808">Optional behavior at runtime</a><br>
+ 5.6.2.1 <a href="#d3e853">Example</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
5.8 <a href="#interrelated-domains">Interrelated domains</a><br>
6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
@@ -208,9 +208,9 @@
the Socratic style of beginning with a question, and then answering
the question.
</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-specification-parts"><b>1. Parts of an Assertion Specification</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>2. Semantics Independent of
- Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>6. Specify Semantics Clearly</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML Outline</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>10. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Assertion description should explicitly indicate that wsp:Optional is allowed.</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 essage 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-WSDL-policy-subject"><b>21. Assertion Authors Should Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions fo Different Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></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-semantics-and-form"><b>2. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>3. Start with Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>4. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>5. Provide an XML Outline</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>6. Specify Semantics Clearly</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>7. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>8. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>9. Use Parameters for Useful
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>10. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>11. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>12. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>13. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>14. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>15. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>16. Assertion description should explicitly indicate that wsp:Optional is allowed.</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>17. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>18. Consider entire essage exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>19. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>20. Assertion Authors Should Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>21. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>22. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>23. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>24. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>25. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>26. Use Independent Assertions fo Different Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>27. Change of the Policy Subject Over Time</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
are typically defined in a dedicated specification that describes
@@ -269,7 +269,7 @@
best practices will be an assertion specification that describes
a contract for the consumers and providers of the capabilities and constraints of the domain.
</p></div><div class="div1">
-<h2><a name="d3e265" id="d3e265"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="assertion-authors" id="assertion-authors"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
@@ -305,7 +305,8 @@
description should specify a WSDL policy subject.
</p><p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
specification [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]. The
- WS-SecurityPolicy authors have defined their scope as follows:
+ WS-SecurityPolicy authors have defined the scope of their
+ target domain (security) as follows:
</p><p><em>"This document [WS-SecurityPolicy] defines a set of
security policy assertions for use with the WS-Policy
framework with respect to security features provided in WSS:
@@ -390,14 +391,16 @@
For example, if an assertion applies to the SOAP protocol, it would be necessary
to consider how its presence must interact with other policy assertions that
are defined for security.
- </p><div class="boxedtext"><p><a name="bp-assertion-specification-parts" id="bp-assertion-specification-parts"></a><span class="practicelab">Best
-Practice 1: Parts of an Assertion Specification</span></p><p class="practice">
- Assertion Authors should include the following items in an
- assertion specification: </p></div><p>
- <ul><li><p><em>The definition of the assertion's semantic.</em> </p></li><li><p><em>The specification of the set of valid policy subjects to which an
- assertion may be attached.</em></p></li><li><p><em>The scope of the assertion in the context of a particular policy
- subject.</em></p></li><li><p><em>Any composition considerations if the assertion is used with
- other assertions in a context.</em></p></li></ul>
+ </p><p>Assertion Authors should include the following items in an
+ assertion specification:
+ </p><p>
+ <ul><li><p>The definition of the assertion's semantic
+ (See best practice <a href="#AssertionDefinitions"><b>6. 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>20. Assertion Authors Should Specify 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 in WSDL </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>25. 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
@@ -416,7 +419,7 @@
allows policy tools to choose the most appropriate mechanism to attach a
policy without having to analyze the contents of the policy.
</p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Best
-Practice 2: Semantics Independent of
+Practice 1: Semantics Independent of
Attachment Mechanisms</span></p><p class="practice">
The semantics of a policy assertion should not depend on the
attachment mechanism used.</p></div><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">April 25th 07, editors
@@ -448,7 +451,7 @@
description for a policy assertion should not depend on the style used
to author a policy expression that contains the assertion.
</p><div class="boxedtext"><p><a name="bp-semantics-and-form" id="bp-semantics-and-form"></a><span class="practicelab">Best
-Practice 3: Semantics Independent of the Form</span></p><p class="practice">The semantics of an assertion should be independent of
+Practice 2: Semantics Independent of the Form</span></p><p class="practice">The semantics of an assertion should be independent of
the form (compact or normal form) of policy expressions that contain the
assertion.</p></div><p>
In the example below, the policy expression is shown in its two forms,
@@ -545,19 +548,38 @@
work progresses, one may add more parameters or nested policy assertions
to meet one's interoperability needs.
</p><div class="boxedtext"><p><a name="bp-assertion-start" id="bp-assertion-start"></a><span class="practicelab">Best
-Practice 4: Start with Simple Assertion</span></p><p class="practice">Assertion Authors should start with a simple working assertion
+Practice 3: Start with Simple Assertion</span></p><p class="practice">Assertion Authors should start with a simple working assertion
that allows assertion parameter extensibility. </p></div><p>New Assertion Authors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex domain that has been decomposed into a set of policy expressions.
</p></div><div class="div3">
<h4><a name="QName_and_XML_Information_Set_representation" id="QName_and_XML_Information_Set_representation"></a>5.3.2 QName and XML Information Set representation</h4><p>Web Services Policy language allows Assertion Authors to invent
their own XML dialects to represent policy assertions. The policy language relies only
on the policy assertion XML element QName. This QName is unique and identifies the
- behavior represented by a policy assertion. Assertion Authors have the option to
+ behavior represented by a policy assertion. Assertion Authors have the option to
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
- versus attributes apply is. Use a unique QName to identify a distinct behavior and provide
- an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Best
-Practice 5: Use Unique QNames</span></p><p class="practice">Assertion Authors should use a unique QName to identify a distinct behavior.</p></div><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
+ versus attributes apply is: Use a unique QName to identify a distinct behavior </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Best
+Practice 4: Use Unique QNames</span></p><p class="practice">Assertion Authors should use a unique QName to identify a distinct behavior.</p></div><p> and provide
+ an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
+Practice 5: Provide an XML Outline</span></p><p class="practice"> An assertion description should provide an XML outline plus an XML schema to specify the
+ syntax of the assertion.
+ </p></div><p> An example of this method (below) is given in the Web Services Reliable Messaging Policy document. [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]
+ </p><div class="exampleOuter"><div class="exampleInner"><pre>
+ <wsrmp:RMAssertion [wsp:Optional="true"]? ...>
+ <wsp:Policy >
+ [ <wsrmp:SequenceSTR/> |
+ <wsrmp:SequenceTransportSecurity/> ] ?
+ <wsrmp:DeliveryAssurance/>
+ <wsp:Policy >
+ [ <wsrmp:ExactlyOnce/> |
+ <wsrmp:AtLeastOnce/> |
+ <wsrmp:AtMostOnce/> ]
+ <wsrmp:InOrder/> ?
+ </wsp:Policy>
+ </wsrmp:DeliveryAssurance> ] ?
+ </wsp:Policy>
+ </wsrmp:RMAssertion/>
+ </pre></div></div><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
document). If the assertion has a nested policy expression then the assertion XML
outline can enumerate the nested assertions that are allowed. An example is the following:
</p><div class="exampleOuter"><div class="exampleInner"><pre>
@@ -578,14 +600,7 @@
</pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Best
Practice 6: Specify Semantics Clearly</span></p><p class="practice"> An assertion description should clearly and completely specify the semantics of a policy
assertion.
- </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
-Practice 7: Provide an XML Outline</span></p><p class="practice"> An assertion description should provide an XML outline plus an XML schema to specify the
- syntax of the assertion.
- </p></div><div class="exampleOuter"><div class="exampleInner"><pre>
- <wsrmp:RMAssertion [wsp:Optional="true"]? ...>
- ...
- </wsrmp:RMAssertion/>
- </pre></div></div></div><div class="div3">
+ </p></div></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
@@ -616,7 +631,7 @@
their assertions by specifying additional properties, headers,
etc. that must be present in a message as part of their assertion design.
</p><div class="boxedtext"><p><a name="bp-not-necessary-to-understand-a-message" id="bp-not-necessary-to-understand-a-message"></a><span class="practicelab">Best
-Practice 8: Not Necessary to Understand a Message</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
+Practice 7: Not Necessary to Understand a Message</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
in policy that isn't attached to the message, it isn't possible
to later decipher it. This is very different from expressing, in
policy, what ciphers (and so forth) are supported by a particular
@@ -646,7 +661,7 @@
</p><p>It is the responsibility of the Assertion Authors to avoid duplication of assertions.
A review by a broad community is the best way to ensure that the granularity of a set
of domain assertions is appropriate.</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Best
-Practice 9: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
+Practice 8: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
<h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
assertion beyond its type. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the approach.
@@ -661,7 +676,7 @@
domain specific processing for policy intersection.</p><p>In the XML representation of a policy assertion, the child elements
and attributes of the assertion excluding child elements and attributes
from the policy language namespace name are the assertion parameters.</p><div class="boxedtext"><p><a name="bp-assertion-parameters" id="bp-assertion-parameters"></a><span class="practicelab">Best
-Practice 10: Use Parameters for Useful
+Practice 9: Use Parameters for Useful
Information</span></p><p class="practice">Assertion Authors should represent useful (or additional)
information necessary for engaging the behavior represented by a policy
assertion as assertion parameters.
@@ -680,11 +695,7 @@
</wsp:Policy></pre></div></div></div><div class="div3">
<h4><a name="nested-assertions" id="nested-assertions"></a>5.4.2 Nested Assertions</h4><p>The framework provides the ability to "nest" policy assertions. For domains with a complex set of
options, nesting provides one way to indicate dependent
- elements within a behavior. The granularity of assertions is
- determined by the authors and it is recommended that care be
- taken when defining nested policies to ensure that the options
- provided appropriately specify policy alternatives within a specific behavior.
- </p><p>
+ elements within a behavior.</p><p>
The following design questions below can help
to determine when to use nested policy expressions:</p><ul><li><p>Are these assertions designed for the same policy subject? </p></li><li><p>Do these assertions represent dependent behaviors?</p></li></ul><p>If the answers are yes to both of these questions then leveraging nested policy
expressions is something to consider. Keep in mind that a nested policy expression participates in
@@ -695,10 +706,10 @@
that are allowed. There is one caveat to watch out for: policy assertions
with deeply nested policy can greatly increase the complexity of a policy and should be
avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Best
-Practice 11: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant
+Practice 10: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant
to a compatibility test and apply to the same policy subject using
nested policy assertions.</p></div><div class="boxedtext"><p><a name="bp-declare-nested-assertions" id="bp-declare-nested-assertions"></a><span class="practicelab">Best
-Practice 12: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors
+Practice 11: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors
should enumerate the nested policy assertions that are allowed.</p></div><p>The main consideration for selecting parameters or nesting
of assertions is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
@@ -720,7 +731,7 @@
delegated to the specific domain handlers that are not visible
to the WS-Policy framework. However, domain specific intersection processing reduces
interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Best
-Practice 13: Discourage Domain Specific Intersection</span></p><p class="practice">An
+Practice 12: Discourage Domain Specific Intersection</span></p><p class="practice">An
assertion description should only specify domain specific intersection
semantics when policy intersection is insufficient.</p></div><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
</p><p>Securing messages is a complex usage scenario. The WS-SecurityPolicy Assertion Authors have defined the
@@ -816,15 +827,15 @@
of the ignorable attribute.
</p><div class="div3">
<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
-Practice 14: Assertions Document Ignorable Behavior</span></p><p class="practice"> An assertion description should use the wsp:Ignorable attribute
+Practice 13: Assertions Document Ignorable Behavior</span></p><p class="practice"> An assertion description should use the wsp:Ignorable attribute
to indicate that the behavior indicated by the QName may be ignored by policy intersection.
</p></div></div><div class="div3">
<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
-Practice 15: Ignorable Attribute in XML</span></p><p class="practice"> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
+Practice 14: Ignorable Attribute in XML</span></p><p class="practice"> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
to indicate ignorable behavior.
</p></div></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="d3e767" id="d3e767"></a>5.6.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
+<h4><a name="d3e768" id="d3e768"></a>5.6.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
compact authoring form for assertions, such behaviors are marked by
using <code>wsp:Optional</code> attribute with a value of
"true". (In order to simplify reference to such assertions,
@@ -839,7 +850,7 @@
the wsp:Optional attribute. Assertion Authors should clearly indicate in the assertion
definition that it is possible to be optional
and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
-Practice 16: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to
+Practice 15: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to
indicate optional behaviors.</p></div><p>To give a general example, the definition of assertion syntax for a hypothetical assertion such as SampleAssertion,
should allow attribute extensibility as part of the XML definition, allowing the wsp:Optional attribute to be used:
</p><div class="exampleOuter">
@@ -847,7 +858,7 @@
This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
</pre></div></div><p>The portion of the assertion definition that describes policy subjects and assertion attachment should indicate
that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Best
-Practice 17: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the
+Practice 16: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the
behavior indicated by the QName is optional for the associated policy subject.</p></div><p>Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should
include discussion of optionality.
</p><div class="exampleOuter">
@@ -855,14 +866,14 @@
it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port.
The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.
</pre></div></div></div><div class="div3">
-<h4><a name="d3e807" id="d3e807"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e808" id="d3e808"></a>5.6.2 Optional behavior at runtime</h4><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
consumer to select the policy alternative that does not contain the assertion,
and thus not engaging the behavior.
</p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Best
-Practice 18: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present
+Practice 17: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present
in compatible policy expressions.</p></div><p> The target scope of an optional assertion is an important factor for
Assertion Authors to consider as it determines the
<em>granularity</em> where the behavior is optionally
@@ -894,7 +905,7 @@
assertions and require the use of endpoint policy subject
when message policy subject is used via attachment.
</p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Best
-Practice 19: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest
+Practice 18: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest
possible granularity to limit the degree to which optionality applies.</p></div><p>
Behaviors must be engaged
with respect to messages that are targeted to the provider
@@ -908,9 +919,9 @@
(Such an out of band mechanism is outside the scope of WS-Policy
Framework).
</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Best
-Practice 20: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
+Practice 19: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
either out of band or as reflected by the message content.</p></div><div class="div4">
-<h5><a name="d3e852" id="d3e852"></a>5.6.2.1 Example</h5><p>
+<h5><a name="d3e853" id="d3e853"></a>5.6.2.1 Example</h5><p>
The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the
use of
<cite><a href="#MTOM">MTOM</a></cite> as an optional behavior that can be engaged by a consumer.
@@ -947,7 +958,7 @@
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 21: Assertion Authors Should Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which
+Practice 20: Assertion Authors Should Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant 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.
@@ -980,7 +991,7 @@
policy attachments to 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 22: Choose the Most Granular Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular policy subject
+Practice 21: Choose the Most Granular Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular policy subject
to which the behavior represented by a policy assertion applies.
</p></div><p>
For authoring convenience, Assertion Authors may allow the
@@ -991,32 +1002,13 @@
same assertion attached to different policy subjects at the same
time in order to avoid conflicting 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 23: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy
+Practice 22: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy
subjects, the assertion description should describe the semantics of multiple
instances of the same assertion attached to multiple policy subjects
at the same time.
</p></div><p>If the capability is not really suitable and may imply
different semantics with respect to attachment points, the
- Assertion Authors should consider the following:</p><ul><li><p> Decompose the semantics with several assertions.</p></li><li><p> Rewrite a single assertion targeting a specific subject. </p></li></ul><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 following paragraph is likely to change,
- as there is an issue 4074, open against this paragraph.
- </td></tr></table>
- </p><p>The current set of subjects as mapped to the WSDL 1.1
- elements, can also constrain the assertion constructs.
- For Example, in WS-RM, the Assertion Authors chose to support
- certain capabilities at the endpoint level. This resulted in
- the finer granularity of the assertion to apply at the message
- policy subject, but the assertion semantics also indicates that
- the if a sender chose to engage RM semantics (although not specified
- via attachment in WSDL at incoming messages), the providers will honor
- the engagement of RM. So, the WS-RM Policy is a capability that
- governs a target endpoints capability to accept sequences that
- is beyond single message exchanges. This is illustrative of how the
- Assertion Authors can specify additional constraints and assumptions
- for attachment and engagement of behavior. Such additional constraints
- should be clearly specified by the Assertion Authors.
- </p><p>Since many attachment points are available in WSDL, it would be
+ Assertion Authors should consider the following:</p><ul><li><p> Decompose the semantics with several assertions.</p></li><li><p> Rewrite a single assertion targeting a specific subject. </p></li></ul><p>Since many attachment points are available in WSDL, it would be
necessary for Assertion Authors to recommend a preferred attachment
point. One approach would be to identify different attachment points in
a policy subject, choose the most granular policy subject that the
@@ -1032,7 +1024,7 @@
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 24: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple attachment points
+Practice 23: Specify Preferred Attachment Point for an Assertion</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
@@ -1051,7 +1043,7 @@
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 25: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the
+Practice 24: 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. An assertion description 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
@@ -1070,7 +1062,7 @@
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 26: Specify Composition with Related Assertions</span></p><p class="practice">An assertion description should clearly specify how the assertion may compose
+Practice 25: Specify Composition with Related Assertions</span></p><p class="practice">An assertion description should clearly specify how the assertion may compose
with other related assertions, if any.</p></div></div></div><div class="div1">
<h2><a name="versioning-policy-assertions" id="versioning-policy-assertions"></a>6. Versioning Policy Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
how they anticipate new assertions being added to the set. There are three aspects to versioning policy assetions:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
@@ -1100,7 +1092,7 @@
[<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 27: Use Independent Assertions for Different Versions of a Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different
+Practice 26: Use 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
WSS: SOAP Message Security 1.0. </p><div class="exampleOuter">
@@ -1113,7 +1105,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 <a href="#bp-assertion-specification-parts">Best Practice: Parts of an Assertion Specification</a> specifies that policy authors should
+ The best practice <a href="#bp-WSDL-policy-subject"><b>20. Assertion Authors Should Specify 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
@@ -1129,7 +1121,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 28: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time,
+Practice 27: Change of the Policy Subject Over Time</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 class="div1">
<h2><a name="best-practices-attachment" id="best-practices-attachment"></a>7. Applying Best Practices for Policy Attachment</h2><div class="div2">
@@ -1245,6 +1237,7 @@
can utilize them. In this case, the WS-SecurityPolicy Assertion Authors
factored out common elements of security mechanisms and utilized a
feature of WS-Policy called "nested" assertions. In the case of
+
an <code>sp:TransportBinding</code> assertion, just indicating the use of
transport-level security for protecting messages is not
sufficient. For a consumer of a web service provided by a company,
@@ -1675,12 +1668,12 @@
are reflected.
</td></tr><tr><td rowspan="1" colspan="1">20070518</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="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 rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a> (from
+ </td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-specify-composition"><b>25. 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
Section <a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a> needs to be re-structured.
- </td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a> (from
+ </td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-not-necessary-to-understand-a-message"><b>7. Not Necessary to Understand a Message</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="#self-describing"><b>5.3.3 Self Describing Messages </b></a>.
@@ -1718,4 +1711,13 @@
</td></tr><tr><td rowspan="1" colspan="1">20070601</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Implemented Resolution in Editors' actions
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/310">310</a> and
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/311">311</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">200706013</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented Resolution in Editors' actions
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/292">292</a> and
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/293">293</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">200706016</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/289">289</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070616</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the resolution
+ for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4074">4074</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/286">286</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -d -r1.90 -r1.91
--- ws-policy-guidelines.xml 13 Jun 2007 19:16:19 -0000 1.90
+++ ws-policy-guidelines.xml 17 Jun 2007 05:14:27 -0000 1.91
@@ -259,7 +259,7 @@
</p>
</div1>
- <div1>
+ <div1 id="assertion-authors">
<head>Who is involved in authoring Assertions? </head>
<p>In order for the policy framework to enable communities to
@@ -307,7 +307,8 @@
</p>
<p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
specification [<bibref ref="WS-SecurityPolicy"/>]. The
- WS-SecurityPolicy authors have defined their scope as follows:
+ WS-SecurityPolicy authors have defined the scope of their
+ target domain (security) as follows:
</p>
<p><emph>"This document [WS-SecurityPolicy] defines a set of
security policy assertions for use with the WS-Policy
@@ -440,20 +441,21 @@
are defined for security.
</p>
- <p role="practice" id="bp-assertion-specification-parts"><quote>Parts of an Assertion Specification</quote>
- <quote>
- Assertion Authors should include the following items in an
- assertion specification: </quote>
+ <p>Assertion Authors should include the following items in an
+ assertion specification:
</p>
<p>
<ulist>
- <item><p><emph>The definition of the assertion's semantic.</emph> </p></item>
- <item><p><emph>The specification of the set of valid policy subjects to which an
- assertion may be attached.</emph></p></item>
- <item><p><emph>The scope of the assertion in the context of a particular policy
- subject.</emph></p></item>
- <item><p><emph>Any composition considerations if the assertion is used with
- other assertions in a context.</emph></p></item>
+ <item><p>The definition of the assertion's semantic
+ (See best practice <specref ref="AssertionDefinitions"/>).</p></item>
+ <item><p>The specification of the set of valid policy subjects to which an
+ assertion may be attached
+ (See best practice <specref ref="bp-WSDL-policy-subject"/>).</p></item>
+ <item><p>The scope of the assertion in the context of a particular policy
+ subject (See best practices in Section <specref ref="levels-of-abstraction"/>).</p></item>
+ <item><p>Any composition considerations if the assertion is used with
+ other assertions in a context
+ (See best practice <specref ref="bp-specify-composition"/>).</p></item>
</ulist>
</p>
@@ -851,11 +853,7 @@
<head>Nested Assertions</head>
<p>The framework provides the ability to "nest" policy assertions. For domains with a complex set of
options, nesting provides one way to indicate dependent
- elements within a behavior. The granularity of assertions is
- determined by the authors and it is recommended that care be
- taken when defining nested policies to ensure that the options
- provided appropriately specify policy alternatives within a specific behavior.
- </p>
+ elements within a behavior.</p>
<p>
The following design questions below can help
to determine when to use nested policy expressions:</p>
@@ -1323,31 +1321,6 @@
</item>
</ulist>
- <p>
- <ednote>
- <edtext>
- The following paragraph is likely to change,
- as there is an issue 4074, open against this paragraph.
- </edtext>
- </ednote>
- </p>
-
- <p>The current set of subjects as mapped to the WSDL 1.1
- elements, can also constrain the assertion constructs.
- For Example, in WS-RM, the Assertion Authors chose to support
- certain capabilities at the endpoint level. This resulted in
- the finer granularity of the assertion to apply at the message
- policy subject, but the assertion semantics also indicates that
- the if a sender chose to engage RM semantics (although not specified
- via attachment in WSDL at incoming messages), the providers will honor
- the engagement of RM. So, the WS-RM Policy is a capability that
- governs a target endpoints capability to accept sequences that
- is beyond single message exchanges. This is illustrative of how the
- Assertion Authors can specify additional constraints and assumptions
- for attachment and engagement of behavior. Such additional constraints
- should be clearly specified by the Assertion Authors.
- </p>
-
<p>Since many attachment points are available in WSDL, it would be
necessary for Assertion Authors to recommend a preferred attachment
point. One approach would be to identify different attachment points in
@@ -1513,7 +1486,7 @@
<div2 id="supporting-new-policy-subjects">
<head>Supporting New Policy Subjects</head>
<p>
- The <loc href="#bp-assertion-specification-parts">Best Practice: Parts of an Assertion Specification</loc> specifies that policy authors should
+ The best practice <specref ref="bp-WSDL-policy-subject"/> 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
@@ -2693,7 +2666,23 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/292">292</loc> and
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/293">293</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>200706016</td>
+ <td>ASV</td>
+ <td>Implemented Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/289">289</loc>.
+ </td>
+ </tr>
+ <tr>
+ <td>20070616</td>
+ <td>ASV</td>
+ <td>Implemented the resolution
+ for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4074">4074</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/286">286</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Sunday, 17 June 2007 05:14:43 UTC