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

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 08:20:06 +0100

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.
Surprising and error prone conversions should be avoided, though.

Grüße, Carsten

---

From: Glyn Normington <[email-masked]>
Date: Tue, 9 Mar 2021 07:34:13 +0000

On 09/03/2021 07:20, Carsten Bormann wrote:
> the expression language is used both in index expressions [()]

Is there a compelling use case for index expressions which could not be 
supported by other means? (If not, we could drop them.)

---

From: Greg Dennis <[email-masked]>
Date: Tue, 9 Mar 2021 07:40:38 +0000 (UTC)

Carsten, I think you've made a good summary of the problem space.  Thank you.
Glyn, both Stefan and I have shown examples where the index expression could be valuable.  You've suggested that we drop them in other places, and my response is the same as I've described in the GitHub issues: just because their usage may be less frequent doesn't mean that the syntax is useless.  I can guarantee that if we drop it, users will complain.
Greg

-- 
Jsonpath mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Glyn Normington <[email-masked]>
Date: Tue, 9 Mar 2021 08:45:22 +0000

I'm afraid I simply don't remember a compelling use case for index 
expressions which could not be supported by other means. It would also 
be helpful to include a compelling use case in the spec to motivate the 
feature.

So please could someone oblige me by picking what they think is the most 
compelling use case? A link to a GitHub issue would be fine too. In 
https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/57, 
the consensus appeared to be going against index expressions, but then 
the discussion veered away apparently without reference to a specific 
use case.

On Tue, 9 Mar 2021, 07:40 Greg Dennis, <[email-masked] 
<mailto:[email-masked]>> wrote:

    Carsten, I think you've made a good summary of the problem space.
    Thank you.

    Glyn, both Stefan and I have shown examples where the index
    expression could be valuable.  You've suggested that we drop them in
    other places, and my response is the same as I've described in the
    GitHub issues: just because their usage may be less frequent doesn't
    mean that the syntax is useless.  I can guarantee that if we drop
    it, users will complain.

    Greg

        On Tue, 9 Mar 2021 at 8:34 pm, Glyn Normington
        <[email-masked]
        <mailto:[email-masked]>> wrote:
         > the expression language is used both in index expressions [()]

        Is there a compelling use case for index expressions which could
        not be
        supported by other means? (If not, we could drop them.)

        -- 
        Jsonpath mailing list
        [email-masked] <mailto:[email-masked]>
        https://www.ietf.org/mailman/listinfo/jsonpath
        <https://www.ietf.org/mailman/listinfo/jsonpath>

---

From: Greg Dennis <[email-masked]>
Date: Tue, 9 Mar 2021 09:03:19 +0000 (UTC)

In https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/57, Stefan highlights several use cases where the index to be selected could be contained within the data itself.  I'd be interested in knowing how to achieve this with the filter expression or any other mechanism we've previously discussed.
Further, I've given an explicit example in https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/17#issuecomment-701892056

  On Tue, 9 Mar 2021 at 9:45 pm, Glyn Normington<[email-masked]> wrote:   -- 
Jsonpath mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 10:18:01 +0100

Who provides the cheapest flight from London to Berlin?
(Maybe too hard for JSONpath, though.)

Grüße, Carsten

> On 2021-03-09, at 10:03, Greg Dennis <gregsdennis=[email-masked]> wrote:
> 
> On Tue, 9 Mar 2021 at 9:45 pm, Glyn Normington
> <[email-masked]> wrote:
> -- 
> Jsonpath mailing list
> [email-masked]

---

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

hmm .. in ...

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/57

I presented a single use case using root selector '$' by referencing 
data in the same JSON document. I named it 'level of indirection'.

Regarding practical use cases of the current element selector '@' there 
seems to be a general cluelessness (apart from that '@.length' thing).

So let's focus on filter expressions first and and possibly include 
index expressions (good terms here) together with union stuff at a later 
time or exclude them completely.

Am 09.03.2021 um 10:03 schrieb Greg Dennis:
> In 
> Stefan highlights several use cases where the index to be selected 
> could be contained within the data itself.  I'd be interested in 
> knowing how to achieve this with the filter expression or any other 
> mechanism we've previously discussed.
>
> Further, I've given an explicit example in 
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/17
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virenfrei. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>