[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Ordered Combinators
Greetings, I would still like to issue a caution to these ordered Permit-Overrides and Deny-Overrides. The current combinator algorithms imply that it may return Permit-Indeterminate, Deny-Indeterminate, or NotApplciable-Indeterminate based on the availability of the arguments or errors in evaluating their consitiuents, being careful to make sure one does not return the wrong thing, i.e. Deny in the face of and Indeterminate in Permit-Overrides, or Permit in the face of an Indterminate in Deny-Overrides So, why the ordered combinators? Is it only there to make sure that if you are evaluating in the face of errors or availability of arguments, so that you will get the same answer from different implementations based on the same inputs/availability or error conditions? This requires a lot more than just specifying an ordering to the combining algorithm. Otherwise, you are giving a "false sense of integrity." I think you are biting off more than you can chew. In PolicySets, this requires that all Policies be evaluated by the same evaluation engine. If a "sub" policy's combinator evaluates a rule that generates an Indeterminate, then the PolicySet may return Indeterminate. However, under another implementation although the same "sub" policy will get evaluated at the same point, but indeterminate may not be the case due to a different evaluation of the rules of the "sub" policy, but you have no real control of this. So, I think it that really doesn't take the problem you are seeking to fix. Also, I'm a little concerned about the definitions of and, or, and n-of, which also affects this. I'll write that under a separate thread. Cheers, -Polar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]