[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
On Mon, Dec 02, 2002 at 03:48:39PM -0500, Polar Humenn wrote: > 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. Actually, I think our implementations aren't so different, but I also won't bore people with the details now. (I probably just didn't explain our approach quite right) > 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. Yes, we do this "lookup" but we don't have any runtime checking needed to support it. As I said in my previous email, the map function only complicates this from the API point of view, since it may require programmers to do a little more work. > 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. Actually, that's basically what's going on in our system too. It's too hard to describe the subtle differences succinctly, so I won't try here. When I get more time on my hands I'll send you a better reply. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC