Re: Policy Framework and Policy Domain division of labor, and the 'absent policies are present as negations' principle.

>Dale Moberg wrote: However, the real payoff is that the domain assertion authors regain the
>freedom to specify semantic relations among policy assertions they would
>like to formulate for their domains, and the distinction between the
>framework and the domain assertion author's semantic specification
>options become clearer.
>
mm1: Dale, I think there is value in the statement to separate the 
Framework specification and the flexibility to the domain assertion 
authors. Looking at our Action 270 concept proposal supports this.

>Second, Chris Ferris noticed that the policy provider's context for
>policy language of a policy alternative and the policy consumer's
>context for policy language of its policy alternative (for matching
>policy alternatives!) need not be the same. 
>
mm1: I think that use of the policy alternative scopes what processing 
occurs in a modular way. What more can you provide that indicates this 
could be valuable and necessary to our current work (no position either 
way)? Thanks.

>This results in the
>invisible semantics of empty nested policies differing considerably on
>the consumer and provider sides. This seems to be another reason for
>tossing out AIN as a framework principle. (I am not here considering
>that we instead enlarge the scope, and explicitly provide some semantic
>constants for domain authors to use!-Ashok likes this, I would put it
>into v.next.)
>
> 
>
>Here is the example I gathered CF was discussing (I may have it wrong
>since his explanation was not written down, but it is still an
>interesting example IMO)
>
> 
>
>ProviderPolicy - two policy alternatives, one with an empty nested
>policy.
>
> 
>
><Policy>
>
>    <ExactlyOne>
>
>        <All>
>
>           <A>
>
>            <Policy/>
>
>          <A/>
>
>        </All>
>
>         <All>\
>
>                <A>
>
>               <Policy>
>
>               <ExactlyOne> 
>
>               <All>
>
>                  <B/>
>
>               </All>
>
>                </ExactlyOne>
>
>               </Policy>
>
>         </A>
>
>         </All>
>
>      </ExactlyOne>
>
></Policy>
>
> 
>
>In this case, the AIN principle appears to imply that the empty nested
>policy has the semantics of the negation of policy assertion B (because
>the policy alternative language is set {B}, and B is absent from the
>empty nested policy. 
>
> 
>
>Now consider a Consumer's policy with one policy alternative,
>
> 
>
><Policy>
>
>    <ExactlyOne>
>
>        <All>
>
>           <A>
>
>            <Policy/>
>
>          <A/>
>
>        </All>
>
>   </ExactlyOne>
>
></Policy>
>
> 
>
>In this case, the consumer policy alternative language of the nested
>empty policy is the null set. So no negations are implicitly present.
>
> 
>
>So the intersection procedure of the consumer and provider should yield
>
> 
>
>        <All>
>
>           <A>
>
>            <Policy/>
>
>          <A/>
>
>        </All>
>
> 
>
>in common. Yet the "meaning" of the empty nested policy differs in that
>from the provider's context, the meaning is not-B and from the
>consumer's perspective the meaning is null.
>
> 
>
>I think this is yet another anomaly stemming from including the AIN
>principle in the WS-Policy framework. IMO it adds another reason to
>remove the AIN principle and the Policy alternative language definitions
>from the spec.
>
> 
>
> 
>
>
>  
>

Received on Monday, 23 April 2007 16:57:21 UTC