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?



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



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


Powered by eList eXpress LLC