From nobody Mon Dec 7 03:59:02 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36163A134F for ; Mon, 7 Dec 2020 03:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 74WJipe_lJif for ; Mon, 7 Dec 2020 03:59:00 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 284653A134E for ; Mon, 7 Dec 2020 03:59:00 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id f23so19110235ejk.2 for ; Mon, 07 Dec 2020 03:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=tGjzeYGW3LJxoenxH6i7jIM7MxuxGm0RlJKxHaEs/YY=; b=soSggiedt5zFtDLLJPrG+tXGTFdXfd9h2oTINX0okeDrYcMS1xd42YfcfBdzIRGhd/ IlmOx2kIa1yWN42sHuaWs7hvF67WRnNuBD35zO+QyS3EzkqFFeVJm2CBVRU8WgKFdtz5 9IbWxhvaix4hj72cUyXqCaTOOds6aHO3infw1J8oglqGIChbGK0TLpqVsMcuOjTAc1IO 3WZOH5s/Qd/ApLrElJLSSUFhHlGDqVIYhNFTuLwa42H9sClEacl1os/TCGYb4nZB2zhe /d3AKqFk3FAsfFfPBl5bSYR5/IaQO858V4f7AnwiobpVtZCCZQLuipSVFUIF/5r90cRS qzoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=tGjzeYGW3LJxoenxH6i7jIM7MxuxGm0RlJKxHaEs/YY=; b=Ub38T2awevsFnNdQMrqCuUyHvQ9LQ3MWw0uBKurO4mxaW/qqSnjTNaZrtlBbNJVQ5J lZ8BoVmlnnSgFPTSC0sFHFG+GJP+2CMxZ3FW4Es8WgIJYYXooqBT9aJIWXtDaHZWv79N ha8DyOyn9thDDTAxPphDrJUp5GjbztCUIpnXibLDyxykv+mhV8xSEvtye8ISHWKBGWsf 4KMIjP0PfmBUTenO4vrnwHi5iq+2qPH9vmO9qVJi9bYec4kxFm7y7ZipNj+DbhSGgRsJ ygp4RRt/JbFtpYCy+Lfgj2GCsRyIGT4Y5/bhMGj3KDLMLaGnIuW7K7+NEjj5PODyNxsU dlsg== X-Gm-Message-State: AOAM533N7gpoSrmR2T+MpC9avvHz/dEglpgNYGbAGkjTKDvNqR9PptyN w03gC1TiUZb6kGQiHTi+w6Y= X-Google-Smtp-Source: ABdhPJwaN+rAjZ78MNiMRukHI+sGsxrL2qN20xZlTVESfGjOPCGcmpuCFzWOtcJJiu6H4bhqXhvQXw== X-Received: by 2002:a17:907:da7:: with SMTP id go39mr12873793ejc.58.1607342338468; Mon, 07 Dec 2020 03:58:58 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id c23sm13322625eds.88.2020.12.07.03.58.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 03:58:57 -0800 (PST) Message-ID: <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> From: Glyn Normington To: Tim Bray Cc: Carsten Bormann , jsonpath@ietf.org Date: Mon, 07 Dec 2020 11:58:56 +0000 In-Reply-To: References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] Merging the drafts X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 11:59:02 -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 < > glyn.normington.work@gmail.com> 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 wrote: > > > > > > On 2020-11-18, at 12:46, Glyn Normington < > > glyn.normington.work@gmail.com> 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 nobody Mon Dec 7 04:09:35 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852DB3A135D for ; Mon, 7 Dec 2020 04:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4VGUWfurVYke for ; Mon, 7 Dec 2020 04:09:30 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34483A135C for ; Mon, 7 Dec 2020 04:09:29 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CqMYg2f14zyVH; Mon, 7 Dec 2020 13:09:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 7 Dec 2020 13:09:27 +0100 X-Mao-Original-Outgoing-Id: 629035766.937441-1355dde1546019d57eb13e503180ea3d Content-Transfer-Encoding: quoted-printable Message-Id: References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> To: jsonpath@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Merging the drafts X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 12:09:34 -0000 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=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 7 04:11:47 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3E3A135E for ; Mon, 7 Dec 2020 04:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i1eBAc2EePCF for ; Mon, 7 Dec 2020 04:11:44 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 D91183A1205 for ; Mon, 7 Dec 2020 04:11:43 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id r5so13412078eda.12 for ; Mon, 07 Dec 2020 04:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=oFiUvBHWmL5sjfIyMFQQT0gLpXvDIwIJutJL5Ik/4ac=; b=izMS1/xqpV3MJ70wZyJZNcpBhLkM9V9kZ30P/6xPKHz+8VAZIPlyuCfAWdFxjqKmac gTMvdZgzkXpFXmJ2n+KHjbu6Q1snNG42VZa//gfjeBTw4BC72t+zZ5UCukUaYQCqKO8V VOmlHweARWNoJ1bWKiZQIIbaEuiWoNZOdnJfnyAX9muJ1BGnh8IELrGyySo5hbWx4YTj DT9fVysH8aWG+TNonADiXjtobjgzhkSlkSmf83tWMAlriIq1afzGOufSac+BfPduWMsz GoDzgX1/bdYYduDfaQIsfA/NA7z0GOukRWrSb/U1oLxXzkpsHmCqMuEreybu8H7/pisy f4Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oFiUvBHWmL5sjfIyMFQQT0gLpXvDIwIJutJL5Ik/4ac=; b=Mwzin6FkOWs19Ya1aKfkPlOl4vNt8lxUJaVPZ/rYyRdcUGoUyThwvy0BZg4qeW6vL9 reklGTdCrr79RbP1NtbaXx975DvJ+udqyYkosGTyaY63zuR7jCMiP0GfrGBqan4DgGIf zsnCb1glAmyI+RCfIZk4krrmZFTUM6nY6sNkYE6CVdEcBFlgSa1XSscit22DSh4YHAg5 ELm4FRa4OtGW167eSZ5nr+w09VFuLa6WsKQCpV0r7t2vvg3jh1UZV3veyLwRNtrnGOd8 +y39nTPkXGGUlIX92yLFcenww6g1lhSNL7pd8ZEhozNC+DuVJnFnDMiLAgYY3I45tC/o ijyw== X-Gm-Message-State: AOAM533vcJv9puqRhjFhTAuhM1S+r6zZpI2WvbYSKOJTo4ektv92X8OW SzRpVdIm4YkvbAtHCcrh5kU= X-Google-Smtp-Source: ABdhPJxbiRi5mgJmu2ikKxWlPUH3m1KPy0iDaU3m+PEHCQoZsgXRGniaCuFttOl1eDdfGGqReph3+g== X-Received: by 2002:a50:c209:: with SMTP id n9mr8540728edf.123.1607343102427; Mon, 07 Dec 2020 04:11:42 -0800 (PST) Received: from ?IPv6:2001:984:65b0:2:1884:f40d:c0f:7982? ([2001:984:65b0:2:1884:f40d:c0f:7982]) by smtp.gmail.com with ESMTPSA id t26sm12017075eji.22.2020.12.07.04.11.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 04:11:41 -0800 (PST) To: Glyn Normington , Tim Bray Cc: jsonpath@ietf.org, Carsten Bormann References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> From: James Message-ID: Date: Mon, 7 Dec 2020 13:11:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-AU Archived-At: Subject: Re: [Jsonpath] Merging the drafts X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 12:11:46 -0000 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 On 07-12-2020 11:58, Glyn Normington wrote: > 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 < >> glyn.normington.work@gmail.com> 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 wrote: >>>> >>>> On 2020-11-18, at 12:46, Glyn Normington < >>> glyn.normington.work@gmail.com> 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 nobody Mon Dec 7 05:02:41 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D13A0CED for ; Mon, 7 Dec 2020 05:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FIE6wXo-Xt0V for ; Mon, 7 Dec 2020 05:02:35 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598623A0CEE for ; Mon, 7 Dec 2020 05:02:34 -0800 (PST) Received: from cpc160115-rdng30-2-0-cust150.15-3.cable.virginm.net ([86.19.35.151] helo=[192.168.0.27]) by smtp04.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from ) id 1kmG9w-000Azy-78; Mon, 07 Dec 2020 13:02:33 +0000 From: Michael Kay Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_29A408FF-D820-4F76-A5A9-4A71F355A9B8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Mon, 7 Dec 2020 13:02:30 +0000 In-Reply-To: <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> Cc: Tim Bray , jsonpath@ietf.org, Carsten Bormann To: Glyn Normington References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> X-Mailer: Apple Mail (2.3445.9.7) X-Mailcore-Auth: 439400257 X-Mailcore-Domain: 1881035 Archived-At: Subject: [Jsonpath] ".." operator X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 13:02:39 -0000 --Apple-Mail=_29A408FF-D820-4F76-A5A9-4A71F355A9B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > The drafts are now merged at=20 > https://jsonpath-standard.github.io/internet-draft/. Thanks Carsten = for > making this happen and thanks to the reviewers of PR 42. >=20 > Is the Working Group happy to adopt this draft as a starting point for > a JSONPath internet draft? >=20 > 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! >>=20 >> On Thu, Nov 26, 2020 at 12:33 PM Glyn Normington < >> glyn.normington.work@gmail.com> wrote: >>> Thanks Carsten! I won=E2=80=99t 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. >>>=20 >>>> On 26 Nov 2020, at 19:45, Carsten Bormann wrote: >>>>=20 >>>> On 2020-11-18, at 12:46, Glyn Normington < >>> glyn.normington.work@gmail.com> wrote: >>>>>=20 >>>>> 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. >>>>=20 >>>> My first PR in Glyn=E2=80=99s repo: >>>>=20 >>>> https://github.com/jsonpath-standard/internet-draft/pull/42 >>>>=20 >>>> (How could it be anything but 42.) >>>>=20 >>>> I didn=E2=80=99t 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=E2=80=99ve seen some = feedback >>> on this round. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>=20 >=20 > --=20 > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath --Apple-Mail=_29A408FF-D820-4F76-A5A9-4A71F355A9B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 <glyn.normington.work@gmail.com> wrote:

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 <
glyn.normington.work@gmail.com> wrote:
Thanks Carsten! I = won=E2=80=99t 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 <cabo@tzi.org> wrote:

On = 2020-11-18, at 12:46, Glyn Normington <
glyn.normington.work@gmail.com> 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=E2=80=99s = repo:

https://github.com/jsonpath-standard/internet-draft/pull/42=

(How could it be anything but 42.)

I didn=E2=80=99t 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=E2=80=99ve seen some feedback
on this round.

Gr=C3=BC=C3=9Fe, Carsten



--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

= --Apple-Mail=_29A408FF-D820-4F76-A5A9-4A71F355A9B8-- From nobody Mon Dec 7 05:04:47 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FD33A15DD; Mon, 7 Dec 2020 05:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3UviOz3FDVVD; Mon, 7 Dec 2020 05:04:36 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614323A1462; Mon, 7 Dec 2020 05:04:27 -0800 (PST) Received: from [192.168.217.120] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CqNn55Bcjzyqc; Mon, 7 Dec 2020 14:04:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 7 Dec 2020 14:04:25 +0100 Cc: Adam Roach , aamelnikov@fastmail.fm, art@ietf.org, "Murray S. Kucherawy" , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 629039065.243829-011a6c29442c8a0a1dd23dffdb832366 Content-Transfer-Encoding: quoted-printable Message-Id: <878DAD1D-3731-42A7-B13E-1A2680381D94@tzi.org> References: <20190604191748.C6BADB82181@rfc-editor.org> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] [art] [Editorial Errata Reported] RFC6901 (5745) X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 13:04:41 -0000 So should this now be processed (as rejected, I presume)? (We are looking at the relationship between JSON Pointer and JSONPath in = the jsonpath WG, and it would be nice to have an errata-free status of = RFC 6901 to work from.) Gr=C3=BC=C3=9Fe, Carsten > On 2019-06-06, at 04:24, Mark Nottingham wrote: >=20 > Sven, >=20 > That section of the specification is specifically about representing = JSON pointers in JSON strings, which does require such escaping. >=20 > Recommend REJECT. >=20 > Cheers, >=20 >> On 5 Jun 2019, at 5:17 am, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC6901, >> "JavaScript Object Notation (JSON) Pointer". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5745 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Sven Willenb=C3=BCcher >>=20 >> Section: 5 >>=20 >> Original Text >> ------------- >> The following JSON strings evaluate to the accompanying values: >>=20 >> "/i\j" 5 >> "/k\"l" 6 >>=20 >> Corrected Text >> -------------- >> The following JSON strings evaluate to the accompanying values: >>=20 >> /i\j 5 >> /k"l 6 >>=20 >> Notes >> ----- >> In JSON itself some special characters like the backslash and the = double quote character can be escaped using a backslash. A similar = escaping was not described for JSON pointers. Therefore it is not clear = to me why such an escaping is needed in JSON pointers too. Maybe the = additional double quotes around the example JSON pointers enforce this. = In the corrected text I have stated my view on this. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC6901 (draft-ietf-appsawg-json-pointer-09) >> -------------------------------------- >> Title : JavaScript Object Notation (JSON) Pointer >> Publication Date : April 2013 >> Author(s) : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed. >> Category : PROPOSED STANDARD >> Source : Applications Area Working Group APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art >=20 >=20 From nobody Mon Dec 7 05:36:37 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8743A139B for ; Mon, 7 Dec 2020 05:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uy7IOJtATf2l for ; Mon, 7 Dec 2020 05:36:34 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 0A8F53A1385 for ; Mon, 7 Dec 2020 05:36:34 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id r5so13692774eda.12 for ; Mon, 07 Dec 2020 05:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=n+LOgFRkgRFdUDai55uAIwkPDucobTgczA2Z/03ZMkg=; b=DcmSMNe5oP5EcGL9VWNIGc2YtgR9fUwbi1276c5r4/efZlEYBtdKC3iPBMtdbDQJPW Q3pdBOgQbt+V9kVeK578YDOjhfb63WwA5fYzMidzi8pCBw6ym4Y0z+VOsqs3wVNKnR6M j5sg30WbRR8LHvMUMFU0LJbrOMFYC+TRp26sJOgf+dibOevrKvq7HKBORYJLDVKyBrEz FBAXY8uaCu4XIsH8AxUeDQY3QdCFw9WJIjfHK9woH7t2hBH7BImOeGl9PIUf6QIVKziV UwwmoHKMZya8Qi2jKZ3kHdI2SfRJHlgtf6Y0eTOb7W8dGhGSWoN0YZ1aeZxVLxlB7RA4 CJ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=n+LOgFRkgRFdUDai55uAIwkPDucobTgczA2Z/03ZMkg=; b=GctcsVZNYnOyst8RfSHhKcyOTaC2UBd762az4YzuKBM90d8QoXu908i15QlH63Levj QgOV3rJ2YaS1wWat4LX1eE4+5L10LRDPVkbyj5tJLNXcrgZl4DKVn6dPlSF79s5R4iuz i9UF7rWKI2ZlTApTXp8MVAUW19QK0BV6tE4UMEt4NXeZcyE+A/XqXUvirmTTsitZf4Wz I6ZBf6ijygmPJ/uZYQQtnrspMmRy8SN2O1V5ZlIHlMWUPJFNpTd8MI83HL+Je3xQAgtP yhp6wtQx/0GU0wi0OfMiJVBgWOyT9VnFGJK9UcUQHGUs+jYWHRPi021VZYv57tA/0hmg y2Bg== X-Gm-Message-State: AOAM530bpzRvluQsj24B1tKeFSaZLD27Nn7o6q4iR6doCaWi+n/GrPpd 4XIkEhosuutNV47lzaW14Bk= X-Google-Smtp-Source: ABdhPJxP5w0sI/OYkRXVsJIUgzo01VT/JbTv0l4jLmhNkMocW9Ql6HNFxQ75dHb4c6hrpTb/5KHWiA== X-Received: by 2002:a05:6402:1684:: with SMTP id a4mr15016768edv.348.1607348192366; Mon, 07 Dec 2020 05:36:32 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id m3sm13537990edj.22.2020.12.07.05.36.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 05:36:31 -0800 (PST) Message-ID: <93bae908b2c6433ecc42405b81849386c2a3bb7a.camel@gmail.com> From: Glyn Normington To: Michael Kay Cc: Tim Bray , jsonpath@ietf.org, Carsten Bormann Date: Mon, 07 Dec 2020 13:36:30 +0000 In-Reply-To: References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] ".." operator X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 13:36:36 -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 > > //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. 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 > > > > On 7 Dec 2020, at 11:58, Glyn Normington < > > glyn.normington.work@gmail.com> wrote: > > > > 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 < > > > glyn.normington.work@gmail.com> 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 > > > > > wrote: > > > > > > > > > > On 2020-11-18, at 12:46, Glyn Normington < > > > > glyn.normington.work@gmail.com> 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 > > > > > > > > > -- > > Jsonpath mailing list > > Jsonpath@ietf.org > > https://www.ietf.org/mailman/listinfo/jsonpath > > From nobody Mon Dec 7 05:51:17 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290513A13CB for ; Mon, 7 Dec 2020 05:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 tauBzdeiSRaW for ; Mon, 7 Dec 2020 05:51:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7416F3A13BA for ; Mon, 7 Dec 2020 05:51:14 -0800 (PST) Received: from cpc160115-rdng30-2-0-cust150.15-3.cable.virginm.net ([86.19.35.151] helo=[192.168.0.27]) by smtp04.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from ) id 1kmGv2-000CEe-2p; Mon, 07 Dec 2020 13:51:12 +0000 From: Michael Kay Message-Id: <65A35BED-E354-475B-8D74-2A792FDF9F98@saxonica.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E3C8FCAD-5443-411B-8DF4-E497CBEF256D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Mon, 7 Dec 2020 13:51:11 +0000 In-Reply-To: <93bae908b2c6433ecc42405b81849386c2a3bb7a.camel@gmail.com> Cc: jsonpath@ietf.org, Carsten Bormann , Tim Bray To: Glyn Normington References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> <93bae908b2c6433ecc42405b81849386c2a3bb7a.camel@gmail.com> X-Mailer: Apple Mail (2.3445.9.7) X-Mailcore-Auth: 439400257 X-Mailcore-Domain: 1881035 Archived-At: Subject: Re: [Jsonpath] ".." operator X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 13:51:16 -0000 --Apple-Mail=_E3C8FCAD-5443-411B-8DF4-E497CBEF256D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > 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. 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= --Apple-Mail=_E3C8FCAD-5443-411B-8DF4-E497CBEF256D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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.

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
= --Apple-Mail=_E3C8FCAD-5443-411B-8DF4-E497CBEF256D-- From nobody Mon Dec 7 06:09:59 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C83A13F3 for ; Mon, 7 Dec 2020 06:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 suMzCA-v24pz for ; Mon, 7 Dec 2020 06:09:56 -0800 (PST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 20D363A13EA for ; Mon, 7 Dec 2020 06:09:49 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id g20so19699049ejb.1 for ; Mon, 07 Dec 2020 06:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=kAYTDkXZWyj8uiHcoeNV8nfm2oTCpCYVkrH1bqjSYe8=; b=h3Z3RxuaHf1dXNEjV2W8q7nqMh1rIM5yY+GUiyY9MXfQuC4mK1Y7rzs7fKIspqehNt 0+RiOvSX54l4gy19VUTCgc+BWQDzmCXts6goyTMib0YBVh7/R6MGo1A1xWOlHV83agGG YIBnkhEmMEGUcc0s0Mg3EMPLvTXLzTxcD2uvSBFF93t47YUkhSO1H/BT7NCbFrICZ0OX 6zSKyBHzqHHlAAJupXLIMo2PAu4c0E8H784BsflekvIxoHgA8zzh8sQe9zBaUHJZUVIb G0uLEvE94dytNowtbyfCWxuebiyFPrMh8t+Ry03gfhL7lSZXuUcroMNe2fMZO9KYW0Rb j2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=kAYTDkXZWyj8uiHcoeNV8nfm2oTCpCYVkrH1bqjSYe8=; b=RQb16IZrUVrcJgg1+d3VSpdN1Z+gYdJ0wu9ZtosVQLIIHE2Oox36Ra2Fmlm1ifj1mj r0zflZYXAIqGGVwAib6Ku6GPJMDHQg5zKdhH2gFyCzxG3rKnt5A0qMlASl11O5VN1/tp 6IysVZ+YPMRg4afRwHrHATbfwnem/hJBjj5ltqZ/iFuO2tGBHif6ITKPpeG7H9o1TeXr 3n+fjRsPy9Pdo+btVU2Guy9TDt0utDViAX7JL0/aCt92Oce9r2o22ghezGOjTMrIJmww MLfcuwdYVAH50NmyUIbVi72RMVasdV80YXKeNB5YUREtqiMCwLgxxaKO97ALjGf8SMlB uqQQ== X-Gm-Message-State: AOAM533WyeL6rEQY+D4GKVhQ+99GNLLS1jMdl71ve+qeINuJ0+YfpioC rKHXdH84t1atR4Nd4wqQl6s= X-Google-Smtp-Source: ABdhPJzenuGdC7dwrTcv4uDhainIWrKLMs4Vpd3ue+NIno4P+XkTf4ySI9zmBelwqHDyJO8cEHL1ZA== X-Received: by 2002:a17:906:22c7:: with SMTP id q7mr19008987eja.486.1607350187594; Mon, 07 Dec 2020 06:09:47 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id dd12sm13342481edb.6.2020.12.07.06.09.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 06:09:46 -0800 (PST) Message-ID: <4f80b1608d2b601626d3f349f40c9591b4b9a3e0.camel@gmail.com> From: Glyn Normington To: Michael Kay Cc: jsonpath@ietf.org, Carsten Bormann , Tim Bray Date: Mon, 07 Dec 2020 14:09:46 +0000 In-Reply-To: <65A35BED-E354-475B-8D74-2A792FDF9F98@saxonica.com> References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> <93bae908b2c6433ecc42405b81849386c2a3bb7a.camel@gmail.com> <65A35BED-E354-475B-8D74-2A792FDF9F98@saxonica.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jsonpath] ".." operator X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 14:09:58 -0000 On Mon, 2020-12-07 at 13:51 +0000, Michael Kay wrote: > > 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 Oops. That should have been .book[2]. > > select > > the third item of each array which is a member of an object with > > key > > "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? 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. > > Michael Kay > Saxonica From nobody Mon Dec 7 06:18:20 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E13A13E4 for ; Mon, 7 Dec 2020 06:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lYI7aqPVHwqG for ; Mon, 7 Dec 2020 06:18:17 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 01CD03A0D78 for ; Mon, 7 Dec 2020 06:18:16 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id b9so9360868ejy.0 for ; Mon, 07 Dec 2020 06:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=/J7VZoNBwbrx86OaOnJVNv9CWXUj+8IAf2SUQGr7pGY=; b=RlZRlwFrZkK7iytWj8hE9G4H/apj5jb1gmljTFruMmZHthWzqc1QAMix+95gU8UPeg YbXp60ahdj3Qt19HxlXMHx19s043HSCQ3BGUAF/LZOb6Ly2tYyhUwgSnWT99mRxtQ9Mj PBSvFIFYseEG+CjRgWIiFQsRUaPoBKRcIQ+gfUxFnnns6Y7OCP6NV4y/HeHIwvAwFBgO ezg1C3QEbGMnmIfQUob7fkcVc3PRK4VroGiQkqPlpnu6+xro0eAxbDFRBJIfJAMejIsE usXqd1rU78Oc+JB5Dpsh+sUGAzfyuBaOtspAoJpAzWSew91hSRxZBFiS0TOrRbUwSyL9 dsrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/J7VZoNBwbrx86OaOnJVNv9CWXUj+8IAf2SUQGr7pGY=; b=bUJIGdXXSUsHRf5VUeKQx7ap4e6JHlT5qi9Yop40vMtpBKqjXzFZK24ysOJFFQNxek 6X3FVnRHpQGjOF6jHS+/YtuZTe33zp+pKgqPl5ZF3ytWf+rTF6BltVv8qssdwmZjoCqD J7LRN4klYmfCMJrxM/4OQM+IORwcn9rLhTkyGCack2zetUT5YzxLe4esT5K6Mopc4CDd 33JEiPBbpz03rwbKoKqId9m8sZVfIMc2v9uRTdTSrj5RGSaHEGWf/gMDEY6FAgHUe2sm Pk0Q6Aa7ELR7+ei9otSngqNMeRNEpNwxRzNoexNYbnKOLK9eLoXzxpo5VBZVMlBTBla7 7DoQ== X-Gm-Message-State: AOAM531h/qJKMjI3km7iiP7V4zMUNJ47onT0G9DkJk7cqVeJYGRkxaS7 EBU8yVNLytxPLoS78lMO+XQxi6zouff0ZA== X-Google-Smtp-Source: ABdhPJwN/CJ/oEpEXoItkEj5zG8CAN1LNAApQimz4CEGp9X/1/cv4AsINpDmEMblwfnt7b5kb22y0g== X-Received: by 2002:a17:906:2806:: with SMTP id r6mr17814259ejc.130.1607350695294; Mon, 07 Dec 2020 06:18:15 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id u19sm12611368ejg.16.2020.12.07.06.18.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 06:18:14 -0800 (PST) Message-ID: From: Glyn Normington To: James , Tim Bray Cc: jsonpath@ietf.org, Carsten Bormann Date: Mon, 07 Dec 2020 14:18:13 +0000 In-Reply-To: References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] Merging the drafts X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 14:18:19 -0000 On Mon, 2020-12-07 at 13:11 +0100, James wrote: > 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. Done. https://datatracker.ietf.org/doc/draft-normington-jsonpath/ > > - J > > On 07-12-2020 11:58, Glyn Normington wrote: > > 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 < > > > glyn.normington.work@gmail.com> 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 > > > > > wrote: > > > > > > > > > > On 2020-11-18, at 12:46, Glyn Normington < > > > > glyn.normington.work@gmail.com> 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 nobody Mon Dec 7 08:40:55 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC963A1458 for ; Mon, 7 Dec 2020 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 tukQqP6AwfTz for ; Mon, 7 Dec 2020 08:40:52 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 5594B3A0FC2 for ; Mon, 7 Dec 2020 08:40:52 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id s11so6968335ljp.4 for ; Mon, 07 Dec 2020 08:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xaWKUJiC+WQvE2JWSpBhoeuIpK+xHyjHBK5t0AW8hzU=; b=SM2jKfjHplR5O+kTJoOcD/htFFooM1tLLs2/45Ufz7qT9+lCOrZlbMRjdXxznIp2eO F32m1eKUI/ahcZ5BgMY7H5o31vTMvyXRhKCwxvODWlYSQTORluLbJIlfLh+CpfnCfYUR UQf9PUoj9Tt+KrecSDV1yOjosymYy18dcGdzmtJnFTmwRukFVltdcGozg4eet7OmTPZG L0rvtldrPYqQHfDoRlbAuJyOLliMKXJxDJt0gBXiYneUm1z39LVsj7mb+WBhXRTQYCMd WcalGBBewd/ftHa8gVz40TizmVpxqnd2rcflxD198aa64YXsZNFEkUxsD1aqPVOJSlB3 oBMg== 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; bh=xaWKUJiC+WQvE2JWSpBhoeuIpK+xHyjHBK5t0AW8hzU=; b=YJmMBTMF3ftC2iYcCE954hQhDbElWC9MxBl6bewAMNlhJogKWJgMReLG4vEJAPM2PA 3upyGFNTyMpyYSDusbBChQZ6INXChcYxL9fE21kw0N8CZ6UT0vFwKXW7K3lmEBItestT ECiKA3QzFkkYY2bXdHn95zbb1ZHQBWx2fIp5u7vxVtnsvpPaDNOwK/G5rx2+zF4OCUqB Odgvqi2pDZ0h3ZITCaoad5TMSzUBqwfkFbUQ8AIn4F0RWJ386voT2wpcYwRuCxHnbiAW PY6L8QOV0nPRr50mrw5L5LDrlyNVCZr3HhOszJMqByqEs3eRyzH1R64VCsyYxiL274zH SPiw== X-Gm-Message-State: AOAM530TiFDnESLfi0IryRyVGgxoAALGbD0LNh3nMgFGkRAJEB1Q/eoW iRcWQ/XXb9DTdz0VGJAo1jFS5PEUMM8mnWdRVzdb+Q== X-Google-Smtp-Source: ABdhPJxvRqGWSWjwwYvPoVxNz2U+8pus2Ew/43ScjwtQ2fxcXEiqc1+wF+TE8SpNct/Rns0OXc+ERevgclUyGYnz6E8= X-Received: by 2002:a2e:8751:: with SMTP id q17mr9201222ljj.179.1607359249873; Mon, 07 Dec 2020 08:40:49 -0800 (PST) MIME-Version: 1.0 References: <76B4D7FC-BC5B-467A-9AF1-3053C3EEECC7@tzi.org> <3d96e2068faec0ebb4ce5295c82876f0129dfcee.camel@gmail.com> In-Reply-To: From: Tim Bray Date: Mon, 7 Dec 2020 08:40:38 -0800 Message-ID: To: Glyn Normington Cc: James , jsonpath@ietf.org, Carsten Bormann Content-Type: multipart/alternative; boundary="0000000000001d92d605b5e27db1" Archived-At: Subject: Re: [Jsonpath] Merging the drafts X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:40:54 -0000 --0000000000001d92d605b5e27db1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the work, folks! On Mon, Dec 7, 2020 at 6:18 AM Glyn Normington < glyn.normington.work@gmail.com> wrote: > On Mon, 2020-12-07 at 13:11 +0100, James wrote: > > 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. > > Done. https://datatracker.ietf.org/doc/draft-normington-jsonpath/ > > > > > - J > > > > On 07-12-2020 11:58, Glyn Normington wrote: > > > 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 < > > > > glyn.normington.work@gmail.com> wrote: > > > > > Thanks Carsten! I won=E2=80=99t be able to review the PR until Mo= nday. > > > > > 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 > > > > > > wrote: > > > > > > > > > > > > On 2020-11-18, at 12:46, Glyn Normington < > > > > > glyn.normington.work@gmail.com> 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=E2=80=99s repo: > > > > > > > > > > > > https://github.com/jsonpath-standard/internet-draft/pull/42 > > > > > > > > > > > > (How could it be anything but 42.) > > > > > > > > > > > > I didn=E2=80=99t 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=E2=80=99ve seen som= e > > > > > feedback > > > > > on this round. > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > --0000000000001d92d605b5e27db1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks for the work, folks!

On Mon, Dec 7, 2020 at 6:18 AM Glyn Normingto= n <glyn.normington.wor= k@gmail.com> wrote:
On Mon, 2020-12-07 at = 13:11 +0100, James wrote:
> 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.

Done. https://datatracker.ietf.org/doc/dr= aft-normington-jsonpath/

>
> - J
>
> On 07-12-2020 11:58, Glyn Normington wrote:
> > The drafts are now merged at
> > https://jsonpath-standard.github.io/int= ernet-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 poin= t
> > 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 <
> > > glyn.normington.work@gmail.com> wrote:
> > > > Thanks Carsten! I won=E2=80=99t be able to review the P= R until Monday.
> > > > I
> > > > hope others will have had a chance to make their commen= ts,
> > > > preferably in the PR, by then.
> > > >
> > > > > On 26 Nov 2020, at 19:45, Carsten Bormann <cabo@tzi.org>
> > > > > wrote:
> > > > >
> > > > > On 2020-11-18, at 12:46, Glyn Normington <
> > > > glyn.normington.work@gmail.com> wrote:
> > > > > > Following on from the Working Group meeting a= t IETF 109,
> > > > > > Carsten
> > > > and I are working on merging the two existing drafts. T= he 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=E2=80=99s repo:
> > > > >
> > > > > https://github.c= om/jsonpath-standard/internet-draft/pull/42
> > > > >
> > > > > (How could it be anything but 42.)
> > > > >
> > > > > I didn=E2=80=99t touch the actual text of the norm= ington draft very
> > > > > much,
> > > > so I plan to put in another round cleaning up the remai= ning
> > > > redundancies and moving things around when we=E2=80=99v= e seen some
> > > > feedback
> > > > on this round.
> > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > >

--0000000000001d92d605b5e27db1-- From nobody Mon Dec 7 12:38:49 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BC63A0A0B for ; Mon, 7 Dec 2020 12:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RNULvcNBlvNs for ; Mon, 7 Dec 2020 12:38:45 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 8EBBD3A09C5 for ; Mon, 7 Dec 2020 12:38:45 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id y17so4665222wrr.10 for ; Mon, 07 Dec 2020 12:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ol9hdAMiV9soOcW+nXrahrQSYllIjgZWznoe5JZN4uQ=; b=vLm3mSk9g6d+3bJEXEQkh5qyyPbF1VHQscjBC1/T7WBYjNrIvbboHDH25F80vbDP1d vSZKFRWb+pmnz194HwTywqS3sz7uxHlsuVoADdk6J3/d95kTIGumN/iegtoVrNyEMv1g eYn4G4mHJiP2EeNaoePaDOl2EJ/aI2etd3doBfqCGSswZ+/8oyNpXsRBtXCTUZS+fRLj px1f+HQFNVo0OkefM6g/5cQzRXKFNx9zjpob1nlLOromvTt7yCntq7TkQWOq2KM4vc2C iFJn8U2nNq7oWso3lYzW231qOkLUcOhS8Sm2B2ich+0/mGXIJnwNEZqREajigQm32Cny q6SA== 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; bh=Ol9hdAMiV9soOcW+nXrahrQSYllIjgZWznoe5JZN4uQ=; b=D7S38LAFXoKOmHFGGRCN2QR5MLu34iemltDsjE2tVLNMYp9UWf2hTkrzDdxcyqIIDW VSH9DErAKod/x9VYGNBbOOMkIJ/5c5pGXzJZDgGzhVQL8jgwicdjf5PzHqTe5j1Hqh5z 7Duoa78nlKqqqKYXhqwdpF7jEu+EIAWxRBzHDh95c+aT+jBmw4Cy/dR3UhWayyT5YlVB bHvKTreBRuH4Qz7JI+UkiSuVfLs0507fSmz4Ce5Cb60hhi7CUgHQbkhPLewkPeEaFKw4 V/tc84wnrhQigkt2lQBZJrT+WKkPhXP78LRWUTxzFpxklY/JScpSCbFhz5MvOmjLlnn+ tMiA== X-Gm-Message-State: AOAM530REoKmy4WIze/tbyFU1bkrXHZIsWfHYarSJxO7UjISOWaKphLY ch2oGkEdpQJD1CsduKkKOObw84TNUmbrI9FLyI6znJfvxJ4jiQ== X-Google-Smtp-Source: ABdhPJy/tgzjHXWwyyyRknSqRiWvysLFSwYNPs1Ii2wu8yk29AxtddEn/VBLcI9DZv4Gr3cc1AbpynWrKmJArlphYBk= X-Received: by 2002:adf:fd06:: with SMTP id e6mr21018182wrr.206.1607373523570; Mon, 07 Dec 2020 12:38:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Mon, 7 Dec 2020 15:38:31 -0500 Message-ID: To: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:38:47 -0000 My general comment is that there is a lot of ambiguous language in the draft, and ambiguous language is the bane of implementers. Some examples below: One. "Data Item: A structure complying to the generic data model of JSON, i.e., composed of containers such as arrays and maps (JSON objects), and of atomic data such as null, true, false, numbers, and text strings." Why introduce the term "map" as the preferred (unparenthized) term? RFC 8259 doesn't mention "map", it uses JSON object. By following "arrays and maps" with "(JSON objects)", it could be read that "arrays and maps" will collectively be referred to as "JSON objects". Later in the draft we read "the root object" ($) and "the current object" (@), which almost suggest that that is the intended meaning. My own view is that the terminology should stay consistent with RFC 8259, and that the word "object" should not be used for items that are not JSON objects in the sense of RFC 8259. What is the purpose of "such as" in the sentence? Aren't the itemizations exclusive? Two. "Since a JSON data item is usually anonymous and doesn't necessarily have a "root member object", JSONPath used the abstract name $ to refer to the top level object of the data item." I realize this sentence is mostly copied from Goessner, but I didn't understand it there either. Regarding "doesn't necessarily" have a "root member object", what is that supposed to mean? It seems to me that the root is _always_ going to be an anonymous JSON value, which, when Goessner was writing, could be a JSON array or object, and since RFC 8259, any JSON value. Three. "Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to the more general bracket-notation." For output paths, Goessner uses the term "normalized path expressions", which should be unambiguously defined. For uniqueness, in addition to avoiding dot-notation, there would need to be other restrictions, including avoiding the descendant operator .., and filters. Four. "The symbol @ is used for the current object." Only if you interpret "object" to mean _any_ JSON value. In the example above this sentence, $.store.book[(@.length-1)].title the symbol @ refers to a JSON array, with a JavaScript like property "length". That arrays must support a JavaScript like property length is not explicitly stated in the draft, but is implied in two examples. This should be clarified. Not all implementations do, for example, implementations that support functions that can be invoked at the tail end of a path typically support a function call length() instead. I also think the @ notation could be better explained, this particular reader struggled to understand what was meant by "current object" in original Goessner, and had to figure it out from examples. Daniel From nobody Mon Dec 7 12:45:15 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600F43A0983 for ; Mon, 7 Dec 2020 12:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 qpA_WvW_8svB for ; Mon, 7 Dec 2020 12:45:12 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 3CA203A097C for ; Mon, 7 Dec 2020 12:45:12 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id b4so12404564lfo.6 for ; Mon, 07 Dec 2020 12:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nMn1AYRx3jB+gVuI1JsnNDrF4306ewutkhX4m3t03sA=; b=ELgB1p1KSL2UaHjKGMuq7vOX24c0rpzPM8l7fivrpZMOeCgygLyGLatqHZRDhVhntX BdUhfxSup7YVcNDZ2twrzjGZ2cocFmQBPQCY+/mAXvSwqiKXJsQZ+9ePHrsnRzjIbBKH otGL1pU5NfX0zB3nXe2Iq0OAe4lgl5o/C0d/RhU0+/1Qaj/Zocvrb6RTOyAdmFGZUTu9 mtZSmfGkdo+Ob9PylFMeVrQLVKEaN67txzFYfYqwHk91LEazejkPkHupa4nAB11pjIg7 jx6I9xDntgOQQ4hWL1bhqpztwATPjQ94G8GyQcr8CJFGYebyHX3R69VpGbjqlaZ8ClrX 2ybQ== 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; bh=nMn1AYRx3jB+gVuI1JsnNDrF4306ewutkhX4m3t03sA=; b=lhwO1tvuCXocFpVDLbyKcBqa/T/yKulqwkqoaT2omR1mwweci6y/ExQt8A3I3cJLry VPeQec0fUS9yE676YRz6FKfxge6LuU/+cqGxQvHVHuaL2LtrtlfnBzR/zhm3Br6vDB0M /KODhUBdVVc0/LtnbCZaueL257QiPIvERTKzQ+ssGvJrEPMWN+59eoceBeIUhYgIh8hf xK2QL5BJzHUgZ1FbwZfyVrni/JfDu6x5PWwAypLPFfgpk3PPCm4URYoAsBfwUhUOfYSF ZH64DmVF7XELfItDghg+8CPbqW58LVwfgmnVuSKvfwzQlIIN7Yw2iyV8Wkna7UMxB7NG LNXA== X-Gm-Message-State: AOAM531yAbdpg+MYLR4n9s5gTKTGi/wJwTo71Dy4sx/WWS4+XJvZXup8 aBhd60HS+pvPvnulb0NniO22KMFX03fMJvDlwaEP5RyRfqJCPA== X-Google-Smtp-Source: ABdhPJy0Ro8ZggWq5DHgNvbGuH7dm9kCvRggi8DYp/4aRKmGdNAiuRqexEtvf81+XJseYQ+inUIpug3Qa4hUYDA3FH8= X-Received: by 2002:a19:40d6:: with SMTP id n205mr2719248lfa.24.1607373910344; Mon, 07 Dec 2020 12:45:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 7 Dec 2020 12:44:59 -0800 Message-ID: To: Daniel P Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="000000000000f29c6005b5e5e648" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:45:14 -0000 --000000000000f29c6005b5e5e648 Content-Type: text/plain; charset="UTF-8" All those points granted, I think we should proceed and as a WG adopt the draft, then you can turn all those issues you just raised into WG issues and we can proceed to work through them in an orderly way. On Mon, Dec 7, 2020 at 12:38 PM Daniel P wrote: > My general comment is that there is a lot of ambiguous language in the > draft, and ambiguous language is the bane of implementers. Some > examples below: > > One. "Data Item: A structure complying to the generic data model of > JSON, i.e., composed of containers such as arrays and maps (JSON > objects), and of atomic data such as null, true, false, numbers, and > text strings." > > Why introduce the term "map" as the preferred (unparenthized) term? > RFC 8259 doesn't mention "map", it uses JSON object. By following > "arrays and maps" with "(JSON objects)", it could be read that "arrays > and maps" will collectively be referred to as "JSON objects". Later in > the draft we read "the root object" ($) and "the current object" (@), > which almost suggest that that is the intended meaning. > > My own view is that the terminology should stay consistent with RFC > 8259, and that the word "object" should not be used for items that are > not JSON objects in the sense of RFC 8259. > > What is the purpose of "such as" in the sentence? Aren't the > itemizations exclusive? > > Two. "Since a JSON data item is usually anonymous and doesn't > necessarily have a "root member object", JSONPath used the abstract > name $ to refer to the top level object of the data item." > > I realize this sentence is mostly copied from Goessner, but I didn't > understand it there either. Regarding "doesn't necessarily" have a > "root member object", what is that supposed to mean? It seems to me > that the root is _always_ going to be an anonymous JSON value, which, > when Goessner was writing, could be a JSON array or object, and since > RFC 8259, any JSON value. > > Three. "Where a JSONPath processor uses JSONPath expressions as > output paths, these will always be converted to the more general > bracket-notation." > > For output paths, Goessner uses the term "normalized path > expressions", which should be unambiguously defined. For uniqueness, > in addition to avoiding dot-notation, there would need to be other > restrictions, including avoiding the descendant operator .., and > filters. > > Four. "The symbol @ is used for the current object." > > Only if you interpret "object" to mean _any_ JSON value. In the > example above this sentence, > > $.store.book[(@.length-1)].title > > the symbol @ refers to a JSON array, with a JavaScript like property > "length". > > That arrays must support a JavaScript like property length is not > explicitly stated in the draft, but is implied in two examples. This > should be clarified. Not all implementations do, for example, > implementations that support functions that can be invoked at the tail > end of a path typically support a function call length() instead. > > I also think the @ notation could be better explained, this particular > reader struggled to understand what was meant by "current object" in > original Goessner, and had to figure it out from examples. > > Daniel > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --000000000000f29c6005b5e5e648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All= those points granted, I think we should proceed and as a WG adopt the draf= t, then you can turn all those issues you just raised into WG issues and we= can proceed to work through them in an orderly way.

On Mon, Dec 7, 20= 20 at 12:38 PM Daniel P <dani= elaparker@gmail.com> wrote:
My general com= ment is that there is a lot of ambiguous language in the
draft, and ambiguous language is the bane of implementers. Some
examples below:

One. "Data Item: A structure complying to the generic data model of JSON, i.e., composed of containers such as arrays and maps (JSON
objects), and of atomic data such as null, true, false, numbers, and
text strings."

Why introduce the term "map" as the preferred (unparenthized) ter= m?
RFC 8259 doesn't mention "map", it uses JSON object.=C2=A0 By= following
"arrays and maps" with "(JSON objects)", it could be re= ad that "arrays
and maps" will collectively be referred to as "JSON objects"= . Later in
the draft we read "the root object" ($) and "the current obj= ect" (@),
which almost suggest that that is the intended meaning.

My own view is that the terminology should stay consistent with RFC
8259, and that the word "object" should not be used for items tha= t are
not JSON objects in the sense of RFC 8259.

What is the purpose of "such as" in the sentence? Aren't the<= br> itemizations exclusive?

Two. "Since a JSON data item is usually anonymous and doesn't
necessarily have a "root member object", JSONPath used the abstra= ct
name $ to refer to the top level object of the data item."

I realize this sentence is mostly copied from Goessner, but I didn't understand it there either. Regarding "doesn't necessarily" h= ave a
"root member object", what is that supposed to mean? It seems to = me
that the root is _always_ going to be an anonymous JSON value, which,
when Goessner was writing, could be a JSON array or object, and since
RFC 8259, any JSON value.

Three.=C2=A0 "Where a JSONPath processor uses JSONPath expressions as<= br> output paths, these will always be converted to the more general
bracket-notation."

For output paths, Goessner uses the term "normalized path
expressions", which should be unambiguously defined. For uniqueness, in addition to avoiding dot-notation, there would need to be other
restrictions, including avoiding the descendant operator .., and
filters.

Four. "The symbol @ is used for the current object."

Only if you interpret "object" to mean _any_ JSON value. In the example above this sentence,

$.store.book[(@.length-1)].title

the symbol @ refers to a JSON array, with a JavaScript like property "= length".

That arrays must support a JavaScript like property length is not
explicitly stated in the draft, but is implied in two examples. This
should be clarified. Not all implementations do, for example,
implementations that support functions that can be invoked at the tail
end of a path typically support a function call length() instead.

I also think the @ notation could be better explained, this particular
reader struggled to understand what was meant by "current object"= in
original Goessner, and had to figure it out from examples.

Daniel

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--000000000000f29c6005b5e5e648-- From nobody Mon Dec 7 12:54:53 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E093A09D6 for ; Mon, 7 Dec 2020 12:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LVZLDoe0A8MC for ; Mon, 7 Dec 2020 12:54:49 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 E6E703A0A0B for ; Mon, 7 Dec 2020 12:54:48 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id f23so21524212ejk.2 for ; Mon, 07 Dec 2020 12:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=MtAR6a1ijwitTS/3/k8rSY/Z/FlrACyKr32u76ujuyA=; b=XDgIMG9bUOuaHAx+Lx7mVXC/8ppzswkMaj4LtfhEGcnqUYdvM53qvcwzDED4YeR8eA mco5uf7ZK55A1WDoAAtVpiW8rf/jCvemBxnCKOnOtyWEu4g+1laupCgfyH9ULgVUkZYD SleEeoWDRa0tOfYfrmN3mLdvhDwd8KYkD+SmHVbNbxCj/2cRz5+l4wp/KqXsM8+a+Jm0 sNeuM1jBXgczep/zt6bWV9bZA0wqBf624H8AJ0VIl+4IVH3sBsMQC//7ZWJG2Nhu/sAZ jTF1cGWRN5g+ClRP2HbeKLY905i7vbhgaIVnBZb8IAG9KgQNHsdoDS5apvAnpURjtRF1 ZtjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=MtAR6a1ijwitTS/3/k8rSY/Z/FlrACyKr32u76ujuyA=; b=FqQqkQt2JBEf1U/GfB4fx7irH54upt7RKhKpTaabMit54+xJNnL4S3hCNUIfLneBrD oHrbOGAv0dCPS2h9Tc1gLYlMMDl1vI9dpP833DZqY9j5YyryXQ5Cx/E05Crk7SjTzEqn 9r53JzofDQ20qlMvsDY8aDSnQ1tE7xni7TWrDzY7GZ66pHey/eI2mGyak6wjSEhXWVh3 P3NADvHtpoKHCiY6frUgChCGu4j15hcze3MHszzWizfwKg4Cy5s3xiG49hYxV8gnFD+K zfflJk+ueOtMc1OlaMBkxc3QfbhZ+kL+kzd29lW6vvojaPQzCt2MNktdXzVMsU1Uuxbb 8a/Q== X-Gm-Message-State: AOAM531F5dA7aHBoMiScMnd+5yRx58j2k2rOhTAj0tpVN6/Gaqi7TrhZ eUtCbVUpNXJzhgmqLsZq99qUCfqQb2ODbA== X-Google-Smtp-Source: ABdhPJx7CJ0rEKBu1X4nZUmczhDQDh2aFe77k1xEbUoDv/2h5ezyIIpY9rR2r89FRKQNNbKJb8GI7w== X-Received: by 2002:a17:906:81ca:: with SMTP id e10mr20327837ejx.449.1607374487008; Mon, 07 Dec 2020 12:54:47 -0800 (PST) Received: from ?IPv6:2001:984:65b0:2:38f5:f2ac:3cc4:1435? ([2001:984:65b0:2:38f5:f2ac:3cc4:1435]) by smtp.gmail.com with ESMTPSA id da9sm12874859edb.84.2020.12.07.12.54.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 12:54:46 -0800 (PST) To: jsonpath@ietf.org From: James Message-ID: Date: Mon, 7 Dec 2020 21:54:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-AU Archived-At: Subject: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:54:52 -0000 This begins a 2 week working group adoption call for https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, ending Tuesday, December 22nd 2020. This document is the merging of Glyn's original document with draft-goessner-dispatch-jsonpath, and is a starting point and not specification complete. After review of the document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack thereof) as silence will not be considered as consent. Thanks! Tim & James From nobody Mon Dec 7 12:59:50 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545313A0A42 for ; Mon, 7 Dec 2020 12:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 2IzNs5bPd8z2 for ; Mon, 7 Dec 2020 12:59:46 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 716053A0A3E for ; Mon, 7 Dec 2020 12:59:46 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id q5so14038683qkc.12 for ; Mon, 07 Dec 2020 12:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDGl6KLg32PtLcOtXqbUm3K+zjoRxfH88xCtdeYQI2Q=; b=JvtUMDxk2JO8PFFTCq8QSlOjsIyyKPkPH9mB9EESZ7A/9JY/12dOSFskjYbakLfw+7 VpzT2lCfYNKfiQlfWaGCorHnELVhlV+5S7E48iJguFmUl7JpDxR28wbm5WGUvQ7Kj+Ua tZGYhxfxZGrxVPipA4vsEEK1jIwRZWus6qHxZ/A+ReZgCwf5viBwoHG2XHQ6BboyM7xd 2PbMNxx294sSTgnhksO2DT5N1b3U4rsm0CmcTTJVdEIElCqr3Tl7wTM/fT1kXA9Ys3Wp Y9VR2ny1u/kZzoiYK+GJrqfu4Su3NkA/K0fMocNeB4AvtGMOoxCoQ4lxcXJv3rdO0tXr rmmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDGl6KLg32PtLcOtXqbUm3K+zjoRxfH88xCtdeYQI2Q=; b=BeNKtBWCIUK7/AQtVowzGB7e/+JdrGtqJeZCgv5BwGqzCX42tcpRUTUUhlLLKHz5ML YHn9FoX5k1XerMBZN1kPDYPAU/OuqrQt9hO5A8GpYCDD2Qz1Ef2xmrV13NCpqb22hdUv syWiteHfLyKm0aKZj4qeGxdwHpMVv+ykOhvcxZ8BZjos6w86ZhVJ3XCfpd9AQTVZ2Wno 2kZcJK0RtkQ1iopKFQp954VidMukzX2mFM2G5B9+xObCB2z1qrlTf7EgTEIwPYdogQLJ cjrPFAWvIY5fRw9ox60rW1slv7Z4HEHIcjJsljddGMLPyEfrTNsK/I8Zp6t2x1L7nSUD fREg== X-Gm-Message-State: AOAM532l9giwekqDDL72KbGV0N0qFo7JOHKUa0xQwfQs+XCJEjWrPW2K a8Q+ZWngySspiWj0atSDZcpqCA== X-Google-Smtp-Source: ABdhPJzkjHiNqSLmgmn76oxiAvxu5LsvQB091mu5CO4fc/QytSI/GFVBvDi0rTVle+qqFkUnto20ng== X-Received: by 2002:a05:620a:1387:: with SMTP id k7mr25012212qki.338.1607374785486; Mon, 07 Dec 2020 12:59:45 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id j17sm12216755qtn.2.2020.12.07.12.59.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 12:59:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Brian Rosen In-Reply-To: Date: Mon, 7 Dec 2020 15:59:44 -0500 Cc: jsonpath@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B537880-EED9-4894-941E-E816306466E9@brianrosen.net> References: To: James X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:59:48 -0000 I support adoption > On Dec 7, 2020, at 3:54 PM, James wrote: >=20 > This begins a 2 week working group adoption call for = https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, ending = Tuesday, December 22nd 2020. This document is the merging of Glyn's = original document with draft-goessner-dispatch-jsonpath, and is a = starting point and not specification complete. >=20 > After review of the document please indicate support (or not) for WG = adoption to the mailing list. Please also provide comments/reasons for = that support (or lack thereof) as silence will not be considered as = consent. >=20 >=20 > Thanks! >=20 > Tim & James >=20 > --=20 > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath From nobody Mon Dec 7 13:02:31 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849F3A09EF for ; Mon, 7 Dec 2020 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 OBVJQ_kCvgmt for ; Mon, 7 Dec 2020 13:02:28 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 453583A0A3E for ; Mon, 7 Dec 2020 13:02:28 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id f24so16564431ljk.13 for ; Mon, 07 Dec 2020 13:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbuS2UiDL+jPGXb3sqys3Tzdc+EX/cgbiJS54VU5yCA=; b=z7o7whNj+am8aAyIsd8lLNjB+7InWwGkqJwkPy/1DYrw5+SNmAvgMdKiHePr21ZDLf OdCZ2hv6y0gF4lcNq073+VZbbhOjt4ha+4avzzp+JCYopYC+u9LOztkuTWlQa9OJBkI/ 6VV8VKzlgzssrGCnWPyYLnkmiktJ5D+Z2nV2rC2/YhiNKvav9U+8GoCk0YfISIQ4hcKX +4cqFBbYxw9PtmkQAc/DueQhErUK5mSYhtz2jTXJbTThN+IuzGrxG3Oaspmysp/cKycp 9bY4pzpV72TfvxGuR8iNlHMH3qhivKHBfpVr0rqtt9LLCkNm7SN3cyRz/Fif6m+WfCI7 bCew== 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; bh=rbuS2UiDL+jPGXb3sqys3Tzdc+EX/cgbiJS54VU5yCA=; b=ZtIsppwwG8xweHoL4KWNiTvR75etbAQ0h4yCl2E1bzlUdZ5fFXSOAHFgWheQHE+STh /DidHdaaWJ4lbObEp/4kXcwK3XHyWDJlBTSTGx0jS042YCTTVpAlEeRugggUDDSHisQ7 CqsI5RBhlWXlIemNzy39RcIWHd4LB2FwvRxbycRYmra6OyKyG2GmF26lHY9vRcY9kpQj cyjW+ALm/3rEMmc48tv2zw70t/C0rOIP+ZphUFErl1q3s7RPByUHbznOwz4x0a/M6ygf Vjid3G6iSac4aqLtjYuFGthT5xL4F2y8s0ckNeussuiqFNkiDMCRJaJv+PcnQAiWImlj Ywgg== X-Gm-Message-State: AOAM533rUIzTLz4ABn+h7h4kuzyHjUVJ+hHOw872nn8Y0uXefVqFhrKj c6O7w3z6hTuOvjwmuZrs/TtoiaoVRPUnLxhEdY0FtA== X-Google-Smtp-Source: ABdhPJwlRe4E6kG/H8bvELeaZNUhcZIOIsjCDS/pjxRkd/4t3GAzZoWveXbTrhWqqdWwwydYzuCD/SjCSjagB8U9+5E= X-Received: by 2002:a05:651c:506:: with SMTP id o6mr4553737ljp.278.1607374946411; Mon, 07 Dec 2020 13:02:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 7 Dec 2020 13:02:15 -0800 Message-ID: To: James Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4039705b5e62463" Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 21:02:31 -0000 --000000000000b4039705b5e62463 Content-Type: text/plain; charset="UTF-8" Adopting this draft does not mean we are expressing WG consensus support for its contents as they stand at the moment. I support adoption. On Mon, Dec 7, 2020 at 12:54 PM James wrote: > This begins a 2 week working group adoption call for > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, ending > Tuesday, December 22nd 2020. This document is the merging of Glyn's > original document with draft-goessner-dispatch-jsonpath, and is a > starting point and not specification complete. > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as > consent. > > > Thanks! > > Tim & James > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --000000000000b4039705b5e62463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= ;chair-hat-on>Adopting this draft does not mean we are expressing WG con= sensus support for its contents as they stand at the moment.</chair-hat-= on>

<chair-hat-off&= gt;I support adoption.</chair-hat-off>

On Mon, Dec 7, 2020 at 12= :54 PM James <james.ietf@gmail.c= om> wrote:
This begins a 2 week working gr= oup adoption call for
https://datatracker.ietf.org/doc/htm= l/draft-normington-jsonpath/, ending
Tuesday, December 22nd 2020. This document is the merging of Glyn's original document with draft-goessner-dispatch-jsonpath, and is a
starting point and not specification complete.

After review of the document please indicate support (or not) for WG
adoption to the mailing list. Please also provide comments/reasons for
that support (or lack thereof) as silence will not be considered as
consent.


Thanks!

