JSONPath comparison and standardisation

[glyn]

@SoftCreatR If you are interested in helping to shape a JSONPath standard, see the IETF JSONPath mailing list for upcoming information about a Working Group to work on the standard. Meanwhile, feel free to join some other implementers here (includes an invitation to their slack workspace) or to add your project to the JSONPath comparison project.

Context: FlowCommunications/JSONPath#55 (comment), thanks to @martinssipenko.

[SoftCreatR]

Hello @glyn,

thank you for pointing that out. As of now, I don't know, if I'm going to extend the functionality of this lib by myself.

The motivation for forking this project was related to a compatibility issue with the PSR-0/PSR-4 standard, which prevented me from finishing my ongoing work using https://github.com/martin-helmich/phpunit-json-assert. So the goal was to have a functional version of this library as a drop-in replacement for its original. And when I saw, that many people are struggling with the same issues, I decided to make this fork public and create an unofficial update (which is now somewhat official).

Now, the next goal is to provide a working version for older PHP versions, so this lib completely supersedes its predecessor. When this is done, I'll think about extending its functionality.

[glyn]

thank you for pointing that out. As of now, I don't know, if I'm going to extend the functionality of this lib by myself.

Fair enough. One other possibility is that a JSONPath standard can help to clarify existing behaviour and you might want to refer to the eventual standard and say things like "This feature works in a standard way".

[SoftCreatR]

Hi @glyn - this is a very late follow-up, but I wanted to close the loop.

Your comment aged well. Since RFC 9535 (https://www.rfc-editor.org/rfc/rfc9535) was published, the standard and the JSONPath Comparison project have become the primary references for this library.

Version 2 now follows RFC semantics as closely as its current feature set allows. This required breaking changes: ambiguous and non-standard legacy syntax is rejected rather than interpreted permissively, and missing values are correctly distinguished from JSON null.

This is not yet a claim of complete RFC support: the function extensions length(), count(), match(), search(), and value() remain unsupported. For all implemented functionality, however, standard behavior is now the goal and default.

So, several years later, I can finally follow up on your suggestion that “this feature works in a standard way.”

Thank you again for pointing the project toward standardization and the comparison suite (https://cburgmer.github.io/json-path-comparison/) back in 2020. It ended up having a significant influence on the direction of v2.