Original text:
Nested descendants selector "..". <del> Union selector "[<sel1>,<sel2>,...,<selN>]", holding a comma delimited list of index, index wild card, array slice, and filter selectors. </del>  Filter selector "[?(<expr>)]" 3.5.8.  3.5.8.1. <del> The union selector is syntactically related to the "index-selector". It contains two or more entries, separated by commas. </del>  3.5.8.2. <del> A union selects any node which is selected by at least one of the union selectors and selects the concatenation of the lists (in the order of the selectors) of nodes selected by the union elements. Note that any node selected in more than one of the union selectors is kept as many times in the node list. </del>  To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-

Reviewer comments:
Clarify related text; add explanation of change. Take slice-selector apart to define slice-index.
I'm going to merge this PR to make forward progress. Tweaks can be added via further PRs as usual.
URL URL
(To me it is inexplicable they aren't already. But changing that was not the remit of .)
I am fine with the status quo of excluding filters within list selectors. One is either building a list of explicite indices/indexes or a boolean expression for filtering. Two or more filter expressions in a list are equivalent to have a single one or'ed them together. Most cases in practises could be solved by a sequence list selector following filter selector filter selector following list selector Any striking use cases I am not aware of?
As mentioned in my comment, I see no reason why a filter can't be included in a list. Some people may prefer to have multiple simple expressions for readability. My implementation already supports this (I'll have to disable this functionality or hide it behind an option if we don't include it).
I don't have a strong opinion on this question. But not only does it seem natural to include filter selectors in list selectors: the comparison project also shows that most implementations that do provide this, also agree on what the result should be. So this would not be a risky addition.
I do have a strong opinion here, as ... index expressions (member names, index and slices) are strongly explicit and single level only. list-selector is merely a list of those index expressions. Example above is easily - and more consistently - reformulated as a pure filter-selector So I would like to see real use cases to be convinced here. If filter selectors are natural to be included in list selectors, then so are index-wild-selector descendant-selector and even list-selector
(The sequence of data items is different between the two.) Could be done. There is no natural syntax for that. That already works :-) If you have the list selector [1, 2, 3], you can include that in [4, 5, 6] by unpacking the brackets, so you have 1, 2, 3, and appending that to the comma-separated list, so you have [4, 5, 6, 1, 2, 3] (Note that all the embedded selectors have their brackets removed before including them in a list-selector.) Grüße, Carsten
??? ... even with filter selectors ?
(I just pushed a slight editorial fix that distinguishes between selectors in general and selector entries in a list selector — the latter don’t have the brackets.) Note the "(in the order of the selector entries)”. So applying $[?(@ % 2 == 0), ?(@ % 2 != 0)] to [1, 2, 3, 4] yields 2, 4, 1, 3 …while applying $[?(@ % 2 == 0 @ % 2 != 0)] to [1, 2, 3, 4] yields 1, 2, 3, 4 Yes, putting [?(@ % 2 == 0)] and [?(@ % 2 != 0)] into a list selector yields [?(@ % 2 == 0), ?(@ % 2 != 0)]. The brackets of the individual filter selectors are gone. Grüße, Carsten
My preference is to include filter selectors in list selectors simply because omitting them seems arbitrary and rather surprising. I don't have a use case to justify this, although I could probably fabricate one if pushed. ;-)
I think the key to the utility here is mixing selector types. If the user wanted to get the first item and also any item where , then they can do: To my knowledge, this can't be done in a single expression.
... this is true ...
I think you are aware of using arithmethic operators here. JSONPath is for selection exclusively. JSONPath is not for calculation.
Selection and calculation are not mutually exclusive, though. Consider Javascript Goessner returns
I do know this very well ... since I am pragmatically reusing the javascript engine for evaluation. People then would want to know/apply ... all products above/below the average product price. normalized values distances between locations trigonometric functions logarithmic scaling vector arithmetic Even when restricting to basic arithmetic operations we need to handle division by zero, NaN, equality of floats/doubles, truncation, rounding, ... Your example above can be solved with a three-liner ... or by smart post-processing of JSONPath selection results. JSONPath is for selection ... the right tool for the right task.
NAME I think it all comes down to taste. The taste of the language designer. With regards to prior experience, there are query languages that have arithmetic operations (SQL, XPath, JSONiq, all JSONPath implementations that use Javascript, Python, Lua) and others that do not (JMESPath, Jayway JSONPath). Either way, there is plenty of prior experience to draw on. There are answers to the technical questions. But taste is another matter. Best regards, Daniel
I think we're getting a little of topic here. We want to know if there are use cases for including the syntax as a viable member of a list selector. I think my example shows that there is a use case, even if somewhat constructed. Someone is going to try it.
That's my position too Daniel.
I have so far not contributed to this discussion, and don't have a strong position myself, but I wanted to explain the quoted argument in a bit more detail. In my (outdated) proposal for an aligned understanding, I identified two major operators: recursive decent and children selection. The latter is implemented here: URL If we were to exclude wildcard or filters, my code would grow. Happy to see (pseudo) code for the other side of the argument to compare.
The term "union" will likely be unfamiliar for readers (it is for me) and could use a bit more description than "A union ~matcher~ selector consists of one or more union elements." "Union" isn't a common term outside of set manipulation. I would call the an "indexer," which is a much more well-known term and is already associated with this construct in many programming languages. The values inside are indices (as opposed to "union children" or "union elements"), of which there are multiple types: Integer Slice String Container query expression Item query expression See for more details on the query-style indexers.
Good point. We have yet to decide whether unions remove or preserve duplicates and I think the outcome of that decision should influence the naming. "Union" as you point out has a set theory connotation and implies removing duplicates. It's tricky though because I think the result is ordered, whereas sets aren't ordered.
Regarding duplicates specifically, please see .
Not much actionable discussion here. Confirm no change needed at 2022-01-18 interim.

Revised text:
Nested descendants selector "..".  <ins> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma separated list of index and slice selectors. </ins> Filter selector "[?(<expr>)]" 3.5.8. <ins> The list selector allows combining member names, array indices, and slices in a single selector. Note: The list selector was called "union selector" in JSONPath-orig, as it was intended to solve use cases addressed by the union selector in XPath.  However, the term "union" has the connotation of a set operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector". </ins> 3.5.8.1.  <ins> The list selector is syntactically related to the "index-selector" and the "slice-selector".  It contains two or more entries, separated by commas. </ins> 3.5.8.2.  <ins> A list selector selects the nodes that are selected by at least one of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one of the selector entries is kept as many times in the node list. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-