Allowing to change rules and facts seems to be in direct contradiction to using an Event-Log for deterministic and reproducible behaviour. Notably, the facts can be a representation of the environment, like e.g. the sound setup in a Studio vs. working on a Laptop. Since a long time, I used the formula to separate decisions from the processing logic in the code. An analysis of the kinds of decisions relevant for the situation with editing a media arrangement reveals that a dangerous conflict might ensue when the foundation of a past rule application changes, possibly by undo or replay of the Event-Log. A solution could be not only to apply rules, but also capture and materialise the fact that a rule has been applied and especially to record a connection between the setting and the rule it was based on. This amounts to documenting the reasoning why some decision came about. If done correct, such a data model would allow to re-evaluate past decisions quickly in case the facts or the rules are changed. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||