[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] concrete proposal of condition reference (#7)
Hi Polar, You are correct. If element is declared abstract, it can not appear in the document by itself, but any element that is a member of the abstract element 'substitution-group' can. Also, there is a requirement that elements in the substitution group must be either of the same type as 'head element' or related by type derivation. To put it in less convoluted terms, <Expression> element is an abstract element of <ExpressionType> type and is a head of a substitution group. All other types are derived from <ExpressionType> and corresponding elements are members of <Expression> substitution group. Point #1: Should variable def be a sequence of expressions or just an expression? I agree, variable-def should be valid expression, so it's just one expression, not many. Point #2: Should <Function> be made into <Expression>?. The problem I see is that by itself <Function> does not have any meaning, it needs to be attached to <Apply>, so that's why I created <HigherOrderApply>. If you feel strongly that <Function> should be made into expression, I will not object to it. We can adopt schema that you propsed in your other message, with <Function> derived from <ExpressionType> with FunctionId attribute. Here is a schema with both changes applied. Simon ----- Original Message ----- From: "Polar Humenn" <polar@syr.edu> To: "Simon Godik" <simon.godik@overxeer.com> Cc: <xacml@lists.oasis-open.org> Sent: Tuesday, February 10, 2004 6:48 AM 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 > >
oasis-xacml-2_0-policy-schema-wd-042.zip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]