Subject: Re: [Jsonpath] Merging the drafts

From: Glyn Normington <[email-masked]>
Date: Mon, 07 Dec 2020 11:58:56 +0000

The drafts are now merged at 
https://jsonpath-standard.github.io/internet-draft/. Thanks Carsten for
making this happen and thanks to the reviewers of PR 42.

Is the Working Group happy to adopt this draft as a starting point for
a JSONPath internet draft?

On Thu, 2020-11-26 at 13:33 -0800, Tim Bray wrote:
> On behalf of James and myself and everyone really, thanks in advance
> to Carsten and Glyn for getting this pulled together!
> 
> On Thu, Nov 26, 2020 at 12:33 PM Glyn Normington <
> [email-masked]> wrote:
> > Thanks Carsten! I won’t be able to review the PR until Monday. I
> > hope others will have had a chance to make their comments,
> > preferably in the PR, by then.
> > 
> > > On 26 Nov 2020, at 19:45, Carsten Bormann <[email-masked]> wrote:
> > > 
> > > On 2020-11-18, at 12:46, Glyn Normington <
> > [email-masked]> wrote:
> > >> 
> > >> Following on from the Working Group meeting at IETF 109, Carsten
> > and I are working on merging the two existing drafts. The goal is
> > to create a merged document that the Working Group will hopefully
> > decide to adopt as a starting point.
> > > 
> > > My first PR in Glyn’s repo:
> > > 
> > > https://github.com/jsonpath-standard/internet-draft/pull/42
> > > 
> > > (How could it be anything but 42.)
> > > 
> > > I didn’t touch the actual text of the normington draft very much,
> > so I plan to put in another round cleaning up the remaining
> > redundancies and moving things around when we’ve seen some feedback
> > on this round.
> > > 
> > > Grüße, Carsten
> > > 
> >

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Dec 2020 13:09:27 +0100

Note that there is some editorial work (consistency) needed to complete the merger, but the shape of the merged document should now be clearly visible as a basis for an adoption call.

(I plan to go ahead on suggesting some of this editorial work while we have the adoption discussion; I hope this shortcut does not create any confusion.)

Please also note an interesting spin-off from PR 42:
https://github.com/jsonpath-standard/internet-draft/issues/44

We will need to develop a position as a WG how we want to handle the overlap between JSON Pointer (RFC 6901) and JSONPath, and how we might want to maybe even use JSON Pointer in JSONPath.

(Again, this technical discussion does not need to resolve before WG adoption of the merged draft.)

Grüße, Carsten

---

From: James <[email-masked]>
Date: Mon, 7 Dec 2020 13:11:40 +0100

Hi Glyn,

Thank you (and to Carsten) for doing the work merging the documents.

It's my understanding for us to start the call for adoption the draft 
should be submitted to datatracker as a individual draft (so keeping its 
current name of draft-normington-jsonpath-00). Once that is done, Tim 
and myself can put the call for adoption out, and provided there is 
consensus adopt it as such.

- J

---

From: Michael Kay <[email-masked]>
Date: Mon, 7 Dec 2020 13:02:30 +0000

I note in section 2 of the "merged draft" there are a number of examples of positional predicates such as

//book[3]	$..book[2]	the third book
In XPath, //book3 selects every book that is the third child of its parent, whereas (//book)[3] selects the third book in the document. (With this simple input document, of course, there is no difference in the result). I wasn't able to determine from the draft spec which of these meanings $..book[2] has, and whether the other meaning is also expressible.

Note that the difference between these two expressions in XPath often trips people up, and that the relative precedence of "//" and "[]" is possibly counter-intuitive.

Michael Kay
Saxonica

> On 7 Dec 2020, at 11:58, Glyn Normington <[email-masked]> wrote:
> 
> -- 
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Glyn Normington <[email-masked]>
Date: Mon, 07 Dec 2020 13:36:30 +0000

On Mon, 2020-12-07 at 13:02 +0000, Michael Kay wrote:
> I note in section 2 of the "merged draft" there are a number of
> examples of positional predicates such as
> 
> In XPath, //book3 selects every book that is the third child of its
> parent, whereas (//book)[3] selects the third book in the document.
> (With this simple input document, of course, there is no difference
> in the result). I wasn't able to determine from the draft spec which
> of these meanings $..book[2] has, and whether the other meaning is
> also expressible.

A general comment is that the merged draft doesn't have any details of
the semantics of .. because I tried to stick to a very small and non-
contentious subset of JSONPath to bootstrap the process of writing a
precise spec. This will need to be added in due course, along with
filters, etc.

But to your point, $..book[2] picks all descendents of the input JSON
value and then applies the selector book[2] to them. So it will select
the third item of each array which is a member of an object with key
"book". I hope that's clear.

> 
> Note that the difference between these two expressions in XPath often
> trips people up, and that the relative precedence of "//" and "[]" is
> possibly counter-intuitive.
> 
> Michael Kay
> Saxonica
> 
>

---

From: Michael Kay <[email-masked]>
Date: Mon, 7 Dec 2020 13:51:11 +0000

> "book". I hope that's clear.

Certainly, if the spec makes it clear which it means, that's fine.

Even better would be to get the usability right: judging by XPath experience, many people will get this wrong, and assume that it selects the second book in the document.

But your explanation makes me realise that there's a bigger difference here beween XPath and JSONPath - in XPath, whether it's //book[3] or (//book)[3], it selects an element named book, whereas in JSON it selects a member of an array "named" book (which in practice would probably be named "books").

Which means that the JSONPath equivalent to //book is not ..book, it is ..book[*].

I wonder if the analogies between XPath and JSONPath are going to be helpful, or whether they're actually dangerous by implying equivalences between constructs that are in fact somewhat different?

Michael Kay
Saxonica

---

From: Glyn Normington <[email-masked]>
Date: Mon, 07 Dec 2020 14:09:46 +0000

On Mon, 2020-12-07 at 13:51 +0000, Michael Kay wrote:
> > value and then applies the selector book[2] to them. So it will 

Oops. That should have been .book[2].

> > select
> Even better would be to get the usability right: judging by XPath
> experience, many people will get this wrong, and assume that it
> selects the second book in the document.
> 
> But your explanation makes me realise that there's a bigger
> difference here beween XPath and JSONPath - in XPath, whether it's
> //book[3] or (//book)[3], it selects an element named book, whereas
> in JSON it selects a member of an array "named" book (which in
> practice would probably be named "books").
> 
> I wonder if the analogies between XPath and JSONPath are going to be
> helpful, or whether they're actually dangerous by implying
> equivalences between constructs that are in fact somewhat different?

I tend to agree. Although JSONPath was inspired by XPath, I wouldn't
want to confuse the JSONPath spec by going into detailed comparisons at
the risk of contradicting the normative text.

---

From: Glyn Normington <[email-masked]>
Date: Mon, 07 Dec 2020 14:18:13 +0000

> consensus adopt it as such.

Done. https://datatracker.ietf.org/doc/draft-normington-jsonpath/

---

From: Tim Bray <[email-masked]>
Date: Mon, 7 Dec 2020 08:40:38 -0800

Thanks for the work, folks!