- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 19 May 2007 01:04:24 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv13830
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Ensured Good Practices G1, G3 and G20 of original IBM/MS Contribution are reflected.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -d -r1.57 -r1.58
--- ws-policy-guidelines.html 17 May 2007 21:12:30 -0000 1.57
+++ ws-policy-guidelines.html 19 May 2007 01:04:21 -0000 1.58
@@ -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="#d3e742">Optional behavior in Compact authoring</a><br>
- 5.6.2 <a href="#d3e782">Optional behavior at runtime</a><br>
- 5.6.2.1 <a href="#d3e827">Example</a><br>
+ 5.6.1 <a href="#d3e747">Optional behavior in Compact authoring</a><br>
+ 5.6.2 <a href="#d3e787">Optional behavior at runtime</a><br>
+ 5.6.2.1 <a href="#d3e832">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>
@@ -209,8 +209,8 @@
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 Good Practice Statements</h2><p>The following good 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 of Policy Assertions</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics of an Assertion and its form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Starting to Build an Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Unique QNames</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>6. Clear Semantics</b></a></p></li><li><p><a href="#XMLOutline"><b>7. XML Outline</b></a></p></li><li><p><a href="#bp-assertions-and-message-semantics"><b>8. Assertions and Message Semantics</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Duplication of Asertions</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. Declare 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 mesage 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. An assertion description should specify a policy subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Granularity of policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Assertion 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. Semantics of multiple assertions of the same kind</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>26. Independent Assertions</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><dv class="div1">
+<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Good Practice Statements</h2><p>The following good 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 of Policy Assertions</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics of an Assertion and its form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with simple Assertions</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. Clear Semantics</b></a></p></li><li><p><a href="#XMLOutline"><b>7. XML Outline</b></a></p></li><li><p><a href="#bp-assertions-and-message-semantics"><b>8. Assertions and Message Semantics</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplicatin 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. Declare 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 mesage 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 Description Should Specify a Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose a 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. Semantics of multiple assertions of the same kind</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>26. Independent Assertions</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
@@ -531,11 +531,14 @@
reflects the options of the domain if the domain has a lot of
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
- are able to use the new domain assertions.
+ are able to use the new domain assertions. To facilitate proper
+ progression of an assertion, assertion authors should start with
+ a simple working assertion that allows extensibility. As the design
+ 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">Good
-practice 4: Starting to Build an Assertion</span></p><p class="practice">Start with a simple working assertion that allows extensibility.
- As your design work progresses, you may add more parameters or nested policy assertions to meet
- your interoperability needs. </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
+practice 4: Start with simple Assertions</span></p><p class="practice">An assertion author 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
@@ -544,9 +547,9 @@
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.</p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Good
-practice 5: Unique QNames</span></p><p class="practice">Use a unique QName to identify the behavior and provide an XML outline
- (plus an XML schema document) to specify the syntax of an assertion. </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 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">Good
+practice 5: Use Unique QNames</span></p><p class="practice">An assertion author 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
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>
@@ -632,10 +635,10 @@
of services need to find value in the set of
assertions or they will not include the assertions in
their service descriptions.
- </p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Good
-practice 9: Duplication of Assertions</span></p><p class="practice">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></div></div><div class="div2">
+ </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">Good
+practice 9: Avoid Duplication of Assertions</span></p><p class="practice">An assertion author 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.
@@ -735,6 +738,7 @@
<code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> is a nested policy assertion of
the <code>sp:TransportBinding</code> policy assertion. The
+
<code>sp:TransportToken</code> assertion requires the use of a
specific transport token and further qualifies the behavior of
the <code>sp:TransportBinding</code> policy assertion (which
@@ -813,7 +817,7 @@
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="d3e742" id="d3e742"></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="d3e747" id="d3e747"></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,
@@ -844,7 +848,7 @@
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="d3e782" id="d3e782"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e787" id="d3e787"></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
@@ -899,7 +903,7 @@
</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Good
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,
either out of band or as reflected by the message content.</p></div><div class="div4">
-<h5><a name="d3e827" id="d3e827"></a>5.6.2.1 Example</h5><p>
+<h5><a name="d3e832" id="d3e832"></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.
@@ -936,7 +940,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">Good
-practice 21: An assertion description should specify a policy subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.
+practice 21: Assertion Description Should Specify a Policy Subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.
For instance, if a policy assertion is to be used with WSDL, the assertion description
should specify a WSDL policy subject – such as service, endpoint, operation and message.
</p></div><p>Assertion authors that wish to utilize WSDL policy subjects need to
@@ -968,7 +972,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">Good
-practice 22: Granularity of policy subjects</span></p><p class="practice">Assertion authors should choose the most granular policy subject
+practice 22: Choose a Granular Policy Subject</span></p><p class="practice">Assertion authors should choose the most granular policy subject
that the behavior represented by a policy assertion applies to.
</p></div><p>
For authoring convenience, an assertion author may allow the
@@ -979,7 +983,7 @@
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">Good
-practice 23: Assertion attachment to multiple policy subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy
+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
subjects, the assertion description should describe the semantics of multiple
instances of the same assertion attached to multiple policy subjects
at the same time.
@@ -1020,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">Good
-practice 24: Specify preferred attachment point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy
+practice 24: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy
subject, an assertion author should specify a preferred attachment
point for the chosen policy subject.
</p></div><p>Assertion authors that utilize WSDL policy subjects need to
@@ -1642,6 +1646,9 @@
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/252">252</a> and
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/255">255</a>.
- </td></tr><tr><td rowspan="1" colspan="1">20070516</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Editorial change to section 5.7 to place best practice after the associated
+ </td></tr><tr><td rowspan="1" colspan="1">20070516</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Editorial change to section 5.7 to place best practices after the associated
explanatory text and to fix grammar.
+ </td></tr><tr><td rowspan="1" colspan="1">20070518</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Ensured Good Practices G1, G3 and G20 of
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">original IBM/MS Contribution</a>
+ are reflected.
</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.72
retrieving revision 1.73
diff -u -d -r1.72 -r1.73
--- ws-policy-guidelines.xml 17 May 2007 21:12:30 -0000 1.72
+++ ws-policy-guidelines.xml 19 May 2007 01:04:22 -0000 1.73
@@ -618,11 +618,15 @@
reflects the options of the domain if the domain has a lot of
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
- are able to use the new domain assertions.
+ are able to use the new domain assertions. To facilitate proper
+ progression of an assertion, assertion authors should start with
+ a simple working assertion that allows extensibility. As the design
+ work progresses, one may add more parameters or nested policy assertions
+ to meet one's interoperability needs.
</p>
- <p role="practice" id="bp-assertion-start"><quote>Starting to Build an Assertion</quote><quote>Start with a simple working assertion that allows extensibility.
- As your design work progresses, you may add more parameters or nested policy assertions to meet
- your interoperability needs. </quote>
+ <p role="practice" id="bp-assertion-start"><quote>Start with simple Assertions</quote>
+ <quote>An assertion author should start with a simple working assertion
+ that allows assertion parameter extensibility. </quote>
</p>
<p>New Assertion Authors are encouraged to look at <bibref ref="WS-RM-Policy"/> to see an example of a
relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <bibref
@@ -637,10 +641,11 @@
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.</p>
+ 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>
- <p role="practice" id="bp-unique-qnames"><quote>Unique QNames</quote><quote>Use a unique QName to identify the behavior and provide an XML outline
- (plus an XML schema document) to specify the syntax of an assertion. </quote>
+ <p role="practice" id="bp-unique-qnames"><quote>Use Unique QNames</quote>
+ <quote>An assertion author should use a unique QName to identify a distinct behavior.</quote>
</p>
<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
@@ -754,9 +759,12 @@
assertions or they will not include the assertions in
their service descriptions.
</p>
- <p role="practice" id="bp-assertion-duplication"><quote>Duplication of Assertions</quote><quote>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. </quote>
+ <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>
+
+ <p role="practice" id="bp-assertion-duplication"><quote>Avoid Duplication of Assertions</quote>
+ <quote>An assertion author should reuse an existing assertion (rather than create a new one) whenever possible.</quote>
</p>
</div3>
</div2>
@@ -1203,7 +1211,7 @@
</ulist>
<p role="practice" id="bp-WSDL-policy-subject">
- <quote>An assertion description should specify a policy subject</quote>
+ <quote>Assertion Description Should Specify a Policy Subject</quote>
<quote>Assertion authors should associate assertions with the appropriate policy subject.
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.
@@ -1244,7 +1252,7 @@
</p>
<p role="practice" id="bp-WSDL-policy-subject-Granularity">
- <quote>Granularity of policy subjects</quote>
+ <quote>Choose a Granular Policy Subject</quote>
<quote>Assertion authors should choose the most granular policy subject
that the behavior represented by a policy assertion applies to.
</quote>
@@ -1261,7 +1269,7 @@
</p>
<p role="practice" id="bp-WSDL-multiple-policy-subjects">
- <quote>Assertion attachment to multiple policy subjects</quote>
+ <quote>Define Semantics of Attachment to Multiple Policy Subjects</quote>
<quote>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
@@ -1324,7 +1332,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 for an Assertion</quote>
<quote>If an assertion can be attached at multiple points within a policy
subject, an assertion author should specify a preferred attachment
point for the chosen policy subject.
@@ -2452,9 +2460,17 @@
<tr>
<td>20070516</td>
<td>PY</td>
- <td>Editorial change to section 5.7 to place best practice after the associated
+ <td>Editorial change to section 5.7 to place best practices after the associated
explanatory text and to fix grammar.
</td>
+ </tr>
+ <tr>
+ <td>20070518</td>
+ <td>PY</td>
+ <td>Ensured Good Practices G1, G3 and G20 of
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">original IBM/MS Contribution</loc>
+ are reflected.
+ </td>
</tr>
</tbody>
</table>
Received on Saturday, 19 May 2007 01:04:35 UTC