RE: Revised positions for closed/open world assumptions

Ashok,
my perspective is that  this "Z" behavior is outside the scope of "the 
policy framework".
So it's not in our purview to speculate about the behavior.
The policy framework will parse and process  assertions contained within 
the policy element tags.
A web service that is enabled to work with the policy framework then needs 
to implement the semantics for the behavior.

so, my answer is at any given point in  time a web service with a policy 
implementation knows its own universe.
so, do you do Z? this is an existential question to be left to the 
phillosophers.
do you do Z today?
will you do Z tomorrow?
where does this line of questioning end?

you may or may not do Z, but  if you do, and you expect ME  to do Z then 
you better tell me that, in which case it would be in one
or both of our policies 

Maryann




"Ashok Malhotra" <ashok.malhotra@oracle.com> 
Sent by: public-ws-policy-request@w3.org
05/11/2007 05:50 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
"David Orchard" <dorchard@bea.com>, "public-ws-policy@w3.org" 
<public-ws-policy@w3.org>, "public-ws-policy-request@w3.org" 
<public-ws-policy-request@w3.org>
Subject
RE: Revised positions for closed/open world assumptions






OK.  Good point!
You would not engage in the behavior indicated by C since you did not 
select an alternative that included C.
You could have but did not.  This is, I believe, for the basis for the 
vocabulary based negation which is currently in the spec.
 
My concern is with the behavior related to Z.  Neither policy talks about 
Z.  Can I do it?
 
So, I have the following questions:
1.      Along with the policies I need to know the universe of all 
possible assertions (behaviors) so that I can tell what was not included 
in the policy.  I don’t know how to specify this universe.
2.      If you say that assertions(behaviors) that are in the universe but 
not in the selected alternative cannot be applied what about assertions 
that are neither in the universe nor in the policies?  I guess we make no 
claims about them.
 
All the best, Ashok 

From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Friday, May 11, 2007 1:59 PM
To: Ashok Malhotra
Cc: David Orchard; public-ws-policy@w3.org; 
public-ws-policy-request@w3.org
Subject: RE: Revised positions for closed/open world assumptions
 

Ashok, 

Maryann and I have been thinking about your concerns. Possibly, the 
confusion relates to the scope to 
which this proposal applies. 

It is our understanding that it applies to those aspects of behavior that 
are controlled/influenced 
by policy framework processing... e.g. those behaviors that are engaged, 
configured, constrained by policy. 

Clearly, there is going to be behavior that is outside the domain of 
policy. That is not relevant 
to policy (though it may be relevant to interoperation, which I believe 
may be Dale's point). 

There may even be behavior that is subsequently documented by policy 
assertions that 
are unknown to an implementation at the time of its deployment. These too 
are out of 
scope of consideration of the policy framework processing as it relates to 
what is or is not applied in the 
context of an alternative that does not include such unknown assertions. 

Does that make things any clearer? 

Consider the following example 

client policy: 

<Policy> 
  <A/> 
  <B/> 
  <C wsp:Optional='true'/> 
</Policy> 

server policy: 

<Policy> 
  <A/> 
  <B/> 
</Policy> 

intersection would yield: 

<Policy> 
  <A/> 
  <B/> 
  <A/> 
  <B/> 
</Policy> 

Would you engage C anyway? 

It is our understanding that if you have an entity that engages C (from 
your previous example) when C is IN the 
alternative selected for interaction with the attached policy subject, 
that it would NOT engage 
that behavior when C is absent the alternative selected for interaction 
with the attached 
policy subject. 

Under the "makes no claims" regime, an implementation would be free to do 
C even though it were not in 
the intersected alternative, because the interpretation of that 
alternative (A, B, A, B) says nothing about whether 
C may or may not be applied. 

What is the point of performing intersection to determine the compatible 
alternative(s) if the implementation 
isn't going to bother to abide by the resulting policy to engage in the 
interaction? 

This may seem like it is drifting back towards the notion of policy 
vocabulary. But, the fact is that 
I think as you point out, you need to at least know what you know and 
behave in a consistent manner with 
regards to what the policy says and the behaviors you apply in the context 
of the interaction. 

The point of policy is to enable interoperation between Web services 
components. In order for it to be 
effective, there needs to be a shared understanding as to what the policy 
means and we need 
to have the respective endpoints behaving in a consistent manner relative 
to the policies that are 
used to determine the set of compatible alternatives from which to choose 
for purposes of interaction. 

Maryann and I have been noodling on language that tries to capture our 
intent better. So, rather than 
add the "No other behaviors are to be applied" language, we think that 
maybe if we added the following 
prose to section 4.5 Intersection, just before the algorithm is described, 
that that might clear up the confusion 
while at the same time preserving the semantic that we believe to be 
important. 

New text for section 4.5: 

If the intersection algorithm produces a policy alternative, common to 
both parties, it indicates that the behaviors 
implied by the assertions in that policy alternative are an implicit 
contract and will be applied for any interaction 
based on that alternative. Any behaviors not represented by policy 
assertions in that alternative are out of scope 
and not applied as a result of policy framework processing. 

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 377 9295 


public-ws-policy-request@w3.org wrote on 05/11/2007 08:17:27 AM:

> 
> Note that 2 requires additional information, namely, all the 
> assertions/behaviors in the closed world.  How is this information 
> conveyed to the policy engine?
> 
> All the best, Ashok
> 
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> > request@w3.org] On Behalf Of David Orchard
> > Sent: Thursday, May 10, 2007 2:11 PM
> > To: public-ws-policy@w3.org
> > Subject: Revised positions for closed/open world assumptions
> > 
> > 
> > Here's my revised estimate of the positions:
> > 
> > Overview
> > There are roughly 3 positions that may be taken on the issue of the
> > meaning of assertions in alternative(s).
> > 
> > 1. AIN Vocabulary flavour:
> > Any behaviour not implied by an assertion that is in a vocabulary 
should
> > not be applied (Roughly original chris proposal)
> > 
> > No proponents. No further elaboration planned.
> > 
> > 2. AIN Closed world flavour (revised MSFT/IBM proposal):
> > Any behaviour not implied by an alternative must not be applied.  Any
> > behaviors implied by assertions in an alternative must be applied.
> > 
> > Questions:
> > 1. Is it OK to omit Ignorable="true" Assertion?
> > 2. Is it OK to omit Optional="true" Assertion?
> > 
> > Pros
> > This ensures that a provider will provide a "complete" description of
> > the behaviors and thus guarantee interop including optional/ignorable.
> > 
> > Cons
> > Pending questions, may limit providers ability to apply behaviors.
> > 
> > 3. AIN Removal (open world):
> > Any behaviour not implied by any assertions in an alternative may or 
may
> > not be applied.  Any behaviors implied by assertions in an alternative
> > must be applied.
> > 
> > Pros
> > Perception of "simpler" specification.  Allows service fuller control
> > over application of behaviors.
> > 
> > Cons
> > Provider might not provide "complete" description.  Interop is
> > guaranteed but optional and/or ignorable behaviors may be missed by
> > clients.
> > 
> > Cheers,
> > Dave
> > 
> 
>