Indeterminate arguments for logical functions.

[steven-legg]

The descriptions for the and, or and n-of (and not) functions don't have any guidance on what happens with arguments that evaluate to Indeterminate. One approach, which would be consistent with other functions, is to return Indeterminate if any argument is Indeterminate, but these functions could do better.

The or function could return true if any argument is true; otherwise, return Indeterminate if any argument is Indeterminate; otherwise, return false.

The and function could return false if any argument is false; otherwise, return Indeterminate if any argument is Indeterminate; otherwise, return true.

The n-of function could return true if at least n of its m Boolean arguments are true; otherwise, return false if at least (m - n + 1) of its arguments are false; otherwise, return Indeterminate.

[humantypo]

That makes sense for or if one or more elements evaluate to True given that the purpose of Indeterminate is to provide information on the decision, not the process.

However for and, not being able to complete the evaluation because an element cannot be evaluated seems consistent with the intent of the Indeterminate result type; as would the case of or not being unable to evaluate any True element, since it indicates that it was not possible to determine the result to completeness (the unintelligible element[s] could influence décrions either way depending upon it’s value).

[cdanger]

The or function could return true if any argument is true; otherwise, return Indeterminate if any argument is Indeterminate; otherwise, return false.

The and function could return false if any argument is false; otherwise, return Indeterminate if any argument is Indeterminate; otherwise, return true.

The n-of function could return true if at least n of its m Boolean arguments are true; otherwise, return false if at least (m - n + 1) of its arguments are false; otherwise, return Indeterminate.

Pretty sure that's already what we do in our implementation, so I'm good with that 👍 . If we can make it more explicit in the spec, the better.

[steven-legg]

The or, and and n-of functions also require the arguments to be evaluated in order and for processing to stop as soon as a result can be determined. This is perhaps too restrictive in that it precludes an implementation from evaluating the arguments in parallel or optimizing the order.

These functions are not like the combining algorithms where the order and stopping conditions determine the resulting obligations and advice.

[humantypo]

Agreed.

To be honest I don’t recall what the perceived benefit of order was for evaluating this with that limitation. Perhaps some sort of implied “importance value” of arguments that a Policy writer could imply…

I suppose immediately stopping upon fulfilling the threshold value could potentially forestall something going amiss after it was met, but Cyril’s previous suggestion re: the role of Indeterminate with these types of functions should address this as well I think.

[steven-legg]

I suppose immediately stopping upon fulfilling the threshold value could potentially forestall something going amiss after it was met, but Cyril’s previous suggestion re: the role of Indeterminate with these types of functions should address this as well I think.

As formulated at the top, continuing to evaluate arguments after a definitive true or false has been determined won't change the result, so anything that goes amiss (Indeterminate) will have no effect (assuming that the implementation traps all errors and doesn't just crash out).

We need to pay attention to side effects in unnecessarily evaluated arguments. The only thing that comes to mind is that evaluating an argument could bring an attribute into the request context (by an attribute designator) or produce a missing attribute error. The way and and or are formulated, if the final result is Indeterminate then all of the arguments must have been evaluated and all the missing attribute errors will have been collected. Those functions can only stop early on a false or true, respectively, in which case any Indeterminate arguments are ignored. If they don't stop then they reach the end and will have collected all the Indeterminate errors. Order will be irrelevant.

The n-of function is a bit different in that it can stop on an Indeterminate error if there aren't enough remaining, unevaluated arguments to satisfy a true or false result, so some error messages might be missed.

Bringing an attribute into the request context early isn't an issue. Bringing it in unnecessarily is an efficiency issue. A well-informed policy writer might order the arguments so that "expensive" attributes are fetched later and possibly avoided.

[humantypo]

The way ‘and’ and ‘or’ are formulated, if the final result is Indeterminate then all of the arguments must have been evaluated and all the missing attribute errors will have been collected. Those functions can only stop early on a false or true, respectively,

Why can’t and return Indeterminate if any element can’t be evaluated? That makes sense with or but and is effectivelyn-of-n…?

[steven-legg]

Why can’t and return Indeterminate if any element can’t be evaluated?

Because one of the yet-to-be evaluated arguments might return false and false trumps Indeterminate.

[steven-legg]

I have updated the logical functions in the core spec to account for Indeterminate as proposed above, but haven't yet made any changes to the order of processing or the mandatory stopping conditions.

I wrote up ternary-if (Issue #13) without a mandatory stopping condition (evaluating both the second and third arguments is allowed though only one of them will actually be used). If we decide to keep mandatory stopping conditions for the logical functions we might want to enforce it on ternary-if as well.

[steven-legg]

We decided to not impose an order of processing on the arguments and to not mandate early stopping conditions. These will be left to the implementation to optimize as it chooses. I will update the core spec accordingly.