Custom token bound to value despite rule not matching

Assume you have a rule like this:

Code: Select all: If <All> If <Any> <Contents Contain Match><"A first pattern with 'Token'"> <Contents Contain Match><"A second pattern with 'Token'"> <Contents Contain Match><"A third pattern with 'Token'"> •Token <is not blank> <Contents Contain Match><"A fourth pattern with 'Token'">

Now also assume an input/preview that causes "Token" to be matched as an empty string (i.e. blank) in the second pattern. The desire of the rule, by checking for <is not blank>, is to make the first top level "if" fail and allow the final match (fourth pattern) to set the token.

However, if in the first part the Token is matched up with the empty string, it gets bound to it, despite the overall condition (if) failing. Consequently the match in the fourth pattern will not happen (even though matching text is available) because the Token is already bound to a value (although be it the empty value).

I would suggest that token bindings to values should only happen if the condition it is in is part of producing a passing/true value all the way up to passing the whole rule. For the purpose of "Preview" one could still display a green check and show a value for the individual condition, but

the actual binding in the next level up where that condition (typically an "If") has a red cross should not show there (and I believe currently clicking on such a red cross produces no view of bound tokens)
the actual binding in the next level up where that condition (typically an "If") has a green check should not show there if this rule (the one level up one) is not part of the overall rule being true

Now, I realize that perhaps a workaround is to replace the line with the fourth pattern with

Code: Select all: <If Any> <If All> • Token <is not blank> <Contents Contain Match><"A fourth pattern with 'New Token'"> <If All> • Token <is blank> • Token <matches> <"'New Token' as ...">

This, however, seems excessive as a long term solution. I cannot see how what I propose breaks existing things from a logic perspective, but do realize that there might be (unlikely) scenarios where somebody actually counted on the old behavior. Yet I feel fixing this is "more" important as it is how one would logically expect things to behave.

Related, but not the same problem: In the current implementation, for the example rule above, there is a second, but minor problem if the match with the third pattern would also produce a match. Note that if the value was bound to the token in the second pattern, the third one should not produce a binding (and it does not), but when clicking on the green check for the <if-any> in the "custom attributes" I see two entries for the Token, but displaying the empty value. I would argue that any rule should only ever show a single attribute once with its bound value.

I just realize the possible workaround will not work anyway due to the same problem. New Token will get bound at the first opportunity.

Well, there are two issues here. First one is whether "is blank" should match something that is set to match empty text. I think a case could be made the other way but the current behavior is to distinguish between something that was never assigned a value and something that was (even if it is empty).

As for the other issue, I've pondered this type of thing before. It's still unclear to me whether that behavior would be best for all cases. I started getting muddled in cases with double-negatives and such.

I think how it should work, taking your suggestion, is that the captured token value is valid starting within the same nested condition. You go up until the nested condition fails, in which case, the token value is reset and anything at that level will be able to capture a value again. I don't think the top level should necessarily be required in this case.

It's something I would consider. If you have additional cases demonstrating this type of behavior, I'd appreciate it as it would help.

Concerning the "is blank". I guess what that reveals is that the naming of the condition is open to misinterpretation. I certainly expected it to match. For what you described, perhaps a better text would be "is undefined", and "is not undefined".

Concerning the level at which the token should be reset: It would seem your suggestion is enough, but I don't think it is. The problem would arise if on a level up the whole nested condition succeeds but, in the level above that that level fails. Any conditions following the upper failed condition, but below it, and possibly even nested would not be allowed to bind again.

The way I think about it is that a token should be reset if the condition it was in is not a part of the overall rule leading to a match. I have not thought about this extensively, but I do not think that if this were to be changed, existing rules that would not attempt my scenario would suddenly behave differently in realistic cases. In other words, I think the change would, effectively, be backwards compatible. If you are not convinced, or worried about it, the behavior could be governed by a top-level checkbox for a whole rule. For older, existing rules, the box would default to off.

As far as additional cases, I am not sure what to say or offer. I described the problem in a somewhat abstract/generic way. I have tons of rules that I have attempted to create that have this issue and where I have had to come up with (complex) work arounds, or just give up. Consequently I do not have "copies" of these rules to give you.

I think the token has to always be bound for at least the scope it is in, otherwise you end up with a loop/oscillating result. Once it fails, then it will reset for everything onwards.

Nonetheless, this will take a lot more thought and investigation as it does effect how rules evaluate and I'm not convinced that there will be no side effects. I don't think a checkbox is appropriate here as the feature is esoteric and it's probably not worth the UI real estate.

As I said, it is under consideration but given the possible effects, it probably won't be even a candidate for implementation until a bigger release where there will be a significant beta cycle.

Oh, and on the "is blank" issue, checking the code, it should match an empty string. If you are seeing otherwise then maybe check for whitespace.