- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 27 Jul 2007 20:04:07 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv30901
Modified Files:
guidelines-bestpractices.xml ws-policy-guidelines.html
ws-policy-guidelines.xml
Log Message:
Implemented the resolution for issue 4660. Editors' action: 342.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -d -r1.92 -r1.93
--- ws-policy-guidelines.html 19 Jul 2007 08:31:09 -0000 1.92
+++ ws-policy-guidelines.html 27 Jul 2007 20:04:03 -0000 1.93
@@ -203,13 +203,12 @@
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. Behaviors 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. Assertion Authors Should Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Assertion Authors Should 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
-attribute</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>21. Assertion
- Authors Should Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Assertion
- Authors Should Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Assertion Authors should Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26. Define Rules for Attachment of an Assertion
- type to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Use Independent Assertions for Different Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+ Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
+Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>21. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Identiy Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26. Define Rules for Attachment of an Assertion
+ type to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Independent Assertions for Different Versions of a
+ Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Document changes to policy
+ 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
are typically defined in a dedicated specification that describes
@@ -421,7 +420,7 @@
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: Behaviors Relevant to Compatibility Tests</span></p><p class="practice">
+Practice 2: 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">
@@ -602,11 +601,11 @@
Practice 8: 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: Assertion Authors Should Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or
+Practice 9: 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: Assertion Authors Should Document Use of the Ignorable
+Practice 10: 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:
@@ -620,8 +619,7 @@
for the use of the wsp:Optional 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
-attribute</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use
+Practice 11: Allow use of wsp:Optional</span></p><p class="practice">An assertion's XML outline and/or schema definition should allow the use
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>
@@ -671,7 +669,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: 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 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
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
@@ -862,7 +860,7 @@
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="d3e806" id="d3e806"></a>5.5.1 Ignorable behavior in authoring</h4><p>
- The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Assertion Authors Should Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Assertion Authors Should Document Use of the Ignorable
+ The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
<h4><a name="d3e819" id="d3e819"></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.
@@ -958,15 +956,13 @@
policy assertion would need to be written with different (and possibly
unknown) attachment mechanisms in mind.
</p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
-Practice 21: Assertion
- Authors Should Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+Practice 21: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
Assertion Authors should leverage defined attachment models when
possible to extend the deployment of their policy assertions and ensure
that there are no additional semantics implied by their
assertions.</p></div><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
specification when possible. </p><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
-Practice 22: Assertion
- Authors Should Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+Practice 22: Use Defined Policy Subjects</span></p><p class="practice"> 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
@@ -979,7 +975,7 @@
combined without conflict. Each domain should define any limitations at
the policy subject level that might impact interoperability.
</p><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
-Practice 23: Assertion Authors should Identify Policy Subjects</span></p><p class="practice">
+Practice 23: Identify Policy Subjects</span></p><p class="practice">
Assertion
Authors should review the policy subjects defined in
WS-PolicyAttachments and identify existing policy subjects when possible
@@ -1083,7 +1079,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 27: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple attachment points
+Practice 27: Specify Preferred 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
@@ -1157,7 +1153,8 @@
[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Best
-Practice 30: Use Independent Assertions for Different Versions of a Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different
+Practice 30: 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">
@@ -1186,7 +1183,8 @@
new policy subjects are added it is incumbent on the authors to retain the
semantic of the policy assertion.
</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
-Practice 31: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time,
+Practice 31: 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">
<h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
@@ -1539,7 +1537,7 @@
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. 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>12. 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>.
@@ -1641,4 +1639,8 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4859">4859</a>.
Editors' action:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070727</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=4660">4660</a>.
+ Editors' action:
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</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.107
retrieving revision 1.108
diff -u -d -r1.107 -r1.108
--- ws-policy-guidelines.xml 19 Jul 2007 08:31:09 -0000 1.107
+++ ws-policy-guidelines.xml 27 Jul 2007 20:04:03 -0000 1.108
@@ -484,7 +484,7 @@
</p>
<p role="practice" id="bp-compatibility-tests">
- <quote>Behaviors Relevant to Compatibility Tests</quote>
+ <quote>Define assertions relevant to compatibility tests</quote>
<quote>
Assertion authors should define assertions for behaviors that are relevant to compatibility assessment, such as web service protocols that manifest on the wire.
</quote>
@@ -726,13 +726,13 @@
</quote>
</p>
- <p role="practice" id="DefineIgnorable"><quote>Assertion Authors Should Document Ignorable Behavior</quote> >
+ <p role="practice" id="DefineIgnorable"><quote>Document Ignorable Behavior</quote> >
<quote>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. </quote>
</p>
- <p role="practice" id="ignorableAssertions"> <quote>Assertion Authors Should Document Use of the Ignorable
+ <p role="practice" id="ignorableAssertions"> <quote>Document Use of the Ignorable
Attribute in XML </quote> >
<quote> 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.
@@ -753,8 +753,7 @@
definition of an assertion as this will allow policy expression authors to
compose compact policy expressions.</p>
<p role="practice" id="bp-assertion-xml-allow-optional">
- <quote>Assertion Authors should allow use of wsp:Optional
-attribute</quote>
+ <quote>Allow use of wsp:Optional</quote>
<quote>An assertion's XML outline and/or schema definition should allow the use
of the wsp:Optional attribute so as to enable policy authors to compose
compact policy expressions.</quote>
@@ -823,7 +822,7 @@
etc. that must be present in a message as part of their assertion design.
</p>
<p role="practice" id="bp-not-necessary-to-understand-a-message">
- <quote>Not Necessary to Understand a Message</quote>
+ <quote>Define message format only</quote>
<quote>Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</quote>
</p>
<p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
@@ -1236,8 +1235,8 @@
unknown) attachment mechanisms in mind.
</p>
- <p role="practice" id="bp-leverage-defined-attachment-mechanisms"><quote>Assertion
- Authors Should Leverage Defined Attachment Mechanisms</quote><quote>
+ <p role="practice" id="bp-leverage-defined-attachment-mechanisms">
+ <quote>Leverage Defined Attachment Mechanisms</quote><quote>
Assertion Authors should leverage defined attachment models when
possible to extend the deployment of their policy assertions and ensure
that there are no additional semantics implied by their
@@ -1245,8 +1244,8 @@
<p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
specification when possible. </p>
- <p role="practice" id="bp-use-defined-policy-subjects"><quote>Assertion
- Authors Should Use Defined Policy Subjects</quote><quote> Assertion
+ <p role="practice" id="bp-use-defined-policy-subjects">
+ <quote>Use Defined Policy Subjects</quote><quote> 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
@@ -1261,7 +1260,7 @@
the policy subject level that might impact interoperability.
</p>
<p role="practice" id="bp-identify-policy-subjects">
- <quote>Assertion Authors should Identify Policy Subjects</quote><quote>
+ <quote>Identify Policy Subjects</quote><quote>
Assertion
Authors should review the policy subjects defined in
WS-PolicyAttachments and identify existing policy subjects when possible
@@ -1419,7 +1418,7 @@
</p>
<p role="practice" id="bp-WSDL-preferred-attachment-point">
- <quote>Specify Preferred Attachment Point for an Assertion</quote>
+ <quote>Specify Preferred Attachment Point</quote>
<quote>If an assertion can be attached at multiple attachment points
within a policy subject, Assertion Authors should specify a
preferred attachment point for the chosen policy subject.
@@ -1547,7 +1546,8 @@
are mutually exclusive for an interaction. Such equivalent
behaviors can be modeled as independent assertions. </p>
<p role="practice" id="bp-independent-assertions">
- <quote>Use Independent Assertions for Different Versions of a Behavior</quote>
+ <quote>Independent Assertions for Different Versions of a
+ Behavior</quote>
<quote>Assertion Authors should use independent assertions for modeling different
versions of a behavior.</quote></p>
@@ -1590,7 +1590,8 @@
semantic of the policy assertion.
</p>
- <p role="practice" id="bp-policy-subject-change"><quote>Change of the Policy Subject Over Time</quote><quote>If the policy subjects change over time,
+ <p role="practice" id="bp-policy-subject-change"><quote>Document changes to policy
+ subject</quote><quote>If the policy subjects change over time,
the assertion description should also be versioned to reflect this
change.</quote>
</p>
@@ -2644,6 +2645,15 @@
Editors' action:
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</loc>.
</td>
+ </tr>
+ <tr>
+ <td>20070727</td>
+ <td>ASV</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4660</loc>.
+ Editors' action:
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</loc>.
+ </td>
</tr>
</tbody>
</table>
Index: guidelines-bestpractices.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/guidelines-bestpractices.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- guidelines-bestpractices.xml 13 Jul 2007 15:40:25 -0000 1.5
+++ guidelines-bestpractices.xml 27 Jul 2007 20:04:02 -0000 1.6
@@ -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-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="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-intersection"/></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><secref ref="bp-assertion-description-explicitly-allow-optional"/></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-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist>
\ No newline at end of file
+<?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-leverage-defined-attachment-mechanisms"/></p></item><item><p><specref ref="bp-use-defined-policy-subjects"/></p></item><item><p><specref ref="bp-identify-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-policy-subject"/></p></item><item><p><specref ref="bp-WSDL-policy-subject-Granularity"/></p></item><item><p><specref ref="bp-WSDL-multiple-policy-subjects"/></p></item><item><p><specref ref="bp-WSDL-preferred-attachment-point"/></p></item><item><p><specref ref="bp-WSDL-policy-multiple-instance-semantics"/></p></item><item><p><specref ref="bp-specify-composition"/></p></item><item><p><specref ref="bp-independent-assertions"/></p></item><item><p><specref ref="bp-policy-subject-change"/></p></item></ulist
\ No newline at end of file
Received on Friday, 27 July 2007 20:04:26 UTC