OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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.


----- 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"
> 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]