1. JSONPath/SPath supports multiple selector, e.g., $["a", "b"] or $[1, 3:10:2, 101]. This may be a bit more tidy than dot or subscript.
2. JSONPath/SPath supports descendant query: a descendant segment produces zero or more descendants of an input value. For example, $..[0] selects all the first element of arbitrary successors that is an array.
3. JSONPath defines filter selectors. SPath doesn't support it now, while it's on the Roadmap. This can be more powerful as a query language.
4. The original reason I wrote such a library is, however, to use JSONPath/SPath syntax beyond a JSON value. That is, I've written a database for processing semi-structured data [1], and my clients told me that's like to extract inner value with JSONPath syntax. All the existing JSONPath libraries, whether mature or not, are, of course, assuming they are handling JSON values. But in ScopeDB, we define our own variant value.
JSONPath is a full query language (https://datatracker.ietf.org/doc/rfc9535/), similar to XPath for XML. It supports things like transformations, array operations, filters, etc.
Any JSON-compatible data (and even some JavaScript data formats beyond strict JSON types) can be converted to an XML representation, have real XPath queries run on it, and the original matching data returned as the results.
We use this to great effect exploring and sifting through data in web browsers, where many different pieces of software may be storing various things globally, but you don't always know where to look.
(The advantage to this approach is that both XML and XPath are specified standards)
1. JSONPath/SPath supports multiple selector, e.g., $["a", "b"] or $[1, 3:10:2, 101]. This may be a bit more tidy than dot or subscript.
2. JSONPath/SPath supports descendant query: a descendant segment produces zero or more descendants of an input value. For example, $..[0] selects all the first element of arbitrary successors that is an array.
3. JSONPath defines filter selectors. SPath doesn't support it now, while it's on the Roadmap. This can be more powerful as a query language.
4. The original reason I wrote such a library is, however, to use JSONPath/SPath syntax beyond a JSON value. That is, I've written a database for processing semi-structured data [1], and my clients told me that's like to extract inner value with JSONPath syntax. All the existing JSONPath libraries, whether mature or not, are, of course, assuming they are handling JSON values. But in ScopeDB, we define our own variant value.
[1] https://www.scopedb.io/reference/datatypes-variant
We use this to great effect exploring and sifting through data in web browsers, where many different pieces of software may be storing various things globally, but you don't always know where to look.
(The advantage to this approach is that both XML and XPath are specified standards)
I think it would be done before I call a 1.0 release.