Re: What is the Vocabulary of an Intersected Policy

+1

it will be incredibly confusing to save a resulting policy from  
intersection and then later try to guess what is in the vocabulary  
that isn't explicitly there in the policy.

Shouldn't the result of intersection be a self-describing policy in  
itself?

regards, Frederick

Frederick Hirsch
Nokia


On Apr 25, 2007, at 7:19 AM, ext Sergey Beryozkin wrote:

> 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
> >>
> >
>

Received on Wednesday, 25 April 2007 12:45:48 UTC