- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 17 Oct 2007 20:16:12 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv21595
Modified Files:
guidelines-bestpractices.xml ws-policy-guidelines.html
ws-policy-guidelines.xml
Log Message:
Implemented the resolution for issue 5185. Editors' action 373.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -d -r1.109 -r1.110
--- ws-policy-guidelines.html 17 Oct 2007 19:34:23 -0000 1.109
+++ ws-policy-guidelines.html 17 Oct 2007 20:16:09 -0000 1.110
@@ -125,10 +125,10 @@
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="#d3e822">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d3e835">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d3e809">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d3e822">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e850">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d3e837">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>
@@ -192,12 +192,11 @@
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-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. Assertion Authors should 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-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 Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>23. Levrage Defined Attachment 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 subjects</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 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
+<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-compatibility-tests"><b>1. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>2. Mark Ignorable Assertions not related to compatibility</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 a 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="#XMLOutline"><b>6. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>8. Document Ignorable Behavior</b></a></p></li><li><p><a hrf="#ignorableAssertions"><b>9. Document Use of the Ignorable
+Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>10. Assertion Authors should allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>11. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>12. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>13. Use Parameters for Useful
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>14. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>15. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>16. Discourage Domain Specific Intersection</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 message 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-assertion-semantics"><b>20. Semantics Independent of Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>21. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attacment-mechanisms"><b>22. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>23. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>24. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>26. Consider Scope of Attachment Points</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>27. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>28. Define Rules for Attachment of an Assertion
+ type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>29. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-UDDI-tmodels"><b>30. Use defined tModels when appropriate</b></a></p></li><li><p><a href="#bp-specify-composition"><b>31. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>32. Independent Assertions for Different Versions of a
+ Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>33. 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
@@ -382,12 +381,12 @@
assertion specification:
</p><p>
<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
+ (See best practice <a href="#AssertionDefinitions"><b>7. 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>26. Specify WSDL 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>25. 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>32. Specify Composition with Related Assertions</b></a>).</p></li></ul>
+ (See best practice <a href="#bp-specify-composition"><b>31. 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
@@ -395,25 +394,11 @@
Additionally, the framework provides for the means to extend the set of
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
- </p><p>Although a policy
- 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 semantics 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
- 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 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><div class="boxedtext"><p><a name="bp-compatibility-tests" id="bp-compatibility-tests"></a><span class="practicelab">Best
-Practice 2: Define assertions relevant to compatibility tests</span></p><p class="practice">
+ </p><div class="boxedtext"><p><a name="bp-compatibility-tests" id="bp-compatibility-tests"></a><span class="practicelab">Best
+Practice 1: Define assertions relevant to compatibility tests</span></p><p class="practice">
Assertion authors should define assertions for behaviors that are relevant to compatibility assessment, such as web service protocols that manifest on the wire.
</p></div><p>Assertion authors may define assertions that are not related to compatibility assessment. These assertions may be used to accurately describe behaviour, even if they do not affect compatibility. WS-Policy has the wsp:Ignorable attribute that may be used for indicating assertions that are not related to compatibility assessment, described in <a href="#Ignorable"><b>5.5 Designating Ignorable Behavior</b></a></p><div class="boxedtext"><p><a name="bp-ignorable-for-not-related-to-compatibility-tests" id="bp-ignorable-for-not-related-to-compatibility-tests"></a><span class="practicelab">Best
-Practice 3: Mark Ignorable Assertions not related to compatibility</span></p><p class="practice">
+Practice 2: Mark Ignorable Assertions not related to compatibility</span></p><p class="practice">
Assertion authors should recommend that assertions that are not relevant to compatibility assessment be marked with the wsp:Ignorable attribute.
</p></div></div><div class="div2">
<h3><a name="compact-full" id="compact-full"></a>5.2 Authoring Styles </h3><p>WS-Policy supports two different authoring styles, compact form and
@@ -437,7 +422,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 4: Semantics Independent of the Form</span></p><p class="practice">The semantics of an assertion should be independent of
+Practice 3: 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,
@@ -534,7 +519,7 @@
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 5: Start with a Simple Assertion</span></p><p class="practice">Assertion Authors should start with a simple working assertion
+Practice 4: Start with a 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 Assertion</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">
@@ -545,8 +530,8 @@
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. 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 6: Use Unique QNames</span></p><p class="practice">Assertion Authors should use a unique QName to identify a distinct behavior.</p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
-Practice 7: Provide an XML definition</span></p><p class="practice">Assertion authors should provide an XML schema definition to
+Practice 5: Use Unique QNames</span></p><p class="practice">Assertion Authors should use a unique QName to identify a distinct behavior.</p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
+Practice 6: Provide an XML definition</span></p><p class="practice">Assertion authors should provide an XML schema definition to
specify the syntax of an assertion. A reader-friendly description such as an
XML outline (see below) is also useful.
</p></div><p> An example of a specification that provides an XML Outline is the Web Services
@@ -588,14 +573,14 @@
</sp:IssuedToken>
</pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Best
-Practice 8: Specify Semantics Clearly</span></p><p class="practice"> Assertion authors should clearly and completely specify the
+Practice 7: Specify Semantics Clearly</span></p><p class="practice"> Assertion authors should clearly and completely specify the
semantics of a policy assertion.
</p></div><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
-Practice 9: Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or
+Practice 8: Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or
constraint against the use of) the wsp:Ignorable attribute to indicate
whether or not the behavior indicated by the QName may be ignored by policy
intersection. </p></div><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
-Practice 10: Document Use of the Ignorable
+Practice 9: Document Use of the Ignorable
Attribute in XML </span></p><p class="practice"> An Assertion Author should document, in the XML outline and/or schema for
the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute.
</p></div><p>To give an example, the WS-ReliableMessaging Policy document specifies attribute extensibility as part of the XML definition, allowing the wsp:Ignorable attribute:
@@ -609,7 +594,7 @@
for the use of the <code>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><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Best
-Practice 11: Assertion Authors should allow use of wsp:Optional</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use
+Practice 10: Assertion Authors should allow 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>
@@ -663,7 +648,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 12: Define message format only</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 11: Define message format only</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
@@ -693,7 +678,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 13: 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 12: 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: assertion parameters and nested policy
expressions. We cover these two cases below followed by a comparison of these
@@ -711,7 +696,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 14: Use Parameters for Useful
+Practice 13: Use Parameters for Useful
Information</span></p><p class="practice">Assertion Authors should represent useful additive
information necessary for engaging the behavior represented by a policy
assertion as assertion parameters.
@@ -744,10 +729,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 15: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant
+Practice 14: 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 16: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors
+Practice 15: 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>Assertion Authors should recognize that the framework can
yield multiple assertions of the same type. The <em>QName</em>
of the assertion is the only vehicle for the framework to
@@ -765,7 +750,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 17: Discourage Domain Specific Intersection</span></p><p class="practice">Assertion authors should only specify domain specific
+Practice 16: Discourage Domain Specific Intersection</span></p><p class="practice">Assertion authors 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
<code>sp:TransportBinding</code> policy assertion to indicate
@@ -852,23 +837,23 @@
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="d3e822" id="d3e822"></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 compatibility 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="d3e809" id="d3e809"></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 compatibility 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>8. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>9. 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="d3e835" id="d3e835"></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="d3e822" id="d3e822"></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="d3e850" id="d3e850"></a>5.6.1 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e837" id="d3e837"></a>5.6.1 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
@@ -900,7 +885,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
@@ -914,7 +899,7 @@
(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><p>
The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the
use of
@@ -942,23 +927,19 @@
(<a href="#bp-entire-mep-for-optional">Best Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</a>).
</p></div></div><div class="div2">
<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.7 Considerations for Policy Attachment</h3><div class="div3">
-<h4><a name="general-attachment-guidelines" id="general-attachment-guidelines"></a>5.7.1 General Guidelines</h4><p>
- The Policy attachment mechanism used to
- 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. 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.
- </p><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><p>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. </p><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 Type</span></p><p class="practice">
+<h4><a name="general-attachment-guidelines" id="general-attachment-guidelines"></a>5.7.1 General Guidelines</h4><p>Although a policy 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 semantics 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 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 20: 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><p>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. </p><p>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.
+ </p><div class="boxedtext"><p><a name="bp-semantics-multiple-same-type" id="bp-semantics-multiple-same-type"></a><span class="practicelab">Best
+Practice 21: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">
Assertion Authors should specify the semantics of multiple instances
of the same policy assertion type in the same policy alternative and the
semantics of parameters and nested policy (if any) when there are
@@ -970,18 +951,18 @@
assertion of the type within the policy alternative.</p></div><p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> for more detail
on the processing for multiple assertions of the same type.</p><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 Attachment Mechanisms</span></p><p class="practice">
+Practice 22: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
Assertion Authors should leverage defined attachment models when
possible to document the use of the policy assertions they author and ensure
that there are no additional semantics implied by the defined
attachment models for their assertions.</p></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
+Practice 23: 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><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">
+Practice 24: 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
@@ -1018,7 +999,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 WSDL 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
+Practice 25: 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
a WSDL policy subject - such as service, endpoint, operation and message it should be stated.
</p></div><p>Assertion Authors that utilize WSDL policy subjects need to
@@ -1032,7 +1013,7 @@
portType element. Assertion Authors should identify the
relevant attachment point when defining a new assertion.
</p><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
+Practice 26: 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><p>
For example, an assertion should only be allowed in the portType element if
@@ -1052,7 +1033,7 @@
policy attachments to WSDL 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 28: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
+Practice 27: 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
@@ -1063,7 +1044,7 @@
when multiple instances of the same assertion are attached to different
WSDL 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 29: Define Rules for Attachment of an Assertion
+Practice 28: Define Rules for Attachment of an Assertion
type to Multiple WSDL policy subjects</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 WSDL policy subjects in
@@ -1091,7 +1072,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 30: Specify Preferred WSDL Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points
+Practice 29: 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
@@ -1118,7 +1099,7 @@
as a UDDI TModel. Assertion Authors defining new assertions should consider each
approach.
</p><div class="boxedtext"><p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class="practicelab">Best
-Practice 31: Use defined tModels when appropriate</span></p><p class="practice">UDDI defines the following policy subjects: Service Provider Policy,
+Practice 30: Use defined tModels when appropriate</span></p><p class="practice">UDDI defines the following policy subjects: Service Provider Policy,
Service Policy subject and Endpoint Policy subject.
</p></div><p>
When defining assertions and recommending a service provider policy
@@ -1133,7 +1114,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 32: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion
+Practice 31: 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
@@ -1176,7 +1157,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 33: Independent Assertions for Different Versions of a
+Practice 32: 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
@@ -1190,7 +1171,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>26. Specify WSDL Policy Subject(s)</b></a> specifies that policy authors should
+ The best practice <a href="#bp-WSDL-policy-subject"><b>25. 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
@@ -1206,7 +1187,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 34: Document changes to policy
+Practice 33: 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">
@@ -1544,12 +1525,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>32. 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>31. 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>12. Define message format only</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>11. Define message format only</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>.
@@ -1680,4 +1661,7 @@
</td></tr><tr><td rowspan="1" colspan="1">20071017</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5128">5128</a>. Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/371">371</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20071017</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5185">5185</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/373">373</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.125
retrieving revision 1.126
diff -u -d -r1.125 -r1.126
--- ws-policy-guidelines.xml 17 Oct 2007 19:34:23 -0000 1.125
+++ ws-policy-guidelines.xml 17 Oct 2007 20:16:09 -0000 1.126
@@ -466,22 +466,6 @@
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
</p>
- <p>Although a policy
- 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 semantics 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
- allows policy tools to choose the most appropriate mechanism to attach a
- policy without having to analyze the contents of the policy.
- </p>
- <p role="practice" id="bp-assertion-semantics"><quote>Semantics Independent of
- Attachment Mechanisms</quote><quote>
- The semantics of a policy assertion should not depend on the
- attachment mechanism used.</quote>
- </p>
<p role="practice" id="bp-compatibility-tests">
<quote>Define assertions relevant to compatibility tests</quote>
@@ -1227,27 +1211,25 @@
<head>Considerations for Policy Attachment</head>
<div3 id="general-attachment-guidelines">
<head>General Guidelines</head>
- <p>
- The Policy attachment mechanism used to
- 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. 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.
- </p>
-
- <p role="practice" id="bp-reusableAssertions">
- <quote>Reusable Assertions</quote><quote>
- Assertion Authors are encouraged to create policy assertions that
- can be used regardless of attachment mechanism.</quote> </p>
+ <p>Although a policy 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 semantics 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 allows policy tools to choose the most
+ appropriate mechanism to attach a policy without having to analyze the contents of the policy.</p>
+ <p role="practice" id="bp-assertion-semantics">
+ <quote>Semantics Independent of Attachment Mechanisms</quote>
+ <quote>The semantics of a policy assertion should not depend on the attachment mechanism used.</quote>
+ </p>
<p>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. </p>
+ <p>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.
+ </p>
<p role="practice" id="bp-semantics-multiple-same-type">
<quote>Describe Semantics of Multiple Assertions of Same Type</quote><quote>
Assertion Authors should specify the semantics of multiple instances
@@ -2758,6 +2740,14 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/371">371</loc>.
</td>
</tr>
+ <tr>
+ <td>20071017</td>
+ <td>FJH</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5185">5185</loc>. Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/373">373</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Index: guidelines-bestpractices.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/guidelines-bestpractices.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- guidelines-bestpractices.xml 22 Sep 2007 01:27:16 -0000 1.7
+++ guidelines-bestpractices.xml 17 Oct 2007 20:16:09 -0000 1.8
@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8"?><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></item><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><iem><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-multiple-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-speciy-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist>
\ No newline at end of file
+<?xml version="1.0" encoding="UTF-8"?><ulist><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></item><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-intersecion"/></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-assertion-semantics"/></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-multiple-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-indeendent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist>
\ No newline at end of file
Received on Wednesday, 17 October 2007 20:16:50 UTC