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

There are 2 parts of this message. First, there is a general design
argument against retaining the "absent policies [within the contextually
relative policy language] are present as negations" (hereafter AIN
principle). Second there is a comment on Chris Ferris's remark on
consumer, provider and empty (nested) policy semantics.

 

A policy framework should aspire to permit a good deal of freedom to
domain policy writers in specifying semantics for their policies, while
nevertheless keeping the description of basic tasks (especially
intersection) reasonably simple. It is possible that frameworks could
standardize semantic constants (like "or", "not", "required",
"supported" "only" "obligatory" "permissible" etc) and insist that
domain policies use these semantic pieces where appropriate. (Xacml and
deontic logics go this way.) But WS-Policy has been very minimalistic in
this regard. The basic components-policy, policy alternative, and policy
assertion (with or without policy nesting or policy parameters) --have
at least a simple baseline intersection procedure that is based on
matching policy alternatives in terms of their constituent policy
assertion qnames.

 

One place where the framework currently intrudes on designing policy
assertions for a domain is in the area of policy assertion
incompatibility relations. A policy assertion author may want to specify
a set of policy assertions that are in some way mutually exclusive.
(MaryAnn calls these constraints of the "only" type.) A domain may wish
to have a data type where the qnames represent mutually incompatible
semantic options so that only one of these policy assertions can be
present in a policy alternative. In such a situation, an empty policy
alternative seems to be forced to have the semantics of a conjunction of
the negations of each policy assertion present in some other
alternative, at least under the current apparatus of 1. policy
alternative languages (which serve to limit the bounds of negation
completeness) and 2. the AIN principle.

 

The policy framework would be considerably simplified by first removing
the AIN principle. Then, since the policy language definitions only use
is in applying the AIN principle, these definitions are no longer
needed.  Intersection remains basically as is, maybe with some
clarification about nested policy matching. [The XML processing
exercises used in canonicalization are not involved in these issues.]

 

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.

 

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