Re: [xacml-comment] C003 and matching in targets and conditions

[Polar Humenn <polar@syr.edu>]

On Mon, 25 Nov 2002, John Merrells wrote:

>
> Polar Humenn wrote:
>
> >It is not a mistake. The *Match constructs take the match function and
> >apply it between each element in the bag and the explicit value.
> >
> >Currently, the equivalent expression to a Match element that would appear
> >in the condition as:
> >
> >( any-of matchId-function primitive bag<primitive> ).
> >
>
> Firstly, this needs to be very clearly pointed ont in the specification.

I agree that in Section A.12 Match Elements we can put a _non-normative_
statement that says that the equivalent expression of a match element in
the terms of higher order functions and reference that section. I say
_non-normative because I want to preclude this definition as being the
implemenation of the particular match element. For example, when the match
element appears in the target it may be a specification of some
complicated indexing function over possibly predetermined values of a
specific attribute type.

> I've read the spec maybe six times in the past three months and I only
> just noticed that the signatures differed in the specifications. [I was
> probably blinded by the natural assumption that the signature would not
> depend upon the context of the expression. I can't think of another
> language that does this.]

I don't know what you mean here. The signature of the Match element is not
the same as the signature of the function USED WITHIN the element.

As for the signature depending on the type of the context of the
expression, is standard type theory. Lots of languages as far back as C,
Fortran, take advantage of such things. For example, the function, "+" in
almost any language can be "integer-add"  or "double-add", or even
"boolean-or", depending on the type of the variables or constants used in
the expression.

> Secondly, this is definitly going to catch users out who have to write
> this stuff. They'll happily cut an expression from a condition and paste
> it into a target, or vis-versa, and get upset. They'll be screwed unless
> they hack out, or in, the calls to 'only-one-of'.
>
> Wouldn't it be simpler for everyone to just make the signature the same
> in both places?

True, and I think we are going to rearrange the schema so that the
explicit value comes first and the designator second. That will give some
consistency between "any-of" and the match elements. However, it is not an
easy cut-paste job, as "any-of" appears in a <Apply> statement with
<Function> and the Match element almost stands on its owwn.

Also, you can use the Match Elements in both the Condition and the Target.

> You've got polymorphism based on the context of the call. How about
> adopting the more usual approach of basing the polymorphism on the type
> of the arguments? If I pass a primitive and a bag it does the match
> thing, if I pass a primitive and a primitive it compares them.

That is not true. The polymorphism is based on the types of the arguments,
not the context of the call. The Designator or arguments all have
explicit data types, and that instantiates the type signature of the Match
element or the application of the "any-of" function.

What you are asking for is a type generalization in an ad-hoc manner,
which requires a runtime check to see what the type of the argument is at
evaluation time. Having it the way we have it, you force the expression to
be type correct, which precludes the need for a runtime check of the
argument's type. That it one of the major benefits of type checking.


> Or, how about using two different names to reflect the fact there are
> two different behaviours... string-equal, string-match, double-match,
> double-equal, ...

I'm missing something in this comment. Two different names for different
behaviors? You mean for the match elements?

> I think that polymorphism on argument type is the best approach, then
> changing the condition signature to be the same as the target signature,
> and then finally having different names for the behaviours.

Forgive me, I am definitely missing something here. The Match element
signature should be the same in both the Target and the Condition. We just
make a statement that if the Match element ends up in the Target that it
was restricted to those functions that are easily used for indexing, (but
I think we are going to relax that condition).

-Polar

>
> John
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>