attribute filter RuleReference ?

[Tom Zeller]

>> which makes me wonder why I was able to parse an invalid schema.
>
> That's an open question which we haven't bottomed out.

In my case the XML was not schema invalid, my understanding of the
<choice> element in the schema was what was wrong.

>  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.

When you say normalize are you referring to Node.normalize() or ?

> [*]
>
> 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.

Would MatcherIdFromPolicy clarify the semantics ?