Original text:
JSONPath queries in these situations. Specifically, the "Semantics" subsections of Sections name-selector, <del> 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 </del>  values, becoming unpredictable if they are not (RFC8259). 1.4. 1.4.3. <del> A wildcard "*" (wildcard) in the expression "[*]" selects all children of a node and in the expression "..[*]" selects all </del>  descendants of a node. An array slice "start:end:step" (slice) selects a series of elements

Reviewer comments:
(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 doesn'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.
NAME Two sources of queries: URL URL
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 ( :-)
NAME Wouldn'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 don'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 don'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 .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME 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 doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this. ... 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'.

Revised text:
JSONPath queries in these situations. Specifically, the "Semantics" subsections of Sections name-selector,  <ins> 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 </ins> values, becoming unpredictable if they are not (RFC8259). 1.4. 1.4.3.  <ins> A wildcard "*" (wildcard-selector) in the expression "[*]" selects all children of a node and in the expression "..[*]" selects all </ins> descendants of a node. An array slice "start:end:step" (slice) selects a series of elements