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

Re: What is the Vocabulary of an Intersected Policy

From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Date: Mon, 23 Apr 2007 20:50:13 +0300
To: Ashok Malhotra <ashok.malhotra@oracle.com>
Cc: ws policy <public-ws-policy@w3.org>
Message-id: <462CF1D5.7090503@Sun.COM>
Hi,

I don't want to get into the proposed solution because I think the 
premise isn't entirely right. Ashok summarizes:

> Now, what is the vocabulary of this policy ?   Looking at this policy 
> alone it should be { A, B}.
>
> BUT, Chris points out the vocabulary should be {A,B,C,D} to remember 
> the fact that this was the union of the vocabularies of the two 
> intersected policies and that {C. D} must not be applied since they 
> were not selected.
>

This is the definition of policy vocabulary:

A *policy vocabulary* is the set of all policy assertion types 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#policy_assertion_type> 
used in a policy.


I don't see how one could derive from there that you must remember 
policy assertion types from a policy that served as input to 
intersection. The policies that are the input for the intersection and 
the policy that is the result of the intersection are different 
entities. Each has their own policy vocabulary.

Fabian


Ashok Malhotra wrote:
>
> We spoke briefly about this on the call today and I see a problem.
>
> This note is an attempt to state the problem clearly .
>
> Consider two normalized policies:
>
> <Policy>
>
>     <ExactlyOne>
>
>         <All>
>
>               <A/>
>
>                <B/>
>
>         </All>
>
>          <All>
>
>                 <C/>
>
>          </All>
>
>       </ExactlyOne>
>
> </Policy>
>
> < Policy>
>
>     < ExactlyOne>
>
>         <All>
>
>               <A/>
>
>                <B/>
>
>         </All>
>
>          <All>
>
>                 <D/>
>
>          </All>
>
>       </ExactlyOne>
>
> </Policy>
>
> Let us intersect these two policies.  What we get is:
>
> <Policy>
>
>     <ExactlyOne>
>
>         <All>
>
>               <A/>
>
>                <B/>
>
>         </All>
>
>     </ExactlyOne>
>
> </Policy>
>
> Now, what is the vocabulary of this policy ?   Looking at this policy 
> alone it should be { A, B}.
>
> BUT, Chris points out the vocabulary should be {A,B,C,D} to remember 
> the fact that this was the union of the vocabularies of the two 
> intersected policies and that {C. D} must not be applied since they 
> were not selected.
>
> This seems like a contradiction.   To remember the negative decision 
> we need to include assertions that are not in the policy , in its 
> vocabulary.
>
> SOLUTIONS:
>
> The only viable solution that I can se e is to drop the ' negation ' 
> semantic, namely, " When an assertion whose type is part of the 
> policy's vocabulary is not included in a policy alternative, the 
> policy alternative without the assertion type indicates that the 
> assertion will not be applied in the context of the attached policy 
> subject."   (Dale was arguing for this on other grounds as well)   
> Some would object strongly to this.  A counter proposal would be to 
> add an explicit NOT operator.
>
> Unfortunately, these are radical suggestions but I do not see any 
> other way out.  
>
> All the best, Ashok
>
Received on Monday, 23 April 2007 17:50:40 GMT

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