a proposal for combining Conclusions

[Bill Parducci <bparducci@gluecode.com>]

Below is a proposal focusing on how Conclusions may be combined in the 
Generalization model. As Simon and I worked through various scenarios it 
became apparent that combining Conclusions was the biggest technical 
hurdle to overcome if we were to be able to meet the use cases 
introduced earlier.

Under this model Imperatives are grouped into named Families. This 
allows us to define inter-Family combination independent of intra-Family 
combination.  The goal here is to remove reliance upon statically named 
combiners, allowing for a any number of Families to be combined with a 
limited set of combiners.

Processing occurs normally for the Policy: Targets matched, Rules 
combined and the corresponding Conclusions are gathered. Combination of 
Conclusions occurs by first ordering Families using the precedence 
defined by the inter-Family combiner then by the precedence defined by 
the intra-Family combiner, in effect creating a two dimensional 
resolution table.

Example:

   imperativeFamilySequence(ACCESS, MOVE)

   imperative(ACCESS, permit-overrides, permit, deny).
   exclusive(ACCESS, permit, deny)

   imperative(MOVE, stand-overrides, stand, sit).
   exclusive(MOVE, stand, sit).

Here we have 2 families: ACCESS and MOVE. The inter-Family combiner for 
ACCESS is deny-overrides and is MOVE is stand-overrides.

Each family consists of a set of mutually-exclusive imperatives. For 
each mutually-exclusive pair (e,e')

   do(e) = do-not(e').

Inter-Family combining follows the sequence: ACCESS, MOVE.

Suppose we have the following Conclusions:

   C1: do(permit), do(sit)
   C2: do(permit), do(stand)
   C3: do(deny), do(sit)

Evaluation occurs by combining Imperatives ONE Family at a time WITHOUT 
regard for Imperatives of lower precedence Famlilies.

In this example the permit-overrides combiner for the ACCESS Family--the 
Family with highest precedence--is applied, C1 (permit) and C2 (permit) 
are selected and C3 (deny) is dropped.

The next Family in order of precedence is MOVE so the MOVE combiner 
(stand-overrides) is applied. The combiner is applied to the MOVE 
Imperatives for C1 and C2 only, causing C2 to be selected (stand) and C1 
to be dropped. The ConclusionSet returned is C2 (permit, stand).

Looking at the problem another way:

   Imp./Con. |    C1       C2     C3
   ------------------------------------
   ACCESS    |   permit  permit  deny
   MOVE      |    sit    stand   sit

Processing occurs by row, from top to bottom. Therefore,

   ACCESS      permit  permit  deny   ---> permit

...this discards C3 so the next evaluation is:

   MOVE         sit    stand          ---> stand

...this discards C1 leaving C2, making the result (ConclusionSet):

   Imp./Con. |    C2
   --------------------
   ACCESS    |   permit
   MOVE      |   stand


The first observation that comes to mind that it is possible for an 
ImperativeFamily (a row in above table) to be ignored as a result of a 
higher precedence ImperativeFamily ruling out a ConclusionSet (column in 
table above) even though the it meets other criteria, however we believe 
that can be addressed by the inter-Family combiner.

Sorry, but to talk about this case in more detail is going to take a 
whiteboard ;)

XML
====

 From a schema perspective the concepts above are expressed thus:

</Policy>
<xs:element name="ImperativeFamily" type="ImperativeFamilyType"/>

<xs:complexType name="ImperativeFamilyType">
   <xs:sequence>
      <xs:element name="Imperative" type="xs:string" 
maxOccurs="unbounded"/>  <= IMPERATIVES
   </xs:sequence>
   <xs:attribute name="Name" type="xs:string" use="required"/>
   (FAMILY NAME)
   <xs:attribute name="Combiner" type="xs:anyURI" use="required"/>
   (INTERNAL FAMILY COMBINER)
</xs:complexType>


Then we add <ImperativeFamily> as a child of <Policy> and <PolicySet>.

<Policy>
   <xs:element ref="ImperativeFamily" minOccurs="0"/>
</Policy>

<PolicySet>
   <xs:element ref="ImperativeFamily" minOccurs="0"/>
</Policy>

Inter-Family combiner is indicated by policy-combiner-id in Policy and 
PolicySet. This element is a child of policy-combiner-parameters or 
policy-set-combiner-parameters.

<xs:element  name="SequenceCombinerParameters" 
type="xs:SequenceCombinerParametersType"/>

<xs:complexType name="SequenceCombinerParametersType">
   <xs:sequence>
      <xs:element  ref ="xs:ImperativeFamily" maxOccurs="unbounded"/>
   </xs:sequence>
</xs:complexType>


Comments welcome ;o)


b