MHonArc v2.5.0b2 -->
xacml message
[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]