Tim & James

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--000000000000b4039705b5e62463-- From nobody Mon Dec 7 14:37:47 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844A3A0B50 for ; Mon, 7 Dec 2020 14:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4DXDgZiMpN1O for ; Mon, 7 Dec 2020 14:37:40 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02973A09D6 for ; Mon, 7 Dec 2020 14:37:39 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CqdVT5clbzyVj; Mon, 7 Dec 2020 23:37:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 7 Dec 2020 23:37:37 +0100 Cc: jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 629073456.967362-551e72ff311f427973b33a21cc676751 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel P X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:37:45 -0000 On 2020-12-07, at 21:38, Daniel P wrote: >=20 > My general comment is that there is a lot of ambiguous language in the > draft, As I said, work is needed. I don=E2=80=99t plan to wait for adoption to start this work, so I = created a PR: https://github.com/jsonpath-standard/internet-draft/pull/46 > and ambiguous language is the bane of implementers. Some > examples below: >=20 > One. "Data Item: A structure complying to the generic data model of > JSON, i.e., composed of containers such as arrays and maps (JSON > objects), and of atomic data such as null, true, false, numbers, and > text strings." >=20 > Why introduce the term "map" as the preferred (unparenthized) term? > RFC 8259 doesn't mention "map", it uses JSON object. =20 Sure. That is probably one of the mistakes that were made in defining = the JSON terminology. (Historically, what happened is that JavaScript has objects and atoms, = but arrays are almost, but not entirely unlike objects. When JSON was = defined, it only called the maps =E2=80=9Cobjects=E2=80=9D, making the = term object be ambiguous between its standard meaning and the =E2=80=9CJSO= N object=E2=80=9D meaning. So to be unambiguous, it is best to have a = term that unambiguously refers to =E2=80=9CJSON objects=E2=80=9D. Maps = naturally is that term, as would be longer terms such as dictionary. If = the WG does not like that term, we can of course revert to the more = ambiguous JSON terminology.) > By following > "arrays and maps" with "(JSON objects)", it could be read that "arrays > and maps" will collectively be referred to as "JSON objects=E2=80=9D. Yep, that is better the other way around. > Later in > the draft we read "the root object" ($) and "the current object" (@), > which almost suggest that that is the intended meaning. That should be item. > My own view is that the terminology should stay consistent with RFC > 8259, and that the word "object" should not be used for items that are > not JSON objects in the sense of RFC 8259. I agree with the latter, but the reason for that is that the RFC 8259 = terminology is confusing, so we could try to be more unambiguous. > What is the purpose of "such as" in the sentence? Aren't the > itemizations exclusive? Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with = =E2=80=9Cnamely=E2=80=9D. > Two. "Since a JSON data item is usually anonymous and doesn't > necessarily have a "root member object", JSONPath used the abstract > name $ to refer to the top level object of the data item." Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D discussion, = see below). > I realize this sentence is mostly copied from Goessner, but I didn't > understand it there either. Regarding "doesn't necessarily" have a > "root member object", what is that supposed to mean? It seems to me > that the root is _always_ going to be an anonymous JSON value, which, > when Goessner was writing, could be a JSON array or object, and since > RFC 8259, any JSON value. Many people who actually work with JSON don=E2=80=99t think in terms of = data items, but in terms of members (entries of a map, i.e. key/value = pairs). Because JSON values are data items and members cannot exist = outside a map, this creates a need to wrap those members into maps, and = to unwrap them again what talking about them as members. See https://ietf-wg-asdf.github.io/SDF/sdf.html#name-sdfchoice for an = example how that thinking looks like in practice (yes, I wrote that, = fully cognizant of the dissonance). But that prevalent thinking does not have to be reflected here, and = I=E2=80=99m proposing a change in the PR. > Three. "Where a JSONPath processor uses JSONPath expressions as > output paths, these will always be converted to the more general > bracket-notation." Fixed in PR. > For output paths, Goessner uses the term "normalized path > expressions", which should be unambiguously defined. For uniqueness, > in addition to avoiding dot-notation, there would need to be other > restrictions, including avoiding the descendant operator .., and > filters. >=20 > Four. "The symbol @ is used for the current object." Fixed in PR. > Only if you interpret "object" to mean _any_ JSON value. In the > example above this sentence, >=20 > $.store.book[(@.length-1)].title >=20 > the symbol @ refers to a JSON array, with a JavaScript like property = "length". >=20 > That arrays must support a JavaScript like property length is not > explicitly stated in the draft, but is implied in two examples. This > should be clarified. Not all implementations do, for example, > implementations that support functions that can be invoked at the tail > end of a path typically support a function call length() instead. Defining .length is part of the outstanding work on the expression = language. > I also think the @ notation could be better explained, this particular > reader struggled to understand what was meant by "current object" in > original Goessner, and had to figure it out from examples. Please send text. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 7 14:50:36 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C7E3A0C00 for ; Mon, 7 Dec 2020 14:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 eMkF8TpHbnLs for ; Mon, 7 Dec 2020 14:50:31 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 30DCC3A0B75 for ; Mon, 7 Dec 2020 14:50:31 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id q8so16831268ljc.12 for ; Mon, 07 Dec 2020 14:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o9TclY+E0Q10JLunV3o+TNkEyVaa0GRpD4xt/YkU08g=; b=Dihirb4CV5cqkiHmPexTkc26H2YQNYisPrengBJ0TZYDof2hLBAvTJLauiwrCshEaw EoRQV9mjvLLOr7elxtyOMwfQ5tYNrvjWB2lQ1RVkCgiVPjpIj2pgHcjtRRtyMhN6Asud V4zqLNhUAm+MpX1p9yujpzJcpHNV5fbdRxGXW/6XK0cPbwAa1YpY9YGB7LHMkALp1bVB wwuVQLLPSbEgq7KKXQcgkIesvAt3tD3knM+Nix52AS1W467y82AHdMMjX6HzIYlJOnSh 3G3bQZWnbNnp8GsFdBFlJD+jZRkA369zEvUn9dS9PFUv0c9C+O/sAcnbc2RK0E5kHlMe 0xWg== 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; bh=o9TclY+E0Q10JLunV3o+TNkEyVaa0GRpD4xt/YkU08g=; b=EvzNTihoenxmkHJtMLe6pndHjKOizWzDuBlowz83ZD76I78Wl/uj9kqSsrzcQGEipR 2+FyiTIhSZtisMt9RcAxlscJD6YWxk0QxlA9E00SgtvAo/dF8EoaIKP1A6nSKAUzdiQc 1/ebGmvK4wXYJfEm30PsxYu2BGV162iddHF6ttEvYlSeLwfKEmeYk1B2ZP19jDYWoaLo SS9UsU6HKriYK6VM1MdSgacuH2hefaoqfLnJKnGmFfXuJdLOTb03crErA6GbxhQDOciW jdbnrqv2zfVuRdXqK3Ox9tI44broN2Y9Sv4NF+4YX+lR5by8f/VPduqshUKbd+2SJbYk fjUw== X-Gm-Message-State: AOAM532mTI8Sq1ux15dJYt2ddlxHHPg4HrBmzU1uQqkuFVOcFT9Zw3Q1 wMI+pVWR8Zg2YRvi4gkhZ2tnOJ7EqfglzPLj1mub2A== X-Google-Smtp-Source: ABdhPJxbtXFmLj0HeAgL2/wZ3TEHEZiFuXWMmhktof17K1uiwlsdMvQ7MgDQ/i8NVteKTJrqXsstTOGlciO61gHBaus= X-Received: by 2002:a2e:8751:: with SMTP id q17mr9818121ljj.179.1607381429125; Mon, 07 Dec 2020 14:50:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 7 Dec 2020 14:50:18 -0800 Message-ID: To: Carsten Bormann Cc: Daniel P , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a16d205b5e7a7d3" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:50:35 -0000 --0000000000001a16d205b5e7a7d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To Carsten's point about what we call things, the number of distinguished terms per RFC8259 is pretty small: JSON text, value, object, array, number, string. Having spent quite a bit of time specifying JSON DSLs, I find that using just those terms doesn't seem to get in the way or cause problems, so I'd argue that we should stick to them (and build up to higher-level constructs as required for JSONPath). On Mon, Dec 7, 2020 at 2:37 PM Carsten Bormann wrote: > On 2020-12-07, at 21:38, Daniel P wrote: > > > > My general comment is that there is a lot of ambiguous language in the > > draft, > > As I said, work is needed. > > I don=E2=80=99t plan to wait for adoption to start this work, so I create= d a PR: > > https://github.com/jsonpath-standard/internet-draft/pull/46 > > > and ambiguous language is the bane of implementers. Some > > examples below: > > > > One. "Data Item: A structure complying to the generic data model of > > JSON, i.e., composed of containers such as arrays and maps (JSON > > objects), and of atomic data such as null, true, false, numbers, and > > text strings." > > > > Why introduce the term "map" as the preferred (unparenthized) term? > > RFC 8259 doesn't mention "map", it uses JSON object. > > Sure. That is probably one of the mistakes that were made in defining th= e > JSON terminology. > > (Historically, what happened is that JavaScript has objects and atoms, bu= t > arrays are almost, but not entirely unlike objects. When JSON was define= d, > it only called the maps =E2=80=9Cobjects=E2=80=9D, making the term object= be ambiguous > between its standard meaning and the =E2=80=9CJSON object=E2=80=9D meanin= g. So to be > unambiguous, it is best to have a term that unambiguously refers to =E2= =80=9CJSON > objects=E2=80=9D. Maps naturally is that term, as would be longer terms = such as > dictionary. If the WG does not like that term, we can of course revert t= o > the more ambiguous JSON terminology.) > > > By following > > "arrays and maps" with "(JSON objects)", it could be read that "arrays > > and maps" will collectively be referred to as "JSON objects=E2=80=9D. > > Yep, that is better the other way around. > > > Later in > > the draft we read "the root object" ($) and "the current object" (@), > > which almost suggest that that is the intended meaning. > > That should be item. > > > My own view is that the terminology should stay consistent with RFC > > 8259, and that the word "object" should not be used for items that are > > not JSON objects in the sense of RFC 8259. > > I agree with the latter, but the reason for that is that the RFC 8259 > terminology is confusing, so we could try to be more unambiguous. > > > What is the purpose of "such as" in the sentence? Aren't the > > itemizations exclusive? > > Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with =E2=80=9Cnam= ely=E2=80=9D. > > > Two. "Since a JSON data item is usually anonymous and doesn't > > necessarily have a "root member object", JSONPath used the abstract > > name $ to refer to the top level object of the data item." > > Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D discussion, s= ee below). > > > I realize this sentence is mostly copied from Goessner, but I didn't > > understand it there either. Regarding "doesn't necessarily" have a > > "root member object", what is that supposed to mean? It seems to me > > that the root is _always_ going to be an anonymous JSON value, which, > > when Goessner was writing, could be a JSON array or object, and since > > RFC 8259, any JSON value. > > Many people who actually work with JSON don=E2=80=99t think in terms of d= ata > items, but in terms of members (entries of a map, i.e. key/value pairs). > Because JSON values are data items and members cannot exist outside a map= , > this creates a need to wrap those members into maps, and to unwrap them > again what talking about them as members. > > See https://ietf-wg-asdf.github.io/SDF/sdf.html#name-sdfchoice for an > example how that thinking looks like in practice (yes, I wrote that, full= y > cognizant of the dissonance). > > But that prevalent thinking does not have to be reflected here, and I=E2= =80=99m > proposing a change in the PR. > > > Three. "Where a JSONPath processor uses JSONPath expressions as > > output paths, these will always be converted to the more general > > bracket-notation." > > Fixed in PR. > > > For output paths, Goessner uses the term "normalized path > > expressions", which should be unambiguously defined. For uniqueness, > > in addition to avoiding dot-notation, there would need to be other > > restrictions, including avoiding the descendant operator .., and > > filters. > > > > Four. "The symbol @ is used for the current object." > > Fixed in PR. > > > Only if you interpret "object" to mean _any_ JSON value. In the > > example above this sentence, > > > > $.store.book[(@.length-1)].title > > > > the symbol @ refers to a JSON array, with a JavaScript like property > "length". > > > > That arrays must support a JavaScript like property length is not > > explicitly stated in the draft, but is implied in two examples. This > > should be clarified. Not all implementations do, for example, > > implementations that support functions that can be invoked at the tail > > end of a path typically support a function call length() instead. > > Defining .length is part of the outstanding work on the expression > language. > > > I also think the @ notation could be better explained, this particular > > reader struggled to understand what was meant by "current object" in > > original Goessner, and had to figure it out from examples. > > Please send text. > > Gr=C3=BC=C3=9Fe, Carsten > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --0000000000001a16d205b5e7a7d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To Carsten's point about what we call things, the number = of distinguished terms per RFC8259 is pretty small: JSON text, value,=C2=A0= object, arr= ay, number, string.=C2=A0 Having spent quite a bit of time specifying JSON = DSLs, I find that using just those terms doesn't seem to get in the way= or cause problems, so I'd argue that we should stick to them=C2=A0(and bui= ld up to higher-level constructs as required for JSONPath).

On Mon, Dec 7, 2020 at 2:37 PM Carsten Bormann <cabo@tzi.org> wrote:
On 2020-12= -07, at 21:38, Daniel P <danielaparker@gmail.com> wrote:
>
> My general comment is that there is a lot of ambiguous language in the=
> draft,

As I said, work is needed.

I don=E2=80=99t plan to wait for adoption to start this work, so I created = a PR:

https://github.com/jsonpath-standard/inte= rnet-draft/pull/46

> and ambiguous language is the bane of implementers. Some
> examples below:
>
> One. "Data Item: A structure complying to the generic data model = of
> JSON, i.e., composed of containers such as arrays and maps (JSON
> objects), and of atomic data such as null, true, false, numbers, and > text strings."
>
> Why introduce the term "map" as the preferred (unparenthized= ) term?
> RFC 8259 doesn't mention "map", it uses JSON object.=C2= =A0

Sure.=C2=A0 That is probably one of the mistakes that were made in defining= the JSON terminology.

(Historically, what happened is that JavaScript has objects and atoms, but = arrays are almost, but not entirely unlike objects.=C2=A0 When JSON was def= ined, it only called the maps =E2=80=9Cobjects=E2=80=9D, making the term ob= ject be ambiguous between its standard meaning and the =E2=80=9CJSON object= =E2=80=9D meaning.=C2=A0 So to be unambiguous, it is best to have a term th= at unambiguously refers to =E2=80=9CJSON objects=E2=80=9D.=C2=A0 Maps natur= ally is that term, as would be longer terms such as dictionary.=C2=A0 If th= e WG does not like that term, we can of course revert to the more ambiguous= JSON terminology.)

> By following
> "arrays and maps" with "(JSON objects)", it could = be read that "arrays
> and maps" will collectively be referred to as "JSON objects= =E2=80=9D.

Yep, that is better the other way around.

> Later in
> the draft we read "the root object" ($) and "the curren= t object" (@),
> which almost suggest that that is the intended meaning.

That should be item.

> My own view is that the terminology should stay consistent with RFC > 8259, and that the word "object" should not be used for item= s that are
> not JSON objects in the sense of RFC 8259.

I agree with the latter, but the reason for that is that the RFC 8259 termi= nology is confusing, so we could try to be more unambiguous.

> What is the purpose of "such as" in the sentence? Aren't= the
> itemizations exclusive?

Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with =E2=80=9Cnamel= y=E2=80=9D.

> Two. "Since a JSON data item is usually anonymous and doesn't=
> necessarily have a "root member object", JSONPath used the a= bstract
> name $ to refer to the top level object of the data item."

Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D discussion, see= below).

> I realize this sentence is mostly copied from Goessner, but I didn'= ;t
> understand it there either. Regarding "doesn't necessarily&qu= ot; have a
> "root member object", what is that supposed to mean? It seem= s to me
> that the root is _always_ going to be an anonymous JSON value, which,<= br> > when Goessner was writing, could be a JSON array or object, and since<= br> > RFC 8259, any JSON value.

Many people who actually work with JSON don=E2=80=99t think in terms of dat= a items, but in terms of members (entries of a map, i.e. key/value pairs).= =C2=A0 Because JSON values are data items and members cannot exist outside = a map, this creates a need to wrap those members into maps, and to unwrap t= hem again what talking about them as members.

See https://ietf-wg-asdf.github.io/SDF/sdf= .html#name-sdfchoice for an example how that thinking looks like in pra= ctice (yes, I wrote that, fully cognizant of the dissonance).

But that prevalent thinking does not have to be reflected here, and I=E2=80= =99m proposing a change in the PR.

> Three.=C2=A0 "Where a JSONPath processor uses JSONPath expression= s as
> output paths, these will always be converted to the more general
> bracket-notation."

Fixed in PR.

> For output paths, Goessner uses the term "normalized path
> expressions", which should be unambiguously defined. For uniquene= ss,
> in addition to avoiding dot-notation, there would need to be other
> restrictions, including avoiding the descendant operator .., and
> filters.
>
> Four. "The symbol @ is used for the current object."

Fixed in PR.

> Only if you interpret "object" to mean _any_ JSON value. In = the
> example above this sentence,
>
> $.store.book[(@.length-1)].title
>
> the symbol @ refers to a JSON array, with a JavaScript like property &= quot;length".
>
> That arrays must support a JavaScript like property length is not
> explicitly stated in the draft, but is implied in two examples. This > should be clarified. Not all implementations do, for example,
> implementations that support functions that can be invoked at the tail=
> end of a path typically support a function call length() instead.

Defining .length is part of the outstanding work on the expression language= .

> I also think the @ notation could be better explained, this particular=
> reader struggled to understand what was meant by "current object&= quot; in
> original Goessner, and had to figure it out from examples.

Please send text.

Gr=C3=BC=C3=9Fe, Carsten

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--0000000000001a16d205b5e7a7d3-- From nobody Mon Dec 7 14:55:09 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10003A0C1E for ; Mon, 7 Dec 2020 14:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 dlyMAISaZPkP for ; Mon, 7 Dec 2020 14:55:04 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 8247C3A0C16 for ; Mon, 7 Dec 2020 14:55:04 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id a8so5703247lfb.3 for ; Mon, 07 Dec 2020 14:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vK2ezFYc6TFcCQxggA01G4sINLm6Lj8X9aFFfAyC3EA=; b=ROW4+kCmPBBt9eOVOs6Poy418PYiVuR0JozITSF4oeENgxsvPWNFf6vQQLeqdt1JJp AumyS1bjJoMZwXF6+JdPSHpBloTHDyOFde6vHH4N+8Ha6D45nON0gw0ZFGANKQGCax9E 0iIjUFs/dp/9bFFSgB5Idi9nA0xtjnGX7Yz5UPvOefIak7FB3ZuQQ71WILqrYq3VJvrZ RS4cG3QxB7nw2LoqeiafyXyq0OltLmrID0/i3JUzVXTbnFEbLMBr7J+goKkK0wwogxnh /EglXQxCrlVWO/rbN/E7rH5V5o7IYt/sdfe78l6uijIIW4ZarFZ96LT/RM7t0ouBcrEX OdIQ== 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; bh=vK2ezFYc6TFcCQxggA01G4sINLm6Lj8X9aFFfAyC3EA=; b=a6TDnIFGbnhVgCmFe/h9q4eXgeQCZBXwuzmdWxSdsW7kfNMhQiwVBW66rSIC6rFroB j5XJ1dn38mn85+RGAv9KwjD0Ugg0W/0zOwWdiH3axsX2ij6OSSs+qXf06BOzzTOeVexK ExNiaHlZ+34ZK9pZB8TwuW41IsVNeOO6QwWRp/Hot6ZFCBe02sRalUxDsO4CRPw/dOan V6MBp0B23C3FcqjEJN26IanUUhbRTc6x/bRqgenpq7kaL0fTvnPUM3Mkm8a4xuSaP7NL zoZHHufrHVS25sn18HNrqtPkRjjQhG4y3ZBW8iUb0hXesmR1CicXAIAcmQhMxufxec3l 3NZQ== X-Gm-Message-State: AOAM530nb9IrYtd34pa/1fQI78+iJd80F5643T7RstrbSomg/Obkejn9 VmPB/If2WmMTFiSdnOH5EDtbkQvWKuVXxJFX/rCdhA== X-Google-Smtp-Source: ABdhPJxEvdVtGbX8LmaSnnRN3KiOwEtr1U7AqWhyxmkcPv2paRB+YxCV5qUksMQfqZ3CuSqgFxd7zRYgrlkDsNv2SHg= X-Received: by 2002:ac2:4987:: with SMTP id f7mr2574437lfl.41.1607381702401; Mon, 07 Dec 2020 14:55:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 7 Dec 2020 14:54:51 -0800 Message-ID: To: Carsten Bormann Cc: Daniel P , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000063fac905b5e7b7bc" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:55:08 -0000 --00000000000063fac905b5e7b7bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=A6 oh, and I forgot the very useful "member". On Mon, Dec 7, 2020 at 2:50 PM Tim Bray wrote: > To Carsten's point about what we call things, the number of distinguished > terms per RFC8259 is pretty small: JSON text, value, object, array, > number, string. Having spent quite a bit of time specifying JSON DSLs, I > find that using just those terms doesn't seem to get in the way or cause > problems, so I'd argue that we should stick to them (and build up to > higher-level constructs as required for JSONPath). > > On Mon, Dec 7, 2020 at 2:37 PM Carsten Bormann wrote: > >> On 2020-12-07, at 21:38, Daniel P wrote: >> > >> > My general comment is that there is a lot of ambiguous language in the >> > draft, >> >> As I said, work is needed. >> >> I don=E2=80=99t plan to wait for adoption to start this work, so I creat= ed a PR: >> >> https://github.com/jsonpath-standard/internet-draft/pull/46 >> >> > and ambiguous language is the bane of implementers. Some >> > examples below: >> > >> > One. "Data Item: A structure complying to the generic data model of >> > JSON, i.e., composed of containers such as arrays and maps (JSON >> > objects), and of atomic data such as null, true, false, numbers, and >> > text strings." >> > >> > Why introduce the term "map" as the preferred (unparenthized) term? >> > RFC 8259 doesn't mention "map", it uses JSON object. >> >> Sure. That is probably one of the mistakes that were made in defining >> the JSON terminology. >> >> (Historically, what happened is that JavaScript has objects and atoms, >> but arrays are almost, but not entirely unlike objects. When JSON was >> defined, it only called the maps =E2=80=9Cobjects=E2=80=9D, making the t= erm object be >> ambiguous between its standard meaning and the =E2=80=9CJSON object=E2= =80=9D meaning. So >> to be unambiguous, it is best to have a term that unambiguously refers t= o >> =E2=80=9CJSON objects=E2=80=9D. Maps naturally is that term, as would b= e longer terms such >> as dictionary. If the WG does not like that term, we can of course reve= rt >> to the more ambiguous JSON terminology.) >> >> > By following >> > "arrays and maps" with "(JSON objects)", it could be read that "arrays >> > and maps" will collectively be referred to as "JSON objects=E2=80=9D. >> >> Yep, that is better the other way around. >> >> > Later in >> > the draft we read "the root object" ($) and "the current object" (@), >> > which almost suggest that that is the intended meaning. >> >> That should be item. >> >> > My own view is that the terminology should stay consistent with RFC >> > 8259, and that the word "object" should not be used for items that are >> > not JSON objects in the sense of RFC 8259. >> >> I agree with the latter, but the reason for that is that the RFC 8259 >> terminology is confusing, so we could try to be more unambiguous. >> >> > What is the purpose of "such as" in the sentence? Aren't the >> > itemizations exclusive? >> >> Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with =E2=80=9Cna= mely=E2=80=9D. >> >> > Two. "Since a JSON data item is usually anonymous and doesn't >> > necessarily have a "root member object", JSONPath used the abstract >> > name $ to refer to the top level object of the data item." >> >> Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D discussion, = see below). >> >> > I realize this sentence is mostly copied from Goessner, but I didn't >> > understand it there either. Regarding "doesn't necessarily" have a >> > "root member object", what is that supposed to mean? It seems to me >> > that the root is _always_ going to be an anonymous JSON value, which, >> > when Goessner was writing, could be a JSON array or object, and since >> > RFC 8259, any JSON value. >> >> Many people who actually work with JSON don=E2=80=99t think in terms of = data >> items, but in terms of members (entries of a map, i.e. key/value pairs). >> Because JSON values are data items and members cannot exist outside a ma= p, >> this creates a need to wrap those members into maps, and to unwrap them >> again what talking about them as members. >> >> See https://ietf-wg-asdf.github.io/SDF/sdf.html#name-sdfchoice for an >> example how that thinking looks like in practice (yes, I wrote that, ful= ly >> cognizant of the dissonance). >> >> But that prevalent thinking does not have to be reflected here, and I=E2= =80=99m >> proposing a change in the PR. >> >> > Three. "Where a JSONPath processor uses JSONPath expressions as >> > output paths, these will always be converted to the more general >> > bracket-notation." >> >> Fixed in PR. >> >> > For output paths, Goessner uses the term "normalized path >> > expressions", which should be unambiguously defined. For uniqueness, >> > in addition to avoiding dot-notation, there would need to be other >> > restrictions, including avoiding the descendant operator .., and >> > filters. >> > >> > Four. "The symbol @ is used for the current object." >> >> Fixed in PR. >> >> > Only if you interpret "object" to mean _any_ JSON value. In the >> > example above this sentence, >> > >> > $.store.book[(@.length-1)].title >> > >> > the symbol @ refers to a JSON array, with a JavaScript like property >> "length". >> > >> > That arrays must support a JavaScript like property length is not >> > explicitly stated in the draft, but is implied in two examples. This >> > should be clarified. Not all implementations do, for example, >> > implementations that support functions that can be invoked at the tail >> > end of a path typically support a function call length() instead. >> >> Defining .length is part of the outstanding work on the expression >> language. >> >> > I also think the @ notation could be better explained, this particular >> > reader struggled to understand what was meant by "current object" in >> > original Goessner, and had to figure it out from examples. >> >> Please send text. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> -- >> Jsonpath mailing list >> Jsonpath@ietf.org >> https://www.ietf.org/mailman/listinfo/jsonpath >> > --00000000000063fac905b5e7b7bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=A6 oh, and I forgot the very useful "member".=C2=A0

On M= on, Dec 7, 2020 at 2:50 PM Tim Bray <tbray@textuality.com> wrote:
To Carsten's point about what we call things, the number of disti= nguished terms per RFC8259 is pretty small: JSON text, value,=C2=A0object, array, numb= er, string.=C2=A0 Having spent quite a bit of time specifying JSON DSLs, I = find that using just those terms doesn't seem to get in the way or caus= e problems, so I'd argue that we should stick to them=C2=A0(and build up to= higher-level constructs as required for JSONPath).

On Mo= n, Dec 7, 2020 at 2:37 PM Carsten Bormann <cabo@tzi.org> wrote:
= On 2020-12-07, at 21:38, Daniel P <danielaparker@gmail.com> wrote:
>
> My general comment is that there is a lot of ambiguous language in the=
> draft,

As I said, work is needed.

I don=E2=80=99t plan to wait for adoption to start this work, so I created = a PR:

https://github.com/jsonpath-standard/inte= rnet-draft/pull/46

> and ambiguous language is the bane of implementers. Some
> examples below:
>
> One. "Data Item: A structure complying to the generic data model = of
> JSON, i.e., composed of containers such as arrays and maps (JSON
> objects), and of atomic data such as null, true, false, numbers, and > text strings."
>
> Why introduce the term "map" as the preferred (unparenthized= ) term?
> RFC 8259 doesn't mention "map", it uses JSON object.=C2= =A0

Sure.=C2=A0 That is probably one of the mistakes that were made in defining= the JSON terminology.

(Historically, what happened is that JavaScript has objects and atoms, but = arrays are almost, but not entirely unlike objects.=C2=A0 When JSON was def= ined, it only called the maps =E2=80=9Cobjects=E2=80=9D, making the term ob= ject be ambiguous between its standard meaning and the =E2=80=9CJSON object= =E2=80=9D meaning.=C2=A0 So to be unambiguous, it is best to have a term th= at unambiguously refers to =E2=80=9CJSON objects=E2=80=9D.=C2=A0 Maps natur= ally is that term, as would be longer terms such as dictionary.=C2=A0 If th= e WG does not like that term, we can of course revert to the more ambiguous= JSON terminology.)

> By following
> "arrays and maps" with "(JSON objects)", it could = be read that "arrays
> and maps" will collectively be referred to as "JSON objects= =E2=80=9D.

Yep, that is better the other way around.

> Later in
> the draft we read "the root object" ($) and "the curren= t object" (@),
> which almost suggest that that is the intended meaning.

That should be item.

> My own view is that the terminology should stay consistent with RFC > 8259, and that the word "object" should not be used for item= s that are
> not JSON objects in the sense of RFC 8259.

I agree with the latter, but the reason for that is that the RFC 8259 termi= nology is confusing, so we could try to be more unambiguous.

> What is the purpose of "such as" in the sentence? Aren't= the
> itemizations exclusive?

Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with =E2=80=9Cnamel= y=E2=80=9D.

> Two. "Since a JSON data item is usually anonymous and doesn't=
> necessarily have a "root member object", JSONPath used the a= bstract
> name $ to refer to the top level object of the data item."

Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D discussion, see= below).

> I realize this sentence is mostly copied from Goessner, but I didn'= ;t
> understand it there either. Regarding "doesn't necessarily&qu= ot; have a
> "root member object", what is that supposed to mean? It seem= s to me
> that the root is _always_ going to be an anonymous JSON value, which,<= br> > when Goessner was writing, could be a JSON array or object, and since<= br> > RFC 8259, any JSON value.

Many people who actually work with JSON don=E2=80=99t think in terms of dat= a items, but in terms of members (entries of a map, i.e. key/value pairs).= =C2=A0 Because JSON values are data items and members cannot exist outside = a map, this creates a need to wrap those members into maps, and to unwrap t= hem again what talking about them as members.

See https://ietf-wg-asdf.github.io/SDF/sdf= .html#name-sdfchoice for an example how that thinking looks like in pra= ctice (yes, I wrote that, fully cognizant of the dissonance).

But that prevalent thinking does not have to be reflected here, and I=E2=80= =99m proposing a change in the PR.

