OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [xacml] Schema 15f

Title: 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>

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
Subject: RE: [xacml] Schema 15f


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?


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>                                                        


                      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

                  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