Re: [Jsonpath] The draft: ambiguous language

[Daniel P <[e-mail]>]

On Mon, Dec 7, 2020 at 11:00 PM Glyn Normington
<[e-mail]> wrote:
> On Mon, 2020-12-07 at 20:49 -0500, Daniel P wrote:
> > >
> > Related to that, it would be helpful to determine if JSONPath filters
> > apply to both JSON objects and arrays, or only to JSON arrays. Our
> > excellent Burgmer JSONPath comparison has that covered
> >
> > https://cburgmer.github.io/json-path-comparison/results/filter_expression_on_object.html
> >
> > and there is no consensus.
>
> I would support restricting filters to arrays, if others agree.

I've created an issue for this at
https://github.com/jsonpath-standard/internet-draft/issues/47.
>
> > For JSON objects, it's less clear, but perhaps
> >
> > In a filter expression evaluated against a JSON object, the object
> > itself is represented by the symbol @.
>
> Regardless of the current consensus, or lack of one, I find this
> confusing since @ does not correspond to the current item (meaning an
> individual member of the object). It's also unhelpful in deciding which
> items to filter in/out.
>
When an undefined term like "current item" occurs in a spec, some
readers (such as this one) may draw a complete blank, while others
may form an intuitive notion of what that means. But while
"an individual member of the object" may seem intuitive,
_none_ of the implementations in JSONPath Comparison support
that notion, in fact that would require notation like @.key and @.value,
which none support.

Daniel