> Three.=C2=A0 "Where a JSONPath processor uses JSONPath expression= s as
> output paths, these will always be converted to the more general
> bracket-notation."

Fixed in PR.

> For output paths, Goessner uses the term "normalized path
> expressions", which should be unambiguously defined. For uniquene= ss,
> in addition to avoiding dot-notation, there would need to be other
> restrictions, including avoiding the descendant operator .., and
> filters.
>
> Four. "The symbol @ is used for the current object."

Fixed in PR.

> Only if you interpret "object" to mean _any_ JSON value. In = the
> example above this sentence,
>
> $.store.book[(@.length-1)].title
>
> the symbol @ refers to a JSON array, with a JavaScript like property &= quot;length".
>
> That arrays must support a JavaScript like property length is not
> explicitly stated in the draft, but is implied in two examples. This > should be clarified. Not all implementations do, for example,
> implementations that support functions that can be invoked at the tail=
> end of a path typically support a function call length() instead.

Defining .length is part of the outstanding work on the expression language= .

> I also think the @ notation could be better explained, this particular=
> reader struggled to understand what was meant by "current object&= quot; in
> original Goessner, and had to figure it out from examples.

Please send text.

Gr=C3=BC=C3=9Fe, Carsten

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--00000000000063fac905b5e7b7bc-- From nobody Mon Dec 7 15:03:18 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A33B3A0C4D for ; Mon, 7 Dec 2020 15:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ullsnzx-2l6C for ; Mon, 7 Dec 2020 15:03:11 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC8C3A0C29 for ; Mon, 7 Dec 2020 15:03:10 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Cqf3w4BCJzyVj; Tue, 8 Dec 2020 00:03:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 8 Dec 2020 00:03:08 +0100 Cc: Daniel P , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 629074987.901201-8fac21359800fd73cb16ed1b841e46d2 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 23:03:17 -0000 =E2=80=A6 and =E2=80=9Celement=E2=80=9D (the things in arrays). The two terms here that create a bit of a problem are JSON object = (which, as I mentioned, conflicts with the normal use of that term) and = JSON value. The problem with JSON value is that it also can be quite confusing due = to the usual use of that term. Pointing to a tree and saying =E2=80=9Cthe= values inside that tree=E2=80=9D is not going to be felt as equivalent = to =E2=80=9Cthe set of all subtrees of that tree, including the tree = itself=E2=80=9D. But if JSON value is the only term we have, it has to = be. Hence my preference to talk about data items when I mean the items = themselves and not their =E2=80=9Cvalue=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten > On 2020-12-07, at 23:54, Tim Bray wrote: >=20 > =E2=80=A6 oh, and I forgot the very useful "member".=20 >=20 > On Mon, Dec 7, 2020 at 2:50 PM Tim Bray wrote: > To Carsten's point about what we call things, the number of = distinguished terms per RFC8259 is pretty small: JSON text, value, = object, array, number, string. Having spent quite a bit of time = specifying JSON DSLs, I find that using just those terms doesn't seem to = get in the way or cause problems, so I'd argue that we should stick to = them (and build up to higher-level constructs as required for JSONPath). >=20 > On Mon, Dec 7, 2020 at 2:37 PM Carsten Bormann wrote: > On 2020-12-07, at 21:38, Daniel P wrote: > >=20 > > My general comment is that there is a lot of ambiguous language in = the > > draft, >=20 > As I said, work is needed. >=20 > I don=E2=80=99t plan to wait for adoption to start this work, so I = created a PR: >=20 > https://github.com/jsonpath-standard/internet-draft/pull/46 >=20 > > and ambiguous language is the bane of implementers. Some > > examples below: > >=20 > > One. "Data Item: A structure complying to the generic data model of > > JSON, i.e., composed of containers such as arrays and maps (JSON > > objects), and of atomic data such as null, true, false, numbers, and > > text strings." > >=20 > > Why introduce the term "map" as the preferred (unparenthized) term? > > RFC 8259 doesn't mention "map", it uses JSON object. =20 >=20 > Sure. That is probably one of the mistakes that were made in defining = the JSON terminology. >=20 > (Historically, what happened is that JavaScript has objects and atoms, = but arrays are almost, but not entirely unlike objects. When JSON was = defined, it only called the maps =E2=80=9Cobjects=E2=80=9D, making the = term object be ambiguous between its standard meaning and the =E2=80=9CJSO= N object=E2=80=9D meaning. So to be unambiguous, it is best to have a = term that unambiguously refers to =E2=80=9CJSON objects=E2=80=9D. Maps = naturally is that term, as would be longer terms such as dictionary. If = the WG does not like that term, we can of course revert to the more = ambiguous JSON terminology.) >=20 > > By following > > "arrays and maps" with "(JSON objects)", it could be read that = "arrays > > and maps" will collectively be referred to as "JSON objects=E2=80=9D. >=20 > Yep, that is better the other way around. >=20 > > Later in > > the draft we read "the root object" ($) and "the current object" = (@), > > which almost suggest that that is the intended meaning. >=20 > That should be item. >=20 > > My own view is that the terminology should stay consistent with RFC > > 8259, and that the word "object" should not be used for items that = are > > not JSON objects in the sense of RFC 8259. >=20 > I agree with the latter, but the reason for that is that the RFC 8259 = terminology is confusing, so we could try to be more unambiguous. >=20 > > What is the purpose of "such as" in the sentence? Aren't the > > itemizations exclusive? >=20 > Here, they are, so I replaced =E2=80=9Csuch as=E2=80=9D with = =E2=80=9Cnamely=E2=80=9D. >=20 > > Two. "Since a JSON data item is usually anonymous and doesn't > > necessarily have a "root member object", JSONPath used the abstract > > name $ to refer to the top level object of the data item." >=20 > Yep, item (and no need to open the =E2=80=9Cmember=E2=80=9D = discussion, see below). >=20 > > I realize this sentence is mostly copied from Goessner, but I didn't > > understand it there either. Regarding "doesn't necessarily" have a > > "root member object", what is that supposed to mean? It seems to me > > that the root is _always_ going to be an anonymous JSON value, = which, > > when Goessner was writing, could be a JSON array or object, and = since > > RFC 8259, any JSON value. >=20 > Many people who actually work with JSON don=E2=80=99t think in terms = of data items, but in terms of members (entries of a map, i.e. key/value = pairs). Because JSON values are data items and members cannot exist = outside a map, this creates a need to wrap those members into maps, and = to unwrap them again what talking about them as members. >=20 > See https://ietf-wg-asdf.github.io/SDF/sdf.html#name-sdfchoice for an = example how that thinking looks like in practice (yes, I wrote that, = fully cognizant of the dissonance). >=20 > But that prevalent thinking does not have to be reflected here, and = I=E2=80=99m proposing a change in the PR. >=20 > > Three. "Where a JSONPath processor uses JSONPath expressions as > > output paths, these will always be converted to the more general > > bracket-notation." >=20 > Fixed in PR. >=20 > > For output paths, Goessner uses the term "normalized path > > expressions", which should be unambiguously defined. For uniqueness, > > in addition to avoiding dot-notation, there would need to be other > > restrictions, including avoiding the descendant operator .., and > > filters. > >=20 > > Four. "The symbol @ is used for the current object." >=20 > Fixed in PR. >=20 > > Only if you interpret "object" to mean _any_ JSON value. In the > > example above this sentence, > >=20 > > $.store.book[(@.length-1)].title > >=20 > > the symbol @ refers to a JSON array, with a JavaScript like property = "length". > >=20 > > That arrays must support a JavaScript like property length is not > > explicitly stated in the draft, but is implied in two examples. This > > should be clarified. Not all implementations do, for example, > > implementations that support functions that can be invoked at the = tail > > end of a path typically support a function call length() instead. >=20 > Defining .length is part of the outstanding work on the expression = language. >=20 > > I also think the @ notation could be better explained, this = particular > > reader struggled to understand what was meant by "current object" in > > original Goessner, and had to figure it out from examples. >=20 > Please send text. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > --=20 > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath From nobody Mon Dec 7 17:49:49 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911E03A0D4A for ; Mon, 7 Dec 2020 17:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cLFG6Mc7iFdv for ; Mon, 7 Dec 2020 17:49:46 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 C13F13A0B17 for ; Mon, 7 Dec 2020 17:49:14 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id c1so2696366wrq.6 for ; Mon, 07 Dec 2020 17:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HUbrGH83pTwim2YtvGpmO9T+ruH8WQ2W9gD5awJBJXo=; b=TuokS/0VKLXyUNLbAAzpNd29K8ccwMzoRDvqiKQlKu/3eN5Z1rbTG6rKV/QVVqiZTP TMM0hfMy9gR8pRyX4MzjW1f/GgnUFX/iSpYTYQr7l95XknTuxumRLH1ndZtToMABb4y1 2e0cao8KsRuhtsGEP3RZC4hr0h569o+Dt/Rs4MBjfedd7sjF1lYEOGQ9rDnalSR/oXxM nsS6DqS1tZCQBDYXyoJ/iAKjr0u9kwzQ3G+35ey6NANkfSzSavV7W++agm5HKbXLVC5H sZ5badugV4bQekR+qmzcUYvO6NwEFYN+RvztmVinfR9xfaaindS1/YqXCubcsA0wx0h5 yPhA== 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; bh=HUbrGH83pTwim2YtvGpmO9T+ruH8WQ2W9gD5awJBJXo=; b=MELUJNSteqqkik1vFB9popltY8scPfYkw3q1EkpoOIAzrTSNmOqQhcJUjfucI2SdZV JeVpWF+FFfIPOAzPe0wBauTja4S1AYB/TOxfgcrf/NnNpy0uEl/BvnLnlVvrEtHcVfF8 zLWZfy+pqRAvVefrFTrftwXKT1DC9QwGWZVs8R1tevJ/IG9fAGV3S952IREhShyaSAy4 LiZVQYmSzCuxJbmkuG0eUAVyPLiHFOT9ZUh+GTrkrlmv/X+TXozU22XKaqLSZfMAvFrU U9/J/kFkAeSo15W8qRki5eF6EnFiDKJLpE5Py7ZFSOyMxcsXMsyhBNzoJKSQa1oHRuJk MVug== X-Gm-Message-State: AOAM5334D3918xEUl+G2H4yZ6fbyhF19xgyIHIXUmChVPSe4FOLo75XT 8OabQ5U/TGXGq0777OyhUNATQ4/105cIogaS5JU= X-Google-Smtp-Source: ABdhPJzvwwRob7m2Tz4B26v5IcSxgZybKCOunCGlTqHpQf/RJrHAXjD9SyyRH8jH4j7wHphE8/oe9HGRinxW0LfHpb0= X-Received: by 2002:adf:ec92:: with SMTP id z18mr20642351wrn.166.1607392153056; Mon, 07 Dec 2020 17:49:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Mon, 7 Dec 2020 20:49:00 -0500 Message-ID: To: Carsten Bormann Cc: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 01:49:48 -0000 On Mon, Dec 7, 2020 at 5:37 PM Carsten Bormann wrote: > On 2020-12-07, at 21:38, Daniel P wrote: > > > > I also think the @ notation could be better explained, this particular > > reader struggled to understand what was meant by "current object" in > > original Goessner, and had to figure it out from examples. > > Please send text. > Related to that, it would be helpful to determine if JSONPath filters apply to both JSON objects and arrays, or only to JSON arrays. Our excellent Burgmer JSONPath comparison has that covered https://cburgmer.github.io/json-path-comparison/results/filter_expression_on_object.html and there is no consensus. For comparison, I note that JMESPath only defines filters for arrays. For JSON arrays, perhaps text along the following lines: In a filter expression evaluated against a JSON array, each item in the array is evaluated in sequence, and the current item being evaluated is represented by the symbol @. For JSON objects, it's less clear, but perhaps In a filter expression evaluated against a JSON object, the object itself is represented by the symbol @. For Burgmer's case, that's consistent with the minority of implementations that returned {"key": 42, "another": {"key": 1}} Daniel From nobody Mon Dec 7 19:34:14 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA0B3A0DF4 for ; Mon, 7 Dec 2020 19:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SjPC-A0O_XKb for ; Mon, 7 Dec 2020 19:34:10 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 8A6643A0DED for ; Mon, 7 Dec 2020 19:34:10 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id b9so12279958ejy.0 for ; Mon, 07 Dec 2020 19:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=HUz0KIAoGpyrRPZGyJUAP0GzPwSWTpvbo9dlPo8g0fs=; b=VTdEuR2yS+BXrxQUG2Pw8fNo5aGe1uqgwAItZrH3qh3SXQeQY12HCF+nbH3o4OndGg JuWlvi1PGXnioakml+BHluV2n1/OpPv+mACejs9AUua4XEs5ljcinQ1u5RiZjQtWADxH wOuRXGL92V4NoDvfFUxpzuJhXGh3PAqJeJVigAcatRN1CCwKd1qoZa9XIFbHqB/oi5M3 hYIdtnC7yKzk7Mo+ffIZJoUcx/bCX6yrIXG5qfazQ5gk0ppdcA5IFdZjqE4ULT3gAhpb +J3C913yS5sqYQrU1ZuW9ZtG5bWPxKjoabjQf7KL7664UkofnXaLLbB/4YaH882Pty4D JyAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=HUz0KIAoGpyrRPZGyJUAP0GzPwSWTpvbo9dlPo8g0fs=; b=D+lUAZ9jmo+PlKWUFc0imBMYABIBY1cRJrRPCsVCqnkIVLFHFYPWQWbeJsGkvEkk/8 D0l67xty34ov+gqgUeo8mSZ9lHC/o1FSd+O6AkOsBelz7aX4Dh9HQETX4u0bqxilAXja 1LAp9A56fVW5Hu/aIR7lhzT8Zk8UxzGHbKsdmMfd3xUZnAQmGviUZ4ZMCac4S0zVn1gD cdjTysdV7GSlCHZfIOaUJwHB539Q78/tMV5iwEojRd95iygYLxxtwRRACpuJBv4QxhBr E6CyVimdl3cGrCMqFENpKKG2Eotc4KtdOAiSD7dgrvdklGjsP9pHPzf6HqFSA8X3ZZrq 7zpQ== X-Gm-Message-State: AOAM5333SYx5wpIRd+GQB2YWm7ncOHABVttinfV554YckMomscwLS2dm SqNdQOHMTBU/IB+EDeMylLs= X-Google-Smtp-Source: ABdhPJz8xVYM9PzvRbayImvxYnqzXXs7w9JIPA95BxjNs1uUnT2MZhEZpHmhZthS7cc1E6p3YtjdMA== X-Received: by 2002:a17:906:7b8d:: with SMTP id s13mr5279914ejo.479.1607398448955; Mon, 07 Dec 2020 19:34:08 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id ng1sm13415378ejb.112.2020.12.07.19.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 19:34:07 -0800 (PST) Message-ID: <6ad4a8fd2925b7cfdfbdb5c7ad97120f723a2d05.camel@gmail.com> From: Glyn Normington To: James , jsonpath@ietf.org Date: Tue, 08 Dec 2020 03:34:06 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 03:34:12 -0000 I support this adoption. I note the document is an imperfect starting point only and the WG is free to change anything in it. On Mon, 2020-12-07 at 21:54 +0100, James wrote: > This begins a 2 week working group adoption call for > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, > ending > Tuesday, December 22nd 2020. This document is the merging of Glyn's > original document with draft-goessner-dispatch-jsonpath, and is a > starting point and not specification complete. > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons > for > that support (or lack thereof) as silence will not be considered as > consent. > > > Thanks! > > Tim & James > From nobody Mon Dec 7 20:00:26 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A543A0DF6 for ; Mon, 7 Dec 2020 20:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AzjyhPUAovxE for ; Mon, 7 Dec 2020 20:00:22 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 0140F3A0DF7 for ; Mon, 7 Dec 2020 20:00:21 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id v22so16111754edt.9 for ; Mon, 07 Dec 2020 20:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=24Fla/4fsjV2ZQxIOnbQpEqDDD79N0y/34r+6y8Gy+k=; b=l6yN73tXiCCzi8jjOp0y7W8yeiSlOLhZoGPQFKIsThjQmFUBsxwMka7FW0r7HyXhT0 q7zJnTOyK1RcWSaXSudKpZNCK3F3oERGN4hfJ6xNV8Lp0cDQUu/BDfAvb/6N0QwCEOqv 1rDDnJTMKDxC0TG4xSEk1aukcKWhKtL/CnKCHAxWocBIsW6BSHwPJrzmxkc7N/4r7siu oa5s7esCFZWj+YLJ8Ccv68RvUx9RaPMud+3tuE5FzWx5U74xCcalnmQvV4E0aYwkoo6z SUV8deZ93Ys8v9/re4g7DwqnErLRroVuIZjlz75OCNgXXihRTYcgkfCb491Q6CyGL0qD tgLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=24Fla/4fsjV2ZQxIOnbQpEqDDD79N0y/34r+6y8Gy+k=; b=daY1tn4PshWa6aLZbopKJ85MbZGvZthHkZrLrgiXxiikWkjJzNtc3SgjnYtEtTRDUC +Jb4iU56Tn0jL8jZEITJzym2G0kOqSP4DUHhmObKyvltTJSRPlwEr8cPy2cntSfOgx1q bxfYuyQXHXHrLBL0E81+Yma18uftFZ/Uu4Cno9bzwgbGIPKWJXJwXMO2Lfcw8Ta4CYrI APa/4al6rE/uzTkXUjDlb9ZFb/Vsye5Ls+UrfNWBSqvJrxr4KiZ4Y0x4kR9bZIQiErWz GhlPBIKh2ZAG1nd0cLQeRq2I16/cHsneSZP5jIyV680pJ4Blsfu4/CiMb5XHClv0X8S2 6hxA== X-Gm-Message-State: AOAM530BY5Cu+kiExydH9BYy7tKjkBwXS1Gxg+NFNlHuHcL6kbkeAheD W4DWjCu1LBnNK48B5yfru2E= X-Google-Smtp-Source: ABdhPJw0gAnaNUPR5nAi7tUwLY6trVBkgYQIozw3slXLT7ZW9aucLRT7TvLcAXcCrRQ7jTh8M6bwNg== X-Received: by 2002:a50:c406:: with SMTP id v6mr20998016edf.367.1607400020323; Mon, 07 Dec 2020 20:00:20 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id i26sm6098107eja.23.2020.12.07.20.00.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 20:00:19 -0800 (PST) Message-ID: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> From: Glyn Normington To: Daniel P , Carsten Bormann Cc: jsonpath@ietf.org Date: Tue, 08 Dec 2020 04:00:18 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 04:00:24 -0000 On Mon, 2020-12-07 at 20:49 -0500, Daniel P wrote: > On Mon, Dec 7, 2020 at 5:37 PM Carsten Bormann wrote: > > On 2020-12-07, at 21:38, Daniel P wrote: > > > I also think the @ notation could be better explained, this > > > particular > > > reader struggled to understand what was meant by "current object" > > > in > > > original Goessner, and had to figure it out from examples. > > > > Please send text. > > > Related to that, it would be helpful to determine if JSONPath filters > apply to both JSON objects and arrays, or only to JSON arrays. Our > excellent Burgmer JSONPath comparison has that covered > > https://cburgmer.github.io/json-path-comparison/results/filter_expression_on_object.html > > and there is no consensus. For comparison, I note that JMESPath only > defines > filters for arrays. I would support restricting filters to arrays, if others agree. > > For JSON arrays, perhaps text along the following lines: > > In a filter expression evaluated against a JSON array, each > item in the array is evaluated in sequence, and the current item > being evaluated is represented by the symbol @. > > For JSON objects, it's less clear, but perhaps > > In a filter expression evaluated against a JSON object, the object > itself is represented by the symbol @. Regardless of the current consensus, or lack of one, I find this confusing since @ does not correspond to the current item (meaning an individual member of the object). It's also unhelpful in deciding which items to filter in/out. > > For Burgmer's case, that's consistent with the minority of > implementations > that returned > > {"key": 42, "another": {"key": 1}} > > Daniel > From nobody Mon Dec 7 21:00:13 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF7B3A0E29 for ; Mon, 7 Dec 2020 21:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZJcWTyF6XDr8 for ; Mon, 7 Dec 2020 21:00:11 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 BE2AD3A0E27 for ; Mon, 7 Dec 2020 21:00:10 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id r3so14921554wrt.2 for ; Mon, 07 Dec 2020 21:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UnnNWvE97mSyVB/DXjqm9ieauKrNg/9hhocUYJAJT3s=; b=YMwjhnbVJkfnCz6SWvs18TivXH5isvB/IHpOEYMET6siYd2I4/x7/MfDsVnOIBUz/+ cUzqPjJCcWjmSJpIARdG2zn4qt/u3gFoSbV/F2hcavAPOFBwumbpT9cYEdyT0MCcVsFR Cee93Imn2pdxW+jBreRAJlb7I/nRn2CDK0vgeKaG4bEca47BasP33+ZHYhe6OkY2Oc+A xdQW66rcn8YOAup/0+Yl57F4X6DkrJSaUp0FkZom8fB/V186zKLsTrjQCUbdET/RsR0o swC7L7hRWVPKf2m602G9cYYerfwxotn039PeM+GvqGNgPeXMqj12ix7kRGdgcEK8AxY5 bviA== 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; bh=UnnNWvE97mSyVB/DXjqm9ieauKrNg/9hhocUYJAJT3s=; b=nDNrheKqy9IiwwoHMaJ8JAKsUeqwtUvmey+wO+pl66ReMsNKWiwEhTKpjDl91TCSOm PY9iEyDx83fRDQ6YWcaTsYyxRsY6L3bCS9gL8yRySjuZGeXkaqspk9ynkDSxeSU9phek CLoK5ATZ00SqOVibvVJd2jirRwBnwdpc7iNTuruxngim/FMYKUCrFFn0IMbdw/QluUri M2Din/htOPxWS07nefP20TEIOub4KW2XdUbYMH295PJWizpG9JNvWpsiYs3tc+c5N92X epQyaCAmAMVdwdaOZ1/+JGgrufs3D6YvxXQm3vaXWdO1C/HR+M3tkiUAg3b/IfvzKLo+ dfEg== X-Gm-Message-State: AOAM533d9KGWg9oG3y323SU5xXEFxoUOJJjQEbql+wMLIbSN3CXJLxCm PpZmM+a3PnU5Tc4ES0HWA8kLELvyJh5pEJh5RxI= X-Google-Smtp-Source: ABdhPJzBO3tfSaZNv9tWZ3W/uldx+yvbGD0dtNCPQ4SLlAjukMTfTrAUScBxLAtho43qnalxtOrYoI0Hr8ZIHOszMq0= X-Received: by 2002:a5d:6884:: with SMTP id h4mr3831783wru.174.1607403608952; Mon, 07 Dec 2020 21:00:08 -0800 (PST) MIME-Version: 1.0 References: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> In-Reply-To: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> From: Daniel P Date: Mon, 7 Dec 2020 23:59:56 -0500 Message-ID: To: Glyn Normington Cc: Carsten Bormann , jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 05:00:12 -0000 On Mon, Dec 7, 2020 at 11:00 PM Glyn Normington wrote: > On Mon, 2020-12-07 at 20:49 -0500, Daniel P wrote: > I would support restricting filters to arrays, if others agree. > That would be simplest. > > > > For JSON objects, it's less clear, but perhaps > > > > In a filter expression evaluated against a JSON object, the object > > itself is represented by the symbol @. > > Regardless of the current consensus, or lack of one, I find this > confusing since @ does not correspond to the current item (meaning an > individual member of the object). It's also unhelpful in deciding which > items to filter in/out. > The "current item" is what is being defined. In my suggested definition, it is defined as the JSON object itself. With that definition, there can be only one current object, and it is either selected or not. It is noted that this definition is asymmetric with a filter expression evaluated against a JSON array, as with a JSON array, the expression is evaluated against its elements, and with a JSON object, the expression is evaluated against the object itself (not its members.) In Burgmer's case, the JSONPath expression "$[?(@.key)]" is applied to the JSON instance {"key": 42, "another": {"key": 1}}. Implementations that interpret the "current item" to be {"key": 42, "another": {"key": 1}}, i.e. the whole object, find that @.key evaluates as true, and select the whole object. It looks like that includes 9 implementations. The other "minority opinion" result is [{"key": 1}]. It looks like that includes 13 implementations. I think that implies a definition: In a filter expression evaluated against a JSON object, the value part of each name-value pair is evaluated in succession, and the value part being evaluated is represented by the symbol @. Daniel From nobody Tue Dec 8 00:17:21 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2583A0DFA for ; Tue, 8 Dec 2020 00:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h2l7DKoKupL6 for ; Tue, 8 Dec 2020 00:17:18 -0800 (PST) Received: from smtp.iit.cnr.it (mx5.iit.cnr.it [146.48.98.152]) by ietfa.amsl.com (Postfix) with ESMTP id 160CD3A0D3C for ; Tue, 8 Dec 2020 00:17:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 810CBC024C for ; Tue, 8 Dec 2020 09:17:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDAoUMAXugvW for ; Tue, 8 Dec 2020 09:17:14 +0100 (CET) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 0F759C0142 for ; Tue, 8 Dec 2020 09:17:14 +0100 (CET) To: jsonpath@ietf.org References: From: Mario Loffredo Message-ID: <5b0fa110-3a1b-0b95-a832-2af20721671d@iit.cnr.it> Date: Tue, 8 Dec 2020 09:13:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: it Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 08:17:20 -0000 I support adoption. Mario Il 07/12/2020 21:54, James ha scritto: > This begins a 2 week working group adoption call for > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, > ending Tuesday, December 22nd 2020. This document is the merging of > Glyn's original document with draft-goessner-dispatch-jsonpath, and is > a starting point and not specification complete. > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as > consent. > > > Thanks! > > Tim & James > -- Dr. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo From nobody Tue Dec 8 00:38:38 2020 Return-Path: X-Original-To: jsonpath@ietf.org Delivered-To: jsonpath@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E58BB3A0E78; Tue, 8 Dec 2020 00:38:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jsonpath-chairs@ietf.org, superuser@gmail.com, jsonpath@ietf.org, james.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160741670785.14840.6742929596893056804@ietfa.amsl.com> Date: Tue, 08 Dec 2020 00:38:27 -0800 Archived-At: Subject: [Jsonpath] jsonpath - New Meeting Session Request for IETF 110 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 08:38:36 -0000 A new meeting session request has just been submitted by James Gruessing, a Chair of the jsonpath working group. --------------------------------------------------------- Working Group Name: JSON Path Area Name: Applications and Real-Time Area Session Requester: James Gruessing Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: httpbis dispatch avtcore ntp People who must be present: Tim Bray Murray Kucherawy James Gruessing Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 8 01:32:02 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597F13A067A for ; Tue, 8 Dec 2020 01:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8icPSLJ31Kt1 for ; Tue, 8 Dec 2020 01:31:58 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 D6B1F3A0659 for ; Tue, 8 Dec 2020 01:31:58 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id e2so3342489pgi.5 for ; Tue, 08 Dec 2020 01:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b6cuSKzawXP95THD26BpCaxKEclRlbr8PUzJfrxDMQk=; b=C3Svq8wJRv2QbFXGe0fbe4c6nMnuY9u1fIWzfrzkOze64nxaiNiLW8lPBm7sg9m9lh Joi4FzBF0qgkbYoG3mi34cxgWy6AtmC6iKzceJ1SUwDKtKI8USMznv2P5cZ2tg754BKL iI7KqI/PlK75Pq7VFEO7kNxcAqKqeK+Ml7drbtdGrpx+k9okKx5ouVYj7Ep8HwJ9kyXQ gO6/t7uPBle28Go2El6xFz4EiGJXJ65GTsoeYUYAUXEBbT2Tqt2EODSlTUwONztZ7cil RamBqHMlMAlyC9NgM5LCt0qokFm992x4l7Spk6lL/WDf3d7KumTKOFlddMe89R7YPOlZ UQ1A== 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; bh=b6cuSKzawXP95THD26BpCaxKEclRlbr8PUzJfrxDMQk=; b=JKlzXAOG7qUbPym2XfaxfX4jHShkIQS2QKzTopfLiott1u6zLipbMQnL+2VJH+YAH9 DPHrYcHGLCm47RiKM4H30rnM/SKlLdyZGdxwlIheX3OVL2mtyqxn4LjVEhBfzcXE2/V6 Bdl4dWniQWX7FWaqgRlFVwh0l2BLIuW8NzMOhmDZKFqo0qyv4zkQDFZVKlcYcC5fgzQu nwGyZNY0KcSiwdIiLS3+5n7Dd1Oa08aVcsmx3j+AOjUZjZTEXdr51hBJhoou7+1gfljE UJRsWRivIIN6d4RS+OQeSEQL7/5w4tMUAHX6fRMRUo1wawqAQIcx2+0RlTS1Vscgb0rE G10A== X-Gm-Message-State: AOAM5317uEE16EcFGm2R4PZDOK5/Wokh2TMkJBaOK0JQRxqtqB/gJnhs pLuyeOnIrz496EqMaySPS0NMiK52rz3MhVZxm+0= X-Google-Smtp-Source: ABdhPJxS4Nh6AGT3q00EYLduKPXts609Qw8IZqydnh+7Ly8AfuP52U79TV7C5dJKLYkBcoxBOtTOo9Ct1FOW42rG8O0= X-Received: by 2002:a17:90a:d3cf:: with SMTP id d15mr3354899pjw.132.1607419918358; Tue, 08 Dec 2020 01:31:58 -0800 (PST) MIME-Version: 1.0 References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> In-Reply-To: From: Glyn Normington Date: Tue, 8 Dec 2020 09:31:47 +0000 Message-ID: To: Daniel P Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d1cd605b5f09d7c" Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 09:32:00 -0000 --0000000000003d1cd605b5f09d7c Content-Type: text/plain; charset="UTF-8" Did anyone else have an opinion on the behaviour of slices such as [::0]? The current draft allows this and says it returns an empty array, but there is good reason to say it should error so that the slice operation is then consistent with Python slicing. See below for more context. On Thu, 26 Nov 2020 at 10:22, Glyn Normington < glyn.normington.work@gmail.com> wrote: > On 26 Nov 2020, at 09:49, Glyn Normington > wrote: > > > (3) "When step is 0, no elements are selected. This is the one case > which differs from the behaviour of Python, which raises an error in > this case." p. 10 > > Is there a rationale for that choice? As you note, in Python it is an > error. In JMESPath it is also an error, see > https://jmespath.org/specification.html#slices. > > > The rationale is the supposed consensus of implementations. > > > Unless I've missed it, Christoph Burgmer doesn't have a test case for > a slice where step is zero. Perhaps we can prevail upon him to add > one. > > > I will add that test. > > > It turns out there is such a test already, but no consensus: > > > https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html > > Maybe raising an error to be consistent with Python would be a good move. > What do others think? > > --0000000000003d1cd605b5f09d7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Did anyone else have an opinion on the behaviour of slices= such as [::0]? The current draft allows this and says it returns an empty = array, but there is good reason to say it should error so that the slice op= eration is then consistent with Python slicing. See below for more context.=

