Re: What is the Vocabulary of an Intersected Policy

David Orchard wrote:
> If your point is that our definition of policy vocabulary is strict 
> enough that it means that "vocabulary" doesn't make sense to apply to 
> a policy intersection result, then that might be fair

Sort of. My point was the the policy intersection result is a policy in 
its own right with its own distinct vocabulary.

> in which case we might need "policy pre-intersection vocabulary" and 
> "policy post-intersection vocabulary" terms or the rough equivalents.

Personally, I don't see the necessity for additional terms, because 
pre-intersection we have two policies each with their distinct 
vocabularies, post-intersection we have one policy with its own distinct 
vocabulary.

Fabian


>     *From:* public-ws-policy-request@w3.org
>     [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Fabian
>     Ritzmann
>     *Sent:* Monday, April 23, 2007 10:50 AM
>     *To:* Ashok Malhotra
>     *Cc:* ws policy
>     *Subject:* Re: What is the Vocabulary of an Intersected Policy
>
>     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 Wednesday, 25 April 2007 10:58:41 UTC