JMESPath and JSONPath

[kinlane]

Moving this Conversation from Spec 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.

[MikeRalphson]

Just so this isn't lost from view, I'm re-posting my objections to JSONPath in its current form:

• 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
• 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.
• 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.
• The above is also a huge security hole.
• JmesPath is more tightly controlled, with each implementation having to pass the conformance test-suite

[kevinswiber]

Based on some initial thoughts and a conversation in the SIG meeting today, I actually don't think JSONPath or JMESPath, in their current forms, are going to be viable. See here: #8

[ponelat]

Designing our own query language, (ie: JSON Pointer Query)

In the interest of designing something with exacting goals that match the Overlay spec, we put together a rough design of our own query language, provisionally called JSON Pointer Query, and you can find the draft over here.

Note that this is very similar to JSON Path, particularly the IETF draft. So it's worth while to talk to those folks instead of completely redesigning the wheel. But there are some differences in this query lang that are still fun!

[ponelat]

@kevinswiber @darrelmiller @char0n @hkosova interested in your thoughts ^^, @MikeRalphson you too (but you appear "busy" in GitHub? I don't know what that means, I'll assume you're not available to review!)

[ponelat]

Using JSON Pointer as the "query" language for the alpha release of Overlays

While JSON Pointer is not a query language, it can be used to identify locations within a JSON-like document and could be a suitable enough for some use cases (i18n comes to mind). It is also well specified and well implemented.

It large downside is that you cannot "future proof" your query, ie: you have to know all the locations you'd like to change/update/delete ahead of time.

[gregsdennis]

JsonPath delegates scripting to the underlying implementation's language.

For what it's worth, the spec authorship effort for JSON Path has decided that this is not the direction going forward due to lack of interoperability.

[glyn]

Just so this isn't lost from view, I'm re-posting my objections to JSONPath in its current form:

* 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

More recent internet drafts are quite different from the blog post. See https://datatracker.ietf.org/wg/jsonpath/documents/ for the latest draft.