W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > September 2006

2006/ws/policy ws-policy-framework.xml,1.44,1.45

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
Message-Id: <E1GPSFj-0003pf-FG@lionel-hutz.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:49 UTC