Subject: [dispatch] JSONPath or JMESPath?

From: Darrel Miller <[email-masked]>
Date: Mon, 3 Aug 2020 13:27:12 +0000

After reviewing the discussion from the Dispatch meeting related to the JSONPath standardization effort I noticed there was no mention of JMESPath (pronounced JamesPath)  (https://www.jmespath.org ).

In some recent specification work I was involved with, we were faced with the need for this type of query capability.  Our investigation led us to move forward with JMESPath instead of JSONPath.  The reasons included:

  *   It has a complete ABNF description https://jmespath.org/specification.html
  *   It has a compliance suite https://jmespath.org/compliance.html
  *   It has a reasonable set of language support https://jmespath.org/libraries.html
  *   JMESPath doesn’t have a dependency on an underlying scripting language

JMESPath came from the Python world and has been picked up by both AWS and Azure as a query capability in their command line tools.  This drives a significant amount of exposure to developers.
https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html#cli-usage-output-filter
https://docs.microsoft.com/en-us/cli/azure/query-azure-cli?view=azure-cli-latest

While I do believe there is value in standardizing a tech that has wide usage like JSONPath, due to the current challenges with JSONPath implementation variations, would it more valuable to try and coalesce the industry around an option that already has a formally defined grammar and compliance tests?

Darrel

---

From: Glyn Normington <[email-masked]>
Date: Mon, 3 Aug 2020 14:06:32 +0000

Hi Darrel

Thanks for bringing up JMESPath. It’s certainly an excellent project. We have yet to agree a charter for the standardisation of JSONPath. I personally believe one goal should be to minimise the migration cost, both for users and maintainers of existing implementations. OTOH adopting JMESPath would save a tonne of spec work, so I guess it all depends on the goals we agree in the charter. I hope you can join in that discussion (when it gets going) over at [email-masked].

Regards,
Glyn

> On 3 Aug 2020, at 14:27, Darrel Miller <Darrel.Miller=[email-masked]> wrote:
> 
> 	• It has a complete ABNF description https://jmespath.org/specification.html
> 	• It has a compliance suite https://jmespath.org/compliance.html
> 	• It has a reasonable set of language support https://jmespath.org/libraries.html
> 	• JMESPath doesn’t have a dependency on an underlying scripting language
>  
>  
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdispatch&amp;data=02%7C01%7Cnormingtong%40vmware.com%7C4b6ede17c5284ea4ab1208d837b0fbfb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637320580571160457&amp;sdata=id58d2v1n61nlObWNXLt23pv2GIVxwEYtZy7xurVHjE%3D&amp;reserved=0

---

From: Davide Bettio <[email-masked]>
Date: Tue, 4 Aug 2020 15:48:02 +0200

Hello,

I agree, JMESPath looks excellent however I would like to raise points
on this topic:

* both JMESPath and JSONPath have a number of users and softwares
which are using them (JSONPath: [1], [2], etc...)
* JSONPath is easier to implement compared to JMESPath
* JSONPath has wider number of different implementations (and
different supported languages)
* without a JSONPath standard people will continue using and
implementing it, but all inconsistencies will stay there without any
fix (and standard)
* a number of supported JSONPath paths are also valid JMESPath paths
* most JSONPath inconsistencies come out when dealing with corner
cases and nearly ill formed paths
* a JSONPath consensus can be easily found when dealing with all the
most common use cases
* JSONPath "scripting" is mostly used for filtering, a strict spec is
required, but I don't see it as a stopper issue
* JMESPath has support for some useful functions such as sort, ceil,
etc. which they enable more powerful operations

So what I really see here as a major key difference is that JMESPath
has support for functions, which they require a more complex
implementation, and I'm not sure if JSONPath users are interested in
them (to be fairly honest I would find them useful, but I'm not sure
about any other else).

Regards,
Davide Bettio.

[1]: https://kubernetes.io/docs/reference/kubectl/jsonpath/
[2]: https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adjsn/json-path-expressions.html#GUID-2DC05D71-3D62-4A14-855F-76E054032494

Il giorno lun 3 ago 2020 alle ore 15:27 Darrel Miller
<Darrel.Miller=[email-masked]> ha scritto:
> It has a complete ABNF description https://jmespath.org/specification.html
> It has a compliance suite https://jmespath.org/compliance.html
> It has a reasonable set of language support https://jmespath.org/libraries.html
> JMESPath doesn’t have a dependency on an underlying scripting language
>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2020 09:16:36 +1000

Just some general comments (I don't have any particular insights or preferences regarding technology here):

> On 4 Aug 2020, at 11:48 pm, Davide Bettio <[email-masked]> wrote:
> 
> Hello,
> 

The purpose of standardisation isn't to preclude all other approaches being used, nor is it to address all possible problems in the world. What we're trying to do is choose a suitable basis for future work -- one that will result in the best combination of interoperability, deployment, and functionality.

> cases and nearly ill formed paths

Unfortunately, those are the usual places that interoperability becomes hard - and eventually necessary to consider. Consider the history of HTML.

> * a JSONPath consensus can be easily found when dealing with all the

That's only something we can find out by actually trying to achieve consensus; it's premature to say it's easy.

--
Mark Nottingham   https://www.mnot.net/