[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [xacml] syntax for variables and variable references
Forwarded message from Polar. ----- Original Message ----- From: "Polar Humenn" <polar@syr.edu> To: "Simon Godik" <simon.godik@overxeer.com> Cc: "Tim Moses" <tim.moses@entrust.com>; <xacml@lists.oasis-open.org> Sent: Monday, February 02, 2004 7:05 AM Subject: Re: [xacml] syntax for variables and variable references > > Simon, (My mail is getting bounced by the list, so please forward. > Thanks) > > I'm not sure about the variable in targets approach. Targets have simple > matches to bring about indexing. Variables represent general expressions. > Putting general expressions into Targets will force the targets to be > evaluated like the condition, and hence there will be no difference. > > On the rackling around of the types. I don't mind getting rid of the > Condition element. > > Simon, is there xomething in XML that prevents us from arranging the type > structure in a more convential way that usually represents most languages > have their abstract syntax? > > Something like: > > Expression ::= AttributeValue > | AttributeDesignator > | Function > | Apply > | VariableRef > > That would mean that we create a base complex type of <ExpressionType> > which is simply extended by <AttributeValueType>, > <AttributeDesignatorType>, <FunctionType>, <ApplyType>, <VariableRefType>. > Then the <ApplyType> simply contains a sequence of elements of > <ExpressionType>. And therefore a VariableDef just associates a VariableId > with something of <ExpressionType>. > > A Condition is then merely just something of an ExpressionType (which has > to type check to a singleton boolean value). > > Just wondering. > > Cheers, > -Polar > > On Mon, 2 Feb 2004, Simon Godik wrote: > > > Hi Tim, > > > > Schemas are mods of v2-1 schema from the proposal > > http://lists.oasis-open.org/archives/xacml/200401/msg00035.html by > > Michiharu (work iterm 7) > > > > Syntax for variables and variable references. > > > > Current variable syntax definition needs adjustment to account for the > > <condition> element. > > > > I think we should allow variables in target matches as well. > > (not yet included). > > Two possible alternatives for variable syntax. > > > > Alt a: <-- my preference > > ------ > > Drop <condition> element and replace it with the <apply> element. > > This makes it easy to create variable def and ref. Note that <condition> > > and <apply> are of the same type, so change is 'harmless'. > > > > The advantage of this approach is simplicity. There is one element for > > variable definition and one element for variable reference. > > > > ex 1a: rule with top-level <apply>: > > <rule> > > <target>...</target> > > <apply funcid="string-equal">...</apply> > > </rule> > > > > ex 2a: variable def is used in top-level apply: > > <var-def varid="cond1"> > > <apply funcid="string-equal">...</apply> > > </var-def> > > > > <rule> > > <target>...</target> > > <var-ref varid="cond1"/> > > </rule> > > > > For the rule to be valid, <var-ref> must resolve into <apply> element. > > (which it does). Note that the same variable definition can be reused in > > top level <apply> and enclosed <apply> elements. > > > > Alt b: > > ------- > > Keep <condition> element. In addition to existing <variable-def> and > > <variable-ref> elements create <cond-var-def> and <cond-var-ref> elements. > > Then <cond-var-ref> is allowed as an alternative to <condition> in a rule. > > > > In addition to having more syntactic elements, disadvantage of this approach > > is that <cond-var-def> can not be reused for <variable-def>. > > > > ex 1b: The same as 2a but variable is defined for condition: > > > > <cond-def varid="cond1"> > > <cond funcid="string-equal">...</cond> > > </var-def> > > > > <rule> > > <target>...</target> > > <cond-ref varid="cond1"/> > > </rule> > > > > Syntactic detail. > > ----------------- > > Variable is defined with the <VariableDef> element. Type of the variable > > defined by <VariableDef> is determined by the type of enclosed expression. > > Name of the variable defined by <VariableDef> is the value of VariableId > > attribute of type xs:string. > > > > (By derivation from the apply-core-type) Variable definition can be applied to > > any combination of <apply>, <function>, <attr-value>, <subj-attr-desig>, > > <res-attr-desig>, <act-attr-desig>, <env-attr-desig>, <attr-sel>, > > and <var-ref> elements. > > > > <xs:element name="VariableDef" type="xacml:VariableDefType"/> > > <xs:complexType name="VariableDefType"> > > <xs:complexContent> > > <xs:extension base="xacml:ApplyCoreType"> > > <xs:attribute name="VariableId" type="xs:string" use="required"/> > > </xs:extension> > > </xs:complexContent> > > </xs:complexType> > > > > VariableId - required. This is variable name. > > > > Variable is dereferenced with the <VariableRef> element. Variable name > > is defined by the value of VariableId attribute of type xs:string. > > > > <xs:element name="VariableRef" type="xacml:VariableRefType"/> > > <xs:complexType name="VariableRefType"> > > <xs:attribute name="VariableId" type="xs:string"/> > > </xs:complexType> > > > > VariableId - required. This is variable name. Must resolve to named variable > > definition. > > > > Alternative (a): > > ------------------------ > > Rule schema: > > <xs:complexType name="RuleType"> > > <xs:sequence> > > <xs:element ref="xacml:Description" minOccurs="0"/> > > <xs:element ref="xacml:Target" minOccurs="0"/> > > <xs:choice> > > <xs:element ref="xacml:Apply"/> <-- change: <cond> replaced with <apply> > > <xs:element ref="xacml:VariableRef"/> <-- new: variable ref > > </xs:choice> > > </xs:sequence> > > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/> > > <xs:attribute name="Effect" type="xacml:EffectType" use="required"/> > > </xs:complexType> > > > > For the rule to be valid, <VariableRef> must resolve into <apply> element. > > > > Sequence of <VariableDef> elements is included as a child of <Policy> > > element following <PolicyDefaults> element. > > > > Alternative (b). > > ------------------------------ > > Rule schema: > > <xs:complexType name="RuleType"> > > <xs:sequence> > > <xs:element ref="xacml:Description" minOccurs="0"/> > > <xs:element ref="xacml:Target" minOccurs="0"/> > > <xs:choice> > > <xs:element ref="xacml:Condition"/> > > <xs:element ref="xacml:CondVarRef"/> <-- new: condition var reference > > </xs:choice> > > </xs:sequence> > > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/> > > <xs:attribute name="Effect" type="xacml:EffectType" use="required"/> > > </xs:complexType> > > > > <CondVarDef> defines condition variable. Condition variable can be used > > only for conditions. > > > > <xs:element name="CondVarDef" type="xacml:CondVarDefType"/> > > <xs:complexType name="CondVarDefType"> > > <xs:sequence> > > <xs:element ref="xacml:Condition"/> > > </xs:sequence> > > <xs:attribute name="VariableId" type="xs:string" use="required"/> > > </xs:complexType> > > > > VariableId is a name of condition variable. > > > > Condition variable reference is of <VariableRefType>: > > <xs:element name="CondVarRef" type="xacml:VariableRefType"/> > > > > Condition variable reference must resolve to named condition variable. > > > > Sequence of choices between <VariableDef> and <CondVarDef> elements is > > included as a child of <Policy> element following <PolicyDefaults> element. > > > > Simon > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]