Re: [Jsonpath] The draft: ambiguous language

[Carsten Bormann <[e-mail]>]

On 2020-12-10, at 17:58, Daniel P <[e-mail]> wrote:
> 
>> 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.

The processing model obviously needs to be written up.

I left off https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00#section-3 from the merge proposal, maybe I should have left it in as a quarry.

This says:

   Within a script, @ stands for the position under consideration.

(Where “script” would now be “expression language”.)

Positions are on data items (called JSON values in RFC 8259), not on map entries (called members in RFC 8259, which are not JSON values).

   Position:  A JSON data item identical to or nested within the JSON
      data item to which the query is applied to, expressed either by
      the value of that data item or by providing a JSONPath Output
      Path.

(This could have said “argument” instead of "the JSON data item to which the query is applied to”.)

I didn’t want to spend a lot of time on the processing model until we understand what direction the discussion on the handling of duplicate matches is taking.

Grüße, Carsten