Recursive Tree Traversal

[springcomp]

Please, consider adding features to do arbitrarily deep searches, much like the xpath query  //my-element/my-other-element.

[icaine]

+1
Use case 1: sometimes i do analyses of json schemas and i want to see values for a given key/select no matter how deep they are...
Use case 2: there is a value under unique key but deep in the structure so writing exact (long) path is annoying while the performance isn't an issue..

[springcomp]

I have drafted a very ugly working prototype for a new descendant-expression:

Recursive Traversal

JEP
Author	Maxime Labelle
Status	draft
Created	24-06-2023

Abstract

Motivation

Specification

A new descendant-expression will be added as an alternative to the expression grammar rule:

descendant = ".." identifier
descendant-expression = ( expression ) 1*( descendant )

expression =/ descendant-expression

A descendant-expression is a projection that returns an array with all the elements of the JSON input with the specified name.

Examples

Given the following JSON input:

{
  "name": "first",
  "top": { "name": "second" },
  "nested": {
    "name": [
      1, "string", false,
      { "name": "third" }
    ]
  }
}

The following expressions are possible:

Expression	Result
..name	["first","second",[1,"string",false,{"name":"third"}],"third"]
..name.length(@)	[5, 6, 4, 5]
..name..name	["third"]

Compliance Tests

This JEP standardizes a syntax that was formely not valid. For this reason, one of the syntax.json compliance tests must be changed or removed altogether:

    {
      "expression": ".foo",
      "error": "syntax"
    },
    {
      "expression": "foo..bar",
-     "error": "syntax"
+     "result": null
    },

A new file descendant.json will be added to the compliance test suite.

[kit494way]

I understand that the expression does not guarantee to return values in a specific order, is it right?

[kit494way]

Should we support ..[?value > `1`]?

descendant = ".." ( identifier / bracket-specifier )

[springcomp]

I understand that the expression does not guarantee to return values in a specific order, is it right?

Indeed nothing in JMESPath guarantees specific order.
That’s actually an open point.

As supporting filter-expression I think that’s a great idea.
As currently proposed, the descendant-expression is a projection and would not work with filters out of the box.

In fact the more I think of this, the more I think it should not return a projection, but an array instead.
Otherwise, you need to stop the projection to support something like this:

"..locations[]|[?state=='WA']"