Subject: Re: [Jsonpath] Some Comments ...

From: Daniel P <[email-masked]>
Date: Sat, 27 Feb 2021 09:16:24 -0500

> From: "Stefan Gössner" <[email-masked]>

> I copied these comments forward to Github ... for better reading and further commenting.
>
> https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/54
>
> I would also like to try out that cool Github discussion tab, Daniel wrote about.
>

I took the liberty of making a request to enable discussions for the
repository. Once enabled, it will show up as an option under
Settings/Features, and whoever's administering the site can check it,
which will make the tab visible.

Daniel

---

From: Daniel P <[email-masked]>
Date: Sat, 27 Feb 2021 16:59:45 -0500

> Am 26.02.2021 um 19:30 schrieb Stefan Gössner:
>
> I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'`
> addresses > the array itself and implies that array has a `length`
> property. In filter expression examples `'@'` more consistently addresses
the
> current array element.

For a contrary opinion, I think it's a good thing that there's a precedent
to regard the current element within the square brackets notation, when it
isn't a filter expression [?()], as the array or object itself.
Admittedly, not much would be lost if the original @.length example,
supported by about a dozen implementations in Burgmer's comparisons, were
not permitted. But there are other possible uses.

A JSONPath question that arises from time to time is whether it is possible
to
have a JSONPath union of multiple different paths, for example, see
https://stackoverflow.com/questions/55497833/jsonpath-union-of-multiple-different-paths/55505099#55505099.
A handful of JSONPath implementations support a limited form of that by
allowing dots between literals inside the bracket notation, and at least
one implementation (possibly a minority of one) supports full path
expressions with notation like

$..['name',@.address.city]

That particular implementation finds that that feature gets used a lot,
judging from feedback.

For comparison, in JMESPath, a loosely comparable (only loosely) construct
to a JSONPath union is a MultiSelect List. Each expression in a MultiSelect
List [expr-1,expr-2,...,expr-n] is evaluated against the "current node",
which in this context is the array or object itself. On the other hand,
within a JMESPath filter expression [? expression], the "current node" is
the current array element, as it is in JSONPath filters.

Daniel

---

From: Daniel P <[email-masked]>
Date: Sun, 28 Feb 2021 15:47:51 -0500

Am 26.02.2021 um 19:30 schrieb Stefan Gössner:
> addresses the array itself and implies that array has a `length`
> property. In filter expression examples `'@'` more consistently addresses the
> current array element.
>
If I may be permitted to make a second comment on this point.

I don't see any confusion or difficulty. "@" does not represent the "current
array element", it simply represents the current item, whatever that may
happen to be.  Given an "?", the processing model requires an iteration
over the elements of the then current item (the array); the
expression following the "?" is evaluated with each of those elements,
and an "@" appearing in that expression is substituted for with those
elements.

But given "[(", no iteration is implied, hence no change to the current
item.

Daniel