- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 17 Jul 2007 11:47:44 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv19114
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Implemented the resolution for issue 4852, Editors' action 332.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -d -r1.81 -r1.82
--- ws-policy-guidelines.html 17 Jul 2007 10:41:43 -0000 1.81
+++ ws-policy-guidelines.html 17 Jul 2007 11:47:41 -0000 1.82
@@ -139,8 +139,8 @@
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="#d3e780">Optional behavior in Compact authoring</a><br>
- 5.6.2 <a href="#d3e820">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d3e778">Optional behavior in Compact authoring</a><br>
+ 5.6.2 <a href="#d3e818">Optional behavior at runtime</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>
@@ -162,7 +162,7 @@
F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>The WS-Policy specification defines a policy to be a collection
- of policy alternatives with each policy alternative a
+ of policy alternatives. Each policy alternative a
collection of policy assertions. The Web Services Policy 1.5 - Framework provides a flexible framework to
represent
consistent combinations of behaviors from a variety of domains.
@@ -208,8 +208,8 @@
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-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>6. Provide an XML Outline</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>10. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Use the wsp:Optional attribute to indicate optional</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 whn specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>21. Assertion Authors Should Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Different Versions of a Bhavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+ 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-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 Outline</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>10. Use Parameters for Useful
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Use the wsp:Optional attribute to indicate optional</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 whn 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. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Different Versions of a Behavior</b></a></p></li><i><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
<h2><a name="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
@@ -283,9 +283,9 @@
<h3><a name="roles" id="roles"></a>4.1 Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
and responsibilities for the authors, consumers and providers.
</p><div class="div3">
-<h4><a name="domain-owners" id="domain-owners"></a>4.1.1 Assertion Authors</h4><p>Assertion Authors are a community that chooses to
+<h4><a name="domain-owners" id="domain-owners"></a>4.1.1 Assertion Authors</h4><p>Assertion Authors are part of a community that chooses to
exploit the WS-Policy Framework by creating their own
- specification to define a set of assertions that express the
+ specifications to define a set of assertions that express the
capabilities and constraints of that target domain. The
WS-Policy Framework is based on a declarative model, meaning
that it is incumbent on the Assertion Authors to define both the semantics of
@@ -323,7 +323,7 @@
</p></div><div class="div3">
<h4><a name="consumers" id="consumers"></a>4.1.2 Consumers</h4><p>A consumer of WS-Policy
Assertions can be any entity that is capable of parsing a
- WS-Policy XML element and selecting one alternative from the
+ WS-Policy XML expression and selecting one alternative from the
policy. This selected alternative is then used to govern the creation of a message
to send to the subject to which the policy alternative was
attached. The WS-Policy Attachment specification defines a
@@ -369,22 +369,22 @@
</p><p>
Assertions can be simple or they can be complex. Assertion Authors may choose
to specify multiple peer assertions, each carrying the semantic of a particular
- behavior, or they may choose to specify assertions that contains assertion parameters
- and/or nested policy expression (nested assertions), each of which relate to an
- aspect of the behavior, yet encapsulated within a single assertion.
+ behavior, or they may choose to specify assertions that contain assertion parameters
+ and/or nested policy expressions (nested assertions), where each nested assertion of which
+ relates to an aspect of the behavior, yet encapsulated within a single assertion.
There are advantages to simplifying the set of assertions. The ultimate goal of
policy is to enable interoperability. By keeping assertion design as simple as
possible, Assertion Authors will more likely be able to meet that objective.
</p><p>
- Therefore, Assertion Authors need to have a specific goal in mind for the assertions
+ Assertion Authors need to have a specific goal in mind for the assertions
that they author. Assertion specifications should include a detailed specification
- of the assertion’s semantics, a set of valid policy subjects to which the asserction
+ of the assertion’s semantics and, a set of valid policy subjects to which the assertion
maybe attached. The specification should also include the scope of the assertion
in the context of a particular policy subject. For example, an assertion with
Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
or it can be scoped to all messages exchanged with that endpoint. The former case
permits a client to select a different alternative with each successive message
- exchange. Finally, if a set of assertions describes a wide range of behaviors,
+ exchange. Finally,
the ability to combine individual assertions may also need to be considered.
For example, if an assertion applies to the SOAP protocol, it would be necessary
to consider how its presence must interact with other policy assertions that
@@ -395,7 +395,7 @@
<ul><li><p>The definition of the assertion's semantic
(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>21. Assertion Authors Should Specify Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
+ (See best practice <a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
subject (See best practices in Section <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment in WSDL </b></a>).</p></li><li><p>Any composition considerations if the assertion is used with
other assertions in a context
(See best practice <a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a>).</p></li></ul>
@@ -551,7 +551,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 4: Start with 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</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">
@@ -561,9 +561,8 @@
behavior represented by a policy assertion. Assertion Authors have the option to
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
- versus attributes apply is: Use a unique QName to identify a distinct behavior </p><div class="boxedtext"><p><a name="bp-unique-qnames" id="bp-unique-qnames"></a><span class="practicelab">Best
-Practice 5: Use Unique QNames</span></p><p class="practice">Assertion Authors should use a unique QName to identify a distinct behavior.</p></div><p> and provide
- an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Best
+ 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 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 Outline</span></p><p class="practice">Assertion authors should provide an XML outline plus an XML schema to
specify the syntax of an assertion.
</p></div><p> An example of this method (below) is given in the Web Services Reliable Messaging Policy document. [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]
@@ -837,7 +836,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="d3e780" id="d3e780"></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="d3e778" id="d3e778"></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,
@@ -868,7 +867,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="d3e820" id="d3e820"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e818" id="d3e818"></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
@@ -959,7 +958,7 @@
made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
-Practice 21: Assertion Authors Should Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which
+Practice 21: Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which
the assertion may be associated. For instance, if a policy assertion is to be used with
WSDL, the assertion description should specify a WSDL policy subject - such as service,
endpoint, operation and message.
@@ -1071,7 +1070,7 @@
security mechanism (e.g. <code>sp:HttpsToken</code>)".
</p></div></div><div class="div1">
<h2><a name="versioning-policy-assertions" id="versioning-policy-assertions"></a>6. Versioning Policy Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
- how they anticipate new assertions being added to the set. There are three aspects to versioning policy assetions:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
+ how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
</p><p> Assertion Authors should review the WS-Policy Primer <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
and the specifications <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> <cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>
@@ -1111,7 +1110,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>21. Assertion Authors Should Specify Policy Subject(s)</b></a> specifies that policy authors should
+ The best practice <a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a> specifies that policy authors should
define the set of policy subjects to which policy assertions can be
attached. Over time, new policy subjects may need to be defined. When
this occurs, policy Assertion Authors may update the list of policy
@@ -1736,8 +1735,12 @@
Updated the WSDL 20 reference [<cite><a href="#WSDL20">WSDL 2.0 Core Language</a></cite>] and WS-SecurityPolicy reference [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]
for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4831">4831</a>.
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/326">326</a>
- </td></tr><tr><td rowspan="1" colspan="1">20070713</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution
+ </td></tr><tr><td rowspan="1" colspan="1">20070717</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=4853">4853</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/333">333</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070717</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=4852">4852</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</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.96
retrieving revision 1.97
diff -u -d -r1.96 -r1.97
--- ws-policy-guidelines.xml 17 Jul 2007 10:41:43 -0000 1.96
+++ ws-policy-guidelines.xml 17 Jul 2007 11:47:41 -0000 1.97
@@ -86,7 +86,7 @@
<head>Introduction</head>
<p>The WS-Policy specification defines a policy to be a collection
- of policy alternatives with each policy alternative a
+ of policy alternatives. Each policy alternative a
collection of policy assertions. The &framework.title; provides a flexible framework to
represent
consistent combinations of behaviors from a variety of domains.
@@ -283,9 +283,9 @@
<div3 id="domain-owners">
<head> Assertion Authors</head>
- <p>Assertion Authors are a community that chooses to
+ <p>Assertion Authors are part of a community that chooses to
exploit the WS-Policy Framework by creating their own
- specification to define a set of assertions that express the
+ specifications to define a set of assertions that express the
capabilities and constraints of that target domain. The
WS-Policy Framework is based on a declarative model, meaning
that it is incumbent on the Assertion Authors to define both the semantics of
@@ -333,7 +333,7 @@
<head>Consumers</head>
<p>A consumer of WS-Policy
Assertions can be any entity that is capable of parsing a
- WS-Policy XML element and selecting one alternative from the
+ WS-Policy XML expression and selecting one alternative from the
policy. This selected alternative is then used to govern the creation of a message
to send to the subject to which the policy alternative was
attached. The WS-Policy Attachment specification defines a
@@ -417,23 +417,23 @@
<p>
Assertions can be simple or they can be complex. Assertion Authors may choose
to specify multiple peer assertions, each carrying the semantic of a particular
- behavior, or they may choose to specify assertions that contains assertion parameters
- and/or nested policy expression (nested assertions), each of which relate to an
- aspect of the behavior, yet encapsulated within a single assertion.
+ behavior, or they may choose to specify assertions that contain assertion parameters
+ and/or nested policy expressions (nested assertions), where each nested assertion of which
+ relates to an aspect of the behavior, yet encapsulated within a single assertion.
There are advantages to simplifying the set of assertions. The ultimate goal of
policy is to enable interoperability. By keeping assertion design as simple as
possible, Assertion Authors will more likely be able to meet that objective.
</p>
<p>
- Therefore, Assertion Authors need to have a specific goal in mind for the assertions
+ Assertion Authors need to have a specific goal in mind for the assertions
that they author. Assertion specifications should include a detailed specification
- of the assertion’s semantics, a set of valid policy subjects to which the asserction
+ of the assertion’s semantics and, a set of valid policy subjects to which the assertion
maybe attached. The specification should also include the scope of the assertion
in the context of a particular policy subject. For example, an assertion with
Endpoint Policy Subject can be scoped to a given message exchange with that endpoint,
or it can be scoped to all messages exchanged with that endpoint. The former case
permits a client to select a different alternative with each successive message
- exchange. Finally, if a set of assertions describes a wide range of behaviors,
+ exchange. Finally,
the ability to combine individual assertions may also need to be considered.
For example, if an assertion applies to the SOAP protocol, it would be necessary
to consider how its presence must interact with other policy assertions that
@@ -649,7 +649,7 @@
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>Start with Simple Assertion</quote>
+ <p role="practice" id="bp-assertion-start"><quote>Start with a Simple Assertion</quote>
<quote>Assertion Authors should start with a simple working assertion
that allows assertion parameter extensibility. </quote>
</p>
@@ -666,13 +666,12 @@
behavior represented by a policy assertion. Assertion Authors have the option to
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
- versus attributes apply is: Use a unique QName to identify a distinct behavior </p>
+ versus attributes apply. Use a unique QName to identify a distinct behavior.</p>
<p role="practice" id="bp-unique-qnames"><quote>Use Unique QNames</quote>
- <quote>Assertion Authors should use a unique QName to identify a distinct behavior.</quote> </p>
- <p> and provide
- an XML outline (plus an XML schema document) to specify the syntax of an assertion. </p>
- <p role="practice" id="XMLOutline"> <quote>Provide an XML Outline</quote> >
+ <quote>Assertion Authors should use a unique QName to identify a distinct behavior.</quote> </p>
+
+ <p role="practice" id="XMLOutline"> <quote>Provide an XML Outline</quote> >
<quote>Assertion authors should provide an XML outline plus an XML schema to
specify the syntax of an assertion.
</quote>
@@ -1249,7 +1248,7 @@
</ulist>
<p role="practice" id="bp-WSDL-policy-subject">
- <quote>Assertion Authors Should Specify Policy Subject(s)</quote>
+ <quote>Specify Policy Subject(s)</quote>
<quote>Assertion Authors should specify the set of relevant policy subjects with which
the assertion may be associated. For instance, if a policy assertion is to be used with
WSDL, the assertion description should specify a WSDL policy subject - such as service,
@@ -1416,7 +1415,7 @@
<div1 id="versioning-policy-assertions">
<head>Versioning Policy Assertions</head>
<p>Assertion Authors need to consider not just the expression of the current set of requirements but
- how they anticipate new assertions being added to the set. There are three aspects to versioning policy assetions:</p>
+ how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p>
<ulist>
<item>
<p> Assertion Extensibility </p>
@@ -2723,14 +2722,23 @@
</td>
</tr>
<tr>
- <td>20070713</td>
+ <td>20070717</td>
<td>FJH</td>
<td>Implemented the resolution
for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4853">4853</loc>.
Editors' action
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/333">333</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070717</td>
+ <td>FJH</td>
+ <td>Implemented the resolution
+ for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4852">4852</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Tuesday, 17 July 2007 11:47:47 UTC