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

Davide Bettio <davide.bettio@ispirata.com> Tue, 21 July 2020 15:17 UTC

Return-Path: <davide.bettio@ispirata.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C093A0A4A for <dispatch@ietfa.amsl.com>; Tue, 21 Jul 2020 08:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ispirata.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2a9ek21UPAA for <dispatch@ietfa.amsl.com>; Tue, 21 Jul 2020 08:17:33 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8FF3A0A3F for <dispatch@ietf.org>; Tue, 21 Jul 2020 08:17:33 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id 22so3217840wmg.1 for <dispatch@ietf.org>; Tue, 21 Jul 2020 08:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispirata.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NkqBT5ddPkOmnmAzL/fvj6t+kj2dQvBSD6gHHsFXMVU=; b=n3tvNVv7nbY6N6LPWVjVbqFCXQ3Tfhom4krEF6NWz7w9GgRkjtHYJirnqa8doda0BN G8ZVTyOppWzLesNJVPgFvAJFkToCo/t8LHI15QZhcA6l06kLKfFuM2bxz8mp0h0I9PPU c3Ke4xl2iW++6fTs/yHTu71eQL9WEIX6dmZ3bffKPMwTEyWFkvVIUwrZsa72mGkuQvh0 WqehkwLghPMItSuPNTnRWYG5tTykvCsiFstNbk+ARa3+LIPHpUzJu+bb/Ni3wMnsirvO SPsT8HSnxPBEEPImWsEe0VHRMjeoBQhYQNJj5AfRhKyUWw8+GOY+H4svY12At3/SCqW+ KhyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NkqBT5ddPkOmnmAzL/fvj6t+kj2dQvBSD6gHHsFXMVU=; b=mPioF8xP36STMo/oP1K5TG6hKRg1KMitq6QjNtZb8q2ThmaMjN5fhVPlMRELmugdsf zhC3BqVrjqYdhRAMb/Nvq7qd2JmhBv0KBP7NriS7tJhntPJu5XQKsuq2VF6M5P4Nr5ro lcLHyxW+l/0Kg1Cr7l5OEji9uspCRX9Iy3/lr2LDyJccAjrFlXYN70O0fNNAb3jJsYWb UG8MDvTsH5h11I77lX5LYfBRjIVHn4vLojJMt3DBwj9jBEGrX/r3Rwlmju9fNGYonk1W kXaNI1+wASyoCAoVsDgft2G0R+XxCBIDSpUJ0kT/geXatfHeS/FbJ6zuSlmahwCQjg+V hQWQ==
X-Gm-Message-State: AOAM531wLsOq2Uv5LpS9sfYFuaQ/dcHaks6ULBxMnkduYZn7/2Y7Fbcx f3qfFqkrOxSXEKA+azsnw1HP1KFL0bWAW8K8CzVr60hsPz30vQ==
X-Google-Smtp-Source: ABdhPJxwTCJhmqqQ+ubyWm9Mwn36mIzkl4le1KmVuvR+FkKgzoyGlqk2e+1/7CH2WWWEeG2YAMCsem4PLXK3Gz/idyg=
X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr4590054wmk.149.1595344651336; Tue, 21 Jul 2020 08:17:31 -0700 (PDT)
MIME-Version: 1.0
References: <C1579620-12ED-4BC0-9B1D-9A2D0AB147F2@vmware.com>
In-Reply-To: <C1579620-12ED-4BC0-9B1D-9A2D0AB147F2@vmware.com>
From: Davide Bettio <davide.bettio@ispirata.com>
Date: Tue, 21 Jul 2020 17:17:00 +0200
Message-ID: <CAAWU5L6aTniVu31EP7QLwXkCuePsw-gfP8vUXk9+8JaTCFeF6w@mail.gmail.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/JERimhIHFnFQBXgivhqlX8rYZwI>
Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 15:17:35 -0000

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
<normingtong@vmware.com> ha scritto:
>
> 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: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> > Date: 2020-07-13 at 22:08:50 CEST
> > To: "Stefan Gössner" <stefan.goessner@fh-dortmund.de>de>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>de>, "Carsten Bormann" <cabo@tzi.org>
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch