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