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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml-comment] Public Comment


Ok, I see what you say... A function without parameters can be treated
as a constant. But anyway the meaning of the Fuction element depends on
the context. That was why I was not able to understand the difference,
because is the only element that is context dependent.

It's strange, but it's clear now.

Thanks,
DiegoG

-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu] 
Sent: Thursday, October 21, 2004 1:41 PM
To: diego gonzalez
Cc: xacml-comment@lists.oasis-open.org
Subject: RE: [xacml-comment] Public Comment

On Thu, 21 Oct 2004, diego gonzalez wrote:

> Thank you very much for your aswer,
>
> So you say the VariableDefinition that contains a Function is 
> considered as a function reference that can only be used as a 
> parameter for an Apply. It means the Function element acts like a
function reference.
>
> In the case of a Condition, placing a Function element as the single 
> child for a Condition, means evaluating the function (which is not the

> same usage for the other Function element usage) only if the function 
> does not have any parameter and its return value is bool, otherwise an

> error is returned.

Well, I would prefer to think of the error comming from the compiler as
not passing the type checking phase.

> I'm correct?

Yes.

> Now what happes in this case:
>
> <VariableDefinition VariableId="SomeVariable">
>   <Function FunctionId="someFunction"
> </VariableDefinition>
>
> <Rule>
>   <Condition>
>     <VariableReference VariableId="SomeVariable"/>
>   </Condition>
> <Rule>


For this rule, if the type of someFunction is not a constant of boolean
type, your interpreter or compiler would raise an exception that it is
invalid XACML.

> <Rule>
>   <Condition>
>     <Apply FunctionId="function-receiving-a-function">
>       <VariableReference VariableId="SomeVariable"/>
>     <Apply>
>   </Condition>
> <Rule>

This is allowed provided your "function-receiving-a-function" is typed
correctly.

> If this is supported (I mean if this is a valid policy), it means the 
> evaluation of a variable must change its behavior depending on the 
> execution context: if the variable is evaluated as the single entry of

> a condition it must evaluate the Function element, but if the 
> VariableReference appears as an Apply parameter it must not evaluate 
> the function but using it as a function reference.

Well, that may depend on your evaluation strategy. But still, if you use
the pass-by-value technique you "evaluate" the arguments before you pass
them.  Still, if the argument is a Function, and it requires arguments
then it evaluates to a Function that requires arguments. If it is a
constant, it has no arguments, and therefore is evaluated, just as you
would "evaluate" a constant representation or a "constant expression"
such as (2+3).

Cheers,
-Polar

> What do you think about this?
>
> Best regards,
> Diego Gonzalez
> Lagash Systems SA
>
> -----Original Message-----
> From: Polar Humenn [mailto:polar@syr.edu]
> Sent: Thursday, October 21, 2004 11:13 AM
> To: diego gonzalez
> Cc: xacml-comment@lists.oasis-open.org
> Subject: Re: [xacml-comment] Public Comment
>
> On Wed, 21 Oct 2004 comment-form@oasis-open.org wrote:
>
> > Comment from: diegog@lagash.com
> >
> > Hi,
> >
> > I found something strange during the implementation of the
Variables.
> I've found there is a new element in the schema called Expression 
> which is a common element for every "parameter" of the Apply. The idea

> is great because it makes the schema very simple.
> > It means the Apply's inner elements can be any of the elements that
> can be treated as Expresions, where the Function elemet is also 
> included.
> >
> > On other hand, the VariableDefinition also define it's value as an
> Expression which also includes the Function element. So the following 
> Xml is validated by the schema:
> >
> > <VariableDefinition VariableId="variable">
> > 	<Function
> > FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" /> 
> > </VariableDefinition>
> >
> > The same happens with the Condition element, the following xml is 
> > also
> validated by the schema:
> >
> > <Condition>
> > 	<Function
> > FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" /> 
> > </Condition>
> >
> > The questions are:
> >  - This is valid?
> >  I've not found the explanation in the document if there is a 
> > variable
>
> > that can contain a function.
>
> The schema validity is only a syntax check. It doesn't say anything 
> about the more stringent semantic restrictions placed on the content 
> of the language, such as type checking. Obviously, you can write a 
> schema valid expression that isn't type correct, and therefore would 
> not be valid XACML. Such as applying "string-equal" to two integers.
>
> It is true that any Expression may be a Function, which is in turn 
> passed to the application (Apply) of another function as an argument, 
> such as with the higher-order functions.
>
> So, there should be no problem with a VariableDefinition being a 
> Function.
>
> The Condition, however, forces its contained expression to reduce to a

> boolean value. A Function placed in a Condition as you have it, can 
> only be this, if it is a zero-ary function (i.e.  takes no arguments).

> A zero-ary function is otherwise known as a constant, and is better 
> off being represented as a simple value, Nothing precludes that 
> restriction however. We do not define any zero-ary Functions, but that

> doesn't have to stop your implemenation from doing so. :^) We just 
> require that it not return different values for different evaluations.

> That is to say that a zero-ary function MAY NOT base it value on 
> anything "outside" of the XACML request, like weather, a zenner-diode,
random-number, etc.
>
> >  - In the case of the Condition I think this is not valid, but I'll 
> > like to hear your thoughts on this.
>
> Hope that helps.
>
> Cheers,
> -Polar
>
>
> >
> > Hope you have time to answer the questions,
> >
> > Thanks in advance,
> > Diego Gonzalez
> > Lagash Systems SA
> >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]