- From: benedictws via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Sep 2017 11:52:40 +0000
- To: public-poe-archives@w3.org
Hi Michael. Thanks for the feedback. Some of your concerns can, I think, be assuaged by being clearer about the scope of the evaluator. The evaluator ensures that the flow of logic encapsulated in the IM has been correctly followed. It does no more than that. It cannot decide whether a constraint has been satisfied or a duty fulfilled. The world is simply a black box to the evaluator. What it can do though is decide whether a rule is active or not-active depending on the states reported to it: satisfied/not satisfied; fulfilled/not fulfilled. This provides a level of interoperability between implementations beyond simply validity. But it does not insist that two implementations share the same view of the world. It has no view of the world! What we're providing here are a set of expected results to which an evaluator should conform. If it does so, then we know it's logical flow is consistent with the standard. We then know that two different implementations that happen to agree on the state of the world will also agree which rules are active when interpreting the same policy. That's the best we can do. And that's why the evaluator does not check against real entities. It's only told the states of rules and constraints. In Example 21 I wish I didn't have a blank header - the obligation and the consequence both have two states, so require two columns to describe them fully. Are they active or not-active, and, if they are active, are they fulfilled or not. In row one the consequence is not active because the obligation has been fulfilled. In row three the obligation has not been fulfilled, triggering the consequence. It's constraint has not been satisfied, so the consequence has not been fulfilled either. The fourth and fifth rows differ from row one because the consequence has been triggered. Maybe the tables need more commentary? In Example 22, row 3, only C1 can determine whether the duty is active or not. R1 simply has to be satisfied before D1 can be fulfilled. It has no influence on the active status of D1. In row 4, if C1 is not satisfied then D1 is not active, and we don't care about the status of R1. It has no effect. In Example 23, row 2, P1 is not active because its duty D1 has not yet been fulfilled, even though its consequence has been. Inherent in the logic of consequence is the idea that its original duty must be fulfilled too. That also explains rows 4 and 5: once the consequence has been trigged both it, and the original duty, must be fulfilled. Again, more commentary needed? Example 24 - ha! This is where these status tables really uncover the true semantics of the model. I'd say this was up for debate! Example 25 - suggestion gladly taken. Hope the tables are a little clearer now. Rows 3 and 7: refinements do not effect the active status of a rule. They speak only to fulfilment. Phew! I think this shows we have a consistent semantics that implementors can test against ... except possibly for the issue raised in Example 24. -- GitHub Notification of comment by benedictws Please view or discuss this issue at https://github.com/w3c/poe/issues/254#issuecomment-328506112 using your GitHub account
Received on Monday, 11 September 2017 11:52:34 UTC