Draft: draft-ietf-jsonpath-base

Commentary: Give an example to emphasise the spec behaviour . At the time of writing , this disagrees with the implementation consensus here : Fixes 
 Please see on the issue . I think we need more semantic text to define what we 're looking for . 
 I 've reworked the text in to make the semantics much more obvious . 
 The current draft does not agree with the when a descendant segment has multiple selectors . The current draft says that a corresponding child segment containing the whole list of selectors should be applied to a descendant nodelist . The implementation consensus is that each selector is be applied to a descendant nodelist and the results concatenated together . Let 's take an example involving arrays ( to avoid non - determinism confusing matters ) . The JSONPath applied to the value according to the current draft gives : but according to the implementation consensus gives : One of the more influential implementations ( Jayway ) agrees with the current draft . I think it is best to go with the current draft behaviour as this can be implemented in a single traversal of the descendants , but wanted to confirm this here . 
 Another advantage of the current draft behaviour is that it is more deterministic than the implementation consensus . For example , the JSONPath applied to the value according to the current draft gives : or but according to the implementation consensus ( with the non - determinism of ) gives : or or or 
 I am very much in favor of cleaning this up . ( If the odd behaviors are very widespread , we could combine the cleaned - up semantics with an interoperability warning that applications that rely on the exact sequence will be less interoperable than ones that do n't . That is , of course , true of most of what the standard is providing ... ) 
 I agree that the current draft is better . 
 Reading the spec again , While it definitely has instruction for order the results of each selector , I do n't think it specifies ordering one way or another for the multiple - selector case . Using the previous example there are two options : Each selector is analyzed separately and the results are concatenated . This is equivalent to ( forgive the syntax ) . This would ( in theory ) require multiple data traversals : one for matching and one for matching . All selectors are analyzed together for each node . This is more akin to ( again , forgive the syntax ) . This would ( in theory ) process both selectors over a single traversal : as each node is visited , both selectors are applied . It sounds like we want the latter , traversal prioritization . 
 You quoted an old version of the spec . The current spec says : I think this makes the multi - selector ordering clear . 
 I still think it 's vague on the distinction I mentioned ( the two options ) . Between the two options , I think this text leans more towards the selector prioritization , suggesting that the selector results in their entirety are concatenated . 
 See
Paragraph (version A):
nodes are visited before all their descendants.
Paragraph (version A):
It applies the child segment "[<selectors>]" to each node and
concatenates the resultant nodelists together in the order in which
the nodes were visited.
Paragraph (version A):
This definition does not stipulate the order in which the children of
an object are visited, since JSON objects are unordered.
Paragraph (version A):
Where a selector can produce a nodelist in more than one possible
order, the selector may produce nodelists in distinct orders each
time it appears in the descendant segment.
Paragraph (version B):
nodes are visited before their descendants.
Paragraph (version B):
The order in which the children of an object are visited is not
stipulated, since JSON objects are unordered.
Paragraph (version B):
Suppose the nodes, in the order visited, are "D1", ..., "Dn" (where
"n >= 1").  Note that "D1" is the input value.
Paragraph (version B):
For each "i" such that "1 <= i <= n", the nodelist "Ri" is defined to
be a result of applying the child segment "[<selectors>]" to the node
"Di".
Paragraph (version B):
The result of the descendant selector is the concatenation of "R1",
..., "Rn" (in that order).
Paragraph (version A):
"[5, 3, [{"j": 4}]]" must appear before "5", "3", and "[{"j":
4}]",
Paragraph (version A):
"5" must appear before "3" which must appear before "[{"j": 4}]",
Paragraph (version A):
"5" and "3" must appear before "{"j": 4}" and "4",
Paragraph (version A):
"{"j": 4}" must appear before "4".
Paragraph (version B):
"[5, 3, [{"j": 4}, {"k": 6}]]" must appear before "5", "3", and
"[{"j": 4}, {"k": 6}]",
Paragraph (version B):
"5" must appear before "3" which must appear before "[{"j": 4},
{"k": 6}]",
Paragraph (version B):
"5" and "3" must appear before "{"j": 4}", "4", ", {"k": 6}", and
"6",
Paragraph (version B):
"[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k":
6}",
Paragraph (version B):
"{"k": 6}" must appear before "6".
Paragraph (version B):
The example above with the query "$.a..[0, 1]" shows that the child
segment "[0, 1]" is applied to each node in turn (rather than the
nodes being visited once per selector, which is the case for some
JSONPath implementations that do not conform to this specification).