On Thu, 26 Nov 2020 at 10:22, Glyn Normington <glyn.normington.work@gmail.com> wrote:<= br>
On 26 Nov 2020, at 09:49, Glyn Normington <glyn.normi= ngton.work@gmail.com> wrote:

<= div>
(3) "When step is 0= , no elements are selected. This is the one case
which differs from the = behaviour of Python, which raises an error in
this case." p. 10
=
Is there a rationale for that choice? As you note, in Python it is anerror. In JMESPath it is also an error, see
https://jmespath.org/spe= cification.html#slices.

The rationale is the supposed consensu= s of implementations.


Unless I've missed it, Christoph= Burgmer doesn't have a test case for
a slice where step is zero. Pe= rhaps we can prevail upon him to add
one.

I will add that test.=

It turns out there is such a= test already, but no consensus:


Maybe raising= an error to be consistent with Python would be a good move. What do others= think?

--0000000000003d1cd605b5f09d7c-- From nobody Tue Dec 8 02:29:25 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1905D3A0AA7 for ; Tue, 8 Dec 2020 02:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FCdJW2GOWj4u for ; Tue, 8 Dec 2020 02:29:22 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659C83A0A96 for ; Tue, 8 Dec 2020 02:29:21 -0800 (PST) Received: from cpc160115-rdng30-2-0-cust150.15-3.cable.virginm.net ([86.19.35.151] helo=[192.168.0.27]) by smtp03.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from ) id 1kmaFD-00023Q-HI; Tue, 08 Dec 2020 10:29:20 +0000 From: Michael Kay Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B9A559C7-D32F-414B-B017-498FF8061783" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Tue, 8 Dec 2020 10:29:18 +0000 In-Reply-To: Cc: Daniel P , jsonpath@ietf.org To: Glyn Normington References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> X-Mailer: Apple Mail (2.3445.9.7) X-Mailcore-Auth: 439400257 X-Mailcore-Domain: 1881035 Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 10:29:24 -0000 --Apple-Mail=_B9A559C7-D32F-414B-B017-498FF8061783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My advice based on experience of XPath design mistakes would be: decide = your policy on errors and then apply it consistently. Either try and = minimise errors by making all meaningless constructs exhibit some kind = of fallback behaviour, or maximise errors by making all meaningless = constructs fail, but don't do it different ways for different errors. On the whole I think JSONPath is designed to be "forgiving", i.e. such = things aren't errors, e.g. I think I read in the spec that filtering a = non-array isn't an error, it's some kind of no-op. That approach isn't = always best for everyone, but it's important to be consistent. Michael Kay Saxonica=20 > On 8 Dec 2020, at 09:31, Glyn Normington = wrote: >=20 > Did anyone else have an opinion on the behaviour of slices such as = [::0]? The current draft allows this and says it returns an empty array, = but there is good reason to say it should error so that the slice = operation is then consistent with Python slicing. See below for more = context. >=20 > On Thu, 26 Nov 2020 at 10:22, Glyn Normington = > = wrote: > On 26 Nov 2020, at 09:49, Glyn Normington = > = wrote: >>=20 >>> (3) "When step is 0, no elements are selected. This is the one case >>> which differs from the behaviour of Python, which raises an error in >>> this case." p. 10 >>>=20 >>> Is there a rationale for that choice? As you note, in Python it is = an >>> error. In JMESPath it is also an error, see >>> https://jmespath.org/specification.html#slices = . >>=20 >> The rationale is the supposed consensus of implementations. >>=20 >>>=20 >>> Unless I've missed it, Christoph Burgmer doesn't have a test case = for >>> a slice where step is zero. Perhaps we can prevail upon him to add >>> one. >>=20 >> I will add that test. >=20 > It turns out there is such a test already, but no consensus: >=20 > = https://cburgmer.github.io/json-path-comparison/results/array_slice_with_s= tep_0.html = >=20 > Maybe raising an error to be consistent with Python would be a good = move. What do others think? >=20 > --=20 > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath --Apple-Mail=_B9A559C7-D32F-414B-B017-498FF8061783 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My = advice based on experience of XPath design mistakes would be: decide = your policy on errors and then apply it consistently. Either try and = minimise errors by making all meaningless constructs exhibit some kind = of fallback behaviour, or maximise errors by making all meaningless = constructs fail, but don't do it different ways for different = errors.

On the whole = I think JSONPath is designed to be "forgiving", i.e. such things aren't = errors, e.g. I think I read in the spec that filtering a non-array isn't = an error, it's some kind of no-op. That approach isn't always best for = everyone, but it's important to be consistent.

Michael Kay
Saxonica 

On 8 Dec 2020, at 09:31, Glyn = Normington <glyn.normington.work@gmail.com> wrote:

Did anyone else have an opinion on the behaviour of slices = such as [::0]? The current draft allows this and says it returns an = empty array, but there is good reason to say it should error so that the = slice operation is then consistent with Python slicing. See below for = more context.

On Thu, 26 = Nov 2020 at 10:22, Glyn Normington <glyn.normington.work@gmail.com> wrote:
On 26 Nov 2020, at 09:49, Glyn Normington <glyn.normington.work@gmail.com> wrote:

(3) "When step is 0, no elements are = selected. This is the one case
which differs from the = behaviour of Python, which raises an error in
this case." = p. 10

Is there a rationale for that choice? = As you note, in Python it is an
error. In JMESPath it is = also an error, see
https://jmespath.org/specification.html#slices.

The rationale is = the supposed consensus of implementations.


Unless I've missed it, = Christoph Burgmer doesn't have a test case for
a slice = where step is zero. Perhaps we can prevail upon him to add
one.

I will add that = test.

It turns out there is such a test already, but no = consensus:

https://cburgmer.github.io/json-path-comparison/results/array_s= lice_with_step_0.html

Maybe raising an error to be consistent with Python would be = a good move. What do others think?

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

= --Apple-Mail=_B9A559C7-D32F-414B-B017-498FF8061783-- From nobody Tue Dec 8 02:33:35 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F623A0ABB for ; Tue, 8 Dec 2020 02:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4NG0GINtj2TO for ; Tue, 8 Dec 2020 02:33:32 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 E54403A0AB5 for ; Tue, 8 Dec 2020 02:33:31 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id r5so16994154eda.12 for ; Tue, 08 Dec 2020 02:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=KQg0yW5/uaZmQp+D3PDx4I2HWZJzgEUZ/qITLQreynM=; b=olsJsZWaaCiI1lje6FUnPj8aXwH/hQAs76wA4xF2G9iFuqqmKXmqHC9zxoFNN/GZzR nuywkIYsWUYYln9bQY1rNF8pOa0/PHhxKeOasRD6OO81PJdRjvcg6NYsM84cN527+zyJ y7ngNaEn028iFxEAs9jYQHfFlCfuworsNVYyFbYfOD5HzfLlLAEuq2W2ghOmSO6hUj0g Zt1YvTniu5aJxkNyTrsWZvX7NjTyBzbB6b6M+rI2UlrcR1ZSG1TyqGP5qkHWZzm1QQLR cg3NfefeZsTcrl6Clwb07ta/6kbFJHGkyTwVdm+aSSpEF3k89jMrtXkJy30e8zBzobg8 ulUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=KQg0yW5/uaZmQp+D3PDx4I2HWZJzgEUZ/qITLQreynM=; b=KLSF6FKnmuOVT5NFy5mHc4BKZ6Bc6+lEXatn91LHV/RDRT8tn/+5GxzaEMAUVnDDe+ 1vaqb18O2MZ2TXchSpKCYAehSAayAkaalL31u/NMOvxxvC/HFbwzLwsyy8D7JJupbVeG r9lFVhQilA5y8bz9sU+CUnxXnxIwyV53exilHS/7tyVQ8GWbmVRbXZnzJmgiTriI4/qh K0D+7lM6F1RjfGeIkfyO9/vfkbUFaUoNmd5LfbQM1Ib9n1X3vulCRkidLfBXIL8NthHv ojYRZWTco/BUSokZzLm6TqGUeLKlJpN/waYv7wZ+9tHki1cGO5hnvd/dODPfQ2TORXI7 JYRg== X-Gm-Message-State: AOAM532ePZjaVrvzMf7C0P9vIFFtVei5qj+HO/p4YZ2BnQrz9K1PDZK7 B3cLQQFTdlN4WLlpHM5lTSg= X-Google-Smtp-Source: ABdhPJyPoFl4szFc6tbirWGA6ovCLtuGMT9ycDskHhE1HXWRGCPLTPywiGqRxxUYutfyrblk2dgMHA== X-Received: by 2002:a05:6402:412:: with SMTP id q18mr6737850edv.213.1607423610195; Tue, 08 Dec 2020 02:33:30 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id cb14sm15212688ejb.105.2020.12.08.02.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 02:33:29 -0800 (PST) Message-ID: <6df98bfccc466c277bf99b495788398150aae56d.camel@gmail.com> From: Glyn Normington To: Michael Kay Cc: Daniel P , jsonpath@ietf.org Date: Tue, 08 Dec 2020 10:33:28 +0000 In-Reply-To: References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 10:33:34 -0000 On Tue, 2020-12-08 at 10:29 +0000, Michael Kay wrote: > My advice based on experience of XPath design mistakes would be: > decide your policy on errors and then apply it consistently. Either > try and minimise errors by making all meaningless constructs exhibit > some kind of fallback behaviour, or maximise errors by making all > meaningless constructs fail, but don't do it different ways for > different errors. > > On the whole I think JSONPath is designed to be "forgiving", i.e. > such things aren't errors, e.g. I think I read in the spec that > filtering a non-array isn't an error, it's some kind of no-op. That > approach isn't always best for everyone, but it's important to be > consistent. That's an excellent point and a good reason for keeping the status quo. > > Michael Kay > Saxonica > > > On 8 Dec 2020, at 09:31, Glyn Normington < > > glyn.normington.work@gmail.com> wrote: > > > > Did anyone else have an opinion on the behaviour of slices such as > > [::0]? The current draft allows this and says it returns an empty > > array, but there is good reason to say it should error so that the > > slice operation is then consistent with Python slicing. See below > > for more context. > > > > On Thu, 26 Nov 2020 at 10:22, Glyn Normington < > > glyn.normington.work@gmail.com> wrote: > > > On 26 Nov 2020, at 09:49, Glyn Normington < > > > glyn.normington.work@gmail.com> wrote: > > > > > (3) "When step is 0, no elements are selected. This is the > > > > > one case > > > > > which differs from the behaviour of Python, which raises an > > > > > error in > > > > > this case." p. 10 > > > > > > > > > > Is there a rationale for that choice? As you note, in Python > > > > > it is an > > > > > error. In JMESPath it is also an error, see > > > > > https://jmespath.org/specification.html#slices. > > > > > > > > The rationale is the supposed consensus of implementations. > > > > > > > > > Unless I've missed it, Christoph Burgmer doesn't have a test > > > > > case for > > > > > a slice where step is zero. Perhaps we can prevail upon him > > > > > to add > > > > > one. > > > > > > > > I will add that test. > > > > > > It turns out there is such a test already, but no consensus: > > > > > > https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html > > > > > > Maybe raising an error to be consistent with Python would be a > > > good move. What do others think? > > > > > > > -- > > Jsonpath mailing list > > Jsonpath@ietf.org > > https://www.ietf.org/mailman/listinfo/jsonpath > > From nobody Tue Dec 8 03:56:27 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF43A0603 for ; Tue, 8 Dec 2020 03:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fp44uFptN4eL for ; Tue, 8 Dec 2020 03:56:24 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E6E3A0C57 for ; Tue, 8 Dec 2020 03:56:11 -0800 (PST) Received: from [192.168.217.120] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CqzCs6tL5zybr; Tue, 8 Dec 2020 12:56:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 8 Dec 2020 12:56:09 +0100 Cc: Glyn Normington , jsonpath@ietf.org, Daniel P X-Mao-Original-Outgoing-Id: 629121369.424232-d41786b4d009a1a801f696b97e65f295 Content-Transfer-Encoding: quoted-printable Message-Id: <8EAFD2CD-E980-49FB-A6F3-218E83ECABC6@tzi.org> References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> To: Michael Kay X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 11:56:26 -0000 On 2020-12-08, at 11:29, Michael Kay wrote: >=20 > decide your policy on errors and then apply it consistently. Good advice. I would expect one component of this policy to be: Whether a JSONPath query is valid or not does not depend on the = arguments it is applied to. I.e., you can look at the query and find out independently, without = knowing any data, whether it is valid or not. (Clearly, a query language could have an =E2=80=9Cassertion=E2=80=9D = system where it returns a special kind of failure for certain input = data. I don=E2=80=99t think that is anticipated in JSONPath. Also, a = query might =E2=80=9Cfail=E2=80=9D in the sense of returning no output; = that query is still a valid query.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 8 04:02:18 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C463A0C38 for ; Tue, 8 Dec 2020 04:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UtTY5DE-EuC1 for ; Tue, 8 Dec 2020 04:02:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3BB3A0B6E for ; Tue, 8 Dec 2020 04:02:14 -0800 (PST) Received: from cpc160115-rdng30-2-0-cust150.15-3.cable.virginm.net ([86.19.35.151] helo=[192.168.0.27]) by smtp03.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from ) id 1kmbh6-000821-00; Tue, 08 Dec 2020 12:02:12 +0000 From: Michael Kay Message-Id: <4DCF5BE0-9357-4B04-B908-7DF4B9FAA831@saxonica.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BECE679F-7218-45AD-8E96-BA30B983CBB3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Tue, 8 Dec 2020 12:02:11 +0000 In-Reply-To: <8EAFD2CD-E980-49FB-A6F3-218E83ECABC6@tzi.org> Cc: Glyn Normington , jsonpath@ietf.org, Daniel P To: Carsten Bormann References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> <8EAFD2CD-E980-49FB-A6F3-218E83ECABC6@tzi.org> X-Mailer: Apple Mail (2.3445.9.7) X-Mailcore-Auth: 439400257 X-Mailcore-Domain: 1881035 Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 12:02:16 -0000 --Apple-Mail=_BECE679F-7218-45AD-8E96-BA30B983CBB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > I.e., you can look at the query and find out independently, without = knowing any data, whether it is valid or not. >=20 I think you're saying there that static errors are OK, dynamic errors = are not. That's roughly what XPath 1.0 did: there were very few dynamic errors = possible in XPath 1.0. (About the only one I can think of is that = count() applied to anything other than a node-set gave an error: which = is rather paradoxical since XPath 2.0, despite introducing much stronger = type checking, made count("x") return 1 rather than an error). Michael Kay Saxonica= --Apple-Mail=_BECE679F-7218-45AD-8E96-BA30B983CBB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I.e., you can look at the query and find out = independently, without knowing any data, whether it is valid or not.


I think you're saying there that static errors are = OK, dynamic errors are not.

That's = roughly what XPath 1.0 did: there were very few dynamic errors possible = in XPath 1.0. (About the only one I can think of is that count() applied = to anything other than a node-set gave an error: which is rather = paradoxical since XPath 2.0, despite introducing much stronger type = checking, made count("x") return 1 rather than an error).

Michael Kay
Saxonica
= --Apple-Mail=_BECE679F-7218-45AD-8E96-BA30B983CBB3-- From nobody Tue Dec 8 09:12:15 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340823A1049 for ; Tue, 8 Dec 2020 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.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 nUesSAF7XAt8 for ; Tue, 8 Dec 2020 09:12:11 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4D7123A1045 for ; Tue, 8 Dec 2020 09:12:11 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id m19so4927467lfb.1 for ; Tue, 08 Dec 2020 09:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PoEJl0p55L7faKmHxUGsOUT8MxT4uG7ixXmtu91iQJ0=; b=QFLrYoV1lLr2gwRLqPSH7i6K2IBLni4Gyjd0Fia6EUX4oqJt0WRYOq4wVY0khsPlQa jBe4l5dORPHLOJo15rxTWxsXcKQ5eAwzoeRlu4b8o4HuXOUcMerdian+QJNUGxRjjTuU PjzrABeIiAPvy060uaPkfFSAEcDGPe/vwOCu0= 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=PoEJl0p55L7faKmHxUGsOUT8MxT4uG7ixXmtu91iQJ0=; b=IenjP9YrApIe8u0aTipovEcm6yHRZuws5HfV3oXygQ3nyE8SMVw5FuLRdXJr5LkhIK nsz8Moy9AhZmoow14iWoL9+obK0W1Kvp8ysuXOkngYbhp7PTeJdEvFjxb+zzyK58/e6Q oFEjcyrqXCjJRUqxOCJFzA7tT6l7v3JdRBfAo2waVHlQPxPSUS4qcOuTX4E9WBrAjKvR VMjvJd0AuQGRY/GdN4e9ecH0rmaUjgMhU9fKG1gmaqdOOhYv2DFZBl3Dhq6TbFAByNd8 9yo3hN6mmcGHyYM1K7t/h2jvYIDd67HGUbVcxRK2VX0gIxX5Kytywk6pfcvnPymYmJMR vK2g== X-Gm-Message-State: AOAM530UoWOkum29wsnrhhvQTyL4fE+CbQxIcJuEYFQG8b9vGHTrjqTV pZxL7g2V2/h722ayMlxS7b4hfxJ58IzNVx+WAT/CLA== X-Google-Smtp-Source: ABdhPJwNrF8QmT8nmM6D+tEYmLIPdMzd1osv+PTmIesB4ni5nJsqnc17ZGLnD8PoRMmoRglSjP9Vmpf/M8aRE7b/rfI= X-Received: by 2002:a19:d4d:: with SMTP id 74mr6274673lfn.403.1607447529180; Tue, 08 Dec 2020 09:12:09 -0800 (PST) MIME-Version: 1.0 References: <5b0fa110-3a1b-0b95-a832-2af20721671d@iit.cnr.it> In-Reply-To: <5b0fa110-3a1b-0b95-a832-2af20721671d@iit.cnr.it> From: Ulysse Carion Date: Tue, 8 Dec 2020 09:11:58 -0800 Message-ID: To: Mario Loffredo Cc: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 17:12:14 -0000 I support adoption of this draft as well. On Tue, Dec 8, 2020 at 12:17 AM Mario Loffredo wrote: > > I support adoption. > > Mario > > Il 07/12/2020 21:54, James ha scritto: > > This begins a 2 week working group adoption call for > > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, > > ending Tuesday, December 22nd 2020. This document is the merging of > > Glyn's original document with draft-goessner-dispatch-jsonpath, and is > > a starting point and not specification complete. > > > > After review of the document please indicate support (or not) for WG > > adoption to the mailing list. Please also provide comments/reasons for > > that support (or lack thereof) as silence will not be considered as > > consent. > > > > > > Thanks! > > > > Tim & James > > > -- > Dr. Mario Loffredo > Technological Unit =E2=80=9CDigital Innovation=E2=80=9D > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Web: http://www.iit.cnr.it/mario.loffredo > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath From nobody Tue Dec 8 11:47:14 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061003A110F for ; Tue, 8 Dec 2020 11:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Fw1MrHY4XJb for ; Tue, 8 Dec 2020 11:47:08 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 80CDA3A110D for ; Tue, 8 Dec 2020 11:47:08 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id d3so2973710wmb.4 for ; Tue, 08 Dec 2020 11:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=RYTvCzTBI0zWeOLjLJ8YTFI74OFow1bUHjH5aLzj8XA=; b=J0t57T9EZfFpGdIMiF7MwhkLmoBhFe9POUUjmyvhwVeqtK8s/aJi4Gdg8BosM2Nouk /xg9M2yEDfbg+5jKtbJnNBr5Ilkqtx/Ww6vSwjt/tNAlvurKVq6UHN3TDPbGBx163hpN cZ3GxrLmZmYPuPC2ccPecn0+QeMnRFp+AdTG+Rc8aoh6j/UHyKUYRDZ1AgMV0ag/8AD4 d654F3wlzBSQESjiCc07L4PBV5QaL1fJqSw3goBwHlyGDRiH27POXyLbvAUaLleYU05+ 77ZdzEvQlVIeyLnDo3/3ZJ3oGJ3gNuzmugBo6+dubPqmK4uS9Ac6L0wSl8ubsPTEgpYg RbjQ== 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:content-transfer-encoding; bh=RYTvCzTBI0zWeOLjLJ8YTFI74OFow1bUHjH5aLzj8XA=; b=GQZIiSHTe8riQdbio9/NFFODedPMyupJAuIR2g2/vLLN/PhLhObO/npqNCgANSzCD4 ATLfPjRmTqThuH2NyzjCY6r6lvDj62GAlHWcHg2F3eWB0KHukabGKU+RTWRGeuXsP08+ M8LpZtRucKMIhxEZptU3TwYpDqg6AcrCzEoIi6EYxFZ+Z1t2g+aJnggORYXH/SLLp1xw FkTZobdaiw2WtDc2z79Kz8xgYCUb9UroDS0EBhx2s8rLc5jLSU4aUX4mihLnz9okw5gJ pkuXdS0IHTX+xpTtqlKfYqCgy1iVupjjQY6twzFOtnuxMSo/ASOEeV0jmKiXgoS/qMs1 j+0A== X-Gm-Message-State: AOAM533tdkprlm4UZpnElo/mAWCB8ImsHzj2R1LI3eXLyV5cq/yNoFjr 9Qx33c6ske+OebSrCdjkFZ2wYuxCdosT4TP5S9o= X-Google-Smtp-Source: ABdhPJydWhwS4n8JH3ygJro8S8dMOTy0XbQ/qbth01CTHQMIDr/fG+Ch2rPXcqnQiRtZec/109uNZzAlCLQqonRfBxQ= X-Received: by 2002:a7b:c208:: with SMTP id x8mr5189383wmi.179.1607456826752; Tue, 08 Dec 2020 11:47:06 -0800 (PST) MIME-Version: 1.0 References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> In-Reply-To: From: Daniel P Date: Tue, 8 Dec 2020 14:46:55 -0500 Message-ID: To: Michael Kay , Carsten Bormann , Glyn Normington , jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 19:47:13 -0000 What about result =3D search(json_instance, "#$@&%*! is that?"); If a JSONPath expression can't be parsed according to syntactical rules, wo= uld "some kind of fallback behaviour" ever be helpful to a user? I can see returning "no results" if an otherwise valid expression cannot be evaluated against t= he provided JSON instance, which many implementations do. Daniel On Tue, Dec 8, 2020 at 5:29 AM Michael Kay wrote: > > My advice based on experience of XPath design mistakes would be: decide y= our policy on errors and then apply it consistently. Either try and minimis= e errors by making all meaningless constructs exhibit some kind of fallback= behaviour, or maximise errors by making all meaningless constructs fail, b= ut don't do it different ways for different errors. > > On the whole I think JSONPath is designed to be "forgiving", i.e. such th= ings aren't errors, e.g. I think I read in the spec that filtering a non-ar= ray isn't an error, it's some kind of no-op. That approach isn't always bes= t for everyone, but it's important to be consistent. > > Michael Kay > Saxonica > > On 8 Dec 2020, at 09:31, Glyn Normington = wrote: > > Did anyone else have an opinion on the behaviour of slices such as [::0]?= The current draft allows this and says it returns an empty array, but ther= e is good reason to say it should error so that the slice operation is then= consistent with Python slicing. See below for more context. > > On Thu, 26 Nov 2020 at 10:22, Glyn Normington wrote: >> >> On 26 Nov 2020, at 09:49, Glyn Normington wrote: >> >> >> (3) "When step is 0, no elements are selected. This is the one case >> which differs from the behaviour of Python, which raises an error in >> this case." p. 10 >> >> Is there a rationale for that choice? As you note, in Python it is an >> error. In JMESPath it is also an error, see >> https://jmespath.org/specification.html#slices. >> >> >> The rationale is the supposed consensus of implementations. >> >> >> Unless I've missed it, Christoph Burgmer doesn't have a test case for >> a slice where step is zero. Perhaps we can prevail upon him to add >> one. >> >> >> I will add that test. >> >> >> It turns out there is such a test already, but no consensus: >> >> https://cburgmer.github.io/json-path-comparison/results/array_slice_with= _step_0.html >> >> Maybe raising an error to be consistent with Python would be a good move= . What do others think? >> > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > > From nobody Tue Dec 8 13:09:16 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3743A09F9 for ; Tue, 8 Dec 2020 13:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9wbxyjfGiwLX for ; Tue, 8 Dec 2020 13:09:11 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2620C3A09F6 for ; Tue, 8 Dec 2020 13:09:10 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CrCTw1q6NzySH; Tue, 8 Dec 2020 22:09:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 8 Dec 2020 22:09:07 +0100 Cc: Michael Kay , Glyn Normington , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 629154547.448975-c9bd8ff3891edae44355ffe809fccb71 Content-Transfer-Encoding: quoted-printable Message-Id: <4E655650-9595-4280-9F1B-0440CA12E12F@tzi.org> References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> To: Daniel P X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 21:09:14 -0000 On 2020-12-08, at 20:46, Daniel P wrote: >=20 > What about >=20 > result =3D search(json_instance, "#$@&%*! is that?"); >=20 > If a JSONPath expression can't be parsed according to syntactical = rules, would > "some kind of fallback behaviour" ever be helpful to a user? No. This should break with a loud bang. > I can see > returning > "no results" if an otherwise valid expression cannot be evaluated = against the > provided JSON instance, which many implementations do. That is what I meant, a query expression should be valid or invalid, but = that should not depend on what argument you are using that against. An implementation should never silently accept a query expression it has = found invalid. (Importantly, I didn=E2=80=99t say it needs to implement = every single validity test, just that it should break violently when one = of those fails that it does implement.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 8 13:35:54 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29FE3A11ED for ; Tue, 8 Dec 2020 13:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 0eAmoohKZvcX for ; Tue, 8 Dec 2020 13:35:42 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 5CBB73A11D8 for ; Tue, 8 Dec 2020 13:35:42 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id b4so341611lfo.6 for ; Tue, 08 Dec 2020 13:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfHdIIF1QPAaXOEPqX9x6rOFlOwOv1Q+hd9zAwy6KmM=; b=bKUKf1wDke8evpXu9CWss/nJlAPc4QIu4R6HUp+adaPoje7c8zighPj3oCyfjEIfQC NftEFB3PK4sDI5KNQmRCpkNW4Kl4T+++dThB58YjNoL9eK/p1sMaVQ6xyPWojd1OFsq0 iFdTQyZhndjQay9zs8DWmFiJJ7kaPW+8utXnHj/bA+iEeUf5gjEQibRY9BZemGG+sar2 ifFmsJK4kDa3R+Z1n/YDptPqLDAZsBxHyw+4jQCOFTiqPDVEO91PgjlQHVDutppBw7cY gv6vmUrZaS8n4k6qGaFG4CIFQdTLlPl4OZSkxm+Lc8cDKiHEQLA621+pb54it+QDKPDN Ai1A== 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; bh=cfHdIIF1QPAaXOEPqX9x6rOFlOwOv1Q+hd9zAwy6KmM=; b=ojVjETIP+zWrOHgBew6EJ7UiqRO8w73W/Sl4lCYYd2lPWzs+2pu1nkSMkabSV2C1mr I6XEx/bIfHl+8DFWAgBTrcLEtMG5mMf7IaeQEuUeAl5S0CACMXz4ocD1Xc8Ez3wlAdXr mWTh5c0v3QzguR34pTpzjsDISjlgIIOlxzG/OZQtOJbG3MS5Yy077xcZKl1LeCn+ZqII g+Mvh1g0R+N+tyhaPbcNCUqGoFSfH5d0iL6OIzJ4Q3o+R6mccRQ1/3WmlsKVzfwGKGx+ gXa9J6gau9KjxMuD+7vNRwUyl9u7ctwqhVluofT0tUTCdhqeagsocWinsAFcLpb0j4Po 3VdA== X-Gm-Message-State: AOAM532/rfHIOvEm9ZoImXm6RRx/rqpxRKhpMoYu1dAeP5zokR3Mqpzl TdOE1K19GsBe4M/O1qdLX9AztxI6T/nJTIey72kJPA== X-Google-Smtp-Source: ABdhPJxz5zl3/mkvmNsD3p3C07d0/X1H2hhCAJQ+KGMqI+vk0p92bBSQYUhsjKNWoWRgcHPlpKJEClB5OOUXlcaHqOE= X-Received: by 2002:ac2:5f63:: with SMTP id c3mr301370lfc.451.1607463340066; Tue, 08 Dec 2020 13:35:40 -0800 (PST) MIME-Version: 1.0 References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> <4E655650-9595-4280-9F1B-0440CA12E12F@tzi.org> In-Reply-To: <4E655650-9595-4280-9F1B-0440CA12E12F@tzi.org> From: Tim Bray Date: Tue, 8 Dec 2020 13:35:28 -0800 Message-ID: To: Carsten Bormann Cc: Daniel P , jsonpath@ietf.org, Glyn Normington , Michael Kay Content-Type: multipart/alternative; boundary="0000000000005fe12705b5fab92c" Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 21:35:52 -0000 --0000000000005fe12705b5fab92c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Carmen. One of the big problems we had at AWS is that JSONPaths could be provided as arguments to our APIs and we really wanted to give a helpful error if they were syntactically malformed and also if they obviously could never produce a useful result. The first was possible (although we didn't do a very good job). If Glyn's code (maybe it already does?) included a JSONPath syntax checker and linter, that would be super useful to the community. On Tue, Dec 8, 2020 at 1:09 PM Carsten Bormann wrote: > On 2020-12-08, at 20:46, Daniel P wrote: > > > > What about > > > > result =3D search(json_instance, "#$@&%*! is that?"); > > > > If a JSONPath expression can't be parsed according to syntactical rules= , > would > > "some kind of fallback behaviour" ever be helpful to a user? > > No. This should break with a loud bang. > > > I can see > > returning > > "no results" if an otherwise valid expression cannot be evaluated > against the > > provided JSON instance, which many implementations do. > > That is what I meant, a query expression should be valid or invalid, but > that should not depend on what argument you are using that against. > > An implementation should never silently accept a query expression it has > found invalid. (Importantly, I didn=E2=80=99t say it needs to implement = every > single validity test, just that it should break violently when one of tho= se > fails that it does implement.) > > Gr=C3=BC=C3=9Fe, Carsten > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --0000000000005fe12705b5fab92c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= gree with Carmen.=C2=A0 One of the big problems we had at AWS is that JSONP= aths could be provided as arguments to our APIs and we really wanted to giv= e a helpful error if they were syntactically malformed and also if they obv= iously could never produce a useful=C2=A0result.=C2=A0 The first was possib= le (although we didn't do a very good job).=C2=A0 If Glyn's code (m= aybe it already does?) included a JSONPath syntax checker and linter, that = would be super useful to the community.

