RE: [xacml] Follow up on TC call

[Daniel Engovatov <dengovatov@crosslogix.com>]

>I get the feeling that you are concerned about "similar" XACML "engines"
>that you can drop extension functions into and they should work for all
>XACML "engine" implementations. (Is that what you mean by
>"interoperability"?).

Yep.  I am convinced that for XACML implementations to be useful most will
have to extend functions.  We already left out a lot - duration
calculations, things like "sum-of-integers", operations on XPATH nodes etc
etc...

Strength of a language is in its libraries - and I want us to be forward
looking and ensure that they can be made
extensions similat and portable easily.

I suggest we do not repeat known mistakes - such as non-portable ABI in C++,
that caused a lot of troubles to library developers.


>For this capability I would think you need to define and standardize an
>interface with which to do that. That is out really out of the scope of
>XACML. However, I can see how that can easily be done with certain
>interface tools, such as Java, JavaBeans, C++, COM, DCOM, .NET,
>CORBA, etc.

Even if it is out of the scope now - I do not think it should be ignored,
and our model should support it.

Second point - why it is easy to implement in each of the technologies you
cited, it is easier to do if it does not involve this new "callback"
semantics of functions invoking other functions - without limiting ourself
to a particular platform of those you cited..  Java passing a string value
to .Net component is easier to deal with then with Java RMI invoking .Net
server..

What I want is to preserve simple value interface and to keep the extension
point to be exactly the same as the limited subset of build-in functionality
that we define.


Also - it is clear from Michiharu e-mail he he misunderstood limitations of
the set functions use in MatchId in the previous draft.  "member-of",
"set-equal" and "at-least-one-member-of" does cover ALL of his use cases
without introducing ambiguity of arbitrary operations in MatchId.  So the
argument that we need those new additions for his use cases is simply not
correct.

Beside that - the only new functionality within the standard collection of
funcitions, that this new extensions open is a set based comparison and
matching.  This is trivial to add by introducing map versions of "*-greater"
and "*-match" operations - at about the same cost as the number of
funcitions needed for the "higher-order" additions, and without the drawback
of complicated extension point semantics.
So the argument that we need those aditions for the extra functionality in
<apply> is not correct either..


Regards.

Daniel.