[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