whensonZWS
commented
3 years ago This issue is resolved in commit 9ab2256. Upon further reading, multiple different tags pointing to the same group of triggers are supposed to have the same [repeat] value. If such conflicts arises, the group of triggers take the [repeat] value of whichever tags that come first.
The mapping between tags and triggers is not simple one tags correspond to one trigge) as I initially thought. First I discovered in some map, many tags can reference one trigger Then when it comes to attached trigger, turns out that one tags can point to a group of trigger via the attached trigger logic.
Mathematically speaking, Let the set of Tags be T, the set of triggers be Tr. The mapping T->Tr is f. Then I initially think f is an injective function. And then I discovered f is just a general function. Attached trigger means the model f is invalid. In fact, it's more correctly represented by a g: T->2^Tr mapping.
Deal to the initial injective assumption, the [repeat] property of triggers is assumed to be the [repeat] property of tags , but this is no longer the case. We conclude that [repeat] is not an innate trigger property, but rather a tag property. Then this creates a serious problem in terms in terms of usability of the tool: user usually associated [repeat] with triggers, not tags. If 2 or more tags with different [repeat] value pointing to the same group of triggers, then how should I display the [repeat] value of a trigger?
Side note: the range of function g should exclude empty set. that is, every tag should point to a trigger. Empty reference will create a warning. On another note, empty trigger reference to event and actions should create warning as well.