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

[John Merrells <merrells@jiffysoftware.com>]

Polar Humenn wrote:

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

I think I must have missed something basic here then. This is my reading 
of the spec...

A12 says that type-equal is a match function, and that the arguments of 
a match function
are <T,bag<T>> : Boolean. A14.1  then says that the arguments for the 
type-equal
functions are <T,T> : Boolean.

I took this to mean that within a <XxxxMatch> element that the signature 
was to be
enforced as the former type, and everywhere else, ie within a condition, 
that it was
to be enforced as the later. Is this a correct interpretation.

>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.
>
I'm saying the same thing. This is how I'd like xacml to work. My 
reading suggests that
the signature is not based on the types passed but on the identity of 
the call site. In C,
or whatever, this would be like saying there's a function foo that can 
be called from
either functions bar or baz, but when calling from baz you have to pass 
an int and when
calling from baz you have to pass a double, and if you try to call the 
wrong one that's
a compile time type error.

>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.
>
Nope, I'm glad xacml expressions are strongly typed.

John