Draft: draft-ietf-jsonpath-base

Commentary: Also tweak the wording of the list semantics section . Fixes Reviewers may find the useful . 
 Just a gentle reminder to re - review as I 'd like to get this PR merged . Thanks . 
 The ( as of 2022 - 08 - 06 ) for the descendant selector involving a list : Do not state which descendants are selected . Order selected items contrary to current implementations . Lead to contradictions over the ordering of duplicate nodes . It is currently implicit that the list selector should select descendants based on the . This should be made explicit . An applies the path to the value : The spec states : Because of the ordering of the array , in all array - sequenced preorders of the above value , , , and appear before and which appear before which appears before which appears before . So the order of the result according to the spec is : However , the current consensus according to the comparison project is : where it seems the value is traversed once per item of the list ( ) . Consider the path applied to the value : There is just one array - sequenced preorder of this value : ( noting the clarification below ) . But the current produces duplicates and can reorder the elements of an array , so the resultant nodelist would be : which is not a sub - sequence of . We should make it clear that an array - sequenced preorder is of nodes rather than values . For example , consider the path applied to the value : The array - sequenced preorder of this value is and the values selected by are and , but the nodelist is not _ a valid result even though it is a subsequence of the values in the array - sequenced preorder . The result is which is a subsequence of the nodes in the array - sequenced preorder . ( In fact , using an array of values to describe an array - sequenced preorder is misleading because it ignores the nodes ' locations within the argument value . ) 
 I propose the following actions : which nodes are selected . the current ordering , regardless of the implementation consensus , since it easily implemented via a single traversal of the descendants . the descendant list selector to reorder a subsequence of the nodes in an array - sequenced preorder , although it must honour the order of the elements in the selector 's list . the definition of array - sequenced preorder . Any objections ? 
 I do n't think you can tell about the ordering from this result , the query is flagged with footnote 4 , see ( ) , which indicates that these results are being sorted before comparison . A quick check shows that a number of implementations that fall in the consensus ( including Goessner JavaScript ) actually return 
 well spotted ( and thanks for raising ) . So that leaves the following proposed actions : which nodes are selected . the descendant list selector to reorder a subsequence of the nodes in an array - sequenced preorder , although it must honour the order of the elements in the selector 's list . the definition of array - sequenced preorder . 
 That sounds complicated :-) One thing to keep in mind is that implementations that return do not do anything complicated , nor do they " reorder a subsequence of the nodes in an array - sequenced preorder " . Rather , they simply apply the selector to each node in the provided node list , and then ( for the recursion operator ) apply the same logic recursively on the children of each node . That description alone implies the above result . 
 I agree it sounds complicated . Perhaps , along the lines you describe , it is best to describe the possible orderings of descendants and then say how particular descendant selectors are apply to those descendants . 
 It may be helpful to think of the recursion operator as an operation that maps the current result list into a new result list according to the following rules : First , create a new empty result list . Then Iterate over the items of the current result list If the current item is an array or object , add it to the end of the new result list . If the current item is an array , iterate over its elements and apply these rules recursively to each element . If the current item is an object , iterate over its members and apply these rules recursively to each member value . This becomes the new current result list . So if the current result list contains the root value the recursive operation produces Then applying the selector to each element in the new current result list produces 
 I 'd prefer to define the orderings of the descendants in terms of a postcondition rather than an algorithm because that avoids implementation bias - a useful property for a spec . Sometimes the postcondition form really does n't work and we have to resort to an algorithm , for example in the slice semantics . Let 's see how the postcondition works out in a PR ... 
 Oh and I would say that describing the part of the descendant selector as a recursion operator is another example of implementation bias ( since implementations need not use recursion ) . The spec talks about descendant selectors because this term describes what the selectors are rather than how they are implemented .
Paragraph (version A):
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 nodelist.
Paragraph (version B):
A list selector selects the nodes that are selected by 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 nodelist.
Paragraph (version A):
the "..<name>" form (and the "..[<index>]" form where "<index>" is
a "quoted-member-name") selects those descendants that are member
values of an object with the given member name.
Paragraph (version A):
the "..[<index>]" form, where "<index>" is an "element-index",
selects those descendants that are array elements with the given
index.
Paragraph (version A):
the "..[<slice-index>]" form selects those descendants that are
array elements selected by the given slice.
Paragraph (version A):
the "..[<filter>]" form selects those descendants that are array
elements or object values selected by the given filter.
Paragraph (version A):
the "..[*]" and "..*" forms select all the descendants.
Paragraph (version B):
A descendant selector selects zero or more descendants of a node.
Paragraph (version A):
The resultant nodelist of a "descendant-selector" applied to a node
must be a sub-sequence of an array-sequenced preorder of the
descendants of the node.