[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] [CR] AttributeSelectorIndirect
>However, if you really want to put a "value" as the second argument, of >which I cannot see a good argument against, it would require a SCHEMA >CHANGE. That what was my reason for allowing <attributevalue> to specify a sequence. >Given that we agree with that, If you believe the /a/b/c/text() will >return a sequence of one you would use: > > <ResourceMatch MatchId="function:string-equal"> > <AttributeSelector RequestContextPath="/a/b/@b1/"> > <Apply FunctionId="string-first-and-only"> > <AttributeSelector > RequestContextPath="/a/b/c/text()"/> > </Apply> > </ResourceMatch> Illegal. First argument is of type sequence<string> - need to 1)wrap both arguments in first-and-only 2)use string-member-of - with <attribute value> for first argument, if you do not care whether the selector returns multiple values 3) use set-equal, with second argument specified using string-sequence function, or another selector, 4) use that new string-at-least-one-member-of (or, God, can it be made shorter? ;) , again, if you do not care about All this options, unless we go back to my original proposal to make functions determine appropriate sequence length at runtime (yeah, I know, it is not good), require relaxing requirements for the <*Match> funtions, to be the same as condition - arbitrary types of arguments to the top predicate. Which is not bad at all, on the other hand - unless you go really crazy, and start putting extension function with side effects into matches. daniel;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC