xacml — archive

[System]

Just to clarify what I was proposing instead of the "higher-order" schema additions - objections to which I listed in previous mails. With the restrictions on MatchId functionality -- with them I fully agree -- in place, the only functionality in the condition that is added by the "higher-order" schema, can be implemented with the following set of functions (not necessarily all mandatory) map-integer-to-decimal map-decimal-to-integer *-bag-greater-then *-bag-greater For integer, decimal, string, date, time, datetime with the semantics of comparing two sequences "any-to-any". Other operations can be covered by changing operands order and using sequence(<attributevalue>) to specify single value. It is logically equivalent. And *-match-is-in - equivalent of "is-in", AKA "member-of" but using string, RFC822, X500 match instead of *-equal That's it - exact same functionality, no need for any additional written restrictions in Match - schema does it for us, and clear extensible semantics of the <apply> - that will allow for easy interoperations on the level of extension function libraries.. And maybe less work to implement and test.. Of course, the "coolness" factor of such solution is low, but here I do not have any argument against.. Not sure if I can be for the call - if not, my vote is strongly against the additions, but if our featuritis is bad enough and it is accepted - for the restrictions on the <MatchId>, and for additional work to clarify the resulting semantics of the function extension point... Regards. Daniel;