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

From: Glyn Normington <[email-masked]>
Date: Fri, 17 Jul 2020 10:56:20 +0000

Several authors and maintainers of JSONPath implementations, including myself, started to gather in June this year to collaborate on an Internet Draft for JSONPath, so I am delighted to see the post below.

Our approach so far has been informed by Christoph Bergmer's JSONPath implementation comparison project ([1]) and its computed consensus. We are working in the open in a GitHub repository ([2]). See the latest pull request text ([3]) to get an idea of our approach. We also have a slack workspace which anyone is welcome to join ([4]).

I look forward to a suitable WG being established so that we can collaborate together.

Regards,
Glyn

[1] https://cburgmer.github.io/json-path-comparison/
[2] https://github.com/jsonpath-standard/internet-draft
[3] https://glyn.github.io/internet-draft/
[4] https://join.slack.com/t/jsonpath-standard/shared_invite/zt-fp521hp0-D7gmDcmOMK4UkrRRug~SQQ

---
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.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

Grüße, Carsten

> Begin forwarded message:
>
> From: [email-masked]<mailto:[email-masked]>
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan Gössner" <[email-masked]<mailto:[email-masked]>>de>, "Stefan Gossner" <[email-masked]<mailto:[email-masked]>>de>, "Carsten Bormann" <[email-masked]<mailto:[email-masked]>>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
>
> Name: draft-goessner-dispatch-jsonpath
> Revision: 00
> Title: JSONPath -- XPath for JSON
> Document date: 2020-07-12
> Group: Individual Submission
> Pages: 14
> URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath
>
>
> Abstract:
>   insert abstract here
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
>

---

From: Davide Bettio <[email-masked]>
Date: Tue, 21 Jul 2020 17:17:00 +0200

Hello,

I am the author of a JSONPath implementation [0], and I am
participating in the community effort [1] that Glyn mentioned.

I really appreciate the clarity of Gössner's article [2] (and that was
really useful in understanding JSONPath), however it quickly turned
into a nightmare when I started to work on an implementation,
therefore I would  love to raise some points that I believe they
should be properly addressed.

1. There are > 35 implementations out there that are used by a huge
number of users (e.g. Kubernetes, Oracle Database, etc...). A standard
should take account of this and it should be as compatible as possible
with them, otherwise we would get a standard with no users. Moreover
there is a lot of fragmentation, so a consensus oriented approach
should be taken [3].

2. Most implementations are supersets of Gössner's original article,
e.g. `key` instead of `$.key` is widely accepted (even by Gössner's
implementations), but it is not part of the original article. In my
opinion, I think we should support them since they are de facto
supported [4].

3. Gössner's article lacks a lot of detail useful for an unambiguous
specification, for instance the following are some of the unspecified
points:

a) negative subscript operator indices are widely supported but there
is no explicit mention for them in Gössner's article

b) negative integers in slice operator are not explicitly mentioned

c) there is no specification for valid dot notation identifiers,
therefore some implementations accept `$.foo-bar`, while others do not
(same
thing for `$.65`, `$.42foo`, $.屬性, `$.-foo` or `$.foo-`).

d) It is not clear if `$` is a valid path or not.

e) It is not clear how to handle `$.foo[010]`.

There are many other similar open issues.

4. There is a huge lack of information about supported filtering
boolean expressions. e.g. which of the following is supported:
`$.store.book[?(@.price < 10)].title`, `$.store.book[?(@.price <
@.foo)].title`,  `$.store.book[?(@.price / 10 < @.foo)].title`? Are
regexps supported? etc...

5. Gössner's article mentions support for scripting, however this
feature might be bad from a security point of view, it is not portable
across different implementations and there isn't any set of minimum
supported features. Furthermore `$[(@.length-1)]` is required if
`$.foo[-1]` is not accepted as a valid path. (Opinion: I believe that
only a limited set of scripting expressions, such as length, should be
supported for backward compatibility).

6. Opinion: I think that any JSONPath implementation should also
support JSONPointer, since it is trivial to implement.

At our company (Ispirata) we are writing software that allows users to
use JSONPath in their data processing pipelines, therefore long term
stability is a fundamental requirement for us.
I think that with a reasonable amount of work it will be possible to
write a standard that takes in account existing implementations, and I
would like to be involved in the discussion / review / writing.

Regards,
Davide Bettio.

[0]: https://github.com/ispirata/exjsonpath
[1]: https://github.com/jsonpath-standard/internet-draft
[2]: https://goessner.net/articles/JsonPath/
[3]: https://cburgmer.github.io/json-path-comparison/
[4]: https://cburgmer.github.io/json-path-comparison/results/dot_notation_without_root.html

Il giorno ven 17 lug 2020 alle ore 18:19 Glyn Normington
<[email-masked]> ha scritto:
> > From: [email-masked]
> > To: "Stefan Gössner" <[email-masked]>de>, "Stefan Gossner" <[email-masked]>de>, "Carsten Bormann" <[email-masked]>
> >
> >
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch