Re: What is the Vocabulary of an Intersected Policy

Hi

I agree with what Fabian says...

I don't understand how adding the client policy's vocabulary into the effective policy's vocabulary can help the client make any useful decisions generically.
If the provider's policy has A&B assertions and client policy has B&C, then the fact that the provider hasn't included C does not mean anything specifc, it may mean negation or may not. The service may still fully support C but it's perfectly legal for it not to expose it. 
Adding C to the intersected policy's vocabulary won't tell the client reliably that C can not be applied. I agree that adding it probably won't harm either but I can't see how it will help.
I personally see the negation can only be a domain specific feature, that is if the assertion A can have 2 other nested policies B & C, then if in a given policy expression A only has a nested B then it might mean, as defined by the documentation of A, that C is not supported..., all this in scope of A only

Thanks, Sergey




----- Original Message ----- 
From: "Fabian Ritzmann" <Fabian.Ritzmann@Sun.COM>
To: "David Orchard" <dorchard@bea.com>
Cc: "Ashok Malhotra" <ashok.malhotra@oracle.com>; "ws policy" <public-ws-policy@w3.org>
Sent: Wednesday, April 25, 2007 11:58 AM
Subject: 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
>>
>