[poe] Not-/Active Rules, evaluation, Policy inheritance and conflicts

nitmws has just created a new issue for https://github.com/w3c/poe:

== Not-/Active Rules, evaluation, Policy inheritance and conflicts ==
In recent discussions about the Active state processing (see 2.6.8 in the IM) we agreed a Not-Active state means a Rule should not be exposed to further evaluations. (Expressed in this draft too: https://github.com/w3c/poe/issues/226#issuecomment-326317601)

This raises the question: does the Not-/Active state of a Rule has an impact on
* the Policy Inheritance (IM 2.9): does an ODRL processor has to first evaluate the Not-/Active state of Rules in the parenting Policy before they are inherited by the child Policy? (Aside: this states implicitly that the inheritance processing relies on states of constraints: a Permission in a parent Policy may be Active on 30 December 2017 but not on 1 January 2018.)
The tricky thing of inheritance is that it not only copies and pastes Rules from the parent to the child but also a semantic merge may be exercised - as shown in the Examples 34 - 36. For that reason I strongly support that only Active Rules should be inherited as else the merging would overly complex.
* the Conflict assessment (IM 2.10): the current section tells a Policy should be assessed for conflicting Rules but it does not mention if the Not-/Active state of a Rule must/should/may be included into this assessment. My feeling tells me that the Not-/Active state should be included (as any assessment would have to check the constraints) but it would be better to write this down in 2.10.

**Strict conclusion regarding 2.9 and 2.10:** explicitly including the Not-/Active state of Rules or not should not change the formal result in the very end of the processing because the processing of inheritance and conflicts MUST have an eye on the constraints. Including the Not-/Active state would make the processing workflow more transparent.

Footnote 1: setting the Not-/Active state of a Rule is nothing else than giving the processing of constraints and its result a name.
Footnote 2: re Conflicts are setting the "valid" state: see #237 


Please view or discuss this issue at https://github.com/w3c/poe/issues/240 using your GitHub account

Received on Saturday, 2 September 2017 05:54:40 UTC