RE: What is the Vocabulary of an Intersected Policy

In the interest of putting all solutions on the table, I should mention a solution that Anne Anderson of SUN suggested in a private communication:
Store the vocabulary explicitly within the policy.  

I'm not recommending this. 

All the best, Ashok

> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Wednesday, April 25, 2007 5:45 AM
> To: ext Sergey Beryozkin
> Cc: Frederick Hirsch; Fabian Ritzmann; David Orchard; Ashok Malhotra; ws
> policy
> Subject: 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 13:32:57 UTC