- 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