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] | [Elist Home]


Subject: Re: [xacml] Attesting implementations and <type>-map,Match arg order issues



Hi Seth,

It took me a while to grasp your implementation, but I think the
difference between your system and ours, is that we use a "unifying"
typechecker.

During typechecking, since the Designators and Values each list their
intended data type, then the only type that must be "deduced" is the type
of an <Apply> expression.

It seems that you "lookup" a function named in the Apply construct and
then ask the function for its return type and then you know what return
type the <Apply> node has, correct? The map function complicates this, by
you having to look up the next argument and ask it. However, it looks like
you forgo this approach for a runtime type check, which is fine.

It is sort of analogous to forcing all integers and floats to be treated
as numbers, but have runtime checks to make sure that they either convert,
or raise errors during evaluation when the types do not match.

We use type variables and type instances for typechecking, and unify them
according to the signatures of the functions and the arguments. When type
variables do not dereferece to explicit types, or variables come in type
conflict, there is an typechecking error before evaluation even starts.

We've completely eliminated run-time checks from our evaluation engine. We
convert every XACML condition into a tree of Expression nodes that are
evaluated against a context and environment. Any new function introduced
to XACML follows the same API any other function does. "Map" and all the
other highter order functions use the same exact API as any other
function. Therefore, our internal API is the extension API as well.

I wrote about it previous to this email, but I thought it was too tedious
with implemenation detail and too long to post on the list, but if you
want that description, you can have it off line.

Cheers,
-Polar



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


Powered by eList eXpress LLC