Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 The notes need separating out into paragraphs . The semantics section needs to be expanded .
Paragraph (version A):
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.
Paragraph (version A):
Comparisons are restricted to primitive values (such as number,
string, "true", "false", "null").  Comparisons with complex values
will fail, i.e. no selection occurs.
Paragraph (version A):
Data types are not implicitly converted in comparisons.  So ""13
== '13'"" selects no node.
Paragraph (version A):
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.
Paragraph (version A):
Paths in filter expressions are Singular Paths, each of which
selects at most one node.
Paragraph (version A):
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.
Paragraph (version A):
false, null, true are lower-case only (case-sensitive).
Paragraph (version B):
Paths in filter expressions are Singular Paths, each of which selects
at most one node.
Paragraph (version B):
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.
Paragraph (version B):
Comparisons are restricted to Singular Path values and primitive
values (such as number, string, "true", "false", "null").
Paragraph (version B):
Comparisons with complex values will fail, i.e. no selection occurs.
Paragraph (version B):
Data types are not implicitly converted in comparisons.  So ""13 ==
'13'"" selects no node.
Paragraph (version B):
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.
Paragraph (version B):
"true", "false", and "null" are lower-case only (case-sensitive).
Paragraph (version B):
Regular expression tests can be applied to JSON string values
(RFC8259) only (on the left-hand side of "=~"); they yield false
otherwise.
Paragraph (version B):
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.
Paragraph (version A):
of their element or member values then.  Applied to other value
types, it will select nothing.
Paragraph (version B):
of their array elements or member values, respectively.  Applied to
other value types, it will select nothing.
Paragraph (version B):
A relative path, beginning with "@", refers to the current array
element or member value as the filter selector iterates over the
array or object.
Paragraph (version B):
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.
Paragraph (version B):
The semantics of regular expressions are as defined in I-D.draft-
bormann-jsonpath-iregexp.