[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Function Document Issues
On Mon, 26 Aug 2002, Daniel Engovatov wrote: > > >that said, my 'proposal' is to ask that you post to the list the > >specifics of what you think we should limit the discussion to. that > >would help clarify the situation (to me anyway :o) > > >thanks > > >b > > I believe we ended up the call agreeing on the document, as it is, minus > the *-on-error functions, that Polar added a bit later. We should certainly > discuss those. My personal opinion - is that having some additional > error-hiding functions is not necessery, and it never came up previously, > though I do not object that it may be useful for some use cses that I am > unaware at the moment. If we use the definitons of AND, OR, and N-OF that we have now, we have Error Hiding functions, which came after the call. > Attached is the specification document, as we finished the discussion today. > We resolved several open issues. I would propose that we review it and vote > on accepting. > If I understand correctly there are two change requests open for discussion. > 1) Add Error catching functions as proposed by Polar > 2) Rewrite "or" and "and" specifications to allow accepting invalid(error) > arguments for the cases, when them having an explicit boolen value would not > change the result. I don't agree with forcing anything opportunisticly to a vote without some level of agreement from all of us. I don't want to "freeze" anything that is still in gel form, just to railroad it into a brick. Let's keep discussing the issues and productively come to a conclusion on the matters before we vote on anything. Cheers, -Polar > Please correct me if I missed anything. > > Thanks. > > Daniel. > > > On a side note: > Also I do not think that, given that we do have arithmetic operations and > missing external data occurring as a normal operational procedure, declaring > of a simple, definitive and deterministic way of computing INDETERMINATE > result of a rule evaluation is in any way an "abhorent" practice - so far I > have not seen any clear use cases or concrete examples demonstrating > otherwise. > > If I remeber correctly - addition of INDETERMINATE, as a separate evaluation > result from NONAPPLICABLE is something we all agreed on for quite some time > - thus we do need explicit rules of computing such result. > > It would not quite work if encountering an overflow, when adding two numbers > received from PEP, one PDP will subsitute resulting value with some default, > other make rule NONAPPLICABLE, other produce INDETERMINATE for one rule and > yet another one halt evaluation. > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC