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

Ah, I think the misinterpretaion problem is this statement in lines
3491-3496,

"Each argument to the named function MUST match the appropriate primitive
types for the <AttributeDesignator> or <AttributeSelector> element and the
following explicit attribute value, such that the explicit attribute value
is placed as the first argument to the function, while an element of the
                                                       ^^^^^^^^^^^^^^^^^
bag returned by the <AttributeDesignator> or <AttributeSelector> element
^^^
is placed as the second argument to the function."


Do you think you are missing the part abou "an element of the bag"?



> A14.1 then says that the arguments for the type-equal functions are
> <T,T> : Boolean.

That is correct.

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

No, the functions don't change their types.  The function "string-equal"
takes two primitive strings and returns a primitive boolean. The Match
element *uses* that function in a specific way with respect to a bag of
values of a primitive type and an explicit value of the same primitive
type.

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

I'm confused about what you mean here. What forces you in "bar" to pass
"foo" an "int"? In contrast, what forces you in "baz" to pass "foo" a
"double"?

I think your interpretation is a bit backward.  It should be, depending on
the arguments given to "foo" in "bar" or "baz" determines which "foo" you
will call. This is called "overloading", where you use the same name to
mean different functions.

Unforunately, in C, symbol overloading is ad-hocly defined and only works
for a set of well known types, such as int, float, double. We elected not
to go with a overloaded "equal" function, because we don't limit the type
system to types of which only those types are defined by XACML. You can
introduce extensions to XACML to handle other datatypes. You would not be
able to call "equal" on them, because you would have to formally specify
the actual equal function to use. For example, you cannot define a
"struct" in C, and call equals on variables (s1 == s2) containing that
struct, you'd have to define a function "TypeEqual(struct C * s1, struct C
*s2)" and explicitly call that.

That is, unless C has gotten more like Haskell over the last few years! :)

Cheers,
-Polar

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