[xacml] Notes for the call

[Daniel Engovatov <dengovatov@crosslogix.com>]

Title: Notes for the call

In this message I want to summarize some of my concerns on the use of hierarchical promotion model and "numerical" designator in v15 of the schema.

I am also a little worried about some other aspects of the current XACML standard proposal - in particular, what I see as too much emphasis on a particular XML resource model and XPATH usage.  I would have preferred for at least part of this functionality to be recommended as optional, extended compliance.  On the other hand, it may be handled at a level, not affecting core implementation.

While the following examples can be, obviously resolved internally, I do believe that most implementation will face similar issues, and the benefits of being "similar" to parts of some draft specification of a language, with a very different set of intended usage is not very appealing. Given the complications. 

It will be probably addressed if we, as decided, add policy definition exchange schema in the future.

For numerical data type functions, the proposed solution does not work well if additional, numeric compatible data types are used.  Our implementation will definitely use, internally, such types as enumerations, "money" data (such as, for example "balance" - convertible to and from float, but with limited accuracy, and range) and others.

1. When a numerical data type convertible both ways is used, XACML standard functions use is unclear.  What type, for example, (MINUS <balance> <float>) should return?

2. When numerical data type can be converted to integer meaningfully, but not to float, for example enumeration - to integer, or Boolean to integer, standard does not guarantee such promotion will not eventually happen.

3. For some types, such as positive integer with a minus operation, return data type will depend on the values of operands.   It may be positive or negative integer.  Similarly, division of two integers may be an integer - when they are divisible, or float.  It is not clear how to handle these situations, especially with extended data types used.

What I propose:

1. Only two numerical data types are used in the standard functions.  Long integer and double (64-bit IEEE  754-1985 double).

2. Permitted promotions are not hierarchical.  If a type can be converted to integer does not mean it can be up converted to float.

       
For numerical data types following promotions are permitted:
a)      All xs:integer types to our chosen long type
b)      All xs:integer types to our chosen float (double) type
c)      All xs:float types to our chosen double type.
d)      optionally Boolean to integer, as in #f to 0 and #t to 1.

3. Function name must have unique return type and name combination in a policy.

4. When function is called, each argument supplied must be of the declared type - or it should be promoted to the declared type, if possible.  Return type is always pre-defined.

5. Each numerical function is defined for both types of argument

double PLUS double double
long PLUS double double
double TIMES double double
long TIMES double double
double DIVIDE double double
long DIVIDE long long  (returns floor of float result)
double MINUS double double
long MINUS long long

and so on for all numerical functions in the current table.  It covers all the needed usage and will not cause ambiguity in the extended implementations.

Daniel Engovatov

----------------------
Crosslogix, Inc.