Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2

From: Glyn Normington <[email-masked]>
Date: Tue, 8 Dec 2020 09:31:47 +0000

Did anyone else have an opinion on the behaviour of slices such as [::0]?
The current draft allows this and says it returns an empty array, but there
is good reason to say it should error so that the slice operation is then
consistent with Python slicing. See below for more context.

On Thu, 26 Nov 2020 at 10:22, Glyn Normington <
[email-masked]> wrote:

> On 26 Nov 2020, at 09:49, Glyn Normington <[email-masked]>
> wrote:
>
>
> (3) "When step is 0, no elements are selected. This is the one case
> which differs from the behaviour of Python, which raises an error in
> this case." p. 10
>
> Is there a rationale for that choice? As you note, in Python it is an
> error. In JMESPath it is also an error, see
> https://jmespath.org/specification.html#slices.
>
>
> The rationale is the supposed consensus of implementations.
>
>
> Unless I've missed it, Christoph Burgmer doesn't have a test case for
> a slice where step is zero. Perhaps we can prevail upon him to add
> one.
>
>
> I will add that test.
>
>
> It turns out there is such a test already, but no consensus:
>
>
> https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html
>
> Maybe raising an error to be consistent with Python would be a good move.
> What do others think?
>
>

---

From: Michael Kay <[email-masked]>
Date: Tue, 8 Dec 2020 10:29:18 +0000

My advice based on experience of XPath design mistakes would be: decide your policy on errors and then apply it consistently. Either try and minimise errors by making all meaningless constructs exhibit some kind of fallback behaviour, or maximise errors by making all meaningless constructs fail, but don't do it different ways for different errors.

On the whole I think JSONPath is designed to be "forgiving", i.e. such things aren't errors, e.g. I think I read in the spec that filtering a non-array isn't an error, it's some kind of no-op. That approach isn't always best for everyone, but it's important to be consistent.

Michael Kay
Saxonica 

> On 8 Dec 2020, at 09:31, Glyn Normington <[email-masked]> wrote:
> 
> Did anyone else have an opinion on the behaviour of slices such as [::0]? The current draft allows this and says it returns an empty array, but there is good reason to say it should error so that the slice operation is then consistent with Python slicing. See below for more context.
> 
> On Thu, 26 Nov 2020 at 10:22, Glyn Normington <[email-masked] <mailto:[email-masked]>> wrote:
> On 26 Nov 2020, at 09:49, Glyn Normington <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> https://jmespath.org/specification.html#slices <https://jmespath.org/specification.html#slices>.
>> 
> https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html <https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html>
> 
> Maybe raising an error to be consistent with Python would be a good move. What do others think?
> 
> -- 
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Glyn Normington <[email-masked]>
Date: Tue, 08 Dec 2020 10:33:28 +0000

On Tue, 2020-12-08 at 10:29 +0000, Michael Kay wrote:
> My advice based on experience of XPath design mistakes would be:
> decide your policy on errors and then apply it consistently. Either
> try and minimise errors by making all meaningless constructs exhibit
> some kind of fallback behaviour, or maximise errors by making all
> meaningless constructs fail, but don't do it different ways for
> different errors.
> 
> On the whole I think JSONPath is designed to be "forgiving", i.e.
> such things aren't errors, e.g. I think I read in the spec that
> filtering a non-array isn't an error, it's some kind of no-op. That
> approach isn't always best for everyone, but it's important to be
> consistent.

That's an excellent point and a good reason for keeping the status quo.

> > Did anyone else have an opinion on the behaviour of slices such as
> > [::0]? The current draft allows this and says it returns an empty
> > array, but there is good reason to say it should error so that the
> > slice operation is then consistent with Python slicing. See below
> > for more context.
> > 
> > > On 26 Nov 2020, at 09:49, Glyn Normington <

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Dec 2020 12:56:09 +0100

On 2020-12-08, at 11:29, Michael Kay <[email-masked]> wrote:
> 
> decide your policy on errors and then apply it consistently.

Good advice.

I would expect one component of this policy to be:

Whether a JSONPath query is valid or not does not depend on the arguments it is applied to.

I.e., you can look at the query and find out independently, without knowing any data, whether it is valid or not.

(Clearly, a query language could have an “assertion” system where it returns a special kind of failure for certain input data.  I don’t think that is anticipated in JSONPath.  Also, a query might “fail” in the sense of returning no output; that query is still a valid query.)

Grüße, Carsten

---

From: Michael Kay <[email-masked]>
Date: Tue, 8 Dec 2020 12:02:11 +0000

> I.e., you can look at the query and find out independently, without knowing any data, whether it is valid or not.

I think you're saying there that static errors are OK, dynamic errors are not.

