Re: Revised positions for closed/open world assumptions

Tom Rutt wrote:

>
> Chris's way seems easier to implement, since all one needs to know is 
> their own input to the intersection, and the output of intersection.
>
> Ashok's directionality seems to imply I need to know what the other 
> side put in to the intersection algorithm
>
> Tom

mm1: Tom, I believe Ashok was only providing an interpretation, taking 
actually Chris' proposed text, to achieve an understanding. There is a 
discussion going on whether or not Chris' text introduces 
directionality. Thanks.

>
>
>
> Ashok Malhotra wrote:
>
>>
>> Chris, I don’t see the need for directionality. How about this:
>>
>> P and R exchange policies and decide on an alternative.
>>
>> P must do what’s mandated by the selected alternative.
>>
>> P cannot do what was in R’s policy but was not selected.
>>
>> R must do what’s mandated by the selected alternative.
>>
>> R cannot do what was in P’s policy but was not selected.
>>
>> No other claims.
>>
>> All the best, Ashok
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com]
>> *Sent:* Friday, May 18, 2007 6:23 AM
>> *To:* Ashok Malhotra
>> *Cc:* public-ws-policy@w3.org
>> *Subject:* RE: Revised positions for closed/open world assumptions
>>
>>
>> Ashok,
>>
>> Maybe "initiating entity" is unclear. Basically, I intend it to be 
>> the entity that engages an interaction
>> by retrieving the other side's policy and intersecting it.
>>
>> If we expand this with a request/response MEP
>>
>> Requestor = R
>> Provider = P
>>
>> If A is in R's policy, but not in P's policy R does not engage that 
>> behavior.
>> If A is in P's policy, but not in R's policy, P does not engage that 
>> behavior
>> If P does not use A's policy to engage the interaction, then 
>> everything is out of scope.
>> One would presume that P would deal with the behaviors represented in 
>> the
>> messages received from R in a manner consistent with their 
>> specification.
>>
>> I recognize that the intersection algorithm is direction independent. 
>> The proposed
>> language does not affect intersection, it just places constraints on 
>> the entity that
>> uses the intersected policy to engage an interaction, limiting the 
>> set of behaviors
>> applied to those that are implied by assertions IN the intersected 
>> policy and (possibly, but we
>> don't say anything about them since they are out of scope) those 
>> which are NOT IN
>> the initiating entity's policy.
>>
>> Those behaviors that are IN the initiating entity's policy but NOT IN 
>> the intersected policy
>> are RIGHT OUT:-)
>>
>> Make sense?
>>
>> 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/17/2007 
>> 07:06:31 PM:
>>
>> > Chris:
>> > In your latest note in this thread you proposed
>> >
>> > Proposed text added to section 4.5:
>> >
>> > If an initiating entity includes a policy assertion type A in
>> > its policy, and this policy assertion type A
>> > does not occur in an intersected policy, then the initiating
>> > entity does not apply the behavior implied by
>> > assertion type A.
>> >
>> > I have two concerns about this proposal:
>> >
>> > 1. It does not say anything about the policy of the responder. Is
>> > the behavior different in the other direction? I think not.
>> > 2. The policy intersection algorithm is direction independent. This
>> > proposal introduces direction dependency and I’m wary of that. If
>> > we go that way then I would like to bring up the complex of ideas
>> > that say that the initiator expresses constraints – what you must
>> > do, and the responder expresses capabilities – what I can do and
>> > intersection works differently if viewed from the two directions.
>> > If we go that route then this leads naturally into the wildcard
>> > matching that DaveO and I have been proposing.
>> >
>> > All the best, Ashok
>>
>

Received on Friday, 18 May 2007 15:42:35 UTC