Change:
Fixes URL
The notes need separating out into paragraphs. The semantics section needs to be expanded.

Discussion:
The current item is selected if and only if the result is "true". <del> Notes: </del> <ins> Paths in filter expressions are Singular Paths, each of which selects at most one node. </ins> <del> Parentheses can be used with "boolean-expr" for grouping.  So filter selection syntax in the original proposal "[?(<expr>)]" is naturally contained in the current lean syntax "[?<expr>]" as a special case. </del> <ins> Parentheses can be used with "boolean-expr" for grouping.  So filter selection syntax in the original proposal "[?(<expr>)]" is naturally contained in the current lean syntax "[?<expr>]" as a special case. </ins> <del> Comparisons are restricted to primitive values (such as number, string, "true", "false", "null").  Comparisons with complex values will fail, i.e. no selection occurs. </del> <ins> Comparisons are restricted to Singular Path values and primitive values (such as number, string, "true", "false", "null"). </ins> <del> Data types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. </del> <ins> Comparisons with complex values will fail, i.e. no selection occurs. </ins> <del> A member or element value by itself in a Boolean context is interpreted as "false" only if it does not exist.  Otherwise it is interpreted as "true".  To be more specific about the actual value, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with structured values. </del> <ins> Data types are not implicitly converted in comparisons.  So ""13 == '13'"" selects no node. </ins> <del> Paths in filter expressions are Singular Paths, each of which selects at most one node. </del> <ins> A member or element value by itself in a Boolean context is interpreted as "false" only if it does not exist.  Otherwise it is interpreted as "true".  To be more specific about the actual value, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with structured values. </ins> <del> The regular expressions in the string-literals on the right-hand side of "=~" are as defined in I-D.draft-bormann-jsonpath-iregexp. Regular expression tests can be applied to JSON string values (RFC8259) only (on the left-hand side of "=~"); they yield false otherwise. </del> <ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". </ins> <del> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". </del> <ins> "true", "false", and "null" are lower-case only (case-sensitive). </ins> <del> false, null, true are lower-case only (case-sensitive). </del> <ins> Regular expression tests can be applied to JSON string values (RFC8259) only (on the left-hand side of "=~"); they yield false otherwise. The syntax of regular expressions in the string-literals on the right-hand side of "=~" is as defined in I-D.draft-bormann-jsonpath- iregexp. </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least

3.5.8.2. The "filter-selector" works with arrays and objects exclusively.  Its <del> result might be a list of </del> <ins> result is a list of </ins> ,

or <del> of their element or member values then.  Applied to other value types, it will select nothing. </del> <ins> of their array elements or member values, respectively.  Applied to other value types, it will select nothing. A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. Comparisons using one of the operators "<", "<=", ">", and ">=" are between numeric values only.  Using these operators to compare other types of values produces a "false" comparison result. The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. </ins> 3.5.8.3.