Subject: [Jsonpath] Fwd: Expression language -- index expressions and filter expressions

From: Stefan Gössner <[email-masked]>
Date: Tue, 9 Mar 2021 18:51:22 +0100

... this is a good summery ...

Am 09.03.2021 um 08:20 schrieb Carsten Bormann:
> I think what we have so far is:
>
> — there needs to be an expression language that is independent from specific implementations and their implementation languages.
> — the expression language is used both in index expressions [()] and filter expressions [?()].
>
> Obviously, in index expressions we need the expression to return an index value (integer, string), while in filter expressions we need a Boolean value.
> Also, in index expressions, the implicit parameter @ is the item to be indexed (the item to which the [()] is applied), while in filter expressions, @ is the item to be filtered (one of the items in the container to which the [?()] is applied).
>
> We have a dial we can turn how conversion-happy the expression language should be.
> E.g., the conversion from the filter expression result to a Boolean can use a big set of “falsy” values (false, 0, “”, [], {}) or be more restrictive in what it accepts.
> Similarly, the conversion from the index expression result to the array index or map key (JSON object member name) could be loose (e.g., converting numbers into strings) or more strict.
>
> Generally, both kinds of expressions won’t know statically to which kind of container (array, JSON object) they are applied.
> It should be possible to write expressions that can operate with both kinds.

... human JSONPath text writers usually know, what they want to address by '$..[3]' or '$..['name']' ...
but during selection process, it will be applied to both types of containers in the loose case. I vote rather
for the strict case with not converting to '$..['3']' and '$..[int('name')]'.

---

From: Stefan Gössner <[email-masked]>
Date: Tue, 9 Mar 2021 19:17:45 +0100

... strict case should also result in better runtime performance ...