[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