attribute filter RuleReference ?

[Rod Widdowson]

> 
> <complexType name="OR">
>   <complexContent>
>    <extension base="afp:MatchFunctorType">
>      <choice minOccurs="2" maxOccurs="unbounded">
>        <element name="Rule" type="afp:MatchFunctorType" />
>        <element name="RuleReference" type="afp:ReferenceType" />
>      </choice>

I'd missed that particular inanity entirely I'm afraid.  Apologies for the
confusion engendered.

I'll maintain that this is a reference to far and that it should be remove
from the schema and the implementation.  I think it will be difficult to
explain the semantics when people move rules between roles (Matcher and
PolicyRule)[*].  Further I'll note that in V2 they were explicitly
unsupported.

If you want to make it work there will be a couple of things to worry about:

1) You do not know a priori what type of rule you are injecting into the
parent.  So you'll need to use another pair of bridging classes, each one
with two constructors (one taking a single Matcher and one taking a single
PolicyRule) then Spring should take care to do the right thing.  The
bridging classes won't be complicated, but they do add needless (to my mind)
complexity.

2) You may find that #getAbsoluteReference() will need some work to
normalize the names for rules.

Neither are particularly onerous, but I just don't think that it's worth the
effort now, nor worth the effort in documentation or the future effort in
support of the odd cases.

> 
> which makes me wonder why I was able to parse an invalid schema.
> 

That's an open question which we haven't bottomed out.  Having had some
experience of writing the parsers and hence exposure to the spring errors
you get when dealing with non schema invalid input I'd recommend that we
plan to normalize anything which is going into a customer schema parser,
just to help the user get a meaningful error.  For now, however it suits
quite nice to allow invalid input since it encourages us to make the more
parsers robust where possible.

Once again, apologies for any confusion.

Rod

[*]

Consider:

<afp:PolicyRequirementRule xsi:type="basic:AttributeValueString"  id="foo"
value="jsmith" ignoreCase="true" />

And

<afp:AttributeRule attributeID="email">
    <afp:PermitValueRule xsi:type="basic:AND" >
	<basic:Rule xsi:type="basic:ANY" />
	<basic:RuleRef ref="foo"/>
    </afp:PermitValueRule>
</afp:AttributeRule>

Do we scope the AttributeValueString rule to the attribute ID  "email"
inside the PermitValueRule or do we use the semantics from where is defined
(inside the PolicyRequirentRule)?  If the former then the current
implementation is borked and we need to revert to one of the previous one
which nobody like - and that purely because of edge case semantics of an
edge case which was explicitly disallowed in V2.  

The latter is completely defensible, but either case will represent
maintenance load because people *will* try to do this sort of stuff if you
give them the rope.