That's roughly what XPath 1.0 did: there were very few dynamic errors possible in XPath 1.0. (About the only one I can think of is that count() applied to anything other than a node-set gave an error: which is rather paradoxical since XPath 2.0, despite introducing much stronger type checking, made count("x") return 1 rather than an error).

Michael Kay
Saxonica

---

From: Daniel P <[email-masked]>
Date: Tue, 8 Dec 2020 14:46:55 -0500

What about

result = search(json_instance, "#$@&%*! is that?");

If a JSONPath expression can't be parsed according to syntactical rules, would
"some kind of fallback behaviour" ever be helpful to a user? I can see
returning
"no results" if an otherwise valid expression cannot be evaluated against the
provided JSON instance, which many implementations do.

Daniel

On Tue, Dec 8, 2020 at 5:29 AM Michael Kay <[email-masked]> wrote:
> On Thu, 26 Nov 2020 at 10:22, Glyn Normington <[email-masked]> wrote:
>>
>> On 26 Nov 2020, at 09:49, Glyn Normington <[email-masked]> wrote:
>>
>>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Dec 2020 22:09:07 +0100

On 2020-12-08, at 20:46, Daniel P <[email-masked]> wrote:
> "some kind of fallback behaviour" ever be helpful to a user?

No.  This should break with a loud bang.

> I can see

That is what I meant, a query expression should be valid or invalid, but that should not depend on what argument you are using that against.

An implementation should never silently accept a query expression it has found invalid.  (Importantly, I didn’t say it needs to implement every single validity test, just that it should break violently when one of those fails that it does implement.)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Tue, 8 Dec 2020 13:35:28 -0800

I agree with Carmen.  One of the big problems we had at AWS is that
JSONPaths could be provided as arguments to our APIs and we really wanted
to give a helpful error if they were syntactically malformed and also if
they obviously could never produce a useful result.  The first was possible
(although we didn't do a very good job).  If Glyn's code (maybe it already
does?) included a JSONPath syntax checker and linter, that would be super
useful to the community.

On Tue, Dec 8, 2020 at 1:09 PM Carsten Bormann <[email-masked]> wrote:

> That is what I meant, a query expression should be valid or invalid, but
> that should not depend on what argument you are using that against.
>
> An implementation should never silently accept a query expression it has
> found invalid.  (Importantly, I didn’t say it needs to implement every
> single validity test, just that it should break violently when one of those
> fails that it does implement.)
>
> Grüße, Carsten
>
> --
> Jsonpath mailing list
> [email-masked]

---

From: Glyn Normington <[email-masked]>
Date: Wed, 09 Dec 2020 03:36:15 +0000

On Tue, 2020-12-08 at 13:35 -0800, Tim Bray wrote:
> JSONPaths could be provided as arguments to our APIs and we really
> wanted to give a helpful error if they were syntactically malformed
> and also if they obviously could never produce a useful result.  The
> first was possible (although we didn't do a very good job).  If
> Glyn's code (maybe it already does?) included a JSONPath syntax
> checker and linter, that would be super useful to the community.

The goals of my reference implementation ([1]) are to implement the
spec and pass the compliance test suite ([2]). To that end, it uses a
Parsing Expression Grammar that fairly closely matches the ABNF in the
spec. So it certainly does syntax checking and error reporting, but
it's far from being a linter as it won't complain about poor style
which is syntactically valid and it won't suggest better ways of
writing a JSONPath.

So, there's a gap in the market for a linter which I do not intend to
fill. Any takers?

[1] 
https://github.com/jsonpath-standard/jsonpath-reference-implementation

[2] Currently at 
https://github.com/jsonpath-standard/jsonpath-reference-implementation/blob/main/tests/cts.json
, although this will move to its own repository in due course

> > That is what I meant, a query expression should be valid or
> > invalid, but that should not depend on what argument you are using
> > that against.
> > 
> > An implementation should never silently accept a query expression
> > it has found invalid.  (Importantly, I didn’t say it needs to
> > implement every single validity test, just that it should break
> > violently when one of those fails that it does implement.)
> > 
> > Grüße, Carsten
> >

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Dec 2020 06:39:24 +0100

On 2020-12-09, at 04:36, Glyn Normington <[email-masked]> wrote:
> 
> Parsing Expression Grammar that fairly closely matches the ABNF

Interesting.  Because I’m lazy (and I want to make sure the ABNF is right), I generally use a PEG parser that is generated right out of the ABNF.

E.g.,
https://github.com/cabo/cddlc/blob/master/lib/parser/cddl.abnftt

(The abnftt gem generates code from the augmented ABNF, but also generates a clean ABNF file that can be diffed against the ABNF from the RFC.  See https://github.com/cabo/cddlc/blob/master/Rakefile .)

Obviously, using ABNF with PEG semantics requires some care when setting up the ABNF (don’t let prioritized choice get in your way).

Grüße, Carsten