Checking contextual integrity

[Rod Widdowson]

Thanks for the input.  Some cumulative comments...

> >It's not clear to me if the failure scenario always represents something
> >exceptional, but given these three options, I think I'd go with #2 or #3.
> 
> Probably most of them will be exceptional,

I'm inclined to think of all of them as exceptional in that the sysadmin who
configured the filter expected that some information would be available to
them it wasn't.  It's certainly not a standard flow.

> I think that understanding flow and semantics is easier of it's tri-state.

Granted.

> >Thinking of the tri-state as an enum makes me feel better ? Or
> >perhaps, as Rod originally hinted, the return value could be an Action
> >@Event.
>
> I assumed it would be an enum.

Me too, but as I was reviewing this mail last night I realized that there is
an implementation wrinkle.  In this situation the tri-state is asking "Does
this attribute value match", but the code calling it is building a list of
"acceptable to the filter" attribute values.  The code calling *that* method
is the one that decides to add (Permit) or remove (Deny) the values from the
result.

So it's not just a {true, false, unknown} enum as a return value it is also
{Collection.isEmpty(), !Collection.isEmpty(), null} tri-state, the
distinction between null and isEmpty() being subtle, but important.  But
that is a paradigm used elsewhere.

> I'm assuming we've considered and rejected the handler-chain kind of
pattern, where you have two boolean methods:
>
>	boolean applicable();

I hadn't but I have now.  In some corner cases the obvious implementation
(check applicability then apply at a global level) doesn’t do what you want.
Consider

<PolicyRequirementRule xsi:type="basic:AND>
    <basic:Rule xsi:type="basic:SomethingToCheckThatPredciateBIsValid"/>
    <basic:Rule xsi:type="basic:PredicateB"/> 
</PolicyRequirementRule>

If you checked against basic:PredicateB applicability at the top then the
rule isn't applicable, but in fact it is.  The same goes for OR, suitably
de-Morganized.

So for my money it doesn't add anything since you end up calling two methods
rather than calling one and looking at a tristate.  Further this area is
already a grotesque tarpit because we have two different things trying to be
the same and adding another orthogonal access at the same level would (I
believe) add even more confusion before you even start to think about the
vocabulary for applicable (because the contexts are correct) or applicable
(because the PolicRequirementRule says so).

I'm actually on vacation through until Monday, but I'll be on the call in 6
hours.  We can discuss this further there, or in mail and on Monday I'll
make a call.

Rod