Original text:
The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp.  3.5.8.3. JSON document:

Reviewer comments:
See also . Ref: URL Fixes URL
To be honest I also considered a comment along the lines of "couldn't we just say 'standard Boolean math'?" But (another little -used math degree here) I found it pleasing and, on reflection, possibly beneficial for an implementor.
Among other things, it dawns on me that if I were implementing, I'd copy-paste all those lines into a unit test.
The proposed operator precedence in the draft is shown below. Precedence Syntax -- -- 5 (...) 4 ! 3 ==, !=,, >=,=~ 2 && 1 It is assumed that these precedences are motivated by existing languages, but it is also noted that operator precedence is different in different languages such as JavaScript and Python. For example, logical not has low precedence in Python but high precedence in JavaScript and C. The less than/greater than operators have higher precedence than the equality operators in JavaScript and C, but the same precedence in Python. Existing JSONPath implementations that follow these languages for evaluating filter expressions will also have these differences. This issue, created by request, collects the comparable operator precedences for Python, JavaScript, Perl, C And XPath 3.1, to illustrate where they're similar to the draft, and where they differ. Perl is included because of these languages, it is the only one that has a operator. Note that in Perl, the precedence of the operator is higher than the comparison operators. One comment: the draft operator precedence table should include an additional column for associativity, which is needed to fully describe the operator. The unary logical not operator should be shown as "right associative", and the binary operators should be shown as "left associative". Precedence Associativity -- -- 7n/a 6left to right 5right to left 4left to right 3left to right 2left to right 1left to right Source: Precedence Associativity -- -- 9left 8left 7chained 6chain na 5left 4left 3right 2left 1left Source: Remarks: Unary "not" is equivalent to "!" except for lower precedence. Binary "and" and "or" are equivalent to && and except lower precedence Precedence Associativity -- -- 6Left to right 5Right to left 4Left to right 3Left to right 2Left to right 1Left to right Source: Precedence Syntax -- -- 8() 7x[index:index] 6x[index] 5x.attribute 4in, not in, is, is not, , >=,<>, !=, == 3not x 2and 1or Source: Precedence Associativity -- -- 3NA 2Either 1Either Source: Remarks: XPath 3.1 and XQuery don't have a logical not operator, there's a operator, but it's a binary operator that means something different. Instead, XPath 3.1 and XQuery provide the function , whose precedence rules follow the rules for functions.
Since logical NOT binds more tightly than logical AND which binds more tightly than logical OR in all but one of the above tables and since we don't support comparison of predicates, I'm finding it hard to think of a case where the semantics differ between these tables. Can anyone provide such an example?
Which one? They're all the same.
One might ask the question, if one were interested in these things, why is the draft precedence ordering slightly different from all of Python, C, JavaScript and Perl? Why not make it the same as at least one of them? There is no difference in implementation effort.
I think we are still decoding this statement. Where is the difference?
The draft relational and equality/inequality operators are grouped together, like Python, but unlike C, JavaScript, and Perl. The draft logical not binds high, like C and JavaScript, but unlike Python. (Perl being Perl has two logical nots, one that binds high and one that binds low, but are otherwise equivalent.)
Logical NOT is missing from the XPath 3.1 table.
XPath 3.1 and XQuery don't have a logical not operator. Instead, they provide the function , whose precedence rules follow the rules for functions (not shown in my table.)
It may also be interesting to compare with the . In , like XPath 3.1, Boolean 'NOT' is a , not an operator.
We could at least document the associativity.
After discussion, is there anything that needs to be changed in the draft aside from adding associativity specification?
LGTM

Revised text:
The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. <ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any true expression, such as "1 == 1", and "F" is any false expression, such as "1 == 0"): </ins> 3.5.8.3. JSON document: