Hi Jan,
One more thing. By not allowing variable definitions in a policy
set, we avoid the issue of visible duplicate definitions. I would
guess that was the main reason. But I was not involved back then, so
I don't know for sure.
Best regards,
Erik
On 2011-05-30 17:14, Erik Rissanen wrote:
Hi Jan,
See inline.
On 2011-05-30 16:38, Jan Herrmann wrote:
Hi all,
three little questions:
1. Would it not be useful to allow a
sting-not-equal Match-function?
Yes, it would since it's not possible to use a "not" function in a
target. However, my opinion is that the fault is not that there is
no string-not-equal function, but the problem is that one cannot
use a condition in a policy or policy set. There are lots of cases
where one has to use weird constructs to work around that, and
your case is just one such example.
2. Is there a reason why one can not define
an ObligationExpression with a FulfillOn=”Indeterminate”
value?
Maybe someone from the XACML 1.0 era here could respond better,
but it seems a bit weird to put enforcement actions in an error,
meaning that we don't even know whether a policy applied or not. I
don't have done a formal analysis of a the matter though.
3. Why do VariableDefinitions have to be
bound to a <Policy> element and not to e.g. the
root <PolicySet> element?
Again, others would know better, but I guess this was simply a
design choice. I guess since conditions can appear only in rules,
the need for variable definitions was most urgent in a Policy. Of
course, now AttributeAssignmentExpression changes that.
Best regards,
Erik
Best Regards
Jan
--
Jan Herrmann
Dipl.-Inform., Dipl.-Geogr.
Scientific
Assistant
Chair for Applied
Informatics / Cooperative Systems
Technische Universität München
Boltzmannstr. 3
85748 Garching
Germany
T: +49 89 289 18692
F: +49 89 289 18657
W: www11.in.tum.de
