- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 18 Sep 2006 23:10:15 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy In directory hutz:/tmp/cvs-serv14604 Modified Files: ws-policy-framework.xml Log Message: Completed action item: http://www.w3.org/2005/06/tracker/wspolicyeds/actions/33 for issue 3672, Clarify the policy model for Web Services Index: ws-policy-framework.xml =================================================================== RCS file: /sources/public/2006/ws/policy/ws-policy-framework.xml,v retrieving revision 1.44 retrieving revision 1.45 diff -u -d -r1.44 -r1.45 --- ws-policy-framework.xml 18 Sep 2006 22:38:20 -0000 1.44 +++ ws-policy-framework.xml 18 Sep 2006 23:10:13 -0000 1.45 @@ -458,48 +458,47 @@ specification.</p> </div2> <div2 id="Web_services"> - <head>Web services</head> + <head>Policies of Entities in a Web Services Based System</head> - <p>Applied in the Web services model, <termref + <p>Applied in the Web services based system, <termref def='policy'>policy</termref> is used to convey conditions - on an interaction between a Web service requestor and a Web service provider. Satisfying assertions in the policy usually - results in behavior that reflects these - conditions. Typically, the provider of a Web service - exposes a policy to convey conditions under which it - provides the service. A requester might use this policy to - decide whether or not to use the service. A requester may - choose any alternative since each is a valid configuration - for interaction with the service, but a requester + on an interaction between entities (requester application, + provider service, Web infrastructure component, etc). Any entity in a + Web services based system may expose a policy to convey conditions under + which it functions. Satisfying assertions in the policy usually results + in behavior that reflects these conditions. For example, if two entities + - requester and provider - expose their policies, a requester might use + the policy of the provider to decide whether or not to use the service. + A requester may choose any alternative since each is a valid + configuration for interaction with the service, but a requester <rfc2119>MUST</rfc2119> choose only a single alternative for an interaction with a service since each represents an alternative configuration.</p> <p>A <termref def='policy_assertion'>policy - assertion</termref> is supported by a - requester if and only if the requester satisfies the - requirement (or accommodates the capability) corresponding - to the assertion. A <termref - def='policy_alternative'>policy alternative</termref> is - supported by a requester if and only if the - requester supports all the assertions in the - alternative. And, a <termref def='policy'>policy</termref> - is supported by a requester if and only if - the requester supports at least one of the alternatives in - the policy. Note that although policy alternatives are - meant to be mutually exclusive, it cannot be decided in - general whether or not more than one alternative can be + assertion</termref> is supported by an entity in the web services + based system if and only if the entity satisfies the requirement + (or accommodates the capability) corresponding to the assertion. + A <termref def='policy_alternative'>policy alternative</termref> + is supported by an entity if and only if the entity supports + all the assertions in the alternative. And, a <termref def='policy'>policy</termref> + is supported by an entity if and only if the entity supports + at least one of the alternatives in the policy. Note that although + policy alternatives are meant to be mutually exclusive, it cannot + be decided in general whether or not more than one alternative can be supported at the same time.</p> - <p>Note that a requester may be able to support a policy - even if the requester does not understand the <termref + <p>Note that an entity may be able to support a policy + even if the entity does not understand the <termref def='policy_assertion_type'>type</termref> of each assertion in the <termref def='policy_vocabulary'>vocabulary of the - policy</termref>; the requester only has to understand the + policy</termref>; the entity only has to understand the type of each assertion in the vocabulary of a <termref - def='policy_alternative'>policy alternative</termref> the requester supports. This characteristic is crucial to + def='policy_alternative'>policy alternative</termref> + the entity supports. This characteristic is crucial to versioning and incremental deployment of new assertions because this allows a provider's policy to include new - assertions in new alternatives while allowing requesters + assertions in new alternatives while allowing entities to continue to use old alternatives in a backward-compatible manner.</p> </div2> @@ -1748,6 +1747,16 @@ Namespace URI versioning Policy is not clear. </td> </tr> + <tr> + <td>20060918</td> + <td>PY</td> + <td>Completed action item: + <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/33">33</loc> + for issue + <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3672">3672</loc>, + Clarify the policy model for Web Services. + </td> + </tr> </tbody> </table> </inform-div1>
Received on Monday, 18 September 2006 23:10:19 UTC