Subject: Re: [Jsonpath] Jsonpath Digest, Vol 2, Issue 1

From: Daniel P <[email-masked]>
Date: Tue, 11 Aug 2020 15:56:00 -0400

> From: Tim Bray <[email-masked]>
> To: Stefan Hagen <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>, Davide Bettio <[email-masked]>, [email-masked]
> Bcc:
> Date: Tue, 11 Aug 2020 10:45:23 -0700
> Subject: Re: [Jsonpath] JSONPath or JMESPath
> 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.
>
Note that there is an emerging ISO SQL/JSON standard for JSONPath that
appears to have
the backing of Google, Amazon, Microsoft and Oracle, cf.
https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip

It seems to me that a separate standardization effort would need to
take this work into account and be
compatible with it, to have broad acceptance.

Daniel

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Aug 2020 00:06:46 +0200

> https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip

This is a TR, but it contains a lot of useful material.  Lots of examples!

> take this work into account

Definitely!  Thank you for the pointer.

> and be

For a definition of compatible.  For instance, I would like to learn more about actual usage of the “strict mode” (*).  Also, it is not clear to me that using SQL as the underlying model will work well for all applications.  But that is exactly what we need to discuss in more detail!

The question right now is what should be written up in the charter.  Unless there is a potential for a WG lockup that can only be avoided by making a selection at WG chartering time, I generally prefer to have the WG make the decisions based on its ongoing work, instead of guessing these decisions at chartering time based on more incomplete information.

Grüße, Carsten

(*) My mental model at the moment is that a JSONPath expression can be valid or erroneous; application of a valid expression yields a result (which may be empty), but does not raise errors.  That may not be the right model for all applications.

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Aug 2020 15:12:19 -0700

Is there a draft charter?  I don't recall seeing one go by but maybe I
missed it.  If not, I can make a first draft.

On Tue, Aug 11, 2020 at 3:06 PM Carsten Bormann <[email-masked]> wrote:

> For a definition of compatible.  For instance, I would like to learn more
> about actual usage of the “strict mode” (*).  Also, it is not clear to me
> that using SQL as the underlying model will work well for all
> applications.  But that is exactly what we need to discuss in more detail!
>
> The question right now is what should be written up in the charter.
> Unless there is a potential for a WG lockup that can only be avoided by
> making a selection at WG chartering time, I generally prefer to have the WG
> make the decisions based on its ongoing work, instead of guessing these
> decisions at chartering time based on more incomplete information.
>
> Grüße, Carsten
>
> (*) My mental model at the moment is that a JSONPath expression can be
> valid or erroneous; application of a valid expression yields a result
> (which may be empty), but does not raise errors.  That may not be the right
> model for all applications.
>
> --
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Aug 2020 00:20:54 +0200

On 2020-08-12, at 00:12, Tim Bray <[email-masked]> wrote:
> 
> Is there a draft charter?  

Not yet.  I thought we might have a little bit of discussion to find out where the different point of views might be lying.

> I don't recall seeing one go by but maybe I missed it.  If not, I can make a first draft.

That would be great!

Since github organizations are cheap, I created one, with a repository that you could use:

https://github.com/jsonpath-wg/charter

Grüße, Carsten

---

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

Hello,

> (*) My mental model at the moment is that a JSONPath expression can be valid or erroneous; application of a valid expression yields a result (which may be empty), but does not raise errors.  That m…

The  general approach that I've seen several times (including my
Elixir implementation) is that an error is raised when there is a
syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises
an error. Conversely a valid expression applied to a bogus input never
raises an error (e.g. $.foo.bar on "test" evals as []).

Regards,
Davide Bettio.