Draft: draft-ietf-jsonpath-base

Commentary: ( Once completed ) 
 Thanks . is not yet closed ; completing this is meant to do that . The triple dot bug was already fixed here in . For me it does n't matter where additional comments are made . I wonder whether we should finish this round ( fixing bugs ) before doing a grand renaming . I also would like some feedback on the names proposed ... 
 well , finishing this round before going on is fine . 
 I think if we agree this we should merge it . Next step could be the great renaming , possibly with some further testing of the grammar . In particular , we should throw collections of JSONPath queries we can find at it . If you have pointers , I could prepare that . 
 Two sources of queries : 
 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 .
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 A):
Specifically, the "Semantics" subsections of Sections name-selector,
wildcard, filter-selector, and descendant-segment describe behavior
that becomes unpredictable when the JSON value for one of the objects
under consideration was constructed out of JSON text that exhibits
multiple members for a single object that share the same member name
("duplicate names", see RFC8259).  Also, selecting a child by name
(name-selector) and comparing strings (comparisons in filter-
selector) assume these strings are sequences of Unicode scalar
values, becoming unpredictable if they are not (RFC8259).
Paragraph (version B):
Specifically, the "Semantics" subsections of Sections name-selector,
wildcard-selector, filter-selector, and descendant-segment describe
behavior that becomes unpredictable when the JSON value for one of
the objects under consideration was constructed out of JSON text that
exhibits multiple members for a single object that share the same
member name ("duplicate names", see RFC8259).  Also, selecting a
child by name (name-selector) and comparing strings (comparisons in
filter-selector) assume these strings are sequences of Unicode scalar
values, becoming unpredictable if they are not (RFC8259).
Paragraph (version A):
A wildcard "*" (wildcard) in the expression "[*]" selects all
children of a node and in the expression "..[*]" selects all
descendants of a node.
Paragraph (version B):
A wildcard "*" (wildcard-selector) in the expression "[*]" selects
all children of a node and in the expression "..[*]" selects all
descendants of a node.