Draft: draft-ietf-jsonpath-base

Commentary: I noticed some ABNF lines were too long , so I a second commit to this PR to shrink the lines . It 's not pretty , so please see what you think . 
 E.g. , 
 I propose a slightly more compact naming of ABNF of - and -segment , which should be more consistent between them two . is well known from LaTeX and means or there . 
 above is wrong ( and so it is in the current spec ) . It needs to read ... to not allow triple dot ( :-) 
 Would n't dotdot - wildcard etc . be less cryptic ? 
 Here are some quibbles with the current ABNF ( prior to PR being merged ) which we can sort out after The Great Renaming : 
 Yes , yes . See . Fixed in I like the way this looks like now . Maybe I do n't understand ; can you elaborate ? Fixed this ( and following ) in Removed in To be fixed in overall overhaul , next Yes ! To be fixed in overall overhaul , next To be fixed in overall overhaul , next Fixed in Discuss this in its own issue , I 'd say . Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths . To stay normalized , we do n't allow random other ones . 
 Of course ... I 'm quite dispassionate here . 
 Please see my proposal in 
 With merged , we still have the expression cleanup the separate issue ( enhancement ) whether should be allowed , to mean 
 My remaining points are covered by PRs , , and . 
 Should n't be named according to all other above ? 
 Yes , I agree . See 
 Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind ? 
 The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic . But that can be a new issue . 
 Indentation of : number of lines such indented 
 ( And it does n't need to be consistent , just a bit less chaotic . ) 
 Let 's make the a new issue . ( I have n't got a good feel for the optimal solution . ) 
 Before we close this issue , slipped through the net in my earlier PRs . 
 Then could resolve to either or . We would introduce an ambiguity , we already found with   ( ) ... 
 OK , with the latest blank space realignments that are part of ( ) , I think we are done with this . 
 I submitted my own commit , so I like this much more now :-) ( But these were minor editorial anyway . )
Mailing list commentary: ... or do we need two selectors here ( Ch.2.61 ) child - longhand = " [ " S selector 1(S " , " S selector ) S " ] " given that ' 1 ' means ' at least one ' .
Paragraph (version B):
A name selector, e.g. "'name'", selects a named child of an object.
Paragraph (version B):
An index selector, e.g. "3", selects an indexed child of an array.
Paragraph (version A):
In what follows, the semantics of each segment are defined for each
kind of input node.
Paragraph (version B):
The following examples show the name selector in use by child
segments.
Paragraph (version A):
The example above with the query "$.o[*, *]" shows that the wildcard
selector may produce nodelists in distinct orders each time it
appears in the child segment, when it is applied to an object node
with two or more members (but not when it is applied to object nodes
with less than two members or to array nodes).
Paragraph (version B):
The example above with the query "$.o[*, *]" shows that the wildcard
selector may produce nodelists in distinct orders each time it
appears in the child segment, when it is applied to an object node
with two or more members (but not when it is applied to object nodes
with fewer than two members or to array nodes).
Paragraph (version B):
To be valid, the index selector value MUST be in the I-JSON range of
exact values, see synsem-overview.
Paragraph (version B):
To be valid, the integers provided MUST be in the I-JSON range of
exact values, see synsem-overview.
Paragraph (version A):
A slice is defined by the two slice parameters, "start" and "end",
and an iteration delta, "step".  Each of these parameters is
optional. "len" is the length of the input array.
Paragraph (version B):
A slice is defined by the two slice parameters, "start" and "end",
and an iteration delta, "step".  Each of these parameters is
optional.  In the rest of this section, "len" denotes the length of
the input array.
Paragraph (version A):
The result of the array index expression "i" applied to an array of
length "len" is defined to be the result of the array slicing
expression "Normalize(i, len):Normalize(i, len)+1:1".
Paragraph (version B):
The result of the array index expression "i" applied to an array of
length "len" is the result of the array slicing expression
"Normalize(i, len):Normalize(i, len)+1:1".
Paragraph (version A):
To be valid, the slice expression parameters MUST be in the I-JSON
range of exact values, see synsem-overview.
Paragraph (version B):
The following examples show the array slice selector in use by a
child segment.
Paragraph (version A):
As the expression is composed of side-effect free components, the
order of evaluation does not need to be (and is not) defined.
Similarly, for "&&"/"||", both a short-circuiting and a fully
evaluating implementation will lead to the same result; both
implementation strategies are therefore valid.
Paragraph (version B):
As the expression is composed of side-effect free components, the
order of evaluation does not need to be (and is not) defined.
Similarly, for conjunction ("&&") and disjunction ("||") (defined
later), both a short-circuiting and a fully evaluating implementation
will lead to the same result; both implementation strategies are
therefore valid.
Paragraph (version A):
Comparisons are restricted to primitive values (that is, numbers,
strings, "true", "false", and "null").  These can be notated as
literal values, or they can be derived from Singular Paths, each of
which selects at most one node.  Function expressions (see fnex) used
in comparison expressions return a primitive value or at most one
node.
Paragraph (version B):
Comparisons are between primitive values (that is, numbers, strings,
"true", "false", and "null"), Singular Paths, each of which selects
at most one node, and function expressions (see fnex) that return a
primitive value or at most one node.
Paragraph (version A):
of their array elements or member values, respectively.  Applied to
primitive values, it will select nothing.
Paragraph (version B):
of their array elements or member values, respectively.  Applied to
primitive values, it selects nothing.
Paragraph (version A):
The example above with the query "$.o[?@<3, ?@<3]" shows that the
filter selector may produce nodelists in distinct orders each time it
appears in the child segment.
Paragraph (version B):
The following examples show the filter selector in use by a child
segment.
Paragraph (version B):
The example above with the query "$.o[?@<3, ?@<3]" shows that a
filter selector may produce nodelists in distinct orders each time it
appears in the child segment.
Paragraph (version A):
The descendant segment consists of a double dot ".." followed by a
child segment ("descendant-segment").
Paragraph (version B):
The descendant segment consists of a double dot ".." followed by a
child segment (using bracket notation).
Paragraph (version A):
Suppose the nodes, in the order visited, are "D1", ..., "Dn" (where
"n >= 1").  Note that "D1" is the input value.
Paragraph (version B):
Suppose the descendant segment is of the form "..[<selectors>]"
(after converting any shorthand form to bracket notation) and the
nodes, in the order visited, are "D1", ..., "Dn" (where "n >= 1").
Note that "D1" is the input value.