[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: another first proposals to address the open issues No 4
Below and attached a first proposals to address the open issues No 4.
Proposal for issue No 4.:
§ The problem/unnecessary restriction:
o The signature of any-of and all-of must be:
§ any-of|all-of(function, a primitive data type, bag)
§ all-of-any|any-of-all|all-of-all(function, bag, bag)
§ map(function-WITH-ONE-Argument-ONLY, bag) … returns bag
o Limitations occur if the inside-function
§ has more than two (or one) parameter(s)
§ doesn’t have an inverse counter part
1. Because of this you might need to change the order of the last two parameters - in case of an inside-function with two parameters)
o a more flexible definition of any-of and all-of will eliminate the limitations (c.p. from line 4664).
o the any-of-any function could be changed to a function where with exception of the first parameter (that specifies a function over primitive data types) all following parameter will be bags. The result will be true if the function applied to one of the tupels of the cross product set evaluates to true.
o all-of-any, any-of-all, all-of-all must be updated correspondingly… Problem: explosion of functions due to increased number of parameters.
o map should also allow for arbitrary functions and thus should be changed to c.p. 4862.
§ example: add 5 to every value in an integer bag would be expressed as:
1. map(integer-add, pointer-to-bag, 5)
Two further comments:
o any-of-any (all-of-all) with two bags where one bag has one element corresponds to the any-of (all-of) function.
o any-of, all-of, any-of-any, all-of-all start introducing some sort of loops in XACML. Why not adding a for loop and maybe if-than-else constructs?