Re: [Jsonpath] June interim meeting

[Carsten Bormann <[e-mail]>]

On 2021-06-14, at 14:39, Greg Dennis <gregsdennis=[e-mail]> wrote:
> 
> #97 has been rebased.

Thank you.  Please see my recent comment.

> Carsten, would you explain your understanding of the difference between string in JSON and strings in JSONPath, please?  

This is best explained in my draft slides, https://github.com/ietf-wg-jsonpath/slides-wip/blob/main/2021-06-15-jsonpath-cabo.pdf

> Isn't JSONPath built on JSON?  Wouldn't that necessitate the same definition?  

That is getting to the core of the issue.
The definitions in RFC 8259 (actually, there is no formal definitions section there) cannot be used without additional salting, as they do not distinguish between the data and the notation.
JSONPath does not operate on JSON notation (“JSON text” in RFC 8259), but on JSON data.
So we have to do the work RFC 8259 didn’t.

> You've been rather aggressive

s/aggressive/terse/

> with comments on strings, but you haven't offered any alternatives or reasons for your objections.  You've simply stated that what Stefan and I have written is wrong.  (I've tried to follow from your "slides," but they seem more like fragmented notes: reminders of talking points for you.  There's not really much reasoning to follow in there.)

OK, so maybe we do need to discuss this online tomorrow.

> My primary objection to the use of "literals" (and why I used "values" instead) is that we discussed and agreed using "values" in the previous meeting.  

Of course, because we do need the values (I wanted to be more explicit here, but we arrived at using the RFC 8259 terms here).
We also need the notation for the values, and a common word for that has been “literal” (see ECMA-262 for many examples).

> We never discussed the word "literal."  If this is the direction you'd like us to go, that's fine, but we need to discuss it first.  Instead, you've both proposed it and urgently pushed for it on both of the major change sets.

I think we have a different perception of how common this term is, so that may explain our different perception of how necessary a discussion of this term is.
It sure was good enough for ECMA-262.

Grüße, Carsten