W3C home > Mailing lists > Public > public-ws-policy@w3.org > March 2007

Friendly ammendment to Action 217 (bug 4288)

From: Maryann Hondo <mhondo@us.ibm.com>
Date: Wed, 7 Mar 2007 12:47:01 -0500
To: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-ID: <OFA03CF003.E476E3BF-ON87257297.00619183-85257297.00618242@us.ibm.com>
I would like to highlight some text that currently exists in the spec and 
propose
a friendly ammendment to this action item to reconcile this example in the
primer with the spec.

The section from the text (
http://www.w3.org/TR/2006/WD-ws-policy-20061117/)  is  in section 3.4 
(last 2 paragraphs) :

A policy assertion 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 policy 
alternative is supported by an entity if and only if the entity supports 
all the assertions in the alternative. And, a policy 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.
Note that an entity may be able to support a policy even if the entity 
does not understand the type of each assertion in the vocabulary of the 
policy; the entity only has to understand the type of each assertion in 
the vocabulary of a policy alternative 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 entities to continue to use 
old alternatives in a backward-compatible manner.


This leads me to believe that the  proposal from Monica [below]

For action: Action 217 at 
http://www.w3.org/2005/06/tracker/wspolicy/actions/217


UPDATED IN DRAFT
================
Proposal:
A. At the end of Section 2.6, include a brief statement where optional 
policy assertions are discussed.
Change from:
   Contoso is able to meet their customer needs by adding optional
   support for the Optimized MIME Serialization. An optional policy
   assertion represents a behavior that may be engaged.

Change to:

    Contoso is able to meet their customer needs by adding optional
    support for the Optimized MIME Serialization. An optional policy
    assertion represents a behavior that may be engaged. WHEN A POLICY
    ASSERTION IS ABSENT, a policy aware client should not conclude
    anything (other than ‘no claims’) about the absence of THAT policy
    ASSERTION. [2] Where the behavior is not engaged, the absence of
    policy expressions does not indicate anything about the capabilities
    and requirements of a service.


should actually be changed to:

Contoso is supporting [see Section 3.4 of Policy Framework specification] 
Optimized MIME Serialization and indicating this capability
by using the  optional attribute  in combination with  the Optimized MIME 
Serialization assertion. An optional policy assertion represents a
behavior that may be engaged. If Contoso did not suppport the Optimized 
MIME Serialization assertion in its policy, a policy aware
client could not conclude anything (other than ‘no claims’) about 
Optimized MIME Serialization (See Section 2.10 on the absence of policy 
expressions).

Received on Wednesday, 7 March 2007 17:45:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:48 GMT