Re: [dispatch] JSONPath or JMESPath?

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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)

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.

> * 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

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
> most common use cases

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

> * 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=[e-mail]> ha scritto:
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch

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