[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New issue: XACML 3.0 higher order bag functions may have significant problems
Hi Jan, It sounds to me that your comment is that we need a multi-datatype functionality. My understanding is that at present "bags" are only of a single datatype, as described in section 7.3.2 "Attribute Bags": "3257 There SHALL be no notion of a bag containing bags,Given this restriction, I do not see the value of providing a list of parameters of differing datatypes to test against the bag of a specific datatype. For example, if I have a bag of "apples", then it makes senseI do think having a single apple vs an apple-bag is useful, because everyone is not going to want to take the step of putting their single apple into a bag to do an apple to apple comparison. This is analogous to testing if a String is in a String[], vs having to put the single String in a 1 member String array. Apologies for the somewhat overly simplistic representation of the problem, but I am trying to get at what the core of the new functionality is, and either I am still missing something either in the functionality itself or in the possible value of it. However, in these simplistic terms, it does not appear to me to warrant changing 2.0 to move in this direction, at least for this specific "any-of" functionality. Thanks, Rich On 1/12/2012 4:55 AM, herrmanj@informatik.tu-muenchen.de wrote: Hi Rich, see inline. Best regards JanHi Erik, I expected that there was background material that provided the motivation, however, looking at the result, it seems to me that the "any-of" fcn has been expanded in an unnecessary way, since it appears to me that the change of the 2nd parameter in 2.0 to be n-1 parameters in 3.0, really is providing individual elements in separate parameters that could just as well be provided in a bag as they already are in the "any-of-any" fcn.Aggregating the arguments of n-arry functions in a bag of datatype-xy only works if they all have the same datatype wich is in general not the case (e.g. is-within-distance(polygonA, polygonB, 500meters)).Also, the "any-of" is ref'd in some of the other fcns, presumably as being an "atomic" one element 2nd parameter fcn. That ref'ing I expect becomes less meaningful as the 2nd parameter expands to effectively be a bag implemented as multiple parameters. It looks to me as if what might have seemed like a good idea at the time may have emerged as being duplication of existing functionality by effectively providing a less usable alternative to a bag as an n-1 list of individual parameters. I think in the email you ref'd when you said: "With this definition the any-of function actually becomes a special case of any-of-any, with one primitive type argument and one bag argument." that you and I are possibly in technical agreement, although we may have different perspectives on it. Unless there has been some real functionality added w this n-1 construct, my recommendation would be to fall back to the 2.0 impl and remove the n-1 parameter construct in 3.0.due to the limitation mentioned above i disagree and would recommend to keep the more flexible definition as it is now.Thanks, Rich On 1/11/2012 11:49 PM, Erik Rissanen wrote:Hi Rich, Please see this post: http://lists.oasis-open.org/archives/xacml/200912/msg00087.html (And other discussion on this issue.) Best regards, Erik On 2012-01-12 00:19, rich levinson wrote:I was perusing thru section A.3.12 today, looking at some of the details of the higher order bag functions, and it appears to me that there have been some changes made in 3.0 that do not look right. For example, let's compare the 2.0 and 3.0 definitions of "any-of". Some of the diffs are subtle, so I have bolded, italicized the points I want to call attention to. Note: I have tried to line up the paragraphs line by line of the 2 defns. Do not pay too much attention to the line numbers as they are sometimes off by 1 from the original because of quirks in copy and paste. Here are the points about the 2.0 vs 3.0 definitions: 1. Both 2.0 and 3.0 have the same name: /*xacml:1.0:function:any-of, */therefore, one would expect the functions to be identical. I think we will find that the are not only not identical, but have some very strange differences. 2. There is a difference in the hi-level defn of the fcns, where 2.0 uses the singular (compares 1 value to bag of values), and 3.0 uses the plural (compares multiple values to one bag of values). It appears that the change to plural is intentional, as will be evidenced in the points below, however, at this stage, it would appear that at the very minimum that the "name" of the 3.0 fcn should be different than the name of the 2.0 fcn. 3. The most important change is that the 2nd argument of 2.0, has become "n-1" arguments in 3.0. i.e. the "signature" of "any-of" has changed from 3 arguments to "n+1" arguments, because of the expansion of the 2nd argument. Aside from this change in quantity of arguments, I believe the semantics have also changed, and maybe not in a good way. 4. In 2.0, the function was effectively: "Does the 2nd argument appear in the bag in the 3rd argument?" In 3.0, this function appears to have become: "Does the 2nd argument appear in the bag in the last argument? Does the 3rd argument appear in the bag in the last argument? ... Does the nth argument appear in the bag in the last argument? If any of the above answers are "yes" then return true, ow false." We do not know on a true return which of the 2nd thru nth args matched something in the bag. Maybe all of them matched something, maybe only one, or maybe some number in between. 5. Based on prev bullet 4, this new variation on the "any-of" fcn begins to look suspiciously like the "any-of-any" fcn that compares 2 bags looking for anything in bag 1 that matches anything in bag 2. Therefore, it appears to me that the 3.0 defn of "any-of" actually "implements" "any-of-any", which seems pointless. I think there may be other similar issues in this section, but this one is the only I have had time to look at in detail. As usual, I am aware I may be missing something, in which case, in advance, "Never mind" :). The text of 2.0 and 3.0 follows: Thanks, Rich First, here is*2.0*: 4558 • urn:oasis:names:tc:/*xacml:1.0:function:any-of*/ 4559 This function applies a Boolean function between /*a specific primitive value*/ and a bag of 4560 values, and SHALL return "True" if and only if the predicate is "True" for at least one 4561 element of the bag. 4562 This function SHALL take three arguments. The first argument SHALL be an <xacml:Function> element that names a Boolean function that takes/*two arguments*/ of primitive types. /* The second argument SHALL be a value of a primitive data-type. The third argument SHALL be a bag of a primitive data-type. */ The _expression_ SHALL be evaluated as if the function named in the <xacml:Function> argument were applied to the second argument and each element of the third argument (the bag) and the results are combined with “urn:oasis:names:tc:xacml:1.0:function:orâ€. Now, here is*3.0*: 4680ï‚· urn:oasis:names:tc:/*xacml:1.0:function:any-of*/ 4681 This function applies a Boolean function between /*specific primitive values*/ and a bag of 4682 values, and SHALL return "True" if and only if the predicate is "True" for at least one 4683 element of the bag. This function SHALL take n+1 arguments, where n is one or greater. The first argument SHALL be an <Function> element that names a Boolean function that takes/*n arguments*/ of primitive types. /* Under the remaining n arguments, n-1 parameters SHALL be values of primitive data-types and one SHALL be a bag of a primitive data-type.*/ The _expression_ SHALL be evaluated as if the function named in the <Function> argument were applied to the n-1 non-bag arguments and each element of the bag argument and the results are combined with “urn:oasis:names:tc:xacml:1.0:function:orâ€. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]