RE: Revised positions for closed/open world assumptions

Ashok,

Please see my comments below.

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

"Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 05/11/2007 05:50:00 
PM:

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

In the context of the attached policy scope? No. At least, not as a 
result of policy framework processing. The policy framework says nothing
about those behaviors that are 'applied' outside the scope of the policy
framework processing.

In your example, there is no mention of Z in either policy. How is 
behavior 
implied by Z applied in the context of policy framework processing if it
is not in the alternatives in either policy? I am confused.

Policy cannot say anything about behaviors applied
outside the scope of policy framework/attachments processing. Of course,
YMMV with regards to interop if you are applying behaviors outside 
the policy framework that might affect interop. 

Finally, there is the issue of applying behaviors implied by alternatives
related to another policy scope. In the context of another policy scope, 
unrelated 
to the attached policy subject in the aforementioned example? Yes, you
could apply Z, assuming that there is NO policy (as opposed to an empty
policy) attached to that policy subject by the other party.

For instance... let's assume that we have some policy subject (fictitious
since there is no such subject specified in the Attachments spec) that
you define for 'application' which applies to the processing of the 
messages received (I think you used the example of Logging in the past).

If Z implied logging, then IMO, you are free to apply logging in that 
context assuming that there was no policy (again, as opposed to 
an empty policy) attached to that subject by the other party to the 
interaction.

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

See above. Policy says NOTHING about that over  which it has 
no influence. Please read the proposal in my most recent note again.

"Any behaviors not represented by policy assertions in that alternative 
are out of scope and not applied as a result of policy framework 
processing."

The key phrase that we have added as a result of trying to understand your
concerns is 'as a result of policy framework processing'. If Z is not
in either policy, how can it be applied as a result of policy framework
processing unless you are doing something contrary, such as injecting
policy assertions into the intersected policy post intersection?

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

See my comments above. Correct. Policy says nothing about that over
which it has no influence.

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