Attribute Filter predicates

[Rod Widdowson]

> Leave this with me.  I am wondering whether there may be a middle way
> that
> leaves the weirdness in one place (probably the filter engine), allows
> context insensitive parsing, and allows the predicates to concentrate on
> what they should do in the normal place.

Having looked at this all ways up it seems that the best thing is to make
the implementation match the schema.  That is to say that the output of
parsing any <Rule/> is a populated class which implements MatchFunctor.
That way the parsing code is completely context free - you see a thing of
type foo and you summon up a FooClass which implements MatchFunctor.  Done.
This is what V2 did.

I think, however, that we can hide the unpleasantness of having to implement
both <PolicyRequirement> role and the <AttributeRule> role from the actual
rule implementations; so things like PrincipalNameString would just
implement a Predicate<AttributeFilterPolicy>, but AttributeValueString
implements a Predicate<AttributeValue>.  The details of what a Rule means
"in the wrong place" can be hidden in the parent classes.

The Boolean MatchFunctors become marginally more complex since they have to
implement <PolicyRequirement> role in addition to the current implementation
of the <AttributeRule> role.

I have an additional question for Tom (and possibly Scott who has been here
before):

Given that I am going to be modifying this stuff, would it make sense to
exbed the concept of <PermitValueRule> and <DenyValueRule> into real
classes?

What I mean is that the current way that this stanza:

<AttributeRule attributeID="AttributeName">
        <PermitValueRule xsi:type="SomeRandomRule">
</ AttributeRule>

would be represented is by an AttributeValueFilterPolicy which contains:

 - The attributeId "AttributeName"
 - A boolean (matchingPermittedValues) set to True
 - A reference to "SomeRandomRule".

That is to say <AttributeRule/> and <PermitValueRule/> has been flattened
into one class.

What I am wondering is whether it would make the parsers easier to implement
if the upshot was

- An AttributeRule containing:
   - The attributeId "AttributeName"
   - A reference to a PermitValueRule containing
       o A reference to "SomeRandomRule"

Obviously this is slightly more heavyweight in classes/run time cost, but
I'd doubt you’d notice.  But if it makes the parsers easier it might be
beneficial, but I don't (yet) know enough about the parsers to make the
call.

Rod