Subject: [Jsonpath] JSONPath or JMESPath

From: Davide Bettio <[email-masked]>
Date: Tue, 11 Aug 2020 18:17:26 +0200

Hello,

Darrel Miller on [email-masked] started a "JSONPath or JMESPath"
thread, I think we should take a decision on this topic before making
any other decision.

If we go for JMESPath, discussing JSONPath here would be useless, so
can we prioritise this topic?

Regards,
Davide Bettio.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Aug 2020 18:30:08 +0200

On 2020-08-11, at 18:17, Davide Bettio <[email-masked]> wrote:
> thread,

Right, please find (and read) the thread here:

https://mailarchive.ietf.org/arch/msg/dispatch/FoCwaHJVIqJP78GdHT-IaDH32ks/

The reasons he gave for choosing JMESPath are exactly the ones that made me propose the activity this mailing list has been created for.

> I think we should take a decision on this topic before making
> any other decision.

It is a bit outside the scope, as this mailing list was created for standardizing JSONPath, but we certainly don’t want to expend the effort for that if JMESPath is already the solution.
I can’t reach https://www.jmespath.org/ at the moment, so 

> can we prioritise this topic?

Sure.  So what are the advantages of JMESPath over JSONPath that are not about what we’ve set out to do here?

Grüße, Carsten

---

From: Stefan Hagen <[email-masked]>
Date: Tue, 11 Aug 2020 19:22:36 +0200

> Am 11.08.2020 um 18:30 schrieb Carsten Bormann <[email-masked]>:
> 

Try without the www: https://jmespath.org/ works for me while the above URL does not. Or one can start from pypi or https://github.com/jmespath/jmespath.py

> -- 
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath

Best,
Stefan

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Aug 2020 10:45:23 -0700

Sounds like JMESPath is already reasonably well-defined. JSONPath isn't.
JSONPath is widely adopted and in my most recent job, lack of a
standardized definition was a real problem. So it sounds to me like there's
more value for the IETF to add with JSONPath.

On Tue., Aug. 11, 2020, 10:22 a.m. Stefan Hagen, <[email-masked]>
wrote:

> The reasons he gave for choosing JMESPath are exactly the ones that made
> me propose the activity this mailing list has been created for.
>
> It is a bit outside the scope, as this mailing list was created for
> standardizing JSONPath, but we certainly don’t want to expend the effort
> for that if JMESPath is already the solution.
> Try without the www: https://jmespath.org/ works for me while the above
> URL does not.. Or one can start from pypi or
> https://github.com/jmespath/jmespath.py
>
>

---

From: Davide Bettio <[email-masked]>
Date: Wed, 12 Aug 2020 12:56:54 +0200

Hello,

> Sure.  So what are the advantages of JMESPath over JSONPath that are not about what we’ve set out to do here?

The main  difference I found so far is that JMESPath supports
functions, which is IMHO an useful feature, however there are 2 major
drawbacks:
- Increased implementation complexity compared to JSONPath (my Elixir
JSONPath implementation counts a few hundred lines of code).
- JMESPath expressions might be computational heavier, since it has
support for functions such as sort, avg, map, etc... that might be
expensive on huge datasets.

In my opinion the right balance between powerfulness and enabling
simple implementations has been so far one of the key factors that
made JSONPath popular over other alternatives, even if it lacks
support for aggregation functions.

I also realize that exists a kind of hierarchy between existing
competing solutions, and each one has valid use cases:
JSONPointer: no computation (hence deterministic processing time),
returns just a subtree
JSONPath: allows filtering and projections, however the result is
still a subset of the original dataset
JMESPath: allows computations (some of them expensive), and the output
value might not exist in the original JSON object

At the moment JSONPointer and JMESPath have complete specs, while
JSONPath doesn't.

Regards,
Davide Bettio.