On Tue, Dec 8, 2020 at 1:09 PM= Carsten Bormann <cabo@tzi.org> w= rote:
On 2020-12-08, at 20:46, Daniel P <danielaparker@gmail= .com> wrote:
>
> What about
>
> result =3D search(json_instance, "#$@&%*! is that?"); >
> If a JSONPath expression can't be parsed according to syntactical = rules, would
> "some kind of fallback behaviour" ever be helpful to a user?=

No.=C2=A0 This should break with a loud bang.

> I can see
> returning
> "no results" if an otherwise valid expression cannot be eval= uated against the
> provided JSON instance, which many implementations do.

That is what I meant, a query expression should be valid or invalid, but th= at should not depend on what argument you are using that against.

An implementation should never silently accept a query expression it has fo= und invalid.=C2=A0 (Importantly, I didn=E2=80=99t say it needs to implement= every single validity test, just that it should break violently when one o= f those fails that it does implement.)

Gr=C3=BC=C3=9Fe, Carsten

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--0000000000005fe12705b5fab92c-- From nobody Tue Dec 8 19:36:22 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0413A091C for ; Tue, 8 Dec 2020 19:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NtexC6Y4CuRV for ; Tue, 8 Dec 2020 19:36:19 -0800 (PST) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (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 DE2F83A0913 for ; Tue, 8 Dec 2020 19:36:18 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id f23so50013ejk.2 for ; Tue, 08 Dec 2020 19:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=maLPyUVFqe4PtZFelNhwGmx1km4uVvCEXstKNpqneAk=; b=B85QYrdpRCj9F5eK+xm7za5rjNIqbsVEVHSLUjgSXtJ9+CI+8ujo55GcWSWNiYZybo xyak0LPkU0U9rdXYO5zS2Po2JMESg+CiPlZqjblnRtDf8XLCcyjFRkDJMIAPcygURPFe 0961VBNplVPH1RH/UPR9cTjva8peE+bj21K+CoRKIR17VDESHd4cXWdlaie/C6VwzXDe E4PjrpEotxkJ1XEwsCH8w+o6oHx8Y2Hbp1A+R4/HhFqTsTTBRoU8yDJ8TpNYSYK7bgth dZEzxhazeu1N5QfZNS87EGPBptuj/VjTQREyyIV66Fet/yZQ+dwpR/yzpnPL+RqCS17a bfRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=maLPyUVFqe4PtZFelNhwGmx1km4uVvCEXstKNpqneAk=; b=be7EyPzFZH7iA+KHRWRy8usUwOoQlbkwdRMyEa7Zu4dHN4ZVkOzi0MI8W/f1TGUUI6 59XG78IVMS4AS+V/lTt6l8NcOuQCTdN17JLdr5FDwAPNqUhlksqPs5f6qb0k08M1P36F av6yfqhYIiOTW+OSI0kvaUE1Ws47E2Elsoj4SuQCDVLh5Es2fzbkwdDzkRZAU9xYn6zd 8qpmbfkAs0TiJyX5Qs7I7Qzykx8GwwdVHOm2X9z7IOrpKs6W/VE9d3G4frotfOZbSAoY 3Vtl8Tf6j05x60yJsi2dQ/MsKhPQPGaFtLcxXDxWHq7dXqR0j/1+ILzCSz6DzwBhV1lG uO1w== X-Gm-Message-State: AOAM5322F3Ad6GBWPhoSX0p1kZdCHIqAHmSIJbu834OaiFud9cwddsNv Ri+Pxb4x7FvN95c3C7QcELo= X-Google-Smtp-Source: ABdhPJzXgyVslAhT8W3OBtCpDR7HycBwwhlSXGqtEHSYcdW0brq7eueF3N614vwU99GBl+btTg6OnQ== X-Received: by 2002:a17:906:ccc5:: with SMTP id ot5mr404562ejb.248.1607484977190; Tue, 08 Dec 2020 19:36:17 -0800 (PST) Received: from zion.lan (161.110.45.217.dyn.plus.net. [217.45.110.161]) by smtp.gmail.com with ESMTPSA id lz17sm176442ejb.19.2020.12.08.19.36.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 19:36:16 -0800 (PST) Message-ID: From: Glyn Normington To: Tim Bray , Carsten Bormann Cc: Daniel P , jsonpath@ietf.org, Michael Kay Date: Wed, 09 Dec 2020 03:36:15 +0000 In-Reply-To: References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> <4E655650-9595-4280-9F1B-0440CA12E12F@tzi.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 03:36:21 -0000 On Tue, 2020-12-08 at 13:35 -0800, Tim Bray wrote: > I agree with Carmen. One of the big problems we had at AWS is that > JSONPaths could be provided as arguments to our APIs and we really > wanted to give a helpful error if they were syntactically malformed > and also if they obviously could never produce a useful result. The > first was possible (although we didn't do a very good job). If > Glyn's code (maybe it already does?) included a JSONPath syntax > checker and linter, that would be super useful to the community. The goals of my reference implementation ([1]) are to implement the spec and pass the compliance test suite ([2]). To that end, it uses a Parsing Expression Grammar that fairly closely matches the ABNF in the spec. So it certainly does syntax checking and error reporting, but it's far from being a linter as it won't complain about poor style which is syntactically valid and it won't suggest better ways of writing a JSONPath. So, there's a gap in the market for a linter which I do not intend to fill. Any takers? [1] https://github.com/jsonpath-standard/jsonpath-reference-implementation [2] Currently at https://github.com/jsonpath-standard/jsonpath-reference-implementation/blob/main/tests/cts.json , although this will move to its own repository in due course > > On Tue, Dec 8, 2020 at 1:09 PM Carsten Bormann wrote: > > On 2020-12-08, at 20:46, Daniel P wrote: > > > > > > What about > > > > > > result = search(json_instance, "#$@&%*! is that?"); > > > > > > If a JSONPath expression can't be parsed according to syntactical > > rules, would > > > "some kind of fallback behaviour" ever be helpful to a user? > > > > No. This should break with a loud bang. > > > > > I can see > > > returning > > > "no results" if an otherwise valid expression cannot be evaluated > > against the > > > provided JSON instance, which many implementations do. > > > > That is what I meant, a query expression should be valid or > > invalid, but that should not depend on what argument you are using > > that against. > > > > An implementation should never silently accept a query expression > > it has found invalid. (Importantly, I didn’t say it needs to > > implement every single validity test, just that it should break > > violently when one of those fails that it does implement.) > > > > Grüße, Carsten > > From nobody Tue Dec 8 21:39:31 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866133A0C3A for ; Tue, 8 Dec 2020 21:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fIMTJ7wQWWfn for ; Tue, 8 Dec 2020 21:39:27 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE223A0C38 for ; Tue, 8 Dec 2020 21:39:26 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CrQph600NzyRy; Wed, 9 Dec 2020 06:39:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 9 Dec 2020 06:39:24 +0100 Cc: Tim Bray , jsonpath@ietf.org, Michael Kay , Daniel P X-Mao-Original-Outgoing-Id: 629185164.1612951-22b47d19f790f50a9bd74694e53da341 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89140FFF-6B25-4ABC-8A25-92327B1313F3@gmail.com> <4E655650-9595-4280-9F1B-0440CA12E12F@tzi.org> To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 05:39:30 -0000 On 2020-12-09, at 04:36, Glyn Normington = wrote: >=20 > Parsing Expression Grammar that fairly closely matches the ABNF Interesting. Because I=E2=80=99m lazy (and I want to make sure the ABNF = is right), I generally use a PEG parser that is generated right out of = the ABNF. E.g., https://github.com/cabo/cddlc/blob/master/lib/parser/cddl.abnftt (The abnftt gem generates code from the augmented ABNF, but also = generates a clean ABNF file that can be diffed against the ABNF from the = RFC. See https://github.com/cabo/cddlc/blob/master/Rakefile .) Obviously, using ABNF with PEG semantics requires some care when setting = up the ABNF (don=E2=80=99t let prioritized choice get in your way). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 9 01:07:01 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED083A0EF0 for ; Wed, 9 Dec 2020 01:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ycqDErgxtD0A for ; Wed, 9 Dec 2020 01:06:58 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 2296A3A0EED for ; Wed, 9 Dec 2020 01:06:58 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id q5so564776qkc.12 for ; Wed, 09 Dec 2020 01:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6mgO5W3ClJj6CpVAjwV/W/UNDG0mehMyY1YcXeJtM4s=; b=EDlHHqIO5mlpiFUB7JBbL5rdfqmU12J2eFizxSH1hd0um17cXP+3Q+uTI0X+7ffc/1 XZGzHlouYK+FC/ouQuK/LElCsZ1Q2MtG4Q8giZZ3XQp8htABSayvDI07Vf7CMcSYhPz5 qak/dmqpQKt+6JyIFsdUo3feedtXGpqHZjioPh/q/8lephkqMkO0ODJqAv7reMkBukoa Bw0E89tSGqthwHLAyPq11AzZwx+Jhp6o3JO4pNNuc8VZUuRmKDP9onSvh4L4zAX/IbZT 1Y6ZcMArGcUkJiz0aVoATCVbK66Or3yG9xjymwsssgO/mRaNdUQGsMFQNdJNCu+mhEpK vqWg== 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; bh=6mgO5W3ClJj6CpVAjwV/W/UNDG0mehMyY1YcXeJtM4s=; b=b29Ea2UAVVH8LH5Dt3exp5A0Pcp9HJrXqyHTll4j7O27MQbSNLSfdXNjtbbK3p4nm+ ootvtvER3lMa7n67MaXwEprMlKr/5F1lFA7m0jjleKnUBN1CPD96GWUoS7rRH6GSJne2 2kgUK3DhrkOX5SYud6ZE5dxWaU+3MsvtCrUJXBlobSD1tKJJ9Zi+gl83yJ9k5PZLvg9V gqP6b682zwaNV8ruTNHEDF/uJJg8BkX+gq0LBKI1B/QecnKlbgo3z6zQBySqfu4K57Bn t2jJaL4wAOsgadMdhcbAYTAnOyouux+AoCtuyjX4w02cU5K2UvvhxL5M48f/hsPz792G qFWQ== X-Gm-Message-State: AOAM531h/akobkJHSf11wdxlTyLW3N+GjCSenuWXaIqD9WKERP8mMiPJ msEIWbtkEhzdj0wxvTXISWzKPu+i8SEpXr8A3yHO3QjWJjg= X-Google-Smtp-Source: ABdhPJxryqC0Rn+ujOIglxDL6xigBzTs7w9gmmCkY2jxUGFpd8tSWxVrhoTq4NV3XF9tmKj2Ycs1/rDTu1lfX2W3ozY= X-Received: by 2002:a37:4f94:: with SMTP id d142mr1942883qkb.294.1607504817093; Wed, 09 Dec 2020 01:06:57 -0800 (PST) MIME-Version: 1.0 References: <5b0fa110-3a1b-0b95-a832-2af20721671d@iit.cnr.it> In-Reply-To: From: Marko Mikulicic Date: Wed, 9 Dec 2020 10:06:45 +0100 Message-ID: To: Ulysse Carion Cc: Mario Loffredo , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000099042905b6046156" Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 09:07:00 -0000 --00000000000099042905b6046156 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this draft. On Tue, 8 Dec 2020 at 18:12, Ulysse Carion wrote: > I support adoption of this draft as well. > > On Tue, Dec 8, 2020 at 12:17 AM Mario Loffredo > wrote: > > > > I support adoption. > > > > Mario > > > > Il 07/12/2020 21:54, James ha scritto: > > > This begins a 2 week working group adoption call for > > > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, > > > ending Tuesday, December 22nd 2020. This document is the merging of > > > Glyn's original document with draft-goessner-dispatch-jsonpath, and i= s > > > a starting point and not specification complete. > > > > > > After review of the document please indicate support (or not) for WG > > > adoption to the mailing list. Please also provide comments/reasons fo= r > > > that support (or lack thereof) as silence will not be considered as > > > consent. > > > > > > > > > Thanks! > > > > > > Tim & James > > > > > -- > > Dr. Mario Loffredo > > Technological Unit =E2=80=9CDigital Innovation=E2=80=9D > > Institute of Informatics and Telematics (IIT) > > National Research Council (CNR) > > via G. Moruzzi 1, I-56124 PISA, Italy > > Phone: +39.0503153497 > > Web: http://www.iit.cnr.it/mario.loffredo > > > > -- > > Jsonpath mailing list > > Jsonpath@ietf.org > > https://www.ietf.org/mailman/listinfo/jsonpath > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --00000000000099042905b6046156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this draft.=C2=A0


On T= ue, 8 Dec 2020 at 18:12, Ulysse Carion <ulysse=3D40segment.com@dmarc.ietf.org> wrote:
I support adoption of = this draft as well.

On Tue, Dec 8, 2020 at 12:17 AM Mario Loffredo
<mario.lo= ffredo@iit.cnr.it> wrote:
>
> I support adoption.
>
> Mario
>
> Il 07/12/2020 21:54, James ha scritto:
> > This begins a 2 week working group adoption call for
> > https://datatracker.ietf.o= rg/doc/html/draft-normington-jsonpath/,
> > ending Tuesday, December 22nd 2020. This document is the merging = of
> > Glyn's original document with draft-goessner-dispatch-jsonpat= h, and is
> > a starting point and not specification complete.
> >
> > After review of the document please indicate support (or not) for= WG
> > adoption to the mailing list. Please also provide comments/reason= s for
> > that support (or lack thereof) as silence will not be considered = as
> > consent.
> >
> >
> > Thanks!
> >
> > Tim & James
> >
> --
> Dr. Mario Loffredo
> Technological Unit =E2=80=9CDigital Innovation=E2=80=9D
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: http://www.iit.cnr.it/mario.loffredo
>
> --
> Jsonpath mailing list
> Jsonpath@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/jsonpath

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--00000000000099042905b6046156-- From nobody Wed Dec 9 13:30:58 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF743A1735 for ; Wed, 9 Dec 2020 13:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 ORR32vASVGQ1 for ; Wed, 9 Dec 2020 13:30:55 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 624923A1747 for ; Wed, 9 Dec 2020 13:30:54 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id u18so5137547lfd.9 for ; Wed, 09 Dec 2020 13:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0iRErPnvJBvvhVHr8BKU/VZ5ls5Ew2sDxNPtjBCL2Hs=; b=c7Vblt3fkvBd84oFP+yuR1Q5DV7tGlk3msOM/diYdvd6o6Anurvh8dpqJsqYCnJnWf 2i13UIxBoZB5bwho08AhRF3BDhn4kvqEnqsODlsIw3t8nhuG8EVHaTU0cxaD2pJjhuIV Zy6YGxN5RM6rIGkoCp6uL/3hshlARM1fXadlLCQYXRYFMcF19mJuVqZ9rYtXBf9A9lkq fG6xmFpRqIQNaju/ocMN3pRY/EpYq6ZKOgNmEnL/sWZP67dTBoA6GBRHYKY9Lts++htg x7IRbiOSMd5nFwe/hzMVwE8wXi2scIjYxtImJd5byLmLB9VyH8inS4vSscJngXm3hmH6 0SEQ== 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; bh=0iRErPnvJBvvhVHr8BKU/VZ5ls5Ew2sDxNPtjBCL2Hs=; b=gO2GxHtXKXUNFy2nxKST3AmS7vZQLupsnG4CZzYd3QF92rl02VL5a2ikr8ZFm0jAob JnZpDA96DfvAEX2MmUIIXrcrSzvsuHfSyjfBYPP32PcII+uGG3pCpRKK5HFc+RW2tbCs ZfoVgcFIHd0CWo79G+dO3K40HFJR+uAhPh1D0BH49sSkl3dMw1v86rb0lZ1Jhos+Uhm5 kG54RMSDZf5tf07Oy0w0oUntZ7t6ui++KRPQBBs1LN6AjxOvQ41rgAluxzL8SEaDVIIi PJd+LhRRblwa9UNGGNMQ3xnkWAUwjWY+DdG0WLo8WMp/83wA9cxXcxmZD9vCIurhbjwH sW3g== X-Gm-Message-State: AOAM532wZWZrXoGvSdX+8Ta0JbyboHjkxBLGNHoHsg7W4K+6Igg2KxRn 4eVoObs0kZVb0X/S0ZFwKu64KcK73C5/q6mXcs8rdg== X-Google-Smtp-Source: ABdhPJzc0PBb1y+HtJE+vNQIW1D/EtiZJz5ycFfm412ZJOOaRNs8ZP+9FBwygjuOycWDPPaB3MldFL6m759FrbDRDAc= X-Received: by 2002:a19:4941:: with SMTP id l1mr1570388lfj.136.1607549452326; Wed, 09 Dec 2020 13:30:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Wed, 9 Dec 2020 13:30:41 -0800 Message-ID: To: James Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000010b04f05b60ec6b0" Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 21:30:57 -0000 --00000000000010b04f05b60ec6b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the expressions of support. We have to wait two weeks to officially adopt, but that doesn=E2=80=99t mean we have to stop working. I would encourage people who have comments, for example on slice notation, to offer specific language change proposals to back up their arguments. PRs aren't required but are appreciated. We can publish an -01 any time a few of these are adopted. On Mon, Dec 7, 2020 at 12:54 PM James wrote: > This begins a 2 week working group adoption call for > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, ending > Tuesday, December 22nd 2020. This document is the merging of Glyn's > original document with draft-goessner-dispatch-jsonpath, and is a > starting point and not specification complete. > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as > consent. > > > Thanks! > > Tim & James > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --00000000000010b04f05b60ec6b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks for the expressions of support. We have to wait two weeks to officially= adopt, but that doesn=E2=80=99t mean we have to stop working. =C2=A0
=

I would encourage people who h= ave comments, for example on slice notation, to offer specific language cha= nge proposals to back up their arguments. PRs aren't required but are a= ppreciated. We can publish an -01 any time a few of these are adopted.

On Mon, Dec 7, 2020 at 12:54 PM James <james.ietf@gmail.com> wrote:
This = begins a 2 week working group adoption call for
https://datatracker.ietf.org/doc/htm= l/draft-normington-jsonpath/, ending
Tuesday, December 22nd 2020. This document is the merging of Glyn's original document with draft-goessner-dispatch-jsonpath, and is a
starting point and not specification complete.

After review of the document please indicate support (or not) for WG
adoption to the mailing list. Please also provide comments/reasons for
that support (or lack thereof) as silence will not be considered as
consent.


Thanks!

Tim & James

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--00000000000010b04f05b60ec6b0-- From nobody Thu Dec 10 08:59:06 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B53A0EAF for ; Thu, 10 Dec 2020 08:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gRD15BBL2CZb for ; Thu, 10 Dec 2020 08:59:03 -0800 (PST) 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 22DC23A0EAA for ; Thu, 10 Dec 2020 08:59:03 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id y23so6056785wmi.1 for ; Thu, 10 Dec 2020 08:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PVwGK+3s/WrqZ/f20hGALKX8xXnyiGSa6wi6O4lnMF0=; b=S8xwXn2mMnvlDlxI69hhmHJ5HMHdCPmoqotK282FPLnrobzkNZaONUYykXfwlwamze C2QQXSNC1dkaDqT8owjDCNZR8+dRrjpo1/Zq+I+UZ6jRKWCfaUIDLWazFgf7/po1Z1AY q4jC3561cw5BXd4adymBTNZ56tfFFZsGxo94mz2B4GuU7zTNuliik1NxCsB71hyrbHGC x9eYyAqqS9TLZctYC/2OdtDNkC6uzNsJqsh9PRgbXZBku42MhMbL8zhUjbsofKSwP3cL SxjrDCX560pec1toontRtQo52GSiyWWilU7aEf+0GAzWuah/Q6t4tgovIuK3qoU5DeTu THGg== 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; bh=PVwGK+3s/WrqZ/f20hGALKX8xXnyiGSa6wi6O4lnMF0=; b=Qo8UiBe1mb/s9z1xqrivccnl1zRlDaVbs/DCjEsqakqBhfmqIUQxufNJAwa+83mLKa /lOwLSJ+9YVlxwepKkMxwk2zVNZY9ZNY3jXXusO5dyKClgXRorRauww0sQtGDYmyVjuG BkAKA0cqvJQ1HjqA9B+1Kc23sH2u4Ey/ha0U+lIIQ8dM1ypsJsEeu6jmexkdZDnaptC+ m6joABlVGBF1B2jhVmLAl0JYamtjuXGHxp1+bORK7Qy6+pOQdma9smYWEtrWtZ4pJUOy ofoPOkP1Si/3K0ApqwnRp05Wv+xahf9iToWBmP+hSxj9yG1EYTpKyXtKakyItXcP/HiW Am8A== X-Gm-Message-State: AOAM530gFoyoESNR+mkVr0cXN8ODwJPErTT1Sr9pehmEhF36oDixhqvb 6D9i+smZKj5h0HOFCC+wphuSK+1w+q1P/P3TNQM= X-Google-Smtp-Source: ABdhPJxJBvxqHX7ykQZDCRGuZgKKfgQpRYqaYo9CB4Cgr5pcRCYWifagljiqeeA9+wqPcUcFUdeMdYkfZuP3t/xlnzQ= X-Received: by 2002:a7b:cb93:: with SMTP id m19mr9461970wmi.45.1607619541618; Thu, 10 Dec 2020 08:59:01 -0800 (PST) MIME-Version: 1.0 References: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> In-Reply-To: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> From: Daniel P Date: Thu, 10 Dec 2020 11:58:48 -0500 Message-ID: To: Glyn Normington Cc: Carsten Bormann , jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 16:59:05 -0000 On Mon, Dec 7, 2020 at 11:00 PM Glyn Normington wrote: > On Mon, 2020-12-07 at 20:49 -0500, Daniel P wrote: > > > > > Related to that, it would be helpful to determine if JSONPath filters > > apply to both JSON objects and arrays, or only to JSON arrays. Our > > excellent Burgmer JSONPath comparison has that covered > > > > https://cburgmer.github.io/json-path-comparison/results/filter_expression_on_object.html > > > > and there is no consensus. > > I would support restricting filters to arrays, if others agree. I've created an issue for this at https://github.com/jsonpath-standard/internet-draft/issues/47. > > > For JSON objects, it's less clear, but perhaps > > > > In a filter expression evaluated against a JSON object, the object > > itself is represented by the symbol @. > > Regardless of the current consensus, or lack of one, I find this > confusing since @ does not correspond to the current item (meaning an > individual member of the object). It's also unhelpful in deciding which > items to filter in/out. > When an undefined term like "current item" occurs in a spec, some readers (such as this one) may draw a complete blank, while others may form an intuitive notion of what that means. But while "an individual member of the object" may seem intuitive, _none_ of the implementations in JSONPath Comparison support that notion, in fact that would require notation like @.key and @.value, which none support. Daniel From nobody Thu Dec 10 09:06:49 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239733A1110 for ; Thu, 10 Dec 2020 09:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1DAvKbb6EAD9 for ; Thu, 10 Dec 2020 09:06:44 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F94E3A0EC0 for ; Thu, 10 Dec 2020 09:06:44 -0800 (PST) Received: from [192.168.217.120] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CsL1F6lFQzyy6; Thu, 10 Dec 2020 18:06:41 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Thu, 10 Dec 2020 18:06:41 +0100 Cc: Glyn Normington , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 629312801.4920681-5d360dd53cac7386a45d2f26eba70e5b Content-Transfer-Encoding: quoted-printable Message-Id: References: <248696a566bd5974c8b78c5ee0a61ea12f224a84.camel@gmail.com> To: Daniel P X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] The draft: ambiguous language X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 17:06:48 -0000 On 2020-12-10, at 17:58, Daniel P wrote: >=20 >> Regardless of the current consensus, or lack of one, I find this >> confusing since @ does not correspond to the current item (meaning an >> individual member of the object). It's also unhelpful in deciding = which >> items to filter in/out. >>=20 > When an undefined term like "current item" occurs in a spec, some > readers (such as this one) may draw a complete blank, while others > may form an intuitive notion of what that means. But while > "an individual member of the object" may seem intuitive, > _none_ of the implementations in JSONPath Comparison support > that notion, in fact that would require notation like @.key and = @.value, > which none support. The processing model obviously needs to be written up. I left off = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00#section-3 = from the merge proposal, maybe I should have left it in as a quarry. This says: Within a script, @ stands for the position under consideration. (Where =E2=80=9Cscript=E2=80=9D would now be =E2=80=9Cexpression = language=E2=80=9D.) Positions are on data items (called JSON values in RFC 8259), not on map = entries (called members in RFC 8259, which are not JSON values). Position: A JSON data item identical to or nested within the JSON data item to which the query is applied to, expressed either by the value of that data item or by providing a JSONPath Output Path. (This could have said =E2=80=9Cargument=E2=80=9D instead of "the JSON = data item to which the query is applied to=E2=80=9D.) I didn=E2=80=99t want to spend a lot of time on the processing model = until we understand what direction the discussion on the handling of = duplicate matches is taking. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 15 01:50:47 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6C3A0F06 for ; Tue, 15 Dec 2020 01:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 lTGVUpeivfx2 for ; Tue, 15 Dec 2020 01:50:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C713A0F02 for ; Tue, 15 Dec 2020 01:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1608025838; bh=KdbWnMQBCHfzMxRkCxT9qqwVeN15r8KNmCzj/MfVBJ8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=aRE4/Tr9qoS4uXKEs2Fk+vjL50UL+3e1twKGUy26P9fAI0CkkJ/gcpORNc09nooqW Q20sKdrjDgwk9NH6HmiAH4SOVr9rCLpCrwHnyDHsaeAnCjuhQauiuWsLAwpfzYkxDh AoMXY/Hq6WzwfHJHXbP+wFMr7WJzfLWvm39hqcX4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([84.171.155.16]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N1fis-1k4t6M0TA8-0122mT for ; Tue, 15 Dec 2020 10:50:38 +0100 To: jsonpath@ietf.org References: From: Julian Reschke Message-ID: <09ee85cb-eadd-e0c3-5b31-4257191092cf@gmx.de> Date: Tue, 15 Dec 2020 10:50:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:NBTUA92jeQJ+nMHOo27zB6oMbJ5WdQ8t2fFh3zHq6s5rWb2BGVh Nwv88p3zbd+yMDWo5ASuq5c84hNT5qEv6Ml6lKtrb5c9yAIYWRcn+4uLAG5qYwQ7BWzpeQA uZrvPS6o5GFxWE6PKg/NXf4c9nMGkKty6YRHAzT2fo/LswbBxCjUuIewd3Gx/Dnu55gyDhX 5xTDO9mmnt6YP8lRJEYmA== X-UI-Out-Filterresults: notjunk:1;V03:K0:dmTmt2UlAc0=:qRu5mJ7+qUbKcXivhqvSjC QH5tXia3guds1YS0NgQI/hrOOYLp2Aa+V82AzDkdhsVHQB7GaL/lgKF71l8GiEmTkbNVEy2db vQgfamKyiEmEKY86kv6HzlBYCkPPNd7iIIqWKf8T+kWRxXWAeVpRnKt0F7q/hxg2mPW7LfAE/ b71Dn3VXPFvekKf3SDQ/wfj/NemfJDr274n0ZM6lxu8tTvQ0F4gnEQOgTNdIQLHX1BoPXV4ql ibMQa9TpXSd4Otex+FX2d+JAItjx59NzMKHsI+FyV9wpazn62pXxBEwgbwx+V5Xx4kZXv3EM3 KXnNkOAk4aBCxOO8HbRG+Wu/5kb0eHoZKwKkUj+7+mrKHlm5ZOkPOuAs1t/de8lE80T9V/4Ea ZAqcr+8vusDthDLuMHiGfBUIS8TbzDaBvq7Le+sSCO5hosaLK78ykTOr6SEZ1M17KcRxD9hib 6SpqQQgWMB0OYtvt2cqTbnpvdxJ32FAwkrJVIijpRdS1f33c5Fvzjq7cs0wZguM8UcJDv3xV6 vtdttsy5HI5sWadxwhQ3upkYprC6IAjT+DQCWoHZdFE1T+74hUcaERpoOFEGwt+GpQtDdqMdW E6ACaeVU0QK/3h806dwVNupz46TaWS3NOTVhFgwFNOJAPuJXWujf15AM83zrOAZW8m6quk+rQ 1tzzyMoxJrO2C/mJXWzhOzgvE+yelPuc8r/rbfThelzRRcBDppFZV1+jAjLD5dgMDoVGmfxu1 ehBTgiUl2ZlVio1I6kN4cNOAiQKD/XaI7+sD+TddKl5tw0BquUMvlsA/vmAkeh64l9d54BqRK RjRGPHYr/15Hbqmc15j9wYM159ZE31wF+Vn63M9PCwfq1Ro8k8FfipchllPUcnKkXKCH9pp+D CNzZNMll1YKRXZTm9OvA== Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 09:50:43 -0000 Am 07.12.2020 um 21:54 schrieb James: > ... I support adoption and will (occasionally :-) review. Best regards, Julian From nobody Tue Dec 22 12:48:40 2020 Return-Path: X-Original-To: jsonpath@ietf.org Delivered-To: jsonpath@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8233A129F; Tue, 22 Dec 2020 12:48:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160867011904.11923.5358864173588337615@ietfa.amsl.com> Date: Tue, 22 Dec 2020 12:48:39 -0800 Archived-At: Subject: [Jsonpath] The JSONPATH WG has placed draft-normington-jsonpath in state "Adopted by a WG" X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 20:48:39 -0000 The JSONPATH WG has placed draft-normington-jsonpath in state Adopted by a WG (entered by James Gruessing) The document is available at https://datatracker.ietf.org/doc/draft-normington-jsonpath/ From nobody Tue Dec 22 12:52:32 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3B3A12A3 for ; Tue, 22 Dec 2020 12:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uNdKKJ6_3ptD for ; Tue, 22 Dec 2020 12:52:29 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 3666A3A12A7 for ; Tue, 22 Dec 2020 12:52:29 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id x15so13195937ilq.1 for ; Tue, 22 Dec 2020 12:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JRy+CE1K2WT8GUTxGJC8nQaIF6whn+wB+IXD+eUdVrs=; b=vSSciZsTjrrPtRpG/cLLrILfhMcZItX4UJUg+v+8xsvZa8+mQmo9eC01sm4Rircp2h L/ZjGM+gGowZF1+O18acXKxnvjqa0Y+ENQnifkblJfsUjBcHu7oRhM5KYFvXq8OrjIkY 6SsLPzPek8/aHJ8qUqdhKtZd5ug3m9JkIOoxPUtkMDzR5xAJ64bJm/wR8CiM6dABu/lW dPEuItq5vHW8YcF6wo91RNZTcDd0dGzmdWHI1fYo/LYAGmCEJsaopsWg76f4CkghIAJ+ r0MqS8rszlmGj8rgGGN2CEqi7Xl2srYlAx2AAWTxT47QD1uCp+0nL7p5c7U+JzIG3tcS iqmg== 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; bh=JRy+CE1K2WT8GUTxGJC8nQaIF6whn+wB+IXD+eUdVrs=; b=o0M2tpyNiI2hlQvdwFvtUxD+VZwTX7ucPUB/A39pglCOQeQK1qtg7M1kOmYwKXIfxu rBX8cKfnSCP+kOaZFjwbF9mv8TjgqX4gmgyhAj8lpNchcf4nUxNU7siM0yMr4Sp06qkf mu0xInVd7xEgvzD8jTGQQOCDw3qNi4yz9opNmTWJuWAifWrydL/qkVFf9kBgmst+kxYk dtGPUIx10ylKLeDil+d5xZmHnHeDfRQL1CJF9/M1foZ+N7dsxUpcq54lLbY3eH9cf3V9 spzNGH4rCG44sfkXK1HxJcOPPb4nzRAnWRV1aLqJb+tGBNLfmr1DXFi4ETurj+6b2oJA dxNA== X-Gm-Message-State: AOAM530zIhJi9XtMIKjzJq5BUTaJ3raylG5lNq9/e3pJYjkkrL1aXKnZ R27OxGQ/5121Vp+IGBAouzTmLgKz+S54VWbcJgnjO6plmK0= X-Google-Smtp-Source: ABdhPJw5UDTa+SmlJRn4es0hX0P02xvCQbcOh1Cl7LSpGYm+dsOOyZYMHY/LV3YrDAAZ5oU/M/n7LJFV1Ut1i/Ued+s= X-Received: by 2002:a92:ce44:: with SMTP id a4mr22469687ilr.178.1608670348070; Tue, 22 Dec 2020 12:52:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: James Date: Tue, 22 Dec 2020 21:52:17 +0100 Message-ID: To: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="000000000000a854ca05b713c0cd" Archived-At: Subject: Re: [Jsonpath] Call for Adoption: draft-normington-jsonpath X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 20:52:31 -0000 --000000000000a854ca05b713c0cd Content-Type: text/plain; charset="UTF-8" Receiving no objections and entirely positive support for adoption, the working group has adopted the draft. Thank you all. - J On Mon, 7 Dec 2020 at 21:54, James wrote: > This begins a 2 week working group adoption call for > https://datatracker.ietf.org/doc/html/draft-normington-jsonpath/, ending > Tuesday, December 22nd 2020. This document is the merging of Glyn's > original document with draft-goessner-dispatch-jsonpath, and is a > starting point and not specification complete. > > After review of the document please indicate support (or not) for WG > adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as > consent. > > > Thanks! > > Tim & James > > --000000000000a854ca05b713c0cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Receiving no objections and entirely positive support= for adoption, the working group has adopted the draft.

<= /div>
Thank you all.

- J

On Mon, = 7 Dec 2020 at 21:54, James <jame= s.ietf@gmail.com> wrote:
This begins a 2 week working group adoption call for
https://datatracker.ietf.org/doc/htm= l/draft-normington-jsonpath/, ending
Tuesday, December 22nd 2020. This document is the merging of Glyn's original document with draft-goessner-dispatch-jsonpath, and is a
starting point and not specification complete.

After review of the document please indicate support (or not) for WG
adoption to the mailing list. Please also provide comments/reasons for
that support (or lack thereof) as silence will not be considered as
consent.


Thanks!

Tim & James

--000000000000a854ca05b713c0cd-- From nobody Wed Dec 23 01:42:20 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991383A0E6C for ; Wed, 23 Dec 2020 01:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S1OScDBIhVh6 for ; Wed, 23 Dec 2020 01:42:17 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 DBC6C3A0E6B for ; Wed, 23 Dec 2020 01:42:16 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id g24so15617222edw.9 for ; Wed, 23 Dec 2020 01:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:user-agent:mime-version :content-transfer-encoding; bh=TD/E4bIJ2Cw06XH2tp5J7EdTNKcB+vz7aRBkSaXyvEA=; b=kCvB2erEzdglil2jGOpuYF1+RPrDwXkGYjvNNZcNL+qrSSx5Sq4LuOhTjy+8QQuQpQ L2tYNBjSn5zdtrAASxyFnc7QH3vx/B+xKGEtzps5Tj010Oa+rOXVBdSAz6WS5fTQZWGr IATg/rx28r+f+/a92328sOPWFDG7vmzW/bMk7VpeYsk8JmXlFJKZxqRTZper+MuqUNeO HJSiaLbwAfI2XCpcMM3gcCH8viOFUJ+nKv7QLimiTSRvnV4lNO+xNhR4qntny7aSC5mP D9Lk5LF6ZRimVHMN+fXJceCj9xqDJfNC1xbcqXxe3yYUkov8nmpDWNlEDI/VW5c5X5A8 J4Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:user-agent :mime-version:content-transfer-encoding; bh=TD/E4bIJ2Cw06XH2tp5J7EdTNKcB+vz7aRBkSaXyvEA=; b=OU8hakMCgR76J8bmYO6ex1unM53V87lo78yxZzB7Z0XCZWEIB6AivMueL38a/b4PrR vSxWPMHHmuIOLefXSJgYblYs6pfuOuJnxNcXAnJh7BKkkk1ySQyMhkCSXvLXDf4+4TiB 0D+jjxlrxxFFCi+JwJuGlWwn/bZH0P//OXDD2lgfAoJaiXZL4fk1KB0INVbMsPeEYYz3 1kLkGOMqi7u8eGhLHlU0Dav+UeT42FMOMhSFg8zd+Bfp8hBhV9ob50DSfNFa8nnt8vOR WKaeWGgILAfyYT7B37o6EbA7DLQfZH1yN5o4E9pceB2fB5bCsx/626CDQkPjWy6Pfje9 YJWw== X-Gm-Message-State: AOAM530D5u7f5X/OQN6QkR4j9cL7tFb8cfWFxMJo0wbZxcs39CBGqP7t Mrf4pTYkBi31RksRtIvmgSZsaSqJ7Fs1RA== X-Google-Smtp-Source: ABdhPJzWHFVlRVWBr9NvpGxt464QnnLyIF3v/CKIKF6BytogIHJt4fGhJ2igwUaNTJw/0s3/epZHBQ== X-Received: by 2002:a05:6402:190c:: with SMTP id e12mr23555488edz.388.1608716534862; Wed, 23 Dec 2020 01:42:14 -0800 (PST) Received: from zion.lan (111.219.93.209.dyn.plus.net. [209.93.219.111]) by smtp.gmail.com with ESMTPSA id l1sm11275422eje.12.2020.12.23.01.42.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Dec 2020 01:42:14 -0800 (PST) Message-ID: <91af8ff408406533cca7a277c2c219dae19c6a41.camel@gmail.com> From: Glyn Normington To: "jsonpath@ietf.org" Date: Wed, 23 Dec 2020 09:42:13 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Jsonpath] Move the draft repository to the official organisation X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 09:42:19 -0000 Now the merged draft has been adopted, I think we should move the repository containing it, https://github.com/jsonpath-standard/internet-draft, to the official WG organisation https://github.com/ietf-wg-jsonpath for further development. Please note that PR 46 is underway and there are issues which I think should be retained. So I think it makes more sense to move the repo wholesale, and then rename it, rather than copy the contents. If the owner(s) of the above organisation agree, please could one of them temporarily give me admin access to the organisation (or at least the ability to create repositories) and I can then initiate the transfer. Note: I have been invited to collaborate on the repo https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath, but pushing the contents of the current repo there would lose PR 46 and the issues in the current repo. Thanks, Glyn From nobody Wed Dec 23 02:16:02 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AB33A0E88 for ; Wed, 23 Dec 2020 02:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cjVnRUuW1_Kl for ; Wed, 23 Dec 2020 02:15:56 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 EF4673A0E85 for ; Wed, 23 Dec 2020 02:15:55 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id n26so22097929eju.6 for ; Wed, 23 Dec 2020 02:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=W9eyp/1/J6oArkE9ofAO7gSvijHCxXSi6fW1xBJZ6nc=; b=QRhunDhabFBXrXwgcmxTPwiFeYCM7t8wLTdVBJa/kF6Iwis3Tri8Ejc58c5Ky6upn9 NxtKDjv0XehSsY55xHl4qjQXygyEVlPVvwsxvgLzkTPh4wByBriCzSez09MdZcSXDFlw jTuFo2lSxRLVEet95zN3GfPBHGTRyKtNaseDCecsKvQzQeoEQ6e3sZiWOwKXUf4lusQN 2bReQnV2nvDTVsnQTXyTPriP5c4nQhGiVtD6yHh3C6/ril/Qvz4CVGHH5aSCroIifOwx DiLIFMu31XN9cPVYNN2U5uPzQisLMUbF535+mmOx4DKmc7nMSITrkUfaVsmDNa5XS0Tb ba0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=W9eyp/1/J6oArkE9ofAO7gSvijHCxXSi6fW1xBJZ6nc=; b=YwPL9NpqcEs7q+XGZQ7Rlbcj8/MJ08dp9bVfw7BAqtz64Z9G61t1gaAYH0RVaeUiN6 yzoYW1saDlX5Tf8im04j57rS6JAptTCJfpgQZfoFlIkUujglpZaKN1+yECWFvyHlGyUU YWxnL0kTd47vvZe1bgdj4d02F1QlmWH0xAbuddNEUBKRpUOaOziRWWbRGf/3R34q/Zlt shSf5Z2mqdxYxRI4o+xUdjQCH/EPJMhg6cNUOd2nXQU3H2BVPRtNKMPzu5UNEPZr/opM JXPvpjSuv4v28WchnDH0Q23g4N46pWbZ7JQKKu7xfDJmMbj4ZI/sxJWRicsHsodkrQm0 1G/A== X-Gm-Message-State: AOAM53229dpeXI/SeURnr17MmZYmNRsAumj4uWfuQ8Lk3W6mK0JIljRM /LWRIaFZHrM8IksQa9CHIAW4Ny2JO4tVew== X-Google-Smtp-Source: ABdhPJwi0kVwuqjyjpibWqZ86Owl5TVbMoX+Ys0taGNFhGhN+auP/xtV2HBx6kqwlgA8CipSP0wOfw== X-Received: by 2002:a17:907:546:: with SMTP id wk6mr22950733ejb.238.1608718553920; Wed, 23 Dec 2020 02:15:53 -0800 (PST) Received: from zion.lan (111.219.93.209.dyn.plus.net. [209.93.219.111]) by smtp.gmail.com with ESMTPSA id ef11sm11327638ejb.15.2020.12.23.02.15.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Dec 2020 02:15:53 -0800 (PST) Message-ID: From: Glyn Normington To: "jsonpath@ietf.org" Date: Wed, 23 Dec 2020 10:15:52 +0000 In-Reply-To: <91af8ff408406533cca7a277c2c219dae19c6a41.camel@gmail.com> References: <91af8ff408406533cca7a277c2c219dae19c6a41.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] Move the draft repository to the official organisation X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 10:16:01 -0000 Thanks to swift action by James, I've move the repository to: https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath I'm pleased to say that PR 46 survived the move as did the issues. Please update your remotes, e.g.: git remote set-url origin https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath.git On Wed, 2020-12-23 at 09:42 +0000, Glyn Normington wrote: > Now the merged draft has been adopted, I think we should move the > repository containing > it, https://github.com/jsonpath-standard/internet-draft, to the > official WG organisation https://github.com/ietf-wg-jsonpath for > further development. > > Please note that PR 46 is underway and there are issues which I think > should be retained. So I think it makes more sense to move the repo > wholesale, and then rename it, rather than copy the contents. > > If the owner(s) of the above organisation agree, please could one of > them temporarily give me admin access to the organisation (or at > least > the ability to create repositories) and I can then initiate the > transfer. > > Note: I have been invited to collaborate on the repo > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath, but > pushing the contents of the current repo there would lose PR 46 and > the > issues in the current repo. > > Thanks, > Glyn > From nobody Wed Dec 23 10:56:52 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78DB3A0827 for ; Wed, 23 Dec 2020 10:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 zyB3Gk8c8Q48 for ; Wed, 23 Dec 2020 10:56:49 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4094D3A0811 for ; Wed, 23 Dec 2020 10:56:49 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id h22so32845730lfu.2 for ; Wed, 23 Dec 2020 10:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Xvm5ypuYS/m3F/PPhdCKuEfRY/rHw5IRWlrzEu83okg=; b=V4u0PT7L96doU2P4QuHtwSmHT5QlYSJu9aT5etOF46Czi3G0+vu+XfZpI86oYan7SQ VQVyy3JUY6mol1/V6yMPZVAJLXeyJpEw/Y3rKd6ZoeKvy9qOf0WzNMvXh0Av7J7g1j8S BncVyIsHhzDqjz4i/zLrRBp3GuzE/xLP4p5ITlONp/k48fGNbJRJZUH9lbzi9lQ3SgYe n1pVDCEtpMMn2OlLwgVAF4zuOO/aQEsfpCYoDwoH3mYHh4vYPu1yKzUVIPqJarVd0aaG skOIC+yWkloRyNUEuu8y9nqyRuHwbY/wVYoW6kzxGpWzb+2XE52Zfp/Y1QdOdMzkRaOV ex5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Xvm5ypuYS/m3F/PPhdCKuEfRY/rHw5IRWlrzEu83okg=; b=Ik3PlYrYqJZ590p1HIBd6Vu5f//0VVko421rkT4G3LFvqPZkaRR4j+QHmWHmQvacPf NwojMGEZEJ+T1fBJjYmLGk350rkr1STKUfmL+qbLFeViLVT480vBAAS7COpEW7xtQiu4 OOipZqUMd+jdSAK0tvgUtpxNn6zx4smkAJeYL/7YLrCqHl5NzARna8KDiJW2BTRg0P0K ZZDV36kA2kE5MoOUNwg4jBEN95CctJ9JSnReQiIEiWw2DOuN66n7W/japGfPMUziT0oi 5BcaqIFgAhDXWFjVh21DepVbYW2kZzr5QNBUa5kVnAqzXPoT6AzrNfnH4W1O9zcOoF86 S6EA== X-Gm-Message-State: AOAM532Ko9qZA2VpnlQZqo4RRrYzqzNLOWKPreowK6JJI35QPQXzEiQW rJsHa3IsdbZjSwPT4vn27jAu9n9lMprquMdmh0X22C9pstrznQ== X-Google-Smtp-Source: ABdhPJz1C1PRVP9Wd7MHXc9QKboFchC7JEbIqymDv1+/gKQgj+zpm3Mui1gk/IqH8V8EmqkFO1rGGxg5pi4kfrKrF/E= X-Received: by 2002:a19:495b:: with SMTP id l27mr10584636lfj.451.1608749807241; Wed, 23 Dec 2020 10:56:47 -0800 (PST) MIME-Version: 1.0 From: Tim Bray Date: Wed, 23 Dec 2020 10:56:36 -0800 Message-ID: To: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb42d205b72640fa" Archived-At: Subject: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 18:56:51 -0000 --000000000000cb42d205b72640fa Content-Type: text/plain; charset="UTF-8" On behalf of James and myself: Thanks to everyone for the quick consensus on accepting the Carsten/Glyn combined draft for adoption by the WG, and special thanks to Glyn and Carsten for getting this pulled together. The next thing we need to do is get it checked in - James has made a repo in our project at https://github.com/ietf-wg-jsonpath. We think the proper new name is draft-ietf-jsonpath-jsonpath-00 - does anyone disagree? After reaching out to all four people who edited previous drafts, James and I have asked Marko Mikulicic and Stefan Goessner to serve as co-editors for the WG going forward. It would be appreciated if our co-editors could fix up the name and have a look at the issues on Glyn's repo and migrate at least some of them over to our official project, applying editorial judgment about what deserves to be carried forward. As soon as the draft is in place, we're hoping to see a flurry of issues and PRs and looking forward to lively discussion of what a JSONPath really is and what we can most usefully say about it. --000000000000cb42d205b72640fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On behalf of Ja= mes and myself: =C2=A0Thanks to everyone for the quick consensus on accepti= ng the Carsten/Glyn combined draft for adoption by the WG, and special than= ks to Glyn and Carsten for getting this pulled together.

The next thing we ne= ed to do is get it checked in - James has made a repo in our project at=C2= =A0https:= //github.com/ietf-wg-jsonpath.=C2=A0 We think the proper new name is dr= aft-ietf-jsonpath-jsonpath-00 - does anyone disagree?

After reaching out to a= ll four people who edited previous drafts, James and I have asked=C2=A0Marko Mikulicic and Stefan Goessner to serve as co-editors for th= e WG going forward. It would be appreciated if our co-editors could = fix up the name and have a look at the issues on Glyn's repo and migrat= e at least some of them over to our official project, applying editorial=C2= =A0judgment about what deserves to be carried forward.

<= font face=3D"Roboto, RobotoDraft, Helvetica, Arial, sans-serif">As soon as the draft is in place, we're=C2=A0hoping= to see a flurry of issues and PRs and looking forward to lively discussion= of what a JSONPath really is and what we can most usefully say about it.= =C2=A0
--000000000000cb42d205b72640fa-- From nobody Wed Dec 23 23:14:31 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFA53A1093 for ; Wed, 23 Dec 2020 23:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mp07nphP3YpK for ; Wed, 23 Dec 2020 23:14:28 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 3D35F3A0A1E for ; Wed, 23 Dec 2020 23:14:28 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id cm17so1399091edb.4 for ; Wed, 23 Dec 2020 23:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=Q4vP4UBX/HGj45ZliZNXXd1xZHEjjO913KOblkjetXI=; b=LZv3eUiKwcmb7ovVuItF6zNre9pYnF6NQF7fWyodJS9YDWb3iQGB6NZ+gWb6xb5dg1 rTM10MtfWNLMXfmvh77kYgv2UwAqyWKH9xq5DbVRSLgrgc61jzbIjTbNOWqIn+HMjui8 iPyEmO/WJdkyvcbgxcbHgRtTqmvI83R+jkV9evgWMf9JSHNnJcDAOz1DSsaj8VYkIv4g P6Va2XMt5sIGXUCgDKz08EFVa++YHXa8lNrkCOdfYuRSQbKE+lo44KhCOz8yMqgq/tCe ujmr2DgCuCtSOJvUGvEKRvLaapJFO3hSTr6UsFChUTmGiaryZKxY2W6qJ86QYnWmOlJy lkQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Q4vP4UBX/HGj45ZliZNXXd1xZHEjjO913KOblkjetXI=; b=DtRJI14JCwtCxow4QgCRHOW911+isboJmONnGbA/3ZqUGBOCVLvL5gSGlPQnzmUqh7 Y0f8Zo96Xf+m1qqWxJLpcwp5bg1nc6F3EwXOmjn9KYd39xaKwMNDAnnc5cI3JgRQUq2t 3orslTdEj+1Ehs7mOpgspA1wibFq8i/WTHV3Q1mHlEOI3/0qzhxi21RI2xpbSqc/QthY xPaLdFRmXxcnMfW4erKMR3rYKfUIgypSXahjWKJjjSc4PVT5/MuLe2ka+TTD1D1sR3YX Ftt5E2qiY1VMj10AEFB8lVMQLXVfmEuaNjudjMAeZY2CPbDSJFH2AayuTcYs7nNTd9D0 FXjA== X-Gm-Message-State: AOAM5311JjsW3HaF2l2bbx5mFJO8RBcVtcSOgxZsPaHaiTl8az15MsaL ggfNxKO9w5ZWxBSGx1wKGytdoleBOLno4g== X-Google-Smtp-Source: ABdhPJyjEp0jfFxAU9ub9xf+OrNIdlhp4Yeiw/pS17jg7oIUUcIOkKMhD1mJlxNHaFcCKpusTbrntQ== X-Received: by 2002:a50:bc15:: with SMTP id j21mr27313430edh.187.1608794066657; Wed, 23 Dec 2020 23:14:26 -0800 (PST) Received: from zion.lan (111.219.93.209.dyn.plus.net. [209.93.219.111]) by smtp.gmail.com with ESMTPSA id x4sm32362255edr.40.2020.12.23.23.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Dec 2020 23:14:25 -0800 (PST) Message-ID: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> From: Glyn Normington To: Tim Bray , jsonpath@ietf.org Date: Thu, 24 Dec 2020 07:14:24 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 07:14:30 -0000 On Wed, 2020-12-23 at 10:56 -0800, Tim Bray wrote: > On behalf of James and myself:  Thanks to everyone for the quick > consensus on accepting the Carsten/Glyn combined draft for adoption > by the WG, and special thanks to Glyn and Carsten for getting this > pulled together. > > The next thing we need to do is get it checked in - James has made a > repo in our project at https://github.com/ietf-wg-jsonpath.  We think > the proper new name is draft-ietf-jsonpath-jsonpath-00 - does anyone > disagree? I presume that's the name of the document. (The repo should not, of course, have a version in its name.) Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- jsonpath-00 be less cumbersome? I don't feel strongly, but it would be good to know the rationale. > > After reaching out to all four people who edited previous drafts, > James and I have asked Marko Mikulicic and Stefan Goessner to serve > as co-editors for the WG going forward. It would be appreciated if > our co-editors could fix up the name and have a look at the issues on > Glyn's repo and migrate at least some of them over to our official > project, applying editorial judgment about what deserves to be > carried forward. > > As soon as the draft is in place, we're hoping to see a flurry of > issues and PRs and looking forward to lively discussion of what a > JSONPath really is and what we can most usefully say about it.  From nobody Wed Dec 23 23:26:04 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73E53A109F for ; Wed, 23 Dec 2020 23:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 3NIuZbVp5ier for ; Wed, 23 Dec 2020 23:26:01 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 B59823A109E for ; Wed, 23 Dec 2020 23:26:01 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id y19so2822474lfa.13 for ; Wed, 23 Dec 2020 23:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xSPuvIede/gL2/LfUt1MVKAaP3AAripcLgvxe8bvGP4=; b=SDsuiwLEVDTc4zanHyHkNmnMlQLkUIgAYC7wP3cpi/CA5/4+1vrI5lTQEftqlO1fe9 FQBuRltGOIGNywPVrqw7U+n3Lz7Glzrg3PVU/ALujwtSGu5QjjqUS6v11ZiL4WsIovan Neu5BDUYtUb7s3a7U+j5OHKZluq3DkA2OPUkCoo5NWMw0AFeVDvWQiMVSnJEUQE6OZ8t 8/di+anfIIu2Qt30mJFc89fVAzLhgtzPTeseJuakWt7WNOeu/tD8+jzGI0juDnc4VIAf XkY/4Z0q3sLZt+VQLSQBFOZHljK1FiZfHdZUbbRbIK5Ghy8rbmIYSf03FMbbDSN6PARD 3ADg== 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; bh=xSPuvIede/gL2/LfUt1MVKAaP3AAripcLgvxe8bvGP4=; b=lNOrYlDJY3SCOhH1qErj/IDHN91g/HvuxMDRODeksXSjFXX0w7jZRR20eTaQ1vgl0N EOTpi7l5NjTKRhoF4i7wOTWHCxlXbIxRlt1EgE+M7c7iE0E0i/VBRgmmtC+4jPeUPTVA SeIBvfn+OACfcWu422tdXvCO96A3yUERWxB469SI+zitAstX91fi/Ftk400qGvQwg2S6 ThT6kla7xvxDnsGKmDGWNQaFesFgHM6O3bkQLisN5xywdf4nJN8PJPZdWUmjSYJVKTvT 0172n+EpOS8Ebjhm4R5x9cfQ7ocCTsTAg9sV6yXOqmod0dnrGT0Yxb+GOSAWa3G/x+lV fBUA== X-Gm-Message-State: AOAM531NsgNRgug4uItfL4nDAwuzxe0J0tg+23IgQD1+nsVE8oggoOl6 kF7FHO9NhClRKiXwGWgbg+/A2nd3xDrhj9bSbhqlRg== X-Google-Smtp-Source: ABdhPJxXjfPi67lmINuoM+SSmrAaEMp3eukZpsXUj/bRsrO9ivRZb42B+9OCa1exxj/neyUgfLQqzoMUTDJVJjsmuIk= X-Received: by 2002:a2e:8852:: with SMTP id z18mr14559891ljj.94.1608794759574; Wed, 23 Dec 2020 23:25:59 -0800 (PST) MIME-Version: 1.0 References: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> In-Reply-To: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> From: Tim Bray Date: Wed, 23 Dec 2020 23:25:48 -0800 Message-ID: To: Glyn Normington Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="00000000000029485a05b730b8d2" Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 07:26:04 -0000 --00000000000029485a05b730b8d2 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 23, 2020 at 11:14 PM Glyn Normington < glyn.normington.work@gmail.com> wrote: > > The next thing we need to do is get it checked in - James has made a > > repo in our project at https://github.com/ietf-wg-jsonpath. We think > > the proper new name is draft-ietf-jsonpath-jsonpath-00 - does anyone > > disagree? > > I presume that's the name of the document. (The repo should not, of > course, have a version in its name.) > > Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be > good to know the rationale. > The convention is draft-ietf-${WG}-${DRAFT_SUBJECT} - in my previous IETFing I've never been in a situation where the WG name and draft subject are the same, but it can't be entirely unknown. I'll bounce it off our AD. > > > > > After reaching out to all four people who edited previous drafts, > > James and I have asked Marko Mikulicic and Stefan Goessner to serve > > as co-editors for the WG going forward. It would be appreciated if > > our co-editors could fix up the name and have a look at the issues on > > Glyn's repo and migrate at least some of them over to our official > > project, applying editorial judgment about what deserves to be > > carried forward. > > > > As soon as the draft is in place, we're hoping to see a flurry of > > issues and PRs and looking forward to lively discussion of what a > > JSONPath really is and what we can most usefully say about it. > > > --00000000000029485a05b730b8d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 23, 2020 at 11:14 PM Glyn Normington <glyn.normington.work@gmail.com> wrote:
= > The next thing we need to do is get it checked in - James has made a > repo in our project at=C2=A0https://github.com/ietf-wg-jsonp= ath.=C2=A0 We think
> the proper new name is draft-ietf-jsonpath-jsonpath-00 - does anyone > disagree?

I presume that's the name of the document. (The repo should not, of
course, have a version in its name.)

Out of interest, why the "stutter" in the name? Wouldn't draf= t-ietf-
jsonpath-00 be less cumbersome? I don't feel strongly, but it would be<= br> good to know the rationale.

The convention is draft-ietf-$= {WG}-${DRAFT_SUBJECT} - in my previous IETFing=C2=A0I've never been in = a situation where the WG name and draft subject are the same, but it can= 9;t be entirely unknown. I'll bounce it off our AD.

=C2=A0

>
> After reaching out to all four people who edited previous drafts,
> James and I have asked=C2=A0Marko Mikulicic and Stefan Goessner to ser= ve
> as co-editors for the WG going forward. It would be appreciated if
> our co-editors could fix up the name and have a look at the issues on<= br> > Glyn's repo and migrate at least some of them over to our official=
> project, applying editorial=C2=A0judgment about what deserves to be > carried forward.
>
> As soon as the draft is in place, we're=C2=A0hoping to see a flurr= y of
> issues and PRs and looking forward to lively discussion of what a
> JSONPath really is and what we can most usefully say about it.=C2=A0

--00000000000029485a05b730b8d2-- From nobody Wed Dec 23 23:27:59 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDBB3A10A2 for ; Wed, 23 Dec 2020 23:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OLXp7hVY5n1h for ; Wed, 23 Dec 2020 23:27:55 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76413A10A0 for ; Wed, 23 Dec 2020 23:27:54 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4D1hVw4gBQzyRY; Thu, 24 Dec 2020 08:27:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> Date: Thu, 24 Dec 2020 08:27:52 +0100 Cc: Tim Bray , jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 630487671.4360861-d90aecaffdd5e7aa409c0dd1ad881899 Content-Transfer-Encoding: quoted-printable Message-Id: <86F20551-0819-4D0E-B987-5B2D39CE86CF@tzi.org> References: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 07:27:57 -0000 On 2020-12-24, at 08:14, Glyn Normington = wrote: >=20 > Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be > good to know the rationale. Internet-draft naming for WG documents is draft-ietf-wgname-subject-subject-subject-nn Now if there is only one draft in the WG, we might leave the subject off = entirely. I actually find a few cases where this has been done: draft-ietf-cnrp-12.txt draft-ietf-geojson-04.txt draft-ietf-gsmp-11.txt draft-ietf-itrace-04.txt draft-ietf-lisp-24.txt draft-ietf-otp-01.txt draft-ietf-sming-02.txt draft-ietf-upsmib-05.txt Most of these are older cases (1994 to 2006, with geojson at 2016 being = the newest), but it sure could be done again. (Some of the WGs then did develop further drafts with non-empty subject = parts, e.g., lisp.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 23 23:51:29 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F993A10B5 for ; Wed, 23 Dec 2020 23:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 nHThoRCSY6CE for ; Wed, 23 Dec 2020 23:51:27 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 074503A10B3 for ; Wed, 23 Dec 2020 23:51:26 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m25so2974489lfc.11 for ; Wed, 23 Dec 2020 23:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ffYiXHtbtfmTaAU7xYT+9EZiU0egQzF2vE2clhPqV/8=; b=BNk7ktatXRGBlviXSu0MJLh+eSX43uHTg0gph7NFXKTV0KiZw/9gXC6EcFj4ApQ/gu wiAG1tHhf0fGcxd4BnUsc5HsgX1wlY7KMjFOBvUwsCeKOOJCbg2JaFhf5+N+cCaW2cSo DUl++niDxu5hKTHolHUc8f7aWkAfdtQJ+GYNcH/3LDLdfK03MJaVFNs0RT35+oqSpjF0 mAOTj2LDjUQmyB6E8C4jjS6f0PcjPSv0dz5ABqN8oCeh+zUHJVEjLD6/m9bNIxHFMUGt sgvRIBXeHloTwgCfKBZ2fy9J0SRRTXCzECCp8yBKFetzIC4bBe2+XNVA8Gd9AQqeWSic JaCQ== 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; bh=ffYiXHtbtfmTaAU7xYT+9EZiU0egQzF2vE2clhPqV/8=; b=ettm7vrIqz8JwlIjH/U5G88Z4CX9iW3yByMebT9vQGAOeea6tGH9p4XO4xfcH4VOHz Mi5gqr53ESp5op6e8jT6stCYMi6ObobsdOH0/5wRSo7UqzT/73suP4dvEvjR1Daj0JKo n7Q4Pdz5hiGwWYB1onUhMIUB/6vZBmSm1SSNISHpsX2exzrSko6kMNt5aRvSm7hS5NwW iMROT9hf2XGg1CrkmX8MusZ03fVlH5P4ZGyfqGuOlyMk/6Q+itxzYwk7FeKJc+PKCRAC CoGs4hPssv+kpVnrp+ITvzYI+VWDywvcURaKcNieCmE5zYZUU/LMrXCEioU5A6TeHZfj IaeA== X-Gm-Message-State: AOAM5314gzY7rqzy0Cf1DlGBUVXZq6mJN14a5ZiuoM8PNlmmPrUqhnaI jkUafqkuZWeL0+RWWY7G/vibT7N0bmKvdpFqYWUHuorK1gM= X-Google-Smtp-Source: ABdhPJzNmVCnNI/vZmuIpOWPtGh3DxK2aqIztD7ac61tMIogl/FyLX2VDvwRE/RmwjGBNtiJ10bVT1lvX3XTQXXKUug= X-Received: by 2002:a2e:b80d:: with SMTP id u13mr13649751ljo.143.1608796285308; Wed, 23 Dec 2020 23:51:25 -0800 (PST) MIME-Version: 1.0 References: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> <86F20551-0819-4D0E-B987-5B2D39CE86CF@tzi.org> In-Reply-To: <86F20551-0819-4D0E-B987-5B2D39CE86CF@tzi.org> From: Tim Bray Date: Wed, 23 Dec 2020 23:51:14 -0800 Message-ID: To: Carsten Bormann , "Murray S. Kucherawy" Cc: Glyn Normington , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a213205b73113ad" Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 07:51:29 -0000 --0000000000001a213205b73113ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmm, draft-ietf-jsonpath-00 certainly wouldn't offend me, but on the other hand there's a lot to be said for sticking to conventions. I'm imagining someone writing a bot to plow through WG drafts and relying on the convention. I've added Murray to the "To" line to see if he has an opinion. James? Anyone else? On Wed, Dec 23, 2020 at 11:27 PM Carsten Bormann wrote: > On 2020-12-24, at 08:14, Glyn Normington > wrote: > > > > Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- > > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be > > good to know the rationale. > > Internet-draft naming for WG documents is > > draft-ietf-wgname-subject-subject-subject-nn > > Now if there is only one draft in the WG, we might leave the subject off > entirely. > I actually find a few cases where this has been done: > > draft-ietf-cnrp-12.txt > draft-ietf-geojson-04.txt > draft-ietf-gsmp-11.txt > draft-ietf-itrace-04.txt > draft-ietf-lisp-24.txt > draft-ietf-otp-01.txt > draft-ietf-sming-02.txt > draft-ietf-upsmib-05.txt > > Most of these are older cases (1994 to 2006, with geojson at 2016 being > the newest), but it sure could be done again. > > (Some of the WGs then did develop further drafts with non-empty subject > parts, e.g., lisp.) > > Gr=C3=BC=C3=9Fe, Carsten > > --0000000000001a213205b73113ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm= , draft-ietf-jsonpath-00 certainly wouldn't offend me,=C2=A0but on the = other=C2=A0hand there's a lot to be said for sticking to conventions.= =C2=A0 I'm imagining someone writing a bot to plow through WG drafts an= d relying on the convention. I've added Murray to the "To" li= ne to see if he has an opinion.=C2=A0 James? Anyone else?

On Wed, Dec = 23, 2020 at 11:27 PM Carsten Bormann <ca= bo@tzi.org> wrote:
On 2020-12-24, at 08:1= 4, Glyn Normington <glyn.normington.work@gmail.com> wrote:
>
> Out of interest, why the "stutter" in the name? Wouldn't= draft-ietf-
> jsonpath-00 be less cumbersome? I don't feel strongly, but it woul= d be
> good to know the rationale.

Internet-draft naming for WG documents is

draft-ietf-wgname-subject-subject-subject-nn

Now if there is only one draft in the WG, we might leave the subject off en= tirely.
I actually find a few cases where this has been done:

draft-ietf-cnrp-12.txt
draft-ietf-geojson-04.txt
draft-ietf-gsmp-11.txt
draft-ietf-itrace-04.txt
draft-ietf-lisp-24.txt
draft-ietf-otp-01.txt
draft-ietf-sming-02.txt
draft-ietf-upsmib-05.txt

Most of these are older cases (1994 to 2006, with geojson at 2016 being the= newest), but it sure could be done again.

(Some of the WGs then did develop further drafts with non-empty subject par= ts, e.g., lisp.)

Gr=C3=BC=C3=9Fe, Carsten

--0000000000001a213205b73113ad-- From nobody Thu Dec 24 04:32:05 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0E3A1209 for ; Thu, 24 Dec 2020 04:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 ZFWxrGWh7ABZ for ; Thu, 24 Dec 2020 04:32:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6E73A1208 for ; Thu, 24 Dec 2020 04:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1608813120; bh=bWa6Y25jioiqXLR3AvL3ISaghzdM4p3+Xb8f3pZu75c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=I7g4n7F7gdH/RX6D7vbiZRGjLGM2C+CxVZzwNalGJIgAM/KfHVRYLWei2qMppGrA0 3oNnWgy/P8e2ABUKnzfqtSEcf7uEP8YCHrShCHLHGuG3MYcFAPyyfemqSiV0RbNjsJ jKk50C3lvtNGelHx30lK95OsjijeZcBoanAieY9g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([84.171.158.45]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2wL0-1ktViW1LeG-003M4D for ; Thu, 24 Dec 2020 13:32:00 +0100 To: jsonpath@ietf.org References: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> <86F20551-0819-4D0E-B987-5B2D39CE86CF@tzi.org> From: Julian Reschke Message-ID: Date: Thu, 24 Dec 2020 13:31:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:TpfIO6i33bMQXZ/tL21akb2LGKkj1d3qGE78Z5LThYrz/co/g1H LrcktPAsVtkXOfDflpwah/hkUdbQEHhY3G1pgeIG4c2IhWMWf6Ge3ql/1iBVnnllkgspqbg 20xvmOujnvugsAsEv/J5IIocbXwPTx+yrYlmrzPpudqXltQBVqcElgC1aqw8aZWvTLj3huT XlSprHM1SqXZLlOoSR56A== X-UI-Out-Filterresults: notjunk:1;V03:K0:HdXgq7AZ7DM=:4kt1Zpq0C9HpD/qCt5ShvU x+ty5NWy3woC+Nv5MbEYcAXBrQtusw4Q8hN8BtENZtr0vYDP/JoGT+vKhuC/rSuOi5t0wGrgh Yv5bkkscbhKhMDTei18UU9kj8T3CBmz9+rEWm1RqBK5e9jc8nVlt5kSexM/220hmVIHbr3mCJ 7fDLoebKZNqwq8JDex53ioQ9dkxrjaz5a/yJaS8kNxjjEUeuDjSEpHAlliRnZ+f59vZ/bGXxY vxF/f5WEiZEZgJbEQnLmcARIMUfGNvu+tdWGS0yu2NBpnVDwYtUVfzfS7OfhrHP6Fq+bbystS i+Zxt9ssCbxtthGIvIVMEc6LewH+jeECda591gcDgAKUPx+K2ywcwtZ+GWUoqTfHpFI/jXs6P FAXOIkiNLrbE//zV2joDElHgLUWflYnw1oktuo7BBHsYddqG7D2Nw6/SfPeheISFZIF5v1ATQ EzhvR1TRakaEya8w6YQ+xCvQdXVlHlMWeZZ8II3U/yI0X9MQODTlGmhValyYZKs4jhzmxHX2b 9+EuL3saMzZtAVg4m0FuIWAx6WqAe+ctxCeItnIYNqNuVMIXR7iLveI12etxp3mmdzkL4d4d5 Xygq52tpmzWMBkuggElvusTdp2bncauXQG+jOAHNf9WNjwLn0J4g0CTS8Ed7gNKKTRJY0R9UT qbmgm0+KEVHc9AmQrR1ou/gtxtI4Jo+8T+gva6OAxT/XwFQcmGPzdieawcjBKpvqCHQ9M8A9T gsl5lFDMfpo7acoRSPVw/3gBmVDoXrOofmfIEo1AgBhbK/tvfsl+gX2gsjhSV8RTtJpcfUgPT N1cjBSiTtaLS24j9S7W8CANj+Nu2QumSKWwchLDxuVQogtSa5tcBlgetpe0HYNYZza+f+V1C7 yfBXq00El7jmYfFoK2FA== Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 12:32:04 -0000 Am 24.12.2020 um 08:51 schrieb Tim Bray: > Hmm, draft-ietf-jsonpath-00 certainly wouldn't offend me,=C2=A0but on th= e > other=C2=A0hand there's a lot to be said for sticking to conventions.=C2= =A0 I'm > imagining someone writing a bot to plow through WG drafts and relying on > the convention. I've added Murray to the "To" line to see if he has an > opinion.=C2=A0 James? Anyone else? > ... Just lookes at and found it to be not that helpful (yes, sent mail reporting the brokenness). Anyway: I believe sticking with the naming convention is more important than avoiding "stutter". Best regards, Julian From nobody Thu Dec 24 08:35:46 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586E83A1308 for ; Thu, 24 Dec 2020 08:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oloO5MPrvNW1 for ; Thu, 24 Dec 2020 08:35:44 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 E1E8E3A1307 for ; Thu, 24 Dec 2020 08:35:43 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id x26so1564251vsq.1 for ; Thu, 24 Dec 2020 08:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=08amglmstEw8dF4fW4NwSc54IikXnqXijnYKzxZ4apk=; b=aIbyMNxD5lSqpsT8qPDssgYV7gQMzG3CR3EA0CUG2fbAgZZKT1Wf9VtZd/3s3fetCE ljOp3uueb9aD05cUrDWKdVaoMsc45vDalhGqLc15otbPl1kVjkdy+OpEJw8niWv6NF1L z9bVUVxM2iclysjGFe1OkLlkHKJWEH5oqdaMeJWCv2fXM5xKXSH6/fJKuWuRoN7Zu01J bHWdidgpWbq+Y5fDuH1gKxykUcb7VBoCt6eqJNtVJ0k/HX/C7OI7OWR2Zd5sOPD0ZhoG 7xvw4QhoYob1ze88qA3TISJZ7GbyrNLXQ9GTp/2Csuj+yVxIt2GYXJX4YOOmJq9Dyu9A 6dNw== 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; bh=08amglmstEw8dF4fW4NwSc54IikXnqXijnYKzxZ4apk=; b=jBsl0if91njcazIXWjHfmf8UPu7fW5OX4qBb2cTUlEemJEq5ZLusFE+noHvsWcGsoE x4oRQzNUEvTqrGWldNIy9qHDrGpLi+N8t/FHEmhjiRZwoQB1x1xkER5dx8Y0e1l1t6j+ DBMc7rwRidzPsZF0o3jJRnS0YugdOOobzizvESoexRexAXPM/l/1jkehJs7eP9U2sxDl WcZSjZ/Y9VXxzz74aHdX5slK/hFcMfQnIp6OGIYkgfpdCnW4jYc29+9ySq98PioSGrou INQyPJuJTR2ZNpWpUt3EWMi8kfoRN2ckgw033cbxB2VAQRQPpx1qofdq52d4GzqJAVBB /WIQ== X-Gm-Message-State: AOAM532ZMn/PmJVkqAsJp/UNkUxzSFyTtVUQC+KLq7CdZsnBixhH8cmK RAaNNcWgXhPanNEiaSFUvzvDoW9+HFjqldG1LEY= X-Google-Smtp-Source: ABdhPJyuqvQTHKCXr6tdlI8HIg1ZVseAPubBOMX6zzhJ3T0p4ql94nnKsSltDBniE+wOY5RJR78dVD6QuwIfYKnOJnM= X-Received: by 2002:a67:18c6:: with SMTP id 189mr21550351vsy.54.1608827742670; Thu, 24 Dec 2020 08:35:42 -0800 (PST) MIME-Version: 1.0 References: <00da063e49dd4ba176651eb5b52b01bbf18522ac.camel@gmail.com> <86F20551-0819-4D0E-B987-5B2D39CE86CF@tzi.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 24 Dec 2020 08:35:31 -0800 Message-ID: To: Tim Bray Cc: Carsten Bormann , Glyn Normington , jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000001b513b05b73866a5" Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 16:35:45 -0000 --0000000000001b513b05b73866a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suggest draft-ietf-jsonpath-base-00. -MSK On Wed, Dec 23, 2020 at 11:51 PM Tim Bray wrote: > Hmm, draft-ietf-jsonpath-00 certainly wouldn't offend me, but on the > other hand there's a lot to be said for sticking to conventions. I'm > imagining someone writing a bot to plow through WG drafts and relying on > the convention. I've added Murray to the "To" line to see if he has an > opinion. James? Anyone else? > > On Wed, Dec 23, 2020 at 11:27 PM Carsten Bormann wrote: > >> On 2020-12-24, at 08:14, Glyn Normington >> wrote: >> > >> > Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- >> > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be >> > good to know the rationale. >> >> Internet-draft naming for WG documents is >> >> draft-ietf-wgname-subject-subject-subject-nn >> >> Now if there is only one draft in the WG, we might leave the subject off >> entirely. >> I actually find a few cases where this has been done: >> >> draft-ietf-cnrp-12.txt >> draft-ietf-geojson-04.txt >> draft-ietf-gsmp-11.txt >> draft-ietf-itrace-04.txt >> draft-ietf-lisp-24.txt >> draft-ietf-otp-01.txt >> draft-ietf-sming-02.txt >> draft-ietf-upsmib-05.txt >> >> Most of these are older cases (1994 to 2006, with geojson at 2016 being >> the newest), but it sure could be done again. >> >> (Some of the WGs then did develop further drafts with non-empty subject >> parts, e.g., lisp.) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> --0000000000001b513b05b73866a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suggest draft-ietf-jsonpath-base-00.

=
-MSK

On Wed, Dec 23, 2020 at 11:51 PM Tim Bray <tbray@textuality.com> wrote:
=
Hmm, draft-ietf-jsonpa= th-00 certainly wouldn't offend me,=C2=A0but on the other=C2=A0hand the= re's a lot to be said for sticking to conventions.=C2=A0 I'm imagin= ing someone writing a bot to plow through WG drafts and relying on the conv= ention. I've added Murray to the "To" line to see if he has a= n opinion.=C2=A0 James? Anyone else?

On Wed, Dec 23, 2020 at 11:27 PM = Carsten Bormann <cabo@= tzi.org> wrote:
On 2020-12-24, at 08:14, Glyn Normington <glyn.normington.work@gmail.com= > wrote:
>
> Out of interest, why the "stutter" in the name? Wouldn't= draft-ietf-
> jsonpath-00 be less cumbersome? I don't feel strongly, but it woul= d be
> good to know the rationale.

Internet-draft naming for WG documents is

draft-ietf-wgname-subject-subject-subject-nn

Now if there is only one draft in the WG, we might leave the subject off en= tirely.
I actually find a few cases where this has been done:

draft-ietf-cnrp-12.txt
draft-ietf-geojson-04.txt
draft-ietf-gsmp-11.txt
draft-ietf-itrace-04.txt
draft-ietf-lisp-24.txt
draft-ietf-otp-01.txt
draft-ietf-sming-02.txt
draft-ietf-upsmib-05.txt

Most of these are older cases (1994 to 2006, with geojson at 2016 being the= newest), but it sure could be done again.

(Some of the WGs then did develop further drafts with non-empty subject par= ts, e.g., lisp.)

Gr=C3=BC=C3=9Fe, Carsten

--0000000000001b513b05b73866a5-- From nobody Thu Dec 24 09:22:08 2020 Return-Path: X-Original-To: jsonpath@ietfa.amsl.com Delivered-To: jsonpath@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4E3A132D for ; Thu, 24 Dec 2020 09:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dilettant.eu 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 W9ql-_s9-gCY for ; Thu, 24 Dec 2020 09:22:04 -0800 (PST) Received: from mailrelay3-3.pub.mailoutpod1-cph3.one.com (mailrelay3-3.pub.mailoutpod1-cph3.one.com [46.30.212.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82E13A0C35 for ; Thu, 24 Dec 2020 09:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dilettant.eu; s=20191106; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version:from: content-transfer-encoding:content-type:from; bh=i9oJDNQpr86brca3pCcPU3AedmMJLFd1wrP/HLfRbl8=; b=R6xwxSEKi6zMq9Gp2GeFow3irWy/jOXZOgk1d1GYcHkFJr07EUTsmUfUbIAUFMuJrjOM8oeJXHWpC 6WP8XcC2Rmf5+FI4d7Ardh6l0mkmbyUqd6A4BF1/smQgO2nNB+SIs+FN1xofFNf7bD/bzB5cJD/VRF SUvaSi9O9nmIgAzHdm0UBvbb3eB+SVT8PU13y/6oXltXjv9Xm/KIqyqLcu1VEy6uhQ356rPhaWRTft pJBbrKRNOdM5t+UFTjhKTinClYdY82gbkNTdEAzfrv+rbkaxvAuxXj3oQKJ3IX1ipKaSLoW/HpPJMk k0ScpmdnidW/fIv5jYL6mC4RZj3sUlg== X-HalOne-Cookie: 0cacd4b0d6b2451c85a491ae9ad1597a1ae58568 X-HalOne-ID: 87b10f98-460c-11eb-8cb9-d0431ea8bb03 Received: from [192.168.1.112] (60.248.197.178.dynamic.dsl-lte-bonding.zhbmb00p-msn.res.cust.swisscom.ch [178.197.248.60]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 87b10f98-460c-11eb-8cb9-d0431ea8bb03; Thu, 24 Dec 2020 17:21:59 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-DBF005C6-890A-41A7-BE22-E4762DDCAFB5 Content-Transfer-Encoding: 7bit From: Stefan Hagen Mime-Version: 1.0 (1.0) Date: Thu, 24 Dec 2020 18:21:59 +0100 Message-Id: <48DC8041-83F9-42C7-A2B6-F7C7EC7382A6@dilettant.eu> References: Cc: Tim Bray , jsonpath@ietf.org, Glyn Normington , Carsten Bormann In-Reply-To: To: "Murray S. Kucherawy" X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Jsonpath] JSONPath WG next steps X-BeenThere: jsonpath@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A summary description of the list to be included in the table on this page List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 17:22:06 -0000 --Apple-Mail-DBF005C6-890A-41A7-BE22-E4762DDCAFB5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 24.12.2020 um 17:35 schrieb Murray S. Kucherawy : >=20 > =EF=BB=BF > I suggest draft-ietf-jsonpath-base-00. >=20 > -MSK >=20 >> On Wed, Dec 23, 2020 at 11:51 PM Tim Bray wrote: >> Hmm, draft-ietf-jsonpath-00 certainly wouldn't offend me, but on the othe= r hand there's a lot to be said for sticking to conventions. I'm imagining s= omeone writing a bot to plow through WG drafts and relying on the convention= . I've added Murray to the "To" line to see if he has an opinion. James? An= yone else? >>=20 >>> On Wed, Dec 23, 2020 at 11:27 PM Carsten Bormann wrote: >>> On 2020-12-24, at 08:14, Glyn Normington wrote: >>> >=20 >>> > Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- >>> > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be= >>> > good to know the rationale. >>>=20 >>> Internet-draft naming for WG documents is >>>=20 >>> draft-ietf-wgname-subject-subject-subject-nn >>>=20 >>> Now if there is only one draft in the WG, we might leave the subject off= entirely. >>> I actually find a few cases where this has been done: >>>=20 >>> draft-ietf-cnrp-12.txt >>> draft-ietf-geojson-04.txt >>> draft-ietf-gsmp-11.txt >>> draft-ietf-itrace-04.txt >>> draft-ietf-lisp-24.txt >>> draft-ietf-otp-01.txt >>> draft-ietf-sming-02.txt >>> draft-ietf-upsmib-05.txt >>>=20 >>> Most of these are older cases (1994 to 2006, with geojson at 2016 being t= he newest), but it sure could be done again. >>>=20 >>> (Some of the WGs then did develop further drafts with non-empty subject p= arts, e.g., lisp.) >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 I second draft-ietf-jsonpath-base-00 Gr=C3=BC=C3=9Fe, Stefan > --=20 > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath --Apple-Mail-DBF005C6-890A-41A7-BE22-E4762DDCAFB5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Am 24.12.2020 um 17:35 schrieb Murray S. Kucherawy <superuser@gmai= l.com>:

=EF=BB=BF
I suggest draft-ietf-jsonpath-base-00.

-MSK

On Wed, Dec 23, 2020 at 11:51 PM Tim Bra= y <tbray@textuality.com> w= rote:
Hmm, draft-ietf-= jsonpath-00 certainly wouldn't offend me, but on the other hand th= ere's a lot to be said for sticking to conventions.  I'm imagining some= one writing a bot to plow through WG drafts and relying on the convention. I= 've added Murray to the "To" line to see if he has an opinion.  James? A= nyone else?

On Wed, Dec 23, 2020 at 11:27 PM Carsten Bormann <cabo@tzi.org> wrote:
On 2020-12-24, at 08:14= , Glyn Normington <glyn.normington.work@gmail.com> wrote:
>
> Out of interest, why the "stutter" in the name? Wouldn't draft-ietf- > jsonpath-00 be less cumbersome? I don't feel strongly, but it would be<= br> > good to know the rationale.

Internet-draft naming for WG documents is

draft-ietf-wgname-subject-subject-subject-nn

Now if there is only one draft in the WG, we might leave the subject off ent= irely.
I actually find a few cases where this has been done:

draft-ietf-cnrp-12.txt
draft-ietf-geojson-04.txt
draft-ietf-gsmp-11.txt
draft-ietf-itrace-04.txt
draft-ietf-lisp-24.txt
draft-ietf-otp-01.txt
draft-ietf-sming-02.txt
draft-ietf-upsmib-05.txt

Most of these are older cases (1994 to 2006, with geojson at 2016 being the n= ewest), but it sure could be done again.

(Some of the WGs then did develop further drafts with non-empty subject part= s, e.g., lisp.)

Gr=C3=BC=C3=9Fe, Carsten

I second draft-ietf-jsonpat= h-base-00

Gr=C3=BC=C3=9Fe, Stefan

--
Jsonpath mailing list
Jsonpath@iet= f.org
https://www.ietf.org/mailman/listinfo/jsonpath<= br>
= --Apple-Mail-DBF005C6-890A-41A7-BE22-E4762DDCAFB5--