Re: [xacml] Concrete Proposal of ConditionReference (#7)

[Polar Humenn <polar@syr.edu>]

On Wed, 4 Feb 2004, seth proctor wrote:

> Polar Humenn wrote:
> > However, it is not clear that we should avoid recursive definitions. They
> > may be useful, although lead to non-terminating answers. :)
>
> Oh, well yes, there's that :)
>
> Seriously, this actually does worry me a little. Right now a Condition
> is strictly non-recursive (though, of course, a custom function can
> still cause problems). Recursive/cyclic Definitions change what a
> Condition can represent, so we're no longer just talking about
> "syntactic sugar." I agree there might be utility in using recursion,
> but it won't always be possible to tell if we'll bottom out.

Hmmm, I think there's a proof to that effect.  :)

> I dunno. Do you think the benifets outweigh the danger here?

I don't know what the "danger" is?

You mean some policy writer accidentially writing a non-terminating
program?

> > Well, you still have to typecheck everything, (or at least you should).
> > So, the time spent on it is whether you really want to or not. If you do
> > dynamic checking, you can also do dyanmic reference binding, and do what
> > ever you do dyanmically for a type mismatch as for an unreferenced
> > binding.
>
> I guess my point is that I'll do type-checking when I first process the
> definitions, but if I don't know about a reference yet, then I have to
> go back through a second time.

Well, I think it really deepends on how you do your implemenation. These
things may be typechecked in a single pass.

> This leads to cases where I can parse
> many definitions and only on the second pass discover something that was
> invalid (so I shouldn't have spent time processing the rest of it). Like
> I said, it's a small point, but it's still something to consider.

I'll agree, but the point is small.

>  >> [...]
> > I knew that decision to have a special <Condition> element would come back
> > to bite hard. :(
>
> Chomp.
>
> > I personally don't think there is anything special about it, and the fact
> > that it was made "special" seems to be causing needless problems.
>
> What I think is special about it is that when we talk about XACML, the
> term Condition has special meaning. If it was just another Apply tag or
> something, then it's less clear.

If that is the case the the <Condtion> element should have probably
*contained* a boolean typed expression instead of *being*a boolean typed
Apply element, such as:

 <Condition>
   <AttributeValue DataType="...boolean">True</AttributeValue>
 </Condition>

> Given that we're discussing allowing something other than a function at
> the root or a Rule's logic (per the above discussion of point #2),
> however, I can understand why we would get rid of this.

Good.

> By the way, this seems more reasonable to me now. I was concerned in
> part because I didn't see any real change motivating the removal of
> Condition. Allowing more than a function at the root is a real (in my
> opinion) reason to make this change. Thanks for the detail.

Cool.

> >>I don't know what happened to the idea of using Refs in Targets (it
> >>didn't show up in the new proposal, I don't think), but I _really_ don't
> >>like it. If it does show up again, I'll provide some specific comments.
> >
> > I think they are a bad idea, as I have stated in a previous email, I
> > think, if it got through my email hassle, I should check.
>
> Then we agree :)

Good.

> >>   2. It might be nice to group all the VariableDef elements under a
> >>      single VariableDefinitions element, just to make things a little
> >>      clearer.
> >
> >
> > I think "clearer" in this case, is simply a matter of opinion. The
> > approach you mention is in older languages like FORTRAN, C, PASCAL, PL/1,
> > and that was based more on the capabilities and limitations of the
> > compiler writers and compiler internal capabilities more than on the
> > language elements themselves. Now, the tendancy in newer languages is to
> > define things when and where you need them, all in the name of "clarity".
>
> Sure. I just thought I'd throw it out there since it seemed a little
> "clearer" to me.
>
> >>   2a. It might be nice to expand VariableDef to VariableDefinition and
> >>       VariableRef to VariableReference...Def and Ref are just too
> >>       similar looking :)
> >
> >
> > And just when I thought you were worried about verbosity. :^)
>
> No. Really. I am! I just started seeing Ref and Def blending together
> the more I stared at the examples...
>
> >
> >>   3. Can anyone think of a better word for "Variable"? Somehow it's
> >>      still just not sitting quite right with me.
> >
> >
> > Well, I tend to agree with you, because Variable with the word Reference,
> > does seem a bit redundant. However, I can see why we would want to keep
> > the Ref/Def pairing.
>
> Twice in one discussion? Strange...And yes, the Def/Ref pairing should
> be kept.
>
> > I would prefer <ValueDef> and <ValueRef> as you are defining a value and
> > referencing a value respecifively.
>
> I'm not sure I like this more.
>
> > In the way I explained before about having an <ExpressionType> Complex
> > type with which all expressions extend, the Def and Ref components could
> > also be called an <ExpressionDef>, <ExpressionRef>.
>
> This sounds pretty good to me.

There may be pedantic semantic ramifications.

If you call it an ExpressionRef this kind of means you substitute the
Expression and then evaluated when the expression containing the
reference gets evaluated. If you call it a ValueRef, this kind of
means that you evaluate it first and then substitute the value where the
reference appears.

In any case, we must say that Expressions represent Values, and that no
matter when they are evaluated the must represent the same value.

Cheers,
-Polar

>
>
> seth
>