[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] concrete proposal of condition reference (#7)
Simon, I don't understand something, but that's my naivity of XML Schemas. For instance, in <xs:element name="Expression" type="xacml:ExpressionType" abstract="true"/> Does the abstract="true" element mean that in every occurance of <xs:element name="Expression" > means that only an element that extends "ExpressionType" and does not have abstract="true" can appear? (That is to say, you cannot have an <Expression> element appear explicitly in a policy, but anything else of a type that extends "ExpressionType" can. Correct? Point #1. In the VariableDefinition you have: <xs:complexType name="VariableDefinitionType"> <xs:sequence> <xs:element ref="xacml:Expression" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="VariableId" type="xs:string" use="required"/> </xs:complexType> Should this really be an unbounded sequence? I think it should be just a single required occurance. (i.e. var = value ). Shouldn't it be: <xs:complexType name="VariableDefinitionType"> <xs:element ref="xacml:Expression"/> <xs:attribute name="VariableId" type="xs:string" use="required"/> </xs:complexType> Point #2. I really see no reason why "Function" cannot be defined as: <xs:element name="Function" type="xacml:FunctionType"/> <xs:complexType name="FunctionType"> <xs:complexContent> <xs:extension base="xacml:ExpressionType"> <xs:attribute name="FunctionId" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> and get rid of the HigherOrderApply structure you created. (This HigherOrderApply is much more restrictive than what we had). Why do you say it cannot be an <Expression> by itself? What's wrong with the above definition? Cheers, -Polar On Mon, 9 Feb 2004, Simon Godik wrote: > Hi Polar, > Here is schema based on Expression type and derived types. Choice group is also possible, I can put it together if there is > enough interest. > > I summarise my assumptions on the topics discussed in previous emails: > > 1. Redefined variable definition - policy is invalid > 2. Ok to have undefined variable reference in variable definition, but it must be defined later. > 3. More than one place for variable definitions, ie definition can be placed close to the rule. > 4. Expression evaluates to the value and this value remains the same for the entire evaluation. Value type is determined by the type of expression. > > I replaced <Function> element with the <HigherOrderApply> because > <Function> can not be made into expression by itself. I'm not > particularly attached either to it's name or definition, but I think it > makes sense to define higher order expression element. > > Simon >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]