OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

Rich, you’ve got it mostly right, except:


In any-of, there is no constraint on where the bag appears. The parameters are given to FunctionName in the order they appear, with the variation occurring at the position where the bag appears.


In any-of-any, individual (non-bag) parameters are also allowed, which are simply used as constant values of FunctionName arguments (also positionally-determined).


The TC recently decided to remove the Haskell definition because it isn’t generally understood and we thought these functions could be explained by text and examples.





From: rich levinson [mailto:rich.levinson@oracle.com]
Sent: Friday, 13 January, 2012 14:32
To: Tyson, Paul H
Cc: herrmanj@informatik.tu-muenchen.de; Erik Rissanen; xacml@lists.oasis-open.org
Subject: Re: [xacml] New issue: XACML 3.0 higher order bag functions may have significant problems


Hi Paul, Jan, and Erik,

Thanks for the feedback. I think I "get it" now.

Here  is the way I now understand the functionality (please bear
with any ad-hoc notation, it is only temporary).

First: the any-of function can be viewed from the following perspective:

Really, what we are interested in is applying varying sets of
parameters to some function, FunctionName, which takes
n parameters, p1, ... pn, where the variation is done to the
last parameter, pn.

So a code declaration of any-of might look like this:

boolean b = anyOf("FunctionName", p1, ... pn-1, Bag(pn(1->m))

where anyOf is provided with:

  • the FunctionName,
  • n-1 parameters: p1, ... pn-1
  • a Bag of m values for pn

anyOf will then evaluate "Function(p1, ..., pn-1, pnm)" m times,
and if any of the m evaluations returns true then anyOf returns true.

So, with this in mind, I am satisfied that the any-of text in 3.0 appears to be correct,
and aside from the function id, I don't think any changes are needed.

Similarly, for the any-of-any function, I think I have a much clearer picture now
of what its intended behavior is:

This appears to me now to be a "simple" generalization of "any-of",
in the sense that the same function of n parameters, FunctionName,
will be evaluated, except now, any of the n parameters can be a Bag
of values, and things will generally look like this:

boolean b = anyOfAny("FunctionName",
                                           Bag(p1(1->m1),          // (i.e. m sub 1)
                                           Bag(pn-1(1->mn-1),  // (i.e. m sub n-1)
                                           Bag(pn(1->mn))         // (i.e. m sub n)

In this case, the notation (1->m1) means the bag is of length, m1,
and that there will be m1 iterations performed when this fcn is
called with the other n-1 parameters held constant.

A final note of clarification is that there is no real restriction on the
datatypes of the n parameters. i.e. p1 and p2 and any of the others
do not have to be of the same "primitive data type". Within a Bag of p1,
of course, the datatype remains constant, but, in general,

FunctionName(p1, p2, ... pn-1, pn)

can have any primitive data types that it needs to do its job.

So, I am satisfied leaving the text as is. I am not sure if others had similar
problems comprehending the functionality, but, if so, my recommendation
would be to incorporate some of the above representation, which, at least
for me, is easier to understand than what is in the text, but this would require
something of a rewrite of the whole section A.3.12 for consistency, which is
not something that I could allocate the time for right now, so I am not
suggesting anyone else do it either.

One final, final note is that it was because I was doing something else, where
Haskell came up, and I remembered that Haskell was used in this section,
which is why I went to this section to see an example of Haskell applied to
something I was somewhat familiar with. As such, I am a little disappointed
that we are removing it, as it seems to me the Haskell connection might be
helpful for people to understand it better.

Thanks again to Paul, Jan, and Erik for responding and providing the hints
I needed to "get the picture".


On 1/12/2012 5:20 PM, Tyson, Paul H wrote:

Here’s an example showing what the 3.0 definition of any-of can do but the 2.0 couldn’t.


To test whether any of a bag of time values is within a certain range, we can say:


any-of(‘time-in-range’, {05:00,06:00, 07:00}, 06:30, 14:30)


There are 4 arguments to ‘any-of’:

The function name, ‘time-in-range’

A bag of time values

A single time value marking the beginning of the time range.

A single time value marking the end of the time range.


This will be evaluated as 3 calls to ‘time-in-range’:





The last of these will return ‘true’, so the any-of function will return true.


Time-in-range is the only built-in Boolean function of more than 2 arguments, but Jan could probably supply more examples from GeoXACML.


The extended functionality is not everything you would want if you were used to  Lisp or some similar language, but I think it is a useful extension.  However, the 3.0 function needs to be re-identified so 1.0 processors can remain compliant.





From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of rich levinson
Sent: Thursday, 12 January, 2012 15:56
To: herrmanj@informatik.tu-muenchen.de
Cc: Erik Rissanen; xacml@lists.oasis-open.org
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,
or a bag containing values of differing types;
i.e., a bag in XACML SHALL contain only values that
are of the same data-type."

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 sense
to ask:

Is "apple-01" in this bag?
(I think the any-of (fcn-id, apple-id, apple-bag) fcn satisfies that)

It also makes sense to ask:

Is at least one of "apple-01", "apple-02", "apple-03" in this bag?
(I think the any-of-any(fcn-id, apple-bag-1, apple-bag2) satisfies that)
(and therefore there is no need for:

any-of(fcn-id, apple-id1, appleid2, appleid3, apple-bag)

It sounds to me like the multi-data type suggestion would be like this:

any-of(fcn-id, "apple-01", "orange-02", "lemon-03", apple-bag)

This does not seem to make a lot of sense to me. Even though you can't
put apple, orange, lemon in one bag to use the any-of-any fcn, I see no
strong motivation to ask if a specific orange is in the apple-bag.

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



On 1/12/2012 4:55 AM, herrmanj@informatik.tu-muenchen.de wrote:

Hi Rich,
see inline.
Best regards
Hi Erik,
I expected that there was background material that provided the
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.
On 1/11/2012 11:49 PM, Erik Rissanen wrote:
Hi Rich,
Please see this post:
(And other discussion on this issue.)
Best regards,
On 2012-01-12 00:19, rich levinson wrote:
I was perusing thru section A.3.12 today, looking at some of the
of the higher order bag functions, and it  appears to me that there
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
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
      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
      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
      in the points below, however, at this stage, it would appear that
      the very minimum that the "name" of the 3.0 fcn should be
      than the name of the 2.0 fcn.
   3. The most important change is that the 2nd argument of 2.0, has
      "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
      argument. Aside from this change in quantity of arguments, I
      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
      In 3.0, this function appears to have become:
          "Does the 2nd argument appear in the bag in the last
            Does the 3rd argument appear in the bag in the last
            Does the nth argument appear in the bag in the last
            If any of the above answers are "yes" then return true, ow
      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
      2 bags looking for anything in bag 1 that matches anything in bag
      Therefore, it appears to me that the 3.0 defn of "any-of"
      "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:
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
              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
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
              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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]