Subject: Re: [Jsonpath] draft-goessner-dispatch-jsonpath-00.txt

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Sep 2020 18:39:00 +0200

On 2020-07-14, at 07:14, Carsten Bormann <[email-masked]> wrote:
> 
> I would like to initiate discussion for draft-goessner-dispatch-jsonpath:
> 
> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html
> 
> It says:
> 
>> This document picks up the popular JSONPath specification dated
>> 2007-02-21 and provides a more normative definition for it.
>> It is intended as a submission to the IETF DISPATCH WG, in order to
>> find the right way to complete standardization of this specification.
>> In its current state, it is a strawman document showing what needs to
>> be covered.

The result of the discussion at IETF108 was:

> Carsten Bormann presented [JSON Path](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/). There is considerable interest in the work, and people think this might be a good candidate for a focused working group. Carsten will propose charter text to be discussed on the list. (Some discussion might occur on a separate JSON Path list, but the charter discussion will eventually come back to DISPATCH)

We now have had the discussion about a proposed charter over at the JSON Path list, and the resulting proposed charter, based on an initial proposal by Tim Bray, is at:

https://github.com/jsonpath-wg/charter/blob/master/charter.txt

I have set a reply-to to [email-masked].  The IETF mailman recently has been ignoring that, so here’s the manual version: Please keep the discussion that is relevant to the dispatch process on the dispatch list (and keep spinoff threads that are not really relevant to that to the JSONPath list).

Grüße, Carsten

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Sep 2020 17:02:19 -0700

On Sun, Sep 13, 2020 at 9:39 AM Carsten Bormann <[email-masked]> wrote:

> We now have had the discussion about a proposed charter over at the JSON
> Path list, and the resulting proposed charter, based on an initial proposal
> by Tim Bray, is at:
>
> I have set a reply-to to [email-masked].  The IETF mailman recently
> has been ignoring that, so here’s the manual version: Please keep the
> discussion that is relevant to the dispatch process on the dispatch list
> (and keep spinoff threads that are not really relevant to that to the
> JSONPath list).
>

Unless the DISPATCH community has additional feedback over the next week or
two, I'll take that text and start it on its journey.

-MSK

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Sep 2020 10:20:01 +1000

This seems reasonable. 

As I mentioned in the session, I think there's a non-trivial amount of risk here that some implementations won't be willing or able to move away from their current behaviours, even if interoperability would improve if they did so. However, there are ways to mitigate that (e.g., a separate 'rfcxxxx compliant' mode). Even so, it will be important to get good participation from as many current implementers as possible.

Two nits in the charter text:

1) I don't think it's necessary to compare this effort to JSONPointer; they do different things (querying a document vs. referring to a particular part of a document), just as XPath and XPointer do different things. Each has a place, it's not a matter of compatibility or supplanting JSONPath. So, 'Other, incompatible approaches exist... but have not succeeded in supplanting JSONPath' should be removed.

2) If this charter is predicated on adopting a specific draft, it should be listed (e.g., as we did in <https://datatracker.ietf.org/doc/charter-ietf-quic/01/>).

Cheers,

> On 14 Sep 2020, at 10:02 am, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Unless the DISPATCH community has additional feedback over the next week or two, I'll take that text and start it on its journey.
> 
> -MSK
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham   https://www.mnot.net/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Sep 2020 11:07:32 -0700

On Sun, Sep 13, 2020 at 5:20 PM Mark Nottingham <[email-masked]> wrote:

> 1) I don't think it's necessary to compare this effort to JSONPointer;
> they do different things (querying a document vs. referring to a particular
> part of a document), just as XPath and XPointer do different things. Each
> has a place, it's not a matter of compatibility or supplanting JSONPath.
> So, 'Other, incompatible approaches exist... but have not succeeded in
> supplanting JSONPath' should be removed.
>

I suggested including something like this to head off questions from people
who might wonder why we're standardizing another JSON referencing method
when JSON Pointer wasn't that long ago.  Perhaps:

"This work is similar in concept to JSON Pointer (RFC xxxx) but documents a
mechanism that has broader support yet is in need of formal
standardization."

?

2) If this charter is predicated on adopting a specific draft, it should be
> listed (e.g., as we did in <
> https://datatracker.ietf.org/doc/charter-ietf-quic/01/>).
>

I don't think there is such a draft yet, just the external source
material.  We could say that the intent is to generate a draft from the
text found there.

-MSK

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Sep 2020 16:01:08 +1000

> On 15 Sep 2020, at 4:07 am, Murray S. Kucherawy <[email-masked]> wrote:
> 
> I suggested including something like this to head off questions from people who might wonder why we're standardizing another JSON referencing method when JSON Pointer wasn't that long ago.  Perhaps:
> 
> "This work is similar in concept to JSON Pointer (RFC xxxx) but documents a mechanism that has broader support yet is in need of formal standardization."
> 
> ?

No - it's not similar in concept, they're separate things. If you really wanted to mention JSON Pointer, you could say something like "Note that while JSON Pointer (RFC xxxx) is already standardised, it is designed to provide a reference to a single, specific part of a JSON document, whereas JSONPath provides the ability to query a document and potentially return multiple values."

> I don't think there is such a draft yet, just the external source material.  We could say that the intent is to generate a draft from the text found there.

I see two:
* https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/
* https://jsonpath-standard.github.io/internet-draft/

Cheers,

---

From: Tim Bray <[email-masked]>
Date: Tue, 15 Sep 2020 00:21:04 -0700

Plan B: Don't mention JSONPointer at all. It's not what we want to work on,
and the charter should be about what we want to work on.

On Mon., Sep. 14, 2020, 11:02 p.m. Mark Nottingham, <[email-masked]> wrote:

> > I suggested including something like this to head off questions from
> people who might wonder why we're standardizing another JSON referencing
> method when JSON Pointer wasn't that long ago.  Perhaps:
> >
> > "This work is similar in concept to JSON Pointer (RFC xxxx) but
> documents a mechanism that has broader support yet is in need of formal
> standardization."
> >
> > ?
>
> No - it's not similar in concept, they're separate things. If you really
> wanted to mention JSON Pointer, you could say something like "Note that
> while JSON Pointer (RFC xxxx) is already standardised, it is designed to
> provide a reference to a single, specific part of a JSON document, whereas
> JSONPath provides the ability to query a document and potentially return
> multiple values."
>
>
> > 2) If this charter is predicated on adopting a specific draft, it should
> be listed (e.g., as we did in <
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Sep 2020 00:33:20 -0700

> JSONPath provides the ability to query a document and potentially return

That's fine too.  The reason I suggested this is because the abstract for
JSON Pointer:

   JSON Pointer defines a string syntax for identifying a specific value
   within a JavaScript Object Notation (JSON) document.

...and the one for JSONPath that I remember seeing (which I can't find
at the moment) seemed awfully similar, and I expected questions as a
result, so I thought we might try being proactive.

If consensus is to say nothing, I'll send it up that way instead.

> * https://jsonpath-standard.github.io/internet-draft/

Right you are.  Yes, there should be such a reference.

-MSK