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

Re: What is the Vocabulary of an Intersected Policy

From: Tom Rutt <tom@coastin.com>
Date: Mon, 23 Apr 2007 15:15:48 -0400
To: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Cc: Ashok Malhotra <ashok.malhotra@oracle.com>, ws policy <public-ws-policy@w3.org>
Message-id: <462D05E4.4030006@coastin.com>

I agree it would be simpler if we defined vocabulary such that the first 
policy has A, B, C in vocabulary
the second example policy has A, B, D in vocabulary and the third 
(intersection) has A, B in vocabulary.

This seems intuitive to me. Also the intersection algorithm does not 
mention "negation" but the effect of removing
bits of the vocabularies input to the intersection will affect the way 
people define assertion types (including nested assertion types).

Tom Rutt

Fabian Ritzmann wrote:
> 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
>>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Monday, 23 April 2007 19:16:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:33 UTC