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] [CR] DataType attribute required?



That is correct.

When we started discussion about functions, at least my personal idea was
that
if you specify data type within arguments - you can overload function
names (so when you see add(integer, integer) you know which add to use).
But then we decided to have argument type embedded into function names, so
now we have all string-sequence and decimal-member-of.  Type of the argument
is indeed redundant now - as the external source is not aware of XACML types
and
PDP gets everything encoded as strings anyway..

But this will work as long as we do not allow any type conversions ever.  If
we
decide to specify that any functions taking a decimal (numeric) can also
take
an integer, and promote it to decimal, you may get yourself an ambiguous
situation
with extensions.

If I remember correctly - that was exactly the reason  - at some point we
have
proposed implicit promotion between numeric datatypes..

I think no much harm is done by having DataType embedded.  
Simplifies some things..  May be more useful in the future..

Daniel.




-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu]
Sent: Thursday, August 29, 2002 11:42 AM
To: Michiharu Kudoh
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] [CR] DataType attribute required?



Taking this approach to the extreme, means you really need a typechecking
compiler that not only "checks" the type correctness of the policy, but to
WILL HAVE TO "infer" the types of the elements, which is a little bit of a
harder problem. However, in this simple type system (i.e. no recursive,
abstract types), it's not much harder.

So, if you go that far, you might as well eliminate DataType attribute
altogether from the schema, as it doesn't buy you anything but possible
confusion.

As as Michiharu says "In most cases...". However, I would say "In all
cases...." since we can see every expression only appears in a Target or
Condition. The top level expressions in a Target or a Condition in XACML
must result in xs:boolean, and as Michiharu states, the types of all
elements in the expression can be "inferred" from the functions applied to
them.

I would propose to remove the DataType attribute, in this case.

Cheers,
-Polar

On Thu, 29 Aug 2002, Michiharu Kudoh wrote:

> DataType attribute in AttributeDesignatorType is 'required'. But in most
> cases, AttributeDesignator is used below the matching function (e.g.
> string-match) and that function is type-specific. So I think "DataType"
> attribute is not required. I propose to change it to "optional".
>
> <xs:complexType name="AttributeDesignatorType">
>   <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
>   <xs:attribute name="DataType" type="xs:anyURI" use="required"/>
>   <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
> </xs:complexType>
>
> [should be]
> <xs:complexType name="AttributeDesignatorType">
>   <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
>   <xs:attribute name="DataType" type="xs:anyURI" use="optional"/>
>   <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
> </xs:complexType>
>
> Michiharu
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>


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