JSONPath RFC Nearing Publication
Early last year, I wrote about how the JSONPath Internet Draft got started. Since then draft 21 was approved for publication and, after final editing, will be published as an RFC, probably in early 2024.
Meanwhile there has been considerable progress in implementing the draft, with some notable gaps that you may be interested in helping to plug.
Implementations
I started a Rust implementation that I hoped could be used as a Reference Implementation. I got distracted by spending much more time editing the draft than I anticipated, but I also ran into trouble because the lack of documentation of the pest parser makes the parsing code laborious to implement. An advantage, indeed the main point, of using the pest parser is that the parsing expression grammar (PEG) is cleanly separated from the implementation and is therefore easier to compare to the ABNF in the spec than, for example, a hand-crafted parser. If you are interested in taking over this implementation, please email me using link below.
Greg Dennis, who was involved in the JSONPath Working Group, implemented the whole spec in C#. The code is available in his json-everything repository. You can take this for a spin on the online playground.
Carsten Bormann, one of the editors of the spec, wrote a Ruby implementation. This uses his abnftt tool to generate a PEG parser from the ABNF in the spec. Given that we tried to keep the ABNF “PEG-compatible” by ordering choices suitably, the parser is highly likely to match the spec. For usage information, issue:
$ gem install jpt
$ jpt --help
Trevor Hilton implemented the whole spec in Rust using the nom parser combinator library. See serde_json_path for the code or take it for a spin using the online sandbox.
All these implementations have been tested against the Compliance Test Suite.
Compliance Tests
There is an incomplete Compliance Test Suite. The most notable omission from my perspective is testing for non-deterministic behaviour. Currently, all the tests in the CTS produce deterministic results. So any valid implementation should pass the CTS. However, the non-deterministic aspects of the spec (which stem from the unordered nature of JSON objects) are not tested by the CTS.
Regular Expression Support
Since JSONPath supports regular expression matching in filters, the working group produced an interoperable regular expression spec that defines a subset of XML Schema regular expressions that is also a subset of most other regular expression flavours (“I-Regexp”). This was published as RFC 9485.
Carsten wrote a Ruby implementation again based on abnftt. The code is available on github. For usage information, issue:
$ gem install iregexp
$ iregexp --help
This is a reference implementation only insofar as it can be used to express iregexp regular expressions in other popular flavours such as PCRE or JavaScript regular expressions. The implementation repository contains some basic tests, but a full Compliance Test Suite has not been developed. Perhaps a CTS could be based on the XML Schema Test Suite.