Re: [xacml] concrete proposal of condition reference (#7)

[Polar Humenn <polar@syr.edu>]

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
>