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

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 <cabo@tzi.org> wrote:

> On 2020-12-08, at 20:46, Daniel P <danielaparker@gmail.com> wrote:
> >
> > 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?
>
> No.  This should break with a loud bang.
>
> > I can see
> > returning
> > "no results" if an otherwise valid expression cannot be evaluated
> against the
> > provided JSON instance, which many implementations do.
>
> 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
> Jsonpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>