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

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 <mike@saxonica.com> 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.
>
> Michael Kay
> Saxonica
>
> On 8 Dec 2020, at 09:31, Glyn Normington <glyn.normington.work@gmail.com> 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 <glyn.normington.work@gmail.com> wrote:
>>
>> On 26 Nov 2020, at 09:49, Glyn Normington <glyn.normington.work@gmail.com> 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?
>>
> --
> Jsonpath mailing list
> Jsonpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath
>
>