Subject: Re: [Jsonpath] Jsonpath Digest, Vol 15, Issue 4

From: Daniel P <[email-masked]>
Date: Tue, 14 Sep 2021 08:32:02 -0400

> From: Glyn Normington <[email-masked]>
> >
> > These observations suggest that it might be helpful to include a note
> > in the draft that clarifies the purpose of the WG. Is it to
> > standardize existing behaviour?
>
> Yes. Please see our charter:  https://datatracker.ietf.org/wg/jsonpath/about/
>
Thanks for the clarification.

> > What would that mean when the extant
> > implementations exhibit different behaviour, and because they are
> > entrenched in legacy API's, they cannot change?
>
> The charter says:
>
> "Where there are
> differences, the working group will analyze those differences and
> make choices that rough consensus considers technically best, with
> an aim toward minimizing disruption among the different JSONPath
> implementations."
>
> So we don't have to preserve all existing behaviour. It will be up to
> each implementation whether or not to migrate to the eventual
> standard.
>

The differences, as I'm sure you know, are fundamental. Given the
document [{"key" : false}], does "$[?(@.key)]" return [{"key" : false}]
or []? It depends on what implementation you use. In an
expression like @.foo, does @.foo mean a JsonPath expression
evaluated with an EvaluateSingle method, as it does in Jayway and
a dozen other implementations, or does it mean a JavaScript like
variable evaluated with key foo? It depends on what implementation
you use. Can you write "$[?(@.foo[?(@ == 'bar')])]"? It depends
whether you're using an implementation where @.foo is a JSONPath
expression or not. Can we use functions in expressions like
$[?(@.key.normalize()=="Motörhead".normalize())]? It depends on
what implementation you use.

The two most influential implementations in the evolution of
JSONPath, Goessner JsonPath and Jayway JsonPath, come
down on different sides for each of the points listed above.

> > Or is it to invent
> > something new, inspired by the original, picking and choosing from
> > popular implementations as the WG sees fit? If something new, should
> > it have a different name?
>
> I doubt we want to reinvent JMESPath.
>
That's a different thing. JMESPath transforms JSON documents, JSONPath
is generally regarded as selecting from JSON documents. (Although even
there, Jayway, regarded as the second most influential JSONPath
implementation, supports transformation via tail functions. Another difference.)

Realistically, I think that whatever the WG produces will be something new.
A JSONPath B, so to speak. It's unavoidable. Existing behaviour cannot be
standardized because it's too different.

Daniel