Stefan Goessner is the originator of JSONPath, the XPath-like query language for JSON, and hosts its original write-up.
HN links it as the origin of JSONPath, and commenters note the 2007 post was implemented inconsistently for years before it became a standard.
Related/shameless plug: We've been working on a reimagining of JSONPath [1] which we hope will be useful to other people.
Unfortunately, it's not public yet — though we have working libraries in JavaScript and Go (a heavily modified fork of Kubernetes' JSONPath code) we intend to release — mostly because we want to publish a proper spec. In fact, we're looking for a good name for it, as we feel that releasing "JSONPath 2.0" would be a little presumptious. I was thinking something like JSONMatch. If there's sufficient interest I could prioritize it (email me!).
Our own version of JSONPath is intended for both searching and patching documents in general. A simple search would be something like:
friends[name == 'bob'].id
or
shoppingItems[1:3][description, id]
We use this to declaratively extract data from documents, but also change it. The patching support lets you do things like:
match(document, "..[role == 'owner'].role")
.set('admin');
This will set "role". It gets rather magical and beautiful when you have multiple paths that involve unions, subindexed arrays and constraints.
We also have a separate patch notation, expressed in JSON, to declaratively transform documents. It uses these JSONPaths to select and set values. We might write a spec for that, too, although I'm not sure the utility outside our app is that great.
[1] http://goessner.net/articles/JsonPath/
Regarding schemas - there is JSON Schema:
http://json-schema.org/
http://tools.ietf.org/html/draft-zyp-json-schema-02
We've been using this pretty extensively at work. The Java guys wrote something to generate their model from it and on the JavaScript side we've used it to do all kinds of nice things like automagically generating forms that validate according to the schema and verifying that the data we receive from the backend conforms to it in our tests.
From what I can gather very few people are using it. It's not exactly fun to write but a co-worker of mine wrote a dsl to make that less painful.
Of course when you write JavaScript, it's a joy to work with.
On the transformation side there are a few ideas floating, notably JSON-T
http://goessner.net/articles/jsont/
Neither of these things are as mature as XSD and XSLT, but if you love JSON and JavaScript, they're definitely worth investigating.
I had a very similar problem with Ruby and some of our workloads. I ended up utilizing this evented parser [1] to process smaller subsets of the JSON document and then clear them from memory. The result is a memory usage that is at most the size of one of these subsets (plus some overhead).
I have been wanting to generalize this approach with some open source software for some time, but I haven't gotten around to it. I think an attractive solution is for a user to specify a JSONPath [2] upfront about the types of subsets they are interested in. In the case of Ruby these chunks could then be yielded by an iterator and cleared, but I wonder if a more general-purpose CLI program which prints the subsets to stdout would also work if the subsets are small enough. But this adds another serialization/deserialization step.
[1] https://github.com/dgraham/json-stream
[2] http://goessner.net/articles/JsonPath/
Interesting, I only knew about <https://goessner.net/articles/JsonPath/index.html> which makes no reference to =~ nor any such // syntax but it seems there's an IETF draft that is (a) an actual specification (b) includes more modern stuff like what you used: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-07.html#section-3.5.5.1-14
And, while whatever is powering https://jsonpath.com/ does honor your syntax, albeit with an absolutely useless result:
[
{
"name": -1
},
{
"name": -1
},
{
"name": -1
}
]
I found that `pip install jsonpath-ng` does not accept it nor mention it <https://github.com/h2non/jsonpath-ng/tree/v1.5.3?tab=readme-ov-file#extensions> so I think it's out on the bleeding edge or something
I know Reflect[0] doesn't get alot of attention however I always thought it would be a big improvement if `Reflect.set`, `Reflect.get` and `Reflect.deleteProperty` gained support to deal with nested properties. It would effective give developers built-in JSON Path support[1] (like you see in MySQL, Postgres or SQLite databases).
As an unrelated aside, recursive proxies would also be extremely useful
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Reflect
[1]: https://goessner.net/articles/JsonPath/
That is something I have wanted for a long time too. I came from the XML world and am very familiar with XPath. It seems like you are trying to create an XPath type parser for JSON, but also including some more complex features than XPath might include (been a while since I touched it, so I'd have to refresh my memory).
Note that in your README, the links to the github repos for json-path and json-pointer 404.
See also, this: http://goessner.net/articles/JsonPath/