[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Schema 15f
Daniel/Michiharu - So, we have two proposals ...
1. Separate functions for integer and float argument types
2. Explicit functions for round and floor (with one float argument and a return data type of integer).
Any other suggestions?
Personally, I prefer proposal 2. It seems to make it absolutely clear what is supposed to happen when converting a float result to an integer.
<Function Name="urn:oasis:names:tc:XACML:0.15c:operators:round" DataType=xs:integer">
<Function Name="urn:oasis:names:tc:XACML:0.15c:operators:add" DataType=xs:float">
<Attribute DataType="xs:float">1.2E3</Attribute>
<Attribute DataType="xs:integer">1</Attribute></Function>
</Function>
</Function>
All the best. Tim.
-----------------------------------------
Tim Moses
Tel: 613.270.3183
-----Original Message-----
From: Michiharu Kudoh [mailto:KUDO@jp.ibm.com]
Sent: Thursday, July 11, 2002 6:17 AM
To: Daniel Engovatov
Cc: 'XACML'
Subject: RE: [xacml] Schema 15f
Daniel,
I think that a solution for your concern would be to supply a couple of
functions for different numerical data types such as integer_equal,
decimal_equal and float_equal in addition to the numerical_equal. For
example, the integer_equal receives two integers as input arguments and
returns an integer. In this case, you can raise a type exception if the
input argument is float while the integer_equal is used. Is that what you
want to support?
Michiharu
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Daniel Engovatov
<dengovatov@cross To: "'Tim Moses'" <tim.moses@entrust.com>, "'XACML'"
logix.com> <xacml@lists.oasis-open.org>
cc:
2002/07/11 06:10 Subject: RE: [xacml] Schema 15f
Please respond to
Daniel Engovatov
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC