RE: [xacml] Schema 15f

[Daniel Engovatov <dengovatov@crosslogix.com>]

Title: Schema 15f

To clarify my concern.

 

    Using stated promotion rules to determine the return type of a "numerical" operation breaks the isea of strong typing of the return type of the function.

Not good for policy verification..

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Wednesday, July 10, 2002 2:04 PM
To: 'XACML'
Subject: RE: [xacml] Schema 15f

Daniel - My understanding is that your issue is addressed by the "type promotion" rules that Michiharu has identified.

 

In case anyone thinks I have inadvertently revealed a deceit by referring to the contents of Michiharu's document, which I previously said I was unable to decode, I was actually able to decode the plain-text part of the document, which discussed type-promotion, but not the table, which (I assume) contained the legal type-combinations for the functions.

 

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

 

-----Original Message-----
From: Daniel Engovatov [mailto:dengovatov@crosslogix.com]
Sent: Wednesday, July 10, 2002 4:40 PM
To: 'Tim Moses'; 'XACML'
Subject: RE: [xacml] Schema 15f

I apologize for repeating myself, but how do you plan to map "numeric"?  Float's and exact integers do have very different meaning for many, many purposes

(you do not open an account N. 3.0000000001 != 3 - IEEE floats do not guarantee last digit IIRC)  My suggestion was - allow an implicit conversion of integer to float, but

not the other way around (using FLOOR, and ROUND instead...)

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Wednesday, July 10, 2002 1:33 PM
To: 'XACML'
Subject: [xacml] Schema 15f

Colleagues - Attached, please find version 15f of the policy schema, incorporating the decisions we made on Monday last, and the table of function names and legal argument types.  Some notes ...

1. The documents are not "free-standing".  Further explanation is required if one is to fully understand them.  Of course, the intention is to provide that explanation in the specification, which is not available yet.  In the meantime, some "real-time" discussion is necessary.  We can do this on Monday.  Alternatively, we could hold an ad-hoc schema sub-committee meeting on (say) Friday, provided people are ready to discuss by then.

2. There has recently been some discussion of the schema on the list.  I have attempted to address some of the issues raised.  But, I suggest that we hammer out an agenda ahead of our next meeting in order to go over all the issues raised.  I'll review the mail-list and produce an initial schema-issues list.

3. I was unable to decode Michiharu's operator-mapping list.  The attached is my own attempt.  Perhaps, Michiharu will verify my version.  I have retained the "duration" functions, because I personally feel that they have some value, provided we carefully define them.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183