yes, i can see both sides. i think the implementation tried to simplify the required UI layout and filter parameters, but that design leads to the quirks/limitations we’re discussing here.
i think a more robust implementation would represent this functionality using 3 main UI input options, with the first option having a couple of optional choices associated with it:
- with annotation type (can function on its own or with one of the options below):
a. annotation value
b. not annotation value - without annotation type
- without annotation value
… and this is how they would map to parameters:
| case | API parameters | SQL parameters |
|---|---|---|
| 1 | &term_id=[type] | term_id=[type] |
| 1+a | &term_id=[type]&term_value_id=[value] | term_id=[type] and term_value_id=[value] |
| 1+b | &term_id=[type]¬_term_value_id*=[value] | term_id=[type] and term_value_id<>[value] |
| 2 | &without_term_id=[type] | (term_id<>[type] or term_id is null) |
| 3 | &without_term_value_id=[value] | (term_value_id<>[value] or term_value_id is null) |
* note: not_term_value_id would be a new parameter
1, 1+a, and 1+b would be mutually exclusive, but 1 [+a/b], 2, and 3 would be allowed to be used in conjunction with each other.
for an even more robust implementation, you could add special handling for 2 to find only nulls/unspecified… and for an even more robust implementation, you could add handling for mulitple type/value inputs… (slippery slopes!)