MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] [CR] DataType attribute required?
On Thu, 29 Aug 2002, Daniel Engovatov wrote:
>
> ..which raises another issue.
>
> Do we want to allow the same named attribute to be declared of
> different types in different rules.
>
> So that "AccountNumber" is used as integer in one rule, and as <date> in
> another..
>
> Having "DataType" specified, we may specify that within one PolicySet,
> same AttributeId should be associated with one and only one data
> type..
Still, you can infer the type information from the functions applied in
the expression it appears in.
-Polar
>
> Daniel.
>
>
> -----Original Message-----
> From: Polar Humenn [mailto:polar@syr.edu]
> Sent: Thursday, August 29, 2002 12:29 PM
> To: XACML
> Subject: RE: [xacml] [CR] DataType attribute required?
>
>
>
> Such is the thingy with "optional" attributes. If we don't need them now,
> why have them. You can always "add" an optional attribute to the schema
> later, unless there is some non-standard use for it. Otherwise if it
> exists, it just holds redundant information.
>
> -Polar
>
> On Thu, 29 Aug 2002, Daniel Engovatov wrote:
>
> >
> > 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>
> >
> > ----------------------------------------------------------------
> > 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