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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: RE: [xacml] Function Document Issues



>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.  

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.  

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.





Attachment: XACML_functions0.6a.DOC
Description: Binary data



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


Powered by eList eXpress LLC