xacml — archive

[System]

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