- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 31 Jan 2007 20:26:27 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy In directory hutz:/tmp/cvs-serv16302 Modified Files: ws-policy-guidelines.html Log Message: Implement amendment in message 217 with minor editorial modifications for readability of entire sentence. This should complete editors action 152. Index: ws-policy-guidelines.html =================================================================== RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v retrieving revision 1.24 retrieving revision 1.25 diff -u -d -r1.24 -r1.25 --- ws-policy-guidelines.html 31 Jan 2007 20:15:13 -0000 1.24 +++ ws-policy-guidelines.html 31 Jan 2007 20:26:25 -0000 1.25 @@ -828,7 +828,7 @@ policy assertions do not target wire-level behaviors but rather abstract requirements, this technique does not apply. </p></div><div class="div2"> -<h3><a name="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Domain authors need to be clear about how assertions defined in +<h3><a name="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in their domain may fit with assertions for interrelated domains. A classic example of such an interrelated domain is security, because security tends to @@ -836,9 +836,9 @@ of additional assertions related to the interrelated security domain [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>] in Web Services Reliable Messaging Policy - Assertions [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. </p><p>Care should be taken to not duplicate existing - assertions and also to make sure that new assertions are consistent - with pre-existing assertions, when adding assertions related to an + Assertions [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. </p><p>Assertion authors should not duplicate existing + 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></div><div class="div1"> <h2><a name="lifecycle"></a>5. Lifecycle of 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 that govern an assertions lifecycle:</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
Received on Wednesday, 31 January 2007 20:26:31 UTC