RE: [xacml] Follow up on TC call

[Daniel Engovatov <dengovatov@crosslogix.com>]

> If there are no "operations" passed as values to such API, one can
easily
> design a schema for such interoperability APIs, implement it as web
service
> or commonly used component.

>I don't see why you can't.
>-Polar

The problem is that now the extension point is not as clearly specified.
Extension functions will not have the same semantics as those that are
standard - one will have to rely on the schema to signify it, but on
plain language specifications - especially on specifications which are
formulated right now..

We are leaving a LOT of useful functions out of the scope of the 1.0
standard - most implementation are most likely to add those.  If any
extensions that may become popular do follow the "higher order" semantics of
the build in collection - I am afraid interoperability on the extension
level may be troublesome, for the reasons I cited (which is currently out of
the scope of the standard - but do not we want to be forward looking?)

To summurize - I agree that in the form presented are useful - and I can
translate them into more convinient and strict constructs in  implementation
when consuming XACML policy.  But I feel that the  semantics of the
extension point should be clarified - with schema limitations, or somehow
else, to dissallow invoking arbitrary operations 
from the extension point.