JMESPath and JSONPath

[kinlane]

MIGRATING THIS CONVERSATION TO OFFICIAL OVERLAYS REPO
I wanted to showcase the conversation and thinking that has already occurred around the usage of JSONPath and / or JMESPath as part of the overlays specification. I will pull highlights from the TDC conversation a couple weeks back, but if anyone wanted to share why we are consider one over the other, as well as possibly allowing for both i have several API providers and API service providers interested in learning from the conversation. Thanks everyone for helping me grow the discussion here.

JMESPath: https://jmespath.org/
JSONPath: https://tools.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html

[glenveegee]

Looking forward to learning more about the discussions you are having about this. JSONPath and JMESPath both have strengths but seems to be the use case that dictates the choice of the right tool for the job. I use JMESPath a lot in what I do. In my particular use case JMESPath has clear benefits over other similar tools but there are MANY areas that require improvement.

[MikeRalphson]

Could you expand a little on the use-cases which expose the strengths and weaknesses of the two query languages? It's great to have more feedback and data-points. Agreed it is a shame JmesPath seems to be considered "done" when it has a few gaps in functionality.

[glenveegee]

Our use case relies on data transforms and not merely accessing JSON blobs. Imagine a pipeline of JSON consumers where at each step a component in the pipeline generates a new JSON schema that can be consumed downstream. This new JSON schema can be composed of one-or-more JSON blobs, that have functions and data projections applied, to create the new schema. This is where JMESPath really stands out, since it has a richer set of functions and importantly data projections. There are a few downsides to JMESPath for us though.

• It needs more functions (e.g: it has join() but not split())
• It needs needs a means to set query context beyond the current node (see the let proposal JEP 11: The let() Function jmespath/jmespath.site#6)
• It needs life. @jamesls needs to spend some time on the project or delegate the task to a group of trusted developers that are interested in stewardship and development of the SPEC

[MikeRalphson]

Just to capture my initial objections to JsonPath, and why we ended up using JmesPath in the initial draft of the spec.

1. JsonPath did not have a real specification, only a blog post. It now has an Internet Draft, but the text is basically identical with the original blog post and contains the same issues
2. JsonPath has many and varied implementations, all of which implement and extend the 'spec' differently: https://cburgmer.github.io/json-path-comparison/ thus we could end up with overlays which behave differently depending on which tool you use to process them. Not good.
3. JsonPath delegates scripting to the underlying implementation's language. This means we could end up with overlays which only work in Javascript, or only work in Ruby etc. Not good.
4. JmesPath is more tightly controlled, with each implementation having to pass the conformance test-suite

[kinlane]

Thanks @MikeRalphson -- I will add more from the Zoom call too shortly. However, I am going to migrate this conversation to the official repo. We can still talk here, but seems more appropriate that we have over there now that discussions are turned on.

[handrews]

Since this was migrated to the Overlays repo (see link in initial comment) I'm closing it out of this repo.