From nobody Thu Feb 11 10:37:45 2021 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 998223A183E for ; Thu, 11 Feb 2021 10:37:43 -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 wfxWTKFnO6gv for ; Thu, 11 Feb 2021 10:37:42 -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 675A63A1841 for ; Thu, 11 Feb 2021 10:37:42 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id sa23so11633995ejb.0 for ; Thu, 11 Feb 2021 10:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mime-version :content-disposition; bh=0B6cqr+czOH965q0kZCX7dY+9RUAKEXU8rCT7evzuv8=; b=I1x6UCgyL87jByjJXFt2pepdqmmoaloNKdf6R716u2VDB4xTgkUkRa+/GeewHGA2vZ z38e0dHP0eh4+goiZjghi3CDb6Ex7SDlMmBAz2actg2KvMssxe9aDpV1+31rlzdU6aPB w8VpKG/XoUScTChAx3NGkxXOn3SW9MmC6O+gAX0YbYm2ZF1/RUWk0qy4Fss3u0M7Dd6X /bCBy/Vp5KvN2nz28QVXgh0tEn1yCgtq7SFFz2WSEY7Iy7udk+9X3y9vQyDQslKukmwu yoBB0sjWDOvsSW0VQ1KF69wL06u24TB3St6U1l9y475A24XlsOqZV0hnkR4URE8mtZan OWHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-disposition; bh=0B6cqr+czOH965q0kZCX7dY+9RUAKEXU8rCT7evzuv8=; b=EauQCQiwKG2dReU38VBGVN9ffeQHP+qwfp5KR7RG3p4s6Kkq2gdoe02I6psK0DGFNT sDC0NKdS8O4Hl8KMO0ctYt9bsCjeVto/98XMksFPbu1giMedh0lzSdiDGRGyzci6fNjE iT/3tWU/rQxlksF8zu2CLNb2wcC6uEyEyuRNKhXNighWcl7Tsli0llET57h4/SyuC+FE vfDVmqhvdXsLVNKwK6TjkEZKkk2IP4Cym4otXhB50AG22B6rTSkSRmGEr1oejT//Wq7M UVi+WCKBaP7i6Dlk9VS894qR9D6ySFj91vRDOjOixu3UlNCH9w8vHNDyuQvloVYb0lU/ t+MQ== X-Gm-Message-State: AOAM5300jc3ojd6C7ysbSQzPxh1TXSjWDzV2qPJM1oRKTZ3XkCggzfjx EKwPEOb4GmMsleslJdVgZJ8CWF5y6gg= X-Google-Smtp-Source: ABdhPJwuzk8A5M9XZ8eKt8nRZHhPTM05XaO2gxbgQ5fYZJsfUfuuySFYF8kH6DNGRGHMONJI60l5+Q== X-Received: by 2002:a17:906:d8ae:: with SMTP id qc14mr9887872ejb.129.1613068659845; Thu, 11 Feb 2021 10:37:39 -0800 (PST) Received: from localhost (80-100-157-193.ip.xs4all.nl. [80.100.157.193]) by smtp.gmail.com with ESMTPSA id q9sm5127651ejd.113.2021.02.11.10.37.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Feb 2021 10:37:39 -0800 (PST) Date: Thu, 11 Feb 2021 18:37:38 +0000 From: James To: jsonpath@ietf.org Message-ID: <20210211183738.zwyoiz6vmd35calw@d8c0c25eea0a> Reply-To: jsonpath-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Jsonpath] IETF 110 - Call for Agenda Items 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, 11 Feb 2021 18:37:44 -0000 If anyone has an agenda item they would like to bring forward to the working group for our meeting at IETF 110 tentatively on Wednesday March 10th at 12:00pm UTC, please email myself and Tim before February 23rd and we'll include it. Thanks - J From nobody Fri Feb 12 16:37:39 2021 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 A78DF3A11B9; Fri, 12 Feb 2021 16:33:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jsonpath@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641166.31337.12283395832931210154@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:31 -0800 Archived-At: Subject: [Jsonpath] jsonpath - Requested session has been scheduled 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: Sat, 13 Feb 2021 00:33:40 -0000 Dear James Gruessing, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jsonpath Session 1 (2:00 requested) Wednesday, 10 March 2021, Session I 1300-1500 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/jsonpath.ics Request Information: --------------------------------------------------------- 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: James Gruessing Murray Kucherawy Tim Bray Resources Requested: Special Requests: --------------------------------------------------------- From gregsdennis@yahoo.com Sun Feb 14 03:34:39 2021 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 679943A0C74 for ; Sun, 14 Feb 2021 03:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_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 (2048-bit key) header.d=yahoo.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 Il3z5tzerN96 for ; Sun, 14 Feb 2021 03:34:38 -0800 (PST) Received: from sonic305-1.consmr.mail.bf2.yahoo.com (sonic305-1.consmr.mail.bf2.yahoo.com [74.6.133.40]) (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 55F633A0C70 for ; Sun, 14 Feb 2021 03:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1613302476; bh=DCVDDLXRjBHggOmGRCJ/cR8KW2Iu/78hC4pxe47cR50=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=UX3NSQmZ685IBJiOYzdKflOChYTe4soR9zLSC18UUGg3AyGEuS6Hcy3IzCLuyGk0hAz89ZJHOSdFMEe9YCJaMctYJcuXE07hBS4xvLStImrTmjLTcHtwQFo5vgUs78WXtMrRV/EW2646tTIvTIyWDZ4OCn05UkjPZNeEhMxTpTLk3EIVCGxCf6WmpxItIZVDyBPfR3Z/hprf27F8S3IQJV+CIw3IC2FuDRWYUgKFu2iyvBZtcXFICKOgTy1EL6cDpDDbZhBIqGagLAOovCujvxU0tYIDqlqclSCePt1oODutWq/UeExdv1hkYie3IzjBi+5fq36jbf+z+XWZgNa1vw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1613302476; bh=9PqOdHDY1g67l0Q0Lkb4d7pPRMN46Ru/KIRBzzK7Kq7=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=jwSKUCvj7Yb3njnOU90zSJbpahVilQlN1SmkhJZoptTBugxfHNl8fS2wBc7Dy0F/Z354Mu3y5c5QLbicy10tb1CqR7shjPIrIRCmglm7h9zVJJ/w/58ByrsZntjvujmGl6UnnyI+xUSZBno4wNreSUBk5gicVKlYLutTDvQZbdMCNbm6VoUFlzisc0IGV11QdQvTdI4+yvYlpUlzk0oTL0/iUjUOei0XhyMgPL0z0jmyGp8YuCoIN8dtO1ptjvPWzSfsXv/NLKqscHO2ftoLcbFJvNbnrL1a7njXsPXLP0KjSfZCbWMNRa1DZtiRhI+fci9TSwp2vuIiMCLloJFisA== X-YMail-OSG: JX.UubcVM1nf0NqrxqfRUmV2IQFUt3Od5sys2TU.BAO0YTaxo34htMTnSa.0u4n fHzIZlabM55sUyzZSPehYGPJW7LFI1G97hhFLDB1vW77n2xVPEW1qI0P83ugh2mo0X8MWdCIB93u 5W80P5qD3hIAU4JPrtCrtZ6D3yMHqCvbRTteB5WbZisezT.UuWU9zPsc.zZILSHexWPI5CIV4tP4 afREtiU4Dkou9OhDzPEpxVHSfWDGZfFHSb8nszUVVR3u47yl3wUTdNk2T8mxXn1O1mz3swSoKa8_ XWVVfLz4LWMswKRhuK8Iq4En9uB1iquBunEp.6RNGpXVhAatNHFGkkR3S1h739ghpgdRWjkw8fBT 6shYoMzVdlCqjM2NcwDWjpbxO7622Hs2OZTblBglu3BRpLWGia6dwyzbUopR3g9429q_kQw7exUf yODw_b8k1oes1JXQftnN4PiT5uo40foSPEsfY28Vfj9EWL_hPuYgfIZqishLvRH3YS2TGHst3Omd ECcZYtiFSFD1bqj8sA5cPLOSwCO264IIFl.zjIlCRN5X90zIHS5ayerJyp1YXIXQkqQPMxLq5dDp 0.hLkZeBDsXK9oS3_LKNlycz7SEto9iRdiv2EWXFLYVUXTHcOWKAd6MCjmbxxczF.xa2BS09An3J Wk4myGeshr5jBFhd3upJ9FXnPCTeU2GXuP4FYbOKvqt4owmY24oFd0vEbd_JpZaicciKA1FOhLNr EPcck1fdONFbvlkjGaPJ0OEZG7J5Ox_fr9wOYoVaFHqN9y1bLnFwKoQDVS_6IWbC47p5kGoqMrCa l5CdCUlIe3Y6GvTspOzGDG6kTMWpEhVlj6US17SAAfai9K6BeML9Wqtf6l5hFcPiVC0T36DCYaLW PkZOhiuZcghxDtKpGSIWcxYHQIyFb0mcpDm5v72O3p1LUG3dPYwun3baI3KgZuTzKOYzk9u8443i DxthzVyI.BU4d.Kr_Wh0anfjjszSTFJ8ADfdxkt28h7BG3lLgehF6pHSL2mESXPk7nbZoYw7T4k6 BzdmZlSHrdfUnPPTBoLpI6HQdFSnEkHiyZzNVYiW4GnBKjKvSe06uZGMXeJi5XJpywtuavOdDIM. o.zzhkHb6_iWi1GyuW0JcQXOdSXIbc0uvr7NhcHyA6VjkjpiRpBBCIK32bElPdt0hyE6jdcJTf8D uCVBO0FEaI70SUv6xqXdEtY2KcTUL2Op8UiieJmag9aOZvYLrz6i2yscHfPM2SyvgQSXc0WiyDxI kVu_U8OhMHlBAgD3PA4mXtF22OzRoG2VTMg5KT7zCuIF3kMcO2sbBf730U9ilHKeMBHXeLYhdhk_ skteM6l14DdCga0qwts5IYspr5Shv2uKRxqhnzWMeIQUtRDO8jVP9N98Uu5UROI6CB95GTmAWVX8 72StkaaYc8SDt1ox6BpSMS7PO_fKp7EjeMs68MjKvS1A.VaOVM7fSJDrTzw56JZjQYVz6XQoiDIj ebnyEqmU7R.r_Dz2YPmC6E4NOUckybbIKjU2HNK2hQWWK1uEgqlqqpX1uLgotxPN.EEkTNZHW1QJ PFNhu_e7xQrWosvEI.HZsO9L_7oRU6A9AFdblIrCb1mjmeKqJpJlqUm8xIp6egBmTBvXoeBv10T8 qx5iK3R3xAi9JbPaGyA9BtmmyT4r1otYzeyMPA_622neEasAoJr4E1UU_Q0ySBx.r4VDb_cun_b7 uSOWj4Q7JTMfdkycLKgQBOY_E6NvJ5pzObME8EN8qyjK9bU32OprRoYW91SnzuvpIt1cSLV4A_7f P9pBscGW_wEMj2yeaDOI7Ouh81eZYOxf0DmOIAc_XJVy_inqr_hZl0C31HOoLB4zr58Hz6Kw75MP KWUjMA1DP5ucw.LzAiWHawcKMTqFvCsK_ZZsgP6Ahy08vLNbv7zVx39b1LBu5QP7qhk4hbQFxw0T JjQH4azYuT0YfqcmuZ4CMqrSQ.43KtTp0PpP.ILAv21ZfnoGVWxiRP4sfzsoAMx5vT9olBEGXVDk 6IjUEUrqorJU5s6EX20pjGnqmyFAgUWPTMXkgvWk7xB5WrZu9PybkRSSHlVZUfEZ.I.9QbbKVbYr jqWi.5eWMgTmRJ5BkgZbEvM29Czx.Rcg_TfTDtcXlKqzRsAFc3UJHTvqN2PgTfVx.x5cYRN.kz1S KO.IQaPX45mioxq.EeRnilqYkIVtO.jl8yHI5haBwNg1e31XIMnLg.KvEtFk0sAA1nkbGI53yqbn VUk36EDo0j68SyipVWIEr.8vKF1ydNeBaCik_xgHK7sFwiazDQdMM7jZOTS9u0lLNbjpinXdAoY9 lbsNonNePd7sKehIkWh6zz57iaXnq4wQRV_xT3pOGgVgYTByl961NGzq_5a.kPjzlx5Nl7i8g82w tfrZjgJnV2NWOh.pVQQkko_K8J.2d68wjEBGF9xxqyzXiP4uaCriy_8Qlzn1h_FtUwqKACDNETh0 IVIFXEg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sun, 14 Feb 2021 11:34:36 +0000 Date: Sun, 14 Feb 2021 11:34:33 +0000 (UTC) From: Greg Dennis To: "jsonpath@ietf.org" Message-ID: <2066410765.1252324.1613302473152@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1252323_1134259161.1613302473150" References: <2066410765.1252324.1613302473152.ref@mail.yahoo.com> X-Mailer: WebService/1.1.17712 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Archived-At: Subject: [Jsonpath] Not getting mails after subscribing multiple times 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, 17 Feb 2021 04:08:19 -0000 ------=_Part_1252323_1134259161.1613302473150 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello.=C2=A0 I've been subscribing to this feed since late last year (at le= ast 4 times now), and I have yet to receive an email. It would be great if someone could check on this, please. Thank you.Greg Dennis ------=_Part_1252323_1134259161.1613302473150 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hello.  I've been subscribing to this feed since late last year (at least 4 times now), and I have yet to receive an email.

It would be great if someone could check on this, please.

Thank you.
Greg Dennis
------=_Part_1252323_1134259161.1613302473150-- From nobody Fri Feb 26 10:30:38 2021 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 BC4AD3A146F for ; Fri, 26 Feb 2021 10:30:36 -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_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 h6pZJ5Ob6-LU for ; Fri, 26 Feb 2021 10:30:33 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (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 369583A146B for ; Fri, 26 Feb 2021 10:30:32 -0800 (PST) Received: from [192.168.178.20] ([88.130.51.46]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MA7X0-1l5DEi25D0-00BbHm for ; Fri, 26 Feb 2021 19:30:30 +0100 To: jsonpath@ietf.org From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= Message-ID: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> Date: Fri, 26 Feb 2021 19:30:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:YQpAomK8k0LcGvRCSLR3obdI9ot/PY9TunUt2uVQkjC3mCTBm36 x7Oczd9tUgZZVxJl5F2YNtQEPURO9/Pkvi3ySZk6FYYWnMXCPXmlYvQxhbzRspJ2VopFlbr qbnuO1y4SOx8DmPpuwxwg6Tm2tuDB9OyNAR3LU7+hm9pm5Qh0Gn2voWh301lVoyhPsoDGsG 4KotxsIK7+3rSlukkebsw== X-UI-Out-Filterresults: notjunk:1;V03:K0:DJINDhNhw1s=:PvgV6EbVIvrp+o+mZwxlXe k9PCg9fQ3szlsC1gctdmpQwgtYd8yLzf20JvtmTGD4yhY9dllDDWSNcJriQcXXJXMAWp7Yo0F 7PynC5g7KfM185E36A2hjRda7TyopjTii5my06OPc+EMdNXZ7oSOSPLfoA0YbQCwxd4fkKg/a 5zexG0MaClJ5jugB29qQT2t6PCTm+nf0hUMBocxSc8TJAV6hoyFHQ3R/Nnh6yg5G+Kmfvr5Ss 9JjBtDrEVeNhcIYUsQaSR79hxsqZdGOla2VO4SorPKcVRz53h0ik+ETQ0WMVC4BrgtVn4giZv fhZQinu3TQCH6IbHeuEaO47lJR7ogBIaGBGN7Yq6d798obcTrh6z3SeLfp9xdKsEoGekmi0x6 MlMClpSOZI/wOLA2XV6n0NAcDqkSjC6jOvQjIfssqThPG8FDh00ERgL3bU1WTxLKgepNOWGos e8ymtSYhXg== Archived-At: Subject: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 18:30:37 -0000 Hello List, It has been important to go through this list threads carefully. In fact I should have done that at first. Now I can understand the current draft and appreciate the work already done much better. I collected some citations (important from my point of view) with comments already in Markdown. ## Title of the specification > JSONPath: A query language for JSON data. *(Carsten Bormann)* > I think I’d slightly prefer the term “syntax” to “language” because “query language” has a smell of various things that end with the letters “Q” and “L”.  But not passionate about that. *(Tim Bray)* > JSONPath: A query syntax for JSON. > Another wild-card idea: JSONPath: Query expressions for jSON *(Tim Bray)* > The beauty of this is that the plural form “query expressions” implies a set of expressions, so it implies “language”.  It’s indeed more than the grammar/syntax of those, so why not talk about the expressions as a whole.  This also makes it possible to just use “for JSON”, without going into detail what these query expressions operate on. *(Carsten Bormann)* There seems to be an agreement for "*JSONPath: Query expressions for JSON*". I like that also. ## Terminology > 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. *(Daniel P)* > 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). > > … oh, and I forgot the very useful "member". *(Tim Bray)* > … and “element” (the things in arrays). *(Carsten Bormann)* > 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 “the values inside that tree” is not going to be felt as equivalent to “the set of all subtrees of that tree, including the tree itself”.  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 “value”. *(Carsten Bormann)* > I think the key difficulty is whether each (key, value) pair in an object is "a thing" that can be identified and manipulated and potentially returned. (If we're talking analogies, then it's analogous to an attribute node in the XDM model). *(Michael Kay)* > ECMA-404 uses "name/value pair", which is what I understand the term "member" to mean (Douglas Crockford uses "member"). *(Daniel P)* > I think the term “union” is poor. If we think of it as concatenation of results, then the result is as expected. *(Glyn Normington)* I understand, that within RFC8259 we have JSON values of different types. They are structured somehow, which is not so much of interest here. But while querying that structure with JSONPath it is vitally important to identify that hierarchical structure as a tree. So in fact we build up a higher-level construct here. We also need to call "the things" in the tree somehow. I was able to identify * "node" or "item" of a tree * "member" of an object * "name/value" or "key/value" pair alias "member" * "element" of an array but could not see an agreement here. I agree to Glyn calling the term "union" poor (s. below). ## Differentiation from JSON Pointer (JSONPath draft charter) > I anticipate being asked "Why is JSON Pointer not sufficient?" Indeed its abstract says: > >   JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. > >... which sounds awfully similar.  If we could include a sentence about that, or a link to an answer, that might be helpful. *(Murray S. Kucherawy)* > No - it's not similar in concept, they're separate things. If you really wanted to mention JSON Pointer, you could say something like "Note that while JSON Pointer (RFC xxxx) is already standardised, it is designed to provide a reference to a single, specific part of a JSON document, whereas JSONPath provides the ability to query a document and potentially return multiple values." *(Mark Nottingham)* >The short answer is that JSON pointer is good if you already know the structure of the JSON data item you want to point into, and you want to point to exactly one position in there.  If you need to do something that is closer to a “search” (which might also result in multiple positions), JSONPath gives you more rope. *(Carsten Bormann)* +1 ## References to XPath > 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)* > 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. *(Glyn Normington)* > Someone on StackOverflow today asked a question about JSONPath; they called it (and tagged it) XPath, we really don't want that kind of confusion. > > In addition, the reference to the XPath specification in 6.2 is out of date, and the comparison with XPath in Table 2 is very approximate and the terminology inaccurate: for example there is a mention of "node sets", which exist in XPath 1.0 but not in XPath 2.0, yet the citation is to XPath 2.0. For someone who knows the semantics of XPath the comparison raises all sorts of questions about sorting of results into document order, elimination of duplicates etc, which are complications this spec can well do without. (Though some answers are needed, for example if ..store..price matches the same price in more than one way, do you get more than one result? And if not, what does "the same price" actually mean?) *(Michael Kay)* It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. ## Array Slice Operator > Thanks! The ABNF for an array slice in that reference > ``` > integer = [%x2D] (%x30 / (%x31-39 *%x30-39)) > > array-slice = [ integer ] ws %x3A ws [ integer ] >                     [ ws %x3A ws [ integer ] ] >                              ; start:end or start:end:step > ``` > is consistent with JMESPath, Python, and my understanding of ECMASCRIPT 4. > *(Daniel P)* > 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. *(Glyn Normington)* It's good having read this thread and thus understand the current draft much better. I like the decision to be consistent with Python and also getting an empty selection set with `step=0`. FYI: there is a recent proposal for adding slice notation syntax to JavaScript, currently at stage 1 of the TC39 process. https://github.com/tc39/proposal-slice-notation Interestingly it won't have a step argument ... https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-step-argument-like-python-does ... because of syntax collision with the new `this-binding` syntax proposal `::` https://github.com/tc39/proposal-bind-operator However, we should not let us influence by this. ## Unions > I don't think any implementation would remove duplicates from a path such as `"$.store.book"`. I believe this is only somewhat controversial in the context of unions [,]. The name "union" suggests that distinct values be returned, compare with SQL unions. But Stefan Goessner's implementation doesn't do that, it concatenates all results that meet each criteria. There are a few JSONPath implementations that produce real unions with no duplicates instead of concatenated results, but I don't think that's the consensus. *(Daniel P)* > I think the term “union” is poor. If we think of it as concatenation of results, then the result is as expected. *(Glyn Normington)* > I agree with that comment, but it's partly because I'm used to SQL UNION, which is different. I prefer the JMESPath term for an analogous construct, MultiSelect List, https://jmespath.org/specification.html#multiselect-list. *(Daniel P)* Introducing the union operator `[,]` simply was meant an analogon to XPath's operator `'|'`. I cannot tell, if it was a simple combination of node sets in Xpath 1.0 or a true union without duplicates. I obviously was not aware of that subtle (essential ?) union characteristic. So I fully agree to Glyn Normington's '... the term “union” is poor' statement. Are there some better alternative terms, perhaps 'multi-index operator', 'index list', 'subscript list', etc.? ## Duplicates and Ordering > It was my impression that we were talking about duplicated nodes not duplicated values: > > Given th array [10,20,30] > > $..[0,1,0] > > Would yield only two results [10, 20] > > (Not that I'm advocating for removing duplicates, personally I think we shouldn't) *(Marko Mikulicic)* > You’re framing this as “removing duplicates”. Another view is that [10, 20, 10] would be “adding duplicates” (copies of the same node). Related are ordering issues: > > `$..[1,0] ➔ [20, 10] Or [10, 20]` > > I would expect the spec will leaves implementations some leeway here, but that should be based on an examination of existing implementations. *(Carsten Bormann)* > The mental model that leads to omitting duplicate nodes in the output is "selection": if you take an input array and select nodes with index 0,1 or 0, you get only 2 results (since selecting an index twice has no effect). > >OTOH, if you opt for a "collect" model, whenever you encounter a node that matches that query you add it to the result stream, thus the same nodes can be present multiple times in the result. > >I have a slight preference for the "collect" model, because the general case in jsonpath is to collect things that appear at various points in the json tree. For example: > >`{"a": {"b": 1, "c": 2}, "d": 3},  $.a.b yields [1] and not {"a":{"b":1}}` > >(i.e. jsonpath is not a filter and view operation but a pick and gather operation) *(Marko Mikulicic)* > In implementations that support paths (the majority don't), the query function takes a parameter that indicates values or paths. In both cases the query returns a JSON array of JSON values, in the latter case, a JSON array of normalized paths. *(Daniel P)* I must confess to never having thought about duplicates, let alone wanting to eliminate them. So I do like Marko's comparison of 'selection-model' vs. 'collection-model' a lot. I would opt for the latter. In this sense the result of a 'JSONPath query expression' should be termed a 'collection'. Regarding ordering I see something like a 'natural ordering', according to which `$..[0,1] ➔ [10, 20]` `$..[1,0] ➔ [20, 10]` would result with the example above. I do understand the use cases for reordering, duplicates removal, filtering, etc.. But this can always be seen as a postprocessing step on the resulting collection by handing it over to accompanying tools (think of pipe operator). Of course this cannot work on the result collection of values alone (s. duplicate nodes vs. duplicate values above), it rather requires a collection of (normalized) pathes. In this sense, I like this view: > In my opinion the right balance between powerfulness and enabling simple implementations has been so far one of the key factors that made JSONPath popular over other alternatives, even if it lacks support for aggregation functions. *(Davide Bettio)* ## Filter Expressions > Related to that, it would be helpful to determine if JSONPath filters apply to both JSON objects and arrays, or only to JSON arrays. *(Daniel P)* > I would support restricting filters to arrays, if others agree. *(Glyn Normington)* I tend to let implementations and their "normative force of the factual" decide here or in doubt agree to Glyn's restriction to arrays. I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` addresses the array itself and implies that array has a `length` property. In filter expression examples `'@'` more consistently addresses the current array element. The invocation of 'the underlying scripting engine' wasn't meant a serious normative aspect, but rather a quick and dirty solution for JavaScript and PHP implementations at that time. ### Corner Case > Consider this perfectly legal JSON object > > ```{ "ab": 0,  "'a.b": 1,  "a-b": 2, "a": { "b": 3 } }``` > >So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd like to say `$.a-b` but lots of libraries will refuse it because `"a-b"` is not a legal JavaScript "name" construct, that's why you have to say `$['a-b']`. > > But suppose your library would accept `$.a-b`.  Then `$.a-b` and `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't. *(Tim Bray)* Hmm ... this seems to be a hint to better exclude `'-'` from dot-child-selector syntax. I think I have read more discussion about that, currently don't know where. ## Respect Implementations > As I mentioned in the session, I think there's a non-trivial amount of risk here that some implementations won't be willing or able to move away from their current behaviours, even if interoperability would improve if they did so. However, there are ways to mitigate that (e.g., a separate 'rfcxxxx compliant' mode). Even so, it will be important to get good participation from as many current implementers as possible. *(Mark Nottingham)* > The WG will develop a standards-track JSONPath specification that is technically sound and complete, based on the common semantics and other aspects of existing implementations.  Where there are differences, the working group will analyze those differences and make choices that rough consensus considers technically best, with an aim toward minimizing disruption among the different JSONPath implementations. *(Barry Leiba)* > I'm OK with this, but for context: I've been a pretty intense JSONPath user in recent years, and AFAIK the spec, and the implementations, are mostly OK, so the choice between "make JSONPath good" and "don't invalidate implementations" is unlikely to come up. If it did, my predisposition would be to err on the side of not breaking implementations, but I don't think that's inconsistent with Barry's text. *(Tim Bray)* +1 to all. ## Error Handling > My mental model at the moment is that a JSONPath expression can be valid or erroneous; application of a valid expression yields a result (which may be empty), but does not raise errors.  That may not be the right model for all applications. *(Carsten Bormann)* > The  general approach that I've seen several times (including my Elixir implementation) is that an error is raised when there is a syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises an error. Conversely a valid expression applied to a bogus input never raises an error (e.g. `$.foo.bar on "test" evals as []`). *(Davide Bettio)* > 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)* > 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. *(Carsten Bormann)* I like and totally agree with the *forgiving mental model*, so having  only syntax errors, which do not dependent on data. Thanks -- sg From nobody Fri Feb 26 11:12:24 2021 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 95B123A0AD7 for ; Fri, 26 Feb 2021 11:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 Bbq2JpPfKy7D for ; Fri, 26 Feb 2021 11:12:18 -0800 (PST) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 754653A1543 for ; Fri, 26 Feb 2021 11:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614366737; bh=oYDZcNe4I5HRqW/q0IyKHckVmKaWYGuSzcJPcRbbjeY=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Fjk/hpQ8qePANe3sA0EC4JSIO8BppgelXLpc5NjJ2vxhV1vqVSmJk0+PtD1TOblpqNK2VannEoSJh/iXNvaN42FdlT0hyXNfFDmdWfiNW9GAK7j/mL/R7aoCA048dxDGTiVWZVwSGvMFqQ/BQW8YImecQ5GcBo0inyF5sMcXFKXStTNakrSHhtJUZRFErfQDTmguh0WCSt7tQNd7a7bNgx+BTDc71vfz2jKh5qYqjTBm/mbr2m/nJ0FSAUPTX95wVCoP/M4k/G11zBn2mottOq7KgZVJOfFacjItSlOPCbQFAfaLExUJgeKYn6M9a7+QzHT/qwM/7cb/8zV+H9lwdQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614366737; bh=64W/2ccF6YZ63YQAyB3n2fAbcr5abdN8nv3+BRkxfqA=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=sU5WLDrkVDrKF2jwBALdmMPQAFm8/CxrqFq91oJA1KRMead0CPDA5ZnU04SG9UbSYhw7s3bqq7E7aR+3bBqoRZIgYIBkwlvItKhz/OciJgHsVF3s/iuK3J34mCUeVn2boe8slxbxZEEvADOP6BDUc39lcCWXBAzrdK4CWtbt3D5etUZntmAlxsCqDIBPypGNJSZBCpVCLEROG7sfPnly2auq6WsLoQM6ECueSaCWe5hdGl0ZLTe0wpHYFpQeVg7ZggMLdqmbdBhlb+M0yg53Snzm/ZSYKCTnJUOhGycZgpWjGpyVc7SZofDzqMWC3NC1XlJH4KnjCGJn4xhiyRI9sA== X-YMail-OSG: GMCnZ8MVM1m28iG9PnKvhdPKrSqO_mKaK4AxeJ9741pdbc_9zZ4PozlMdTvv1Yp hcenTFJIQs9C92wPrFxzpuGo2MxmrVOVuDZF4W1gct84lwlSiJb7jjgskete8nZEsPCObRo21TCf atZHaAe_k7O3wcFg8op2xGbQHthcfFM1NXQ6xhkV8lf88BtHeIPMOCtWnAGL9G0O2LayMp0nucjE F9u1dV1PLRKRbCY1iv14kwK9zUkEabKMYMg5pSskz4TGBFlZZPDZELbfbpowVVV5OkfhUqkkm1Hz 1cxqXR.YQJcQ25eIKYs7NO8P23MVD4yzRdOfgbyRg36XxUm057lj0QlnlypuYb9NG5vgFCZOgxGP CQCUrpXfXWYpcV8zCUygWbDGyp9g5LzgPyoZ5In5v7ihRPjX1bFyH0CHw7A8wMTUQDxlP4TJaiGB JpiqTIlrVlGGMBrSMZdlsfbxx1c.Pb_4aYb5jMn0Pk704L.TsaxccE4IJQiELKG.3P1kbAGQnuH9 oklMnfMmL00WSkgr8M_6_ceZsddjZ3cWLmSHU.TEu9QevUj76TAhFA_SXGy3yJLHDGesalnTFW3n hm.IMAJX99kC6ZObUi8j77KLvzvlHNHCdLTzJ4K0uuYhadoLcsrZ1VZMszpskzE2rJ3RkdUPP4Xp uaPCr0TYOQIb0ejakZNYNgZJOMeGrfOPBRWOmqi4S03qY7iko0dVuxjyC4JKnpVV4JKN9T9nlTII NF7VMqc6xLzVCg5UbEc0VPCsUuWse28ezMeg7sWW1nL.M_VbrDlPA1IPJi5BGy3QwbLZe4cwmgXA gMT80BXaol.swI_yKT0bxBnR3IMtBPbeesdr6v0D72hKO_PrSMBtz5AvXTSzQkRkluYM2Mpjvjjr 0BhsOobTkRKxyLOB_EJTRyV7MN4CNhaqiV3lDRTVyJ9_hqtcr.HPh0vJUVeE_j2cIjID_l3G4m2C uVy1p46WjPBvxVmhSgVGvwb0XIN7dgXog3DbHLixPm_PhqtH.c6tQckafqz5toF5KnmXBwDjI2ay O4ebihr1Eho4JValJn7fGwP5eH7x1ezXfOIxdVuiJqHF30umuO8kVU6ZURD_c2fUC5QzNXEy1qyV PpXuQNYt6rJLFnnZqIUi8p5blyzSn6TcIPwitWqd0AIcGGg9gslyZQlsNPYzfalH_NGhDriv0rB5 dIAeaciokh8uOhwUXAuQCJMOaEJ6jQ5IYQsfvCRzjWGPmyoNPBq3EoswslKhewJNssrmBR_mbkpz 7XHU2XemAuhJ0VnA.hndQRZNYmR9AeiIhRhMXMvg1gqrLI1fziFKXPp.j8TVsM03G7NxHHZ2L1y4 zAKXNJqnwW4cwVhkVrw7xstRPhJFK789s9fKnrQQ_efyrLWusu6044HLN4Y6zGUkkE2USW9ZgAMG w2pFDsWNhZi5VFaxY3dO8EuLROm2tOHd15Cn.tP29uIultEDy7gRbiYw1dom_JYqRyL8Zyi22Voe MSpA8fmMOiHVIPbyxZLn_9MckrH7hjHPBIH_am6IDo4O7BIw_8oWE9pYvJTcWmuEwcAe5rji.ku3 52c_4pMYJIURJ15RC348bJSGsBzcOUC5ZSt_KC2ixYWkP1mc4BseScLVCJGuyE1wUqQgraGonBYZ .Fla6iLE_J7j3oEBJ27pyYVspNNWv7NZ3KuXmmB37hLJfmkz.x9CWyM2ULXTOx_NT832KpZKvPJh pn.EwTbnN8jBwJPyyOdePB7ecKTCwFcQAb5kxQC_b75tGlHFDxZgSNg9lBf_FuPm29tGPHsw5pjf mXMDs0J4mEvkV8_1c5MZZXDwuMjstw7Tnsa4XVsPZQjiiHhMSEYZgkIKiK2dr.h42NC6in28BZ01 WcD8fyQDf0qBUp0T_F5hofjQPs9t1mVHm7yUC7DiesADukb4UJ9ItcXxGaYTwMrVHsLbjuXT6MQt kC1hsg6hX76jNAbPTHK8FjrWrxvAEz4buMMdElnglyJG5OnbmYhl1gNYYWe5dRN9IndXumcXY0Hd H.2U.UKl.LYFA5_kmjvLAqoSPVO5VgnIf6XD40pyO5FnJNsigk7WOq118yK24diCbtbyyaTb9oGC 9Tk7KpORpdQt6DYipDtFoD6LNhlO8BK53qsPd5LM7UNpr4MY.8ywxi.X92qJbLEE4r5G0fIrkvua 7.hRHfPTqZzx.Ak.ozN5oaLbDYHCYIhR7TySrPnFQKRM2p_jJ9VfyWsTLqyxvY8uyMOgzKHq1ZpG tkb71audm55fZQnJY49sjI7qcQRTZvpkeDojhZQjqa3OinYrm3hQek57BIrHAAJNh7HuAMOCkTH7 qaftQMRw1SCBedJoG3izQcxcIepvdTsWRA3CQqN32jmsPRV_V7FiupsPa65A07kLDd0IDC09RRkt uExo_Zlum4evadSabMowZsn61pyGZ9ofl4nBThnZC9XnYnxv306FmrCbUSITFhzRCUTWrtH4CUb_ P6wYOe6mzRtegGnmVvbm7RbDsHLJyUMk6B93QMi_MbLV3cwkDRXC.aw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 19:12:17 +0000 Date: Fri, 26 Feb 2021 19:12:12 +0000 (UTC) From: Greg Dennis To: "jsonpath@ietf.org" , =?UTF-8?Q?Stefan_G=C3=B6ssner?= Message-ID: <502566941.150044.1614366732927@mail.yahoo.com> In-Reply-To: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_150043_821565506.1614366732920" X-Mailer: WebService/1.1.17828 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 19:12:23 -0000 ------=_Part_150043_821565506.1614366732920 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello List!=C2=A0 I appears I'm finally getting these! Woohoo! Stefan, thank you for your input.=C2=A0 However it seems that the MD format= ting (as much as I appreciate the effort) has been lost and I'm having a ha= rd time parsing quoted text vs your responses in the text as it appears the= email server completely removed any formatting and then further reformatte= d=C2=A0the raw text to ensure that it is compatible with email clients from= 25 years ago. I feel that email is probably the least ideal format for conversations like= this.=C2=A0 The thing is, we have a wonderful GitHub repository (https://g= ithub.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath) complete with issu= es and PRs, mechanisms that are specifically DESIGNED for this sort of disc= ourse. We also have a Slack workspace (https://join.slack.com/t/jsonpath-standard/= shared_invite/zt-mxse9mgl-DK~35JawDjcsFUY9PVO5~Q) which is great for small = side conversations and general questions from the public.=C2=A0 (Though it = appears that the workspace has been removed from the README.)=C2=A0 The nic= e thing about Slack is the integrations.=C2=A0 It's currrently set up to mo= nitor the GitHub repo for new issues and PRs and StackOverflow for new "jso= n-path"-labeled questions. Both of these support formatting (with their own flavors of Markdown). I'm not saying that we should abandon the emails list.=C2=A0 But it's not g= reat for this kind of discussion. It's also worth saying that I've been part of the JSON Schema specification= development for over five years, and using both GitHub and Slack has been = invaluable. Thanks for the effort put into this so far by everyone. Greg On Saturday, February 27, 2021, 07:30:41 AM GMT+13, Stefan G=C3=B6ssner= wrote: =20 =20 Hello List, It has been important to go through this list threads carefully. In fact=20 I should have done that at first. Now I can understand the current draft=20 and appreciate the work already done much better. I collected some citations (important from my point of view) with=20 comments already in Markdown. ## Title of the specification > JSONPath: A query language for JSON data. *(Carsten Bormann)* > I think I=E2=80=99d slightly prefer the term =E2=80=9Csyntax=E2=80=9D to= =E2=80=9Clanguage=E2=80=9D because=20 =E2=80=9Cquery language=E2=80=9D has a smell of various things that end wit= h the letters=20 =E2=80=9CQ=E2=80=9D and =E2=80=9CL=E2=80=9D.=C2=A0 But not passionate about= that. *(Tim Bray)* > JSONPath: A query syntax for JSON. > Another wild-card idea: JSONPath: Query expressions for jSON *(Tim Bray)* > The beauty of this is that the plural form =E2=80=9Cquery expressions=E2= =80=9D=20 implies a set of expressions, so it implies =E2=80=9Clanguage=E2=80=9D.=C2= =A0 It=E2=80=99s indeed=20 more than the grammar/syntax of those, so why not talk about the=20 expressions as a whole.=C2=A0 This also makes it possible to just use =E2= =80=9Cfor=20 JSON=E2=80=9D, without going into detail what these query expressions opera= te on. *(Carsten Bormann)* There seems to be an agreement for "*JSONPath: Query expressions for=20 JSON*". I like that also. ## Terminology > 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. *(Daniel P)* > To Carsten's point about what we call things, the number of distinguishe= d terms per RFC8259 is pretty small: JSON text, value, object, array, 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 (and build up to higher-level constructs as required for JSONPath). > > =E2=80=A6 oh, and I forgot the very useful "member". *(Tim Bray)* > =E2=80=A6 and =E2=80=9Celement=E2=80=9D (the things in arrays). *(Carste= n Bormann)* > The problem with JSON value is that it also can be quite confusing=20 due to the usual use of that term.=C2=A0 Pointing to a tree and saying =E2= =80=9Cthe=20 values inside that tree=E2=80=9D is not going to be felt as equivalent to = =E2=80=9Cthe=20 set of all subtrees of that tree, including the tree itself=E2=80=9D.=C2=A0= But if=20 JSON value is the only term we have, it has to be.=C2=A0 Hence my preferenc= e=20 to talk about data items when I mean the items themselves and not their=20 =E2=80=9Cvalue=E2=80=9D. *(Carsten Bormann)* > I think the key difficulty is whether each (key, value) pair in an=20 object is "a thing" that can be identified and manipulated and=20 potentially returned. (If we're talking analogies, then it's analogous=20 to an attribute node in the XDM model). *(Michael Kay)* > ECMA-404 uses "name/value pair", which is what I understand the term "member" to mean (Douglas Crockford uses "member"). *(Daniel P)* > I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of it as c= oncatenation=20 of results, then the result is as expected. *(Glyn Normington)* I understand, that within RFC8259 we have JSON values of different=20 types. They are structured somehow, which is not so much of interest here. But while querying that structure with JSONPath it is vitally important=20 to identify that hierarchical structure as a tree. So in fact we build=20 up a higher-level construct here. We also need to call "the things" in=20 the tree somehow. I was able to identify * "node" or "item" of a tree * "member" of an object * "name/value" or "key/value" pair alias "member" * "element" of an array but could not see an agreement here. I agree to Glyn calling the term "union" poor (s. below). ## Differentiation from JSON Pointer (JSONPath draft charter) > I anticipate being asked "Why is JSON Pointer not sufficient?" Indeed=20 its abstract says: > >=C2=A0=C2=A0 JSON Pointer defines a string syntax for identifying a speci= fic=20 value within a JavaScript Object Notation (JSON) document. > >... which sounds awfully similar.=C2=A0 If we could include a sentence ab= out that, or a link to an answer, that might be helpful. *(Murray S. Kucherawy)* > No - it's not similar in concept, they're separate things. If you=20 really wanted to mention JSON Pointer, you could say something like=20 "Note that while JSON Pointer (RFC xxxx) is already standardised, it is=20 designed to provide a reference to a single, specific part of a JSON=20 document, whereas JSONPath provides the ability to query a document and=20 potentially return multiple values." *(Mark Nottingham)* >The short answer is that JSON pointer is good if you already know the=20 structure of the JSON data item you want to point into, and you want to=20 point to exactly one position in there.=C2=A0 If you need to do something= =20 that is closer to a =E2=80=9Csearch=E2=80=9D (which might also result in mu= ltiple=20 positions), JSONPath gives you more rope. *(Carsten Bormann)* +1 ## References to XPath > I wonder if the analogies between XPath and JSONPath are going to be=20 helpful, or whether they're actually dangerous by implying equivalences=20 between constructs that are in fact somewhat different? *(Michael Kay)* > 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. *(Glyn Normington)* > Someone on StackOverflow today asked a question about JSONPath; they=20 called it (and tagged it) XPath, we really don't want that kind of=20 confusion. > > In addition, the reference to the XPath specification in 6.2 is out=20 of date, and the comparison with XPath in Table 2 is very approximate=20 and the terminology inaccurate: for example there is a mention of "node=20 sets", which exist in XPath 1.0 but not in XPath 2.0, yet the citation=20 is to XPath 2.0. For someone who knows the semantics of XPath the=20 comparison raises all sorts of questions about sorting of results into=20 document order, elimination of duplicates etc, which are complications=20 this spec can well do without. (Though some answers are needed, for=20 example if ..store..price matches the same price in more than one way,=20 do you get more than one result? And if not, what does "the same price"=20 actually mean?) *(Michael Kay)* It seemed to be important in 2007, while argumenting to have something=20 like XPath for JSON. If nowadays the terminology used has changed=20 significantly with XPath 2.0 and 3.0, we better leave that comparison=20 table 2 out. I am quite passionless here. ## Array Slice Operator > Thanks! The ABNF for an array slice in that reference > ``` > integer =3D [%x2D] (%x30 / (%x31-39 *%x30-39)) > > array-slice =3D [ integer ] ws %x3A ws [ integer ] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ ws %x3A ws [ integer ] ] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ; start:end or start:end:step > ``` > is consistent with JMESPath, Python, and my understanding of ECMASCRIPT 4. > *(Daniel P)* > 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. *(Glyn Normington)* It's good having read this thread and thus understand the current draft=20 much better. I like the decision to be consistent with Python and also=20 getting an empty selection set with `step=3D0`. FYI: there is a recent proposal for adding slice notation syntax to=20 JavaScript, currently at stage 1 of the TC39 process. https://github.com/tc39/proposal-slice-notation Interestingly it won't have a step argument ... https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-s= tep-argument-like-python-does ... because of syntax collision with the new `this-binding` syntax=20 proposal `::` https://github.com/tc39/proposal-bind-operator However, we should not let us influence by this. ## Unions > I don't think any implementation would remove duplicates from a path such as `"$.store.book"`. I believe this is only somewhat controversial in the context of unions [,]. The name "union" suggests that distinct values be returned, compare with SQL unions. But Stefan Goessner's implementation doesn't do that, it concatenates all results that meet each criteria. There are a few JSONPath implementations that produce real unions with no duplicates instead of concatenated results, but I don't think that's the consensus. *(Daniel P)* > I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of it as c= oncatenation=20 of results, then the result is as expected. *(Glyn Normington)* > I agree with that comment, but it's partly because I'm used to SQL UNION= , which is different. I prefer the JMESPath term for an analogous construct, MultiSelect List, https://jmespath.org/specification.html#multiselect-list. *(Daniel P)* Introducing the union operator `[,]` simply was meant an analogon to=20 XPath's operator `'|'`. I cannot tell, if it was a simple combination of=20 node sets in Xpath 1.0 or a true union without duplicates. I obviously=20 was not aware of that subtle (essential ?) union characteristic. So I fully agree to Glyn Normington's '... the term =E2=80=9Cunion=E2=80=9D= is poor'=20 statement. Are there some better alternative terms, perhaps 'multi-index=20 operator', 'index list', 'subscript list', etc.? ## Duplicates and Ordering > It was my impression that we were talking about duplicated nodes not duplicated values: > > Given th array [10,20,30] > > $..[0,1,0] > > Would yield only two results [10, 20] > > (Not that I'm advocating for removing duplicates, personally I think we shouldn't) *(Marko Mikulicic)* > You=E2=80=99re framing this as =E2=80=9Cremoving duplicates=E2=80=9D. Another view is that [10, 20, 10] would be =E2=80=9Cadding duplicates=E2=80= =9D (copies=20 of the same node). Related are ordering issues: > > `$..[1,0] =E2=9E=94 [20, 10] Or [10, 20]` > > I would expect the spec will leaves implementations some leeway here,=20 but that should be based on an examination of existing implementations. *(Carsten Bormann)* > The mental model that leads to omitting duplicate nodes in the output is "selection": if you take an input array and select nodes with index 0,1 or 0, you get only 2 results (since selecting an index twice has no effect). > >OTOH, if you opt for a "collect" model, whenever you encounter a node tha= t matches that query you add it to the result stream, thus the same nodes can be present multiple times in the result. > >I have a slight preference for the "collect" model, because the general case in jsonpath is to collect things that appear at various points in the json tree. For example: > >`{"a": {"b": 1, "c": 2}, "d": 3},=C2=A0 $.a.b yields [1] and not=20 {"a":{"b":1}}` > >(i.e. jsonpath is not a filter and view operation but a pick and gather operation) *(Marko Mikulicic)* > In implementations that support paths (the majority don't), the query function takes a parameter that indicates values or paths. In both cases the query returns a JSON array of JSON values, in the latter case, a JSON array of normalized paths. *(Daniel P)* I must confess to never having thought about duplicates, let alone=20 wanting to eliminate them. So I do like Marko's comparison of=20 'selection-model' vs. 'collection-model' a lot. I would opt for the=20 latter. In this sense the result of a 'JSONPath query expression' should=20 be termed a 'collection'. Regarding ordering I see something like a 'natural ordering', according=20 to which `$..[0,1] =E2=9E=94 [10, 20]` `$..[1,0] =E2=9E=94 [20, 10]` would result with the example above. I do understand the use cases for reordering, duplicates removal,=20 filtering, etc.. But this can always be seen as a postprocessing step on=20 the resulting collection by handing it over to accompanying tools (think=20 of pipe operator). Of course this cannot work on the result collection of values alone (s.=20 duplicate nodes vs. duplicate values above), it rather requires a=20 collection of (normalized) pathes. In this sense, I like this view: > In my opinion the right balance between powerfulness and enabling simple implementations has been so far one of the key factors that made JSONPath popular over other alternatives, even if it lacks support for aggregation functions. *(Davide Bettio)* ## Filter Expressions > Related to that, it would be helpful to determine if JSONPath filters apply to both JSON objects and arrays, or only to JSON arrays. *(Daniel P)* > I would support restricting filters to arrays, if others agree. *(Glyn Normington)* I tend to let implementations and their "normative force of the factual"=20 decide here or in doubt agree to Glyn's restriction to arrays. I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'`=20 addresses the array itself and implies that array has a `length`=20 property. In filter expression examples `'@'` more consistently=20 addresses the current array element. The invocation of 'the underlying scripting engine' wasn't meant a=20 serious normative aspect, but rather a quick and dirty solution for=20 JavaScript and PHP implementations at that time. ### Corner Case > Consider this perfectly legal JSON object > > ```{ "ab": 0,=C2=A0 "'a.b": 1,=C2=A0 "a-b": 2, "a": { "b": 3 } }``` > >So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd=20 like to say `$.a-b` but lots of libraries will refuse it because `"a-b"`=20 is not a legal JavaScript "name" construct, that's why you have to say=20 `$['a-b']`. > > But suppose your library would accept `$.a-b`.=C2=A0 Then `$.a-b` and=20 `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't. *(Tim Bray)* Hmm ... this seems to be a hint to better exclude `'-'` from=20 dot-child-selector syntax. I think I have read more discussion about=20 that, currently don't know where. ## Respect Implementations > As I mentioned in the session, I think there's a non-trivial amount=20 of risk here that some implementations won't be willing or able to move=20 away from their current behaviours, even if interoperability would=20 improve if they did so. However, there are ways to mitigate that (e.g.,=20 a separate 'rfcxxxx compliant' mode). Even so, it will be important to=20 get good participation from as many current implementers as possible. *(Mark Nottingham)* > The WG will develop a standards-track JSONPath specification that is technically sound and complete, based on the common semantics and other aspects of existing implementations.=C2=A0 Where there are differences, the working group will analyze those differences and make choices that rough consensus considers technically best, with an aim toward minimizing disruption among the different JSONPath implementations. *(Barry Leiba)* > I'm OK with this, but for context: I've been a pretty intense=20 JSONPath user in recent years, and AFAIK the spec, and the implementations, are mostly OK, so the choice between "make JSONPath good" and "don't invalidate implementations" is unlikely to come up. If it did, my predisposition would be to err on the side of not breaking implementations, but I don't think that's inconsistent with Barry's text. *(Tim Bray)* +1 to all. ## Error Handling > My mental model at the moment is that a JSONPath expression can be=20 valid or erroneous; application of a valid expression yields a result=20 (which may be empty), but does not raise errors.=C2=A0 That may not be the= =20 right model for all applications. *(Carsten Bormann)* > The=C2=A0 general approach that I've seen several times (including my Elixir implementation) is that an error is raised when there is a syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises an error. Conversely a valid expression applied to a bogus input never raises an error (e.g. `$.foo.bar on "test" evals as []`). *(Davide Bettio)* > On the whole I think JSONPath is designed to be "forgiving", i.e.=20 such things aren't errors, e.g. I think I read in the spec that=20 filtering a non-array isn't an error, it's some kind of no-op. That=20 approach isn't always best for everyone, but it's important to be=20 consistent. *(Michael Kay)* > I would expect one component of this policy to be: > > Whether a JSONPath query is valid or not does not depend on the=20 arguments it is applied to. > > I.e., you can look at the query and find out independently, without=20 knowing any data, whether it is valid or not. *(Carsten Bormann)* I like and totally agree with the *forgiving mental model*, so having=C2=A0= =20 only syntax errors, which do not dependent on data. Thanks -- sg --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_150043_821565506.1614366732920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello List!  I appears = I'm finally getting these! Woohoo!

Stefan, thank you for = your input.  However it seems that the MD formatting (as much as I app= reciate the effort) has been lost and I'm having a hard time parsing quoted= text vs your responses in the text as it appears the email server complete= ly removed any formatting and then further reformatted the raw text to ensure that it is compatible w= ith email clients from 25 years ago.

I feel= that email is probably the least ideal format for conversations like this.=   The thing is, we have a wonderful GitHub repository (https://github.com/ietf-wg-jsonpath/draft-= ietf-jsonpath-jsonpath) complete with issues and PRs, mechanisms that a= re specifically DESIGNED for this sort of discourse.

We a= lso have a Slack workspace (https://join.slack.com/t/jsonpath-standard/shared_invite/z= t-mxse9mgl-DK~35JawDjcsFUY9PVO5~Q) which is great for small side conver= sations and general questions from the public.  (Though it appears tha= t the workspace has been removed from the README.)  The nice thing abo= ut Slack is the integrations.  It's currrently set up to monitor the G= itHub repo for new issues and PRs and StackOverflow for new "json-path"-lab= eled questions.

Both of these support formatting (with th= eir own flavors of Markdown).
<= br>
I'm not saying that we shou= ld abandon the emails list.  But it's not great for this kind of discu= ssion.

It's also worth saying that I've been part of the = JSON Schema specification development for over five years, and using both G= itHub and Slack has been invaluable.

Thanks for the effor= t put into this so far by everyone.

Greg

=20
=20
On Saturday, February 27, 2021, 07:30:41 AM GMT+13, Ste= fan G=C3=B6ssner <stefan@goessner.net> wrote:


Hello List,

It has been important to go through this list t= hreads carefully. In fact
I should have done tha= t at first. Now I can understand the current draft
and appreciate the work already done much better.

I collected some citations (important from m= y point of view) with
comments already in Markdo= wn.


## Title of the specification

=
> JSONPath: A query language for JSON data.
<= div dir=3D"ltr">*(Carsten Bormann)*

> I think I=E2=80=99d slightly prefer the term =E2=80=9Cs= yntax=E2=80=9D to =E2=80=9Clanguage=E2=80=9D because
=E2=80=9Cquery language=E2=80=9D has a smell of various things that en= d with the letters
=E2=80=9CQ=E2=80=9D and =E2= =80=9CL=E2=80=9D.  But not passionate about that.
*(Tim Bray)*

&g= t; JSONPath: A query syntax for JSON.
> Anoth= er wild-card idea: JSONPath: Query expressions for jSON
*(Tim Bray)*

= > The beauty of this is that the plural form =E2=80=9Cquery expressions= =E2=80=9D
implies a set of expressions, so it im= plies =E2=80=9Clanguage=E2=80=9D.  It=E2=80=99s indeed
more than the grammar/syntax of those, so why not talk about th= e
expressions as a whole.  This also makes = it possible to just use =E2=80=9Cfor
JSON=E2=80= =9D, without going into detail what these query expressions operate on.
=
*(Carsten Bormann)*

There seems to be an agreement for "*JSONPath: Query e= xpressions for
JSON*". I like that also.

## Terminology

> My own view is that the termin= ology should stay consistent with RFC
8259, and t= hat the word "object" should not be used for items that are
not JSON objects in the sense of RFC 8259.
*(Daniel P)*

>= ; To Carsten's point about what we call things, the number of distinguished=
terms per RFC8259 is pretty small: JSON text, va= lue, 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 p= roblems, so
I'd argue that we should stick to the= m (and build up to higher-level
constructs as req= uired for JSONPath).
>
> =E2=80=A6 oh, and I forgot the very useful "member".
*(Tim Bray)*

> =E2=80=A6 and =E2=80=9Celement=E2=80=9D (the things in arrays). = *(Carsten Bormann)*

&= gt; 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 th= at 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 n= ot their
=E2=80=9Cvalue=E2=80=9D.
*(Carsten Bormann)*

> I think the key difficulty is whether each (key, value) pai= r in an
object is "a thing" that can be identifi= ed and manipulated and
potentially returned. (If= we're talking analogies, then it's analogous
to= an attribute node in the XDM model).
*(Michael K= ay)*

> ECMA-404 us= es "name/value pair", which is what I understand the term
"member" to mean (Douglas Crockford uses "member").
*(Daniel P)*

> I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of i= t as concatenation
of results, then the result i= s as expected.
*(Glyn Normington)*

I understand, that within RFC8259 we= have JSON values of different
types. They are s= tructured somehow, which is not so much of interest here.

But while querying that structure with = JSONPath it is vitally important
to identify tha= t hierarchical structure as a tree. So in fact we build
up a higher-level construct here. We also need to call "the things= " in
the tree somehow. I was able to identify

* "node" or "item" of a = tree
* "member" of an object
* "name/value" or "key/value" pair alias "member"
* "element" of an array

but could not see an agreement here.
<= br>
I agree to Glyn calling the term "union" poor (s.= below).


## Differentiation from JSON Pointer (JSONPath draft charter)=

> I anticipate be= ing asked "Why is JSON Pointer not sufficient?" Indeed
its abstract says:
>
>   JSON Pointer defines a string syntax for ident= ifying a specific
value within a JavaScript Obje= ct Notation (JSON) document.
>
>... which sounds awfully similar.  If we could includ= e a sentence about
that, or a link to an answer, = that might be helpful.
*(Murray S. Kucherawy)*

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

= >The short answer is that JSON pointer is good if you already know the =
structure of the JSON data item you want to poin= t into, and you want to
point to exactly one pos= ition in there.  If you need to do something
that is closer to a =E2=80=9Csearch=E2=80=9D (which might also result in = multiple
positions), JSONPath gives you more rop= e.
*(Carsten Bormann)*
=
+1

## References to XPath

> I wonder if the analogies between XPath and JSONPath are go= ing to be
helpful, or whether they're actually d= angerous by implying equivalences
between constr= ucts that are in fact somewhat different?
*(Micha= el Kay)*

> I tend = to agree. Although JSONPath was inspired by XPath, I wouldn't
want to confuse the JSONPath spec by going into detailed compa= risons at
the risk of contradicting the normative= text.
*(Glyn Normington)*

> Someone on StackOverflow today asked a= question about JSONPath; they
called it (and ta= gged it) XPath, we really don't want that kind of
confusion.
>
>= ; In addition, the reference to the XPath specification in 6.2 is out
<= /div>
of date, and the comparison with XPath in Table 2 is = very approximate
and the terminology inaccurate:= for example there is a mention of "node
sets", = which exist in XPath 1.0 but not in XPath 2.0, yet the citation
<= div dir=3D"ltr">is to XPath 2.0. For someone who knows the semantics of XPa= th the
comparison raises all sorts of questions = about sorting of results into
document order, el= imination of duplicates etc, which are complications
this spec can well do without. (Though some answers are needed, for
example if ..store..price matches the same price i= n more than one way,
do you get more than one re= sult? And if not, what does "the same price"
act= ually mean?)
*(Michael Kay)*

It seemed to be important in 2007, while a= rgumenting to have something
like XPath for JSON= . If nowadays the terminology used has changed
s= ignificantly with XPath 2.0 and 3.0, we better leave that comparison
table 2 out. I am quite passionless here.

## Array Slice Operator
<= div dir=3D"ltr">
> Thanks! The ABNF for an ar= ray slice in that reference
> ```
> integer =3D [%x2D] (%x30 / (%x31-39 *%x30-39))
>
> array-slice =3D [ = integer ] ws %x3A ws [ integer ]
>  = ;            &n= bsp;      [ ws %x3A ws [ integer ] ]
>         &nb= sp;            =         ; start:end or start:end:step
> ```
> is consis= tent with JMESPath, Python, and my understanding of
ECMASCRIPT 4.
> *(Daniel P)*

> Did anyone else have an opini= on 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 sl= ice operation is then
consistent with Python slic= ing. See below for more context.
*(Glyn Normingto= n)*

It's good having r= ead this thread and thus understand the current draft
much better. I like the decision to be consistent with Python and als= o
getting an empty selection set with `step=3D0`= .

FYI: there is a rece= nt proposal for adding slice notation syntax to
= JavaScript, currently at stage 1 of the TC39 process.


Interestingly it won't have a step argument ...


... because of syntax col= lision with the new `this-binding` syntax
propos= al `::`


However, we should not let us influence= by this.

## Unions

> I don't think any = implementation would remove duplicates from a path
such as `"$.store.book"`. I believe this is only somewhat controversial
in the context of unions [,]. The name "union" sug= gests that distinct
values be returned, compare w= ith SQL unions. But Stefan Goessner's
implementat= ion doesn't do that, it concatenates all results that meet
each criteria. There are a few JSONPath implementations that prod= uce
real unions with no duplicates instead of con= catenated results, but I
don't think that's the c= onsensus.
*(Daniel P)*
=
> I think the term =E2=80=9Cunion=E2=80=9D i= s poor. If we think of it as concatenation
of re= sults, then the result is as expected.
*(Glyn Nor= mington)*

> I agre= e with that comment, but it's partly because I'm used to SQL UNION,
which is different. I prefer the JMESPath term for an an= alogous construct,
MultiSelect List, https://jmes= path.org/specification.html#multiselect-list.
*(D= aniel P)*

Introducing = the union operator `[,]` simply was meant an analogon to
XPath's operator `'|'`. I cannot tell, if it was a simple combinat= ion of
node sets in Xpath 1.0 or a true union wi= thout duplicates. I obviously
was not aware of t= hat subtle (essential ?) union characteristic.
So I fully agree to Glyn Normington's '... the ter= m =E2=80=9Cunion=E2=80=9D is poor'
statement. Ar= e there some better alternative terms, perhaps 'multi-index
operator', 'index list', 'subscript list', etc.?

## Duplicates and Ordering
=

> It was my impression that= we were talking about duplicated nodes not
dupli= cated values:
>
&g= t; Given th array [10,20,30]
>
> $..[0,1,0]
>
> Would yield only two results [10, 20]
>
> (Not that I'm advocating for= removing duplicates, personally I think we
shoul= dn't)
*(Marko Mikulicic)*

> You=E2=80=99re framing this as =E2=80= =9Cremoving duplicates=E2=80=9D.
Another view is = that [10, 20, 10] would be =E2=80=9Cadding duplicates=E2=80=9D (copies
=
of the same node). Related are ordering issues:
<= /div>
>
> `$..[1,0] =E2= =9E=94 [20, 10] Or [10, 20]`
>
> I would expect the spec will leaves implementations some = leeway here,
but that should be based on an exam= ination of existing implementations.
*(Carsten Bo= rmann)*

> The ment= al model that leads to omitting duplicate nodes in the output is
<= div dir=3D"ltr">"selection": if you take an input array and select nodes wi= th index 0,1 or
0, you get only 2 results (since = selecting an index twice has no effect).
>
>OTOH, if you opt for a "collect" model, whenev= er you encounter a node that
matches that query y= ou add it to the result stream, thus the same nodes can
be present multiple times in the result.
>
>I have a slight preference for the "c= ollect" model, because the general
case in jsonpa= th is to collect things that appear at various points in the
json tree. For example:
>
>`{"a": {"b": 1, "c": 2}, "d": 3},  $.a.b yield= s [1] and not
{"a":{"b":1}}`
>
>(i.e. jsonpath is not a filte= r and view operation but a pick and gather
operat= ion)
*(Marko Mikulicic)*

> In implementations that support paths (t= he majority don't), the query
function takes a pa= rameter that indicates values or paths. In both
c= ases the query returns a JSON array of JSON values, in the latter
=
case, a JSON array of normalized paths.
*(Daniel P)*

= I must confess to never having thought about duplicates, let alone
wanting to eliminate them. So I do like Marko's comparis= on of
'selection-model' vs. 'collection-model' a= lot. I would opt for the
latter. In this sense = the result of a 'JSONPath query expression' should
be termed a 'collection'.

Regarding ordering I see something like a 'natural ordering', acco= rding
to which

`$..[0,1] =E2=9E=94 [10, 20]`
`$..[1,0] =E2=9E=94 [20, 10]`

would result with the example above.
I do understand the use cases for reordering, dupli= cates removal,
filtering, etc.. But this can alw= ays be seen as a postprocessing step on
the resu= lting collection by handing it over to accompanying tools (think
=
of pipe operator).

Of course this cannot work on the result collection of values= alone (s.
duplicate nodes vs. duplicate values = above), it rather requires a
collection of (norm= alized) pathes. In this sense, I like this view:
=
> In my opinion the right balance between po= werfulness and enabling
simple implementations ha= s been so far one of the key factors that
made JS= ONPath popular over other alternatives, even if it lacks
support for aggregation functions.
*(Dav= ide Bettio)*

## Filter= Expressions

> Rel= ated to that, it would be helpful to determine if JSONPath filters
apply to both JSON objects and arrays, or only to JSON ar= rays.
*(Daniel P)*

=
> I would support restricting filters to arrays,= if others agree.
*(Glyn Normington)*

I tend to let implementations and= their "normative force of the factual"
decide h= ere or in doubt agree to Glyn's restriction to arrays.

I am very unhappy with confusing `$..book[= (@.length-1)]`, where `'@'`
addresses the array = itself and implies that array has a `length`
pro= perty. In filter expression examples `'@'` more consistently
addresses the current array element.

The invocation of 'the underlying scripting eng= ine' wasn't meant a
serious normative aspect, bu= t rather a quick and dirty solution for
JavaScri= pt and PHP implementations at that time.


### Corner Case

> Consider this perfectly legal= JSON object
>
>= ; ```{ "ab": 0,  "'a.b": 1,  "a-b": 2, "a": { "b": 3 } }```
>
>So `$.ab` is 0, `= $.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd
like to say `$.a-b` but lots of libraries will refuse it because `"a-b= "`
is not a legal JavaScript "name" construct, t= hat's why you have to say
`$['a-b']`.
<= div dir=3D"ltr"> >
> But suppose your libr= ary would accept `$.a-b`.  Then `$.a-b` and
`$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't.
*(Tim Bray)*

Hmm ... this seems to be a hint to better exclude `'-'` from
=
dot-child-selector syntax. I think I have read more = discussion about
that, currently don't know wher= e.

## Respect Implemen= tations

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

> The WG will develop a s= tandards-track JSONPath specification that
is tec= hnically sound and complete, based on the common semantics
and other aspects of existing implementations.  Where there = are
differences, the working group will analyze t= hose differences and
make choices that rough cons= ensus considers technically best, with
an aim tow= ard minimizing disruption among the different JSONPath
implementations.
*(Barry Leiba)*
<= div dir=3D"ltr">
> I'm OK with this, but for = context: I've been a pretty intense
JSONPath use= r
in recent years, and AFAIK the spec, and the im= plementations, are mostly
OK, so the choice betwe= en "make JSONPath good" and "don't invalidate
imp= lementations" is unlikely to come up. If it did, my predisposition would
be to err on the side of not breaking implementatio= ns, but I don't think
that's inconsistent with Ba= rry's text.
*(Tim Bray)*

+1 to all.

## Error Handling

> My mental model at the moment is that a JSONPath expres= sion can be
valid or erroneous; application of a= valid expression yields a result
(which may be = empty), but does not raise errors.  That may not be the
right model for all applications.
*(= Carsten Bormann)*

>= ; The  general approach that I've seen several times (including my
=
Elixir implementation) is that an error is raised wh= en there is a
syntax error, therefore an invalid = expression (e.g. $.foo[[5]) raises
an error. Conv= ersely a valid expression applied to a bogus input never
raises an error (e.g. `$.foo.bar on "test" evals as []`).
*(Davide Bettio)*

> On the whole I think JSONPath is designed to be "forgiv= ing", i.e.
such things aren't errors, e.g. I thi= nk I read in the spec that
filtering a non-array= isn't an error, it's some kind of no-op. That
a= pproach isn't always best for everyone, but it's important to be
=
consistent.
*(Michael Kay)*
<= /div>

> I would expect one c= omponent of this policy to be:
>
> Whether a JSONPath query is valid or not does not depen= d on the
arguments it is applied to.
>
> I.e., you can look at = the query and find out independently, without
kn= owing any data, whether it is valid or not.
*(Car= sten Bormann)*

I like = and totally agree with the *forgiving mental model*, so having 
only syntax errors, which do not dependent on data.

Thanks
--
sg
------=_Part_150043_821565506.1614366732920-- From nobody Fri Feb 26 11:34:37 2021 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 779793A15B9 for ; Fri, 26 Feb 2021 11:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 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, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915] autolearn=no 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 O7XK9vKsFYJ6 for ; Fri, 26 Feb 2021 11:34:33 -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 C86823A15B8 for ; Fri, 26 Feb 2021 11:34:33 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnKbp5kCtzyVW; Fri, 26 Feb 2021 20:34:30 +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: <502566941.150044.1614366732927@mail.yahoo.com> Date: Fri, 26 Feb 2021 20:34:30 +0100 Cc: "jsonpath@ietf.org" , =?utf-8?Q?Stefan_G=C3=B6ssner?= X-Mao-Original-Outgoing-Id: 636060870.140377-8cbee13b8f1d802502a6ffcbb2c31fee Content-Transfer-Encoding: quoted-printable Message-Id: <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 19:34:36 -0000 On 2021-02-26, at 20:12, Greg Dennis = wrote: >=20 > We also have a Slack workspace = (https://join.slack.com/t/jsonpath-standard/shared_invite/zt-mxse9mgl-DK~3= 5JawDjcsFUY9PVO5~Q) which is great for small side conversations and = general questions from the public. (Though it appears that the = workspace has been removed from the README.) The nice thing about Slack = is the integrations. It's currrently set up to monitor the GitHub repo = for new issues and PRs and StackOverflow for new "json-path"-labeled = questions. Do we have a way to get these conversations archived? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 11:52:13 2021 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 ECA4A3A1629 for ; Fri, 26 Feb 2021 11:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915, XM_RANDOM=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 R8Z0aqgKy90J for ; Fri, 26 Feb 2021 11:52:10 -0800 (PST) Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 A387D3A1624 for ; Fri, 26 Feb 2021 11:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614369129; bh=UiXN9YBt69ZqH2pSsb2V5XpIaq5gNPCSx+pGJ+WELRo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=SbrwkIihYFmZwT8cH2yww54V0BL70oUCIZdXi7c6rq/C0mtLS7LXQYsZR2XXElNQnOkWgJeV0HnI9mPif+Mr12Ot0j2OGvgxpY5HAJ3M943UZgfYYafyxPyl7GJnHZPDoj8VdNIPhz+htev9gkFUiSRRkb93yUVA6gZyaClEqiyjwqq56rJCkZGPs/AzZ8NjC6r0210clvo2MPGs74rC0WWtpFTQo8wl2TkEd8IvVNgzPI28h8M/BW49l4GHOG4SvCFuG9RPqwDe/w2tH75gyJQTebazcxLLXo/NY0GHi+5eGZdXURWLedaYdJIAcrPiO7BFJlO6RasUsEVWJuBsWw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614369129; bh=/4mJpdGJpkcKcmFzT4dbHyQ8HG8mPMNW+Its5Dh8fXY=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=TjlMxA/k05XkC82KNto7iGFZAIJaDkC8vklEAFyPBJG4JrMAfvVVsaSQzysPpEnySG+hrB3OderkYqBlxf5fU2k+ia4LaRPhYVEGxZJgQGj0f+rQyVnycMDaE0DQerM+1bPWU5f4Zzerag3fh6UiKlhPt6EWURAkVJqG2pR3AYDOxVpHrPOrqIHRLl0SupFSdeocbMgj+ikKlZibKFcQjmcTowQTgVFnIiRqLLa8TXlWFNRzyZtIArvaYPZ42wCm9MBIsMAsKPmOJhBiE5SoDN+jKYP5iyrHPe6vuBKAkFKJfpg5YIxKomez69qdxD7p0+YOCi+NtpVPGaBM9p4/Fw== X-YMail-OSG: re2zxZIVM1luFBeWv3JnxmYHCImCBx4hmgbGcPHIS5eGgtyMHo301yej3ho4aQ4 KdpHGq5KcjCn.kLS7edbKjzbg6RecTqLlaIRq67sXr_s0g3PIQaAN_beCkDd3IVrBfKBqLQm9J3K 9z12G9GQbABC6WDEPGPsEF8mGZ0pzrKJvtWAC75zxKQY9MyccSKFfHVXJAjrR8pfS0SqN3HSU_Uz IKO0fEt42FOhuFDlI8x8TpSBxPvjfH1QyBCvm4OlUvpXl6.xdemx9eke.BvDZSZEQv5YnvEsFBsi E4gnr9JykdOn.3m.1g8Fa8HKQ_JC1O8UXkNHdyUz4yFr4.BgwR99A_gwA4.xn4ILyDZ0PUwWmPU0 fS2XQ2klz4ItIzZ67oduUsKmI_orGUynReZD7GXNGzg7EFok4Z89HbYtOoBUXOmrE8Q8HJLle8.O dDbcJGYP_HujAtj3DL0.VggOk0lVJhcLQEU96T2RXmU3GTOI48VkfFnM2d3L6EVYqsx8OeC_NRlp YFoTaX3auVk2KaetqbBmjwLCfBQKaZ33oJTvUQVnQI5W_VFZE019iGSSdD41VXfcTYDD6XdTciGB dV7K0UBwR63kpYAm81VKyJRaY8uuBcosqpdEJeCeX7b5.b95Q0yNaYWV0h464tmy9qS5S1AHBfws 4oCT.0pykkGxhMLlOXmPNE31ifUZFva26q3wU5l5ynX3_Gz7KLJFm3I.ODdvhKHEc4uLAGADHaMQ 3FZZPFRjIC5LvVgddkMtzivBkboUB3X99S42sfm4z7IVTeAykLsumXbCtO7eNRrUTom_zQ_6ojOI CWUEFWT_eCxfnzkKLFGCuBfk66AtmGhtqp4XVWcNaeiF7weBh0X3o.sRcZ3HiXjgRYZUjMzHP6jV mwY7vKBw0OL9dLiZPGLhwLDyn3zpugtn84_APZfsokaP1K2eA2v9toIis5xCP8VjMmgB7L1H2gIO sBwBbQ3DUe4mJJwDCFtOn30TVwm_SIIs7Jz0GsAGKx0Ui1FT2K9aJM2tVGSDgRZuxr7DgB6TdPPs M2Tr53TYozbF2aQbEKc.f94u_fSWZIdRx6.lsnpKlMZy1Q5owYnjzJMN2frliGwwxrgY.u_N_yvT L5LpBDiRA7LF8kW1WpXQIT1MiaW7hdSwsj72SLeWa95v4y5_PSd0YUmZV.hfwDUmffmMpI0IyBMz ilNMOpCAmTozLZlbCym1v16RgJiHW9ETu9k2nn0IHxNGuQaRmpvoUHMOxhA1oGyIQXP.BHF0z.VF Gwx2_n50uw.jkt6zlSoLoRUVjLQIsbgITYi6Ii49CuBqG0b8aTul874C4KBvp4srwRcjUP_RptLp WUPRxq33bW9VI6jL5o4Pv3wPwpyXi79Z45d6kHuU.infYKfiSEMz7CXfJjiErq6qA21XxVDVdO7m g3FsiLEJcjQujsmJDPl3tpqU0T93pINtp_OQbRhZohPqwb.E55bZjCdCNuP7kThF6WMua78dqchw jOKa6mFciVNYORwBd44Iz0NemSKdX.f0MaKtocy8nqD1kGiGwDrI.eVqwSnHFrmmSDUHWOJNouqd MMb5EhDAoiK9suC9IkXPYuhaWn5RxY1hRBZA4OP6ATmcDRgL.9LDYVAbu0lYcFTQ78Dml5FsrbX7 _.81HnE7aHMWAS8mF6YWU7zmxq8pz9FjoyFPFIbez1eB0_Ccyg8Da122fFG1mv3oM30nj42i6UMA MuNMvlc36FgliCFO8e3VPFBFoX5X_2D0Mr2I7q1x1ggkmd10dyiUlwLWMGgiHDr1vHRoZBJvT2qR hJWNRAGl2iRDcqC9ZgxCzkUCpqQoWW4d9PDof7LQb6Tzyhn2mMJ1zjy2G7sepBWuLpd0Do7wVdZG sM7KigfVns9oH1UwpuNnXl0XXerlPsI9zI3iL_5nnnDkEKIw.j5PbUHzsi1tXKJylr6zf31nRQKX .DLkI8vlf1CBw7bPylfA9paIe7VDfN2qBqYYDSA_ydHDOvfvnsujWCqujehzQDH7xI.rvxGQCHiF sRQHcPTUjKCfTDnAxZFEWrdfa8Rxr2siQebP.kXHnHkl2KocF.8jhVAEpG0JlhfiKgorm5.exUT_ OqGT.Ap5OxbWxrO1amKaKI3t_EAfvcHYPyfvN1tS1TCSSgbjq1TC22NKcMXv6QEbQ3sL4qdd6Rb1 a6DyRkGLksErPJyVCkd_M1D52KP28vdSshFOpEQRTRyKUjmQybs3S5NLCm1ZLW3FR3lq4AE6X76f 2RLcED_.kSwuKgQwL6KlQE8A.n_.8h83choQHbHb.cEf43CWKxwEcaF1H1_JL588ajWV6mr2UUBf XZ0bSgWwc.VJzbzVjdxN3tRb7WfdiMR5AV5D5T76_JBaeshcno0gNvusU9hiYyE79os0Y5AbDkYe HqBqa36LK8JLK8N4jf1qO9bePOjxbyAgWREZK6g4kgqhZju0XV_SGhR_HVXoiFl99WeAVvcNh0HG 2mhqfmNNk_mECq68McV7dohvb7auWXLoIyDgCMkTVQUCL24KM0NanYq4kUWZ046H4T2DKmnCbg5Q 2onp4Ae6zLVizrzw6QfDn3pc26f7d3sdjZnzUHKDAzE3oNY0ZD..Du84d1uIDR_TqCkQnn_vuE7k CXkl1RK9173Y- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 19:52:09 +0000 Date: Fri, 26 Feb 2021 19:52:03 +0000 (UTC) From: Greg Dennis Reply-To: Greg Dennis To: Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <350059548.134171.1614369123233@mail.yahoo.com> In-Reply-To: <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_134170_1539280747.1614369123232" X-Mailer: WebService/1.1.17828 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/6.19.4; Android/10; QKQ1.190716.003; OnePlus6; OnePlus; ONEPLUS A6003; 5.87; 2087x1080; ) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 19:52:12 -0000 ------=_Part_134170_1539280747.1614369123232 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you're referring to the 10,000 message limit for the free offering, that= 's a valid point against Slack.=C2=A0 But it doesn't provide merit toward e= mail nor detract from GitHub, which does "archive" discussions. Greg =20 =20 On Sat, 27 Feb 2021 at 8:34 am, Carsten Bormann wrote: On= 2021-02-26, at 20:12, Greg Dennis wrote: >=20 > We also have a Slack workspace (https://join.slack.com/t/jsonpath-standar= d/shared_invite/zt-mxse9mgl-DK~35JawDjcsFUY9PVO5~Q) which is great for smal= l side conversations and general questions from the public.=C2=A0 (Though i= t appears that the workspace has been removed from the README.)=C2=A0 The n= ice thing about Slack is the integrations.=C2=A0 It's currrently set up to = monitor the GitHub repo for new issues and PRs and StackOverflow for new "j= son-path"-labeled questions. Do we have a way to get these conversations archived? Gr=C3=BC=C3=9Fe, Carsten =20 ------=_Part_134170_1539280747.1614369123232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you're referring to the 10,000 message limit for the free offering, that= 's a valid point against Slack.  But it doesn't provide merit toward e= mail nor detract from GitHub, which does "archive" discussions.

Greg

On Sat, 27 Feb 2021 at = 8:34 am, Carsten Bormann
<cabo@tzi.org> wrote:
=
On 2021-02-26, at 20:12, Greg Dennis <= ;gregsdennis=3D40yahoo.com@dmarc.ietf.org> wrote:
>
> We also have = a Slack workspace (https://j= oin.slack.com/t/jsonpath-standard/shared_invite/zt-mxse9mgl-DK~35JawDjcsFUY= 9PVO5~Q) which is great for small side conversations and general questi= ons from the public.  (Though it appears that the workspace has been r= emoved from the README.)  The nice thing about Slack is the integratio= ns.  It's currrently set up to monitor the GitHub repo for new issues = and PRs and StackOverflow for new "json-path"-labeled questions.
<= div dir=3D"ltr">
Do we have a way to get these co= nversations archived?

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

------=_Part_134170_1539280747.1614369123232-- From nobody Fri Feb 26 11:55:53 2021 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 5E8A33A1634 for ; Fri, 26 Feb 2021 11:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 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, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915] autolearn=no 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 8FLIek2SoNme for ; Fri, 26 Feb 2021 11:55:49 -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 6C2873A1631 for ; Fri, 26 Feb 2021 11:55:49 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnL4M4Q91zyVW; Fri, 26 Feb 2021 20:55:47 +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: <350059548.134171.1614369123233@mail.yahoo.com> Date: Fri, 26 Feb 2021 20:55:47 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636062147.122781-4a6dee2011d0fde76cea92aab25cb75e Content-Transfer-Encoding: quoted-printable Message-Id: References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 19:55:51 -0000 On 2021-02-26, at 20:52, Greg Dennis wrote: >=20 > If you're referring to the 10,000 message limit for the free offering, = that's a valid point against Slack. But it doesn't provide merit toward = email nor detract from GitHub, which does "archive" discussions. I wasn=E2=80=99t arguing anything; I just want to make sure that if we = adopt slack the slack discussions are not lost when slack goes belly-up. = Email is handled by the IETF itself, for github we have some schemes = for making backups of non-git information (git itself of course is a = giant backup system). For jabber, which (for better or worse) is still = the supported IM system, we again have backups at the IETF. So what=E2=80=99s the backup story for slack? Gr=C3=BC=C3=9Fe, Carsten >=20 > Greg >=20 > On Sat, 27 Feb 2021 at 8:34 am, Carsten Bormann > wrote: > On 2021-02-26, at 20:12, Greg Dennis = wrote: > >=20 > > We also have a Slack workspace = (https://join.slack.com/t/jsonpath-standard/shared_invite/zt-mxse9mgl-DK~3= 5JawDjcsFUY9PVO5~Q) which is great for small side conversations and = general questions from the public. (Though it appears that the = workspace has been removed from the README.) The nice thing about Slack = is the integrations. It's currrently set up to monitor the GitHub repo = for new issues and PRs and StackOverflow for new "json-path"-labeled = questions. >=20 > Do we have a way to get these conversations archived? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Fri Feb 26 11:58:41 2021 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 91C623A164D for ; Fri, 26 Feb 2021 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915, XM_RANDOM=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 gMKoS1TX4Adr for ; Fri, 26 Feb 2021 11:58:38 -0800 (PST) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 0BB3E3A1647 for ; Fri, 26 Feb 2021 11:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614369516; bh=Uz7tXdQUelxiidFTITI+vwDh582+EwF0xPF2J+EVls8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=JEAQXeFXGkWn/r1ywXGpj1T27kg2+18gv3+JlDT0Xksu4flEjcs/TgJ6Z0ZiervtO9cIw2kenRSKRPQOYgkFxedwlp2CRcXQ9t3LoOmANIRDz2DPmiUCn098+TEmCXgBm6wl6d8anmjbT8nBQx/HVBl/s0ez+8wx6Pw8sLDbwxhkJ2JgrpuzAsXpCN0bkv7yhc4Vncr4nRJTh9rY7Mjlr9qv0xIFrI5W0o2nJeSUdXqM3/pqisQA3S7Gx3hJ7vVcH+IKmjx102/cs9SaHHcO0Q2BYoPip3VfP+DQ+Q0nxGr+ubIIUy6gDVJoEu6ercnhGe6Se1QabWXmVuLlB7prUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614369516; bh=ry1lDO9YCZqWcIjv8DuLEba6jaxZVybHChCE72YWaWP=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=k11luE1lU75hFVcYvujESVBPD5knF/uR9M1XRQ/3C2GHw1IE6a9OeGki2XnXTluzdYqBHz8g6iUKPjGmuXxBNr0b8vrH8HQ6hoXPOhC7mJmT8nYYnovO3sDbI4wGa6kHSKFsxM5DEkqWyUE4BCr4J75DI6iKc7tCn+OQLvn0pMzBLyLs82Ehu6MMqHeRLidU6SVSxRmZWuWAGXnqESbECCqe9P6nGaGUpzuCOivFb3AeLEcgmFF1tk+Po4T3g3cBLbrwluPGbXtyYVLdo3yIpmEnMsKWXykzPOB2lte+W1nS5eHZNDsr77DMGgt6Wu6Uv5K08+IbBE3Nk7QFx/SJzQ== X-YMail-OSG: IctttYQVM1mgYMR9oPZONtEJFLtVcCtld4Fu_pGB.wZLwd53DH2Dd0qukm8t50A ANE71q9n65qyhl_Uoml8lXYoJKjDavTRTeDLnLeK4FZVBoUTxHkmqW5P4eBUVwaBtWTTH1mfr.oK pzjVoyDzlp4rp4RcJGSQ2yU8ihuDBVXhGLTWKim2qieeSACDGbaBOqMllqPfBfYNAqEdHxGcOHDJ L3PkuEOMBVsHDP7SxDeI882RdKvEYZ78lSyR8PqqKMhkLrdV8V9OkKTD6iraR2Rc8DLJNEYDRLdw ScidD8GCOi0yCb8Arql9PLm3KXxx33ClmMVSySRRMRBbLWg8POIk1DcCxvuqoF8afqFXj4IWKNE5 4fCCIqv96vwOqdr2cu4Ay_U1P9iwA7qrg7mNjO56HtzaNcCVcdEhuXIGK1gvy88ZZdX41qqcJkr4 .oOAaT7vRHM49RsBdtPdQhju4wr4PJzXGTFTmnFr2pHMMlcVfK1P2DzNlcP7rUDlPoNat9N6D2Lv EIpIQCa3kvQlv_mCdRgpi7lZPgci9wg2Dh9lM1DLAyDbQMBg4MWT4ZLnc2A2fA58c3qAZlIE4G5W XPxFlVmL8bVZStOUJLAeYC1g771p9tS3K3MTeqjQnWHJCC8d5qP7kHURPtSVZO04YfcNiWF6qjv4 QspDzuYRCzzUvqIJ_jH0xhQiIKmtHCZVMlezx8O53.mHbZW6_xDZnqxKNiKJ4yE.97gbQfrfctbH cCJhZs7YDqEOfvuYGpLIjpxJ.izenJT_O07UJLBx65nJZMZiOoWTlM5iuG1V4nYfLumYqJQXnwk8 WuIMVyi348iNh5qaVZfUmHl6JAywsPw.xuZHhEdUMcq2XQcm2Z8UDcUGkVGLtFVabhkUvhyowg.F vTWN2nFp3fGH4n0zC4ZueCR0AxqmzoQNDScdL0kFot5oJTJD7sT59S5Sf9RvUq7DnZ_oVxh0MtTb eKaKiGERRXtJoCNLaitTscXQLVyxAVrDgR4E1Tvk.OI3TlbVtNLGlKkralWeAYSEnIk_eu.1h788 yspt.bewWlO9ldVSzDLN0q.F8Wpw7vZpMN8D_G4ZAzDcC2r7oKMXFZBU0RCiCqBjFVhR2GBDnafZ zDqEgPhhBwNWmocLG.hG6c44pM2o3eICNk5sAl9Hm9pELXi9FFisUgzTjCd1V664nXBSPDx9vkd7 uZxh2xqIlU2UGZW7L5iqG2gg5mJ9bgEZMwsih2qxMKbMml_V7.zplO9iiqUqhjgBPqvIpATD39nZ 2eQi5iNafD5FzdG9jgsy7bpq.9RcQmMfKtr07chatO0jFt_WN5fcuWY5NSk7Qhs_t59aIv8WkJ.0 yhASatpLghQhgqCJvJBBqhFGsfk0hcsHmos0o2PWCoTiUvwoFU02akyP4wany88R1CkHJ8sdCVK8 ALTNDnGfkCS.p0Y0tTicPxUWCJ54jDXix2ojrp85IP_gw0a3WWI0807nDPTCBomPvAViKKq_W1nT x_eHQ38n5fn7MFtmnnna_eKEJGMZKlDsNLuwuAuI0eP3rs1I4tH_JRmAV8XYVaCubQARCuLygp2q rwAibwlVP9l4Qva7BAQVwCUZnJxhL2.Eo.tvHpdMXr21C2g65x.6Q8Chc7zx5JZRKT2iXR3PlHNa VP1Ajz8MDEYFK2Y8xwvXk74UyHkpMP4yVku8kcgRROrJSyZyfVUnetZ02J_DD1Uz_2vtWl5Wa7Sa tulTRFCnxwO.n2bNpLjE6zkHuQqX2a9k5HGOsOAVP7rlWVdBeeeB4OdilnJROfc33xXV9FQZ0Sy3 E_VdIKoiEsJGjySIe3afzdXrLJRzuvrY0xqhDK76.mIbHqlSOK_njIRg...irNrIPi3bkAh.FzXq I8_9KBwo..nCi_Nbm5rDZsaYFIkrXxhV7e12MAcN9QNoxpH05sQAQB3GutvosHCXiz17.XEQ5Dof eFCfbDSg41lVlmikfDREf1sPnpM3lnYI55qE6vwDlVnJ4ADqnn.jBbmd7gHJLzGvDwePGQ14dc7J ndB1LGeUIyyXdSmLtvLc5UJ7xKJ7BeIBI8zP9TsoaRrQACoiG4MAALXhmYzS06853MAkx8m3PFyo 54v7zqXnMPs8DVTPmk7WEhazOmTw1AHcsV4M8bfIB6O1KN0ACfAwm1osTlkPW6JIP5P_ZGL57_kU yhbUguMS7DkCU2f7uRVYawSV3WaQMM6s69hpq.kW8irZAszLG7.zfIaxxaAeDMMnevkHtcWsW15u blHhi_hTdDMIJ22dpIXlXm7Q8mJEKLW7EH3DPJ_3JxwcymYM9N.Y9CRfBTmbJaGF3Zt7TFLKQlC1 duKGfXV.D9H2z8YCYVEj5c2bV.iySV83m.VtsEdgRIU7fAJLYV7fnQxuPXiPU6On13Jdcdz6UWP7 Cm99QYgdsh5XA3Of9q6.Ln_2qI.hXEdqLlRJnj9DZxnujIAw8L9_3lnB6tZ.ZOIRcb_QGmjX5Dyf .FDPSeXKYJON6UW5EvlEbYGRSofxmMDo7yvXN7zAG8IystUMPoRfJR1dObQbq9nuACBbfPEXaXL7 .gOKc8vWBqQSaTv8C7.8um7kvuq5Tak74V3zAapWyi9w9K9Bu3LeXYWJmnZE_tY9jbe2nN_yzCOJ dPTLxHaIrinJYcvkljC3xhWw3Zz3rd4tg7rS2ISiPTQq. X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 19:58:36 +0000 Date: Fri, 26 Feb 2021 19:58:31 +0000 (UTC) From: Greg Dennis Reply-To: Greg Dennis To: cabo@tzi.org, Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <1576492499.98241.1614369511559@mail.yahoo.com> In-Reply-To: References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_98240_640104418.1614369511558" X-Mailer: WebService/1.1.17828 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/6.19.4; Android/10; QKQ1.190716.003; OnePlus6; OnePlus; ONEPLUS A6003; 5.87; 2087x1080; ) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 19:58:39 -0000 ------=_Part_98240_640104418.1614369511558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's my understanding that Slack backs up everything so that WHEN you decid= e to pay for it, you get all of your "lost" history back. Greg=20 =20 On Sat, 27 Feb 2021 at 8:55 am, Carsten Bormann wrote: On= 2021-02-26, at 20:52, Greg Dennis wrote: >=20 > If you're referring to the 10,000 message limit for the free offering, th= at's a valid point against Slack.=C2=A0 But it doesn't provide merit toward= email nor detract from GitHub, which does "archive" discussions. I wasn=E2=80=99t arguing anything; I just want to make sure that if we adop= t slack the slack discussions are not lost when slack goes belly-up.=C2=A0 = Email is handled by the IETF itself, for github we have some schemes for ma= king backups of non-git information (git itself of course is a giant backup= system).=C2=A0 For jabber, which (for better or worse) is still the suppor= ted IM system, we again have backups at the IETF. So what=E2=80=99s the backup story for slack? Gr=C3=BC=C3=9Fe, Carsten >=20 > Greg >=20 > On Sat, 27 Feb 2021 at 8:34 am, Carsten Bormann > wrote: > On 2021-02-26, at 20:12, Greg Dennis wrote: > >=20 > > We also have a Slack workspace (https://join.slack.com/t/jsonpath-stand= ard/shared_invite/zt-mxse9mgl-DK~35JawDjcsFUY9PVO5~Q) which is great for sm= all side conversations and general questions from the public.=C2=A0 (Though= it appears that the workspace has been removed from the README.)=C2=A0 The= nice thing about Slack is the integrations.=C2=A0 It's currrently set up t= o monitor the GitHub repo for new issues and PRs and StackOverflow for new = "json-path"-labeled questions. >=20 > Do we have a way to get these conversations archived? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 =20 ------=_Part_98240_640104418.1614369511558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's my understanding that Slack backs up everything so that WHEN you decid= e to pay for it, you get all of your "lost" history back.

Greg

On Sat, 27 Feb 2021 at= 8:55 am, Carsten Bormann
<cabo@tzi.org> wrote:
On 2021-02-26, at 20:52, Greg Dennis <gregsdennis@yahoo.com> wrote:
>
> If you're referring to the 10,000 message limit for the fre= e offering, that's a valid point against Slack.  But it doesn't provid= e merit toward email nor detract from GitHub, which does "archive" discussi= ons.

I wasn=E2=80=99t arguing anything= ; I just want to make sure that if we adopt slack the slack discussions are= not lost when slack goes belly-up.  Email is handled by the IETF itse= lf, for github we have some schemes for making backups of non-git informati= on (git itself of course is a giant backup system).  For jabber, which= (for better or worse) is still the supported IM system, we again have back= ups at the IETF.

So what=E2=80=99s the= backup story for slack?

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



>
> Greg=
>
> On Sat, 27 Feb 2021 at 8:34= am, Carsten Bormann
> <cabo@tzi.org> = wrote:
> On 2021-02-26, at 20:12, Greg Dennis <greg= sdennis=3D40yahoo.com@dmarc.ietf.org>= ; wrote:
> >
> > We also h= ave a Slack workspace (https://join.slack.com/t/jsonpath-standard/shared_invite/zt-mxs= e9mgl-DK~35JawDjcsFUY9PVO5~Q) which is great for small side conversatio= ns and general questions from the public.  (Though it appears that the= workspace has been removed from the README.)  The nice thing about Sl= ack is the integrations.  It's currrently set up to monitor the GitHub= repo for new issues and PRs and StackOverflow for new "json-path"-labeled = questions.
>
> Do we have a way = to get these conversations archived?
>
> Gr=C3=BC=C3=9Fe, Carsten
>

------=_Part_98240_640104418.1614369511558-- From nobody Fri Feb 26 12:06:55 2021 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 3ADCC3A165F for ; Fri, 26 Feb 2021 12:06: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, 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 rVJOuLzsHWBq for ; Fri, 26 Feb 2021 12:06:51 -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 865B03A165E for ; Fri, 26 Feb 2021 12:06:51 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnLK51c54zyXP; Fri, 26 Feb 2021 21:06:49 +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: <1576492499.98241.1614369511559@mail.yahoo.com> Date: Fri, 26 Feb 2021 21:06:48 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636062808.733323-0b41d2566a3dbc839079c9a2a237abea Content-Transfer-Encoding: quoted-printable Message-Id: References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 20:06:54 -0000 On 2021-02-26, at 20:58, Greg Dennis wrote: >=20 > It's my understanding that Slack backs up everything so that WHEN you = decide to pay for it, you get all of your "lost" history back. That is not answering my question. We need to have backups that are = independent of the vicissitudes of corporate odysseys. =20 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 12:14:48 2021 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 A3A083A1671 for ; Fri, 26 Feb 2021 12:14:47 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, XM_RANDOM=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 JcJevO2No_gr for ; Fri, 26 Feb 2021 12:14:46 -0800 (PST) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 221FE3A1670 for ; Fri, 26 Feb 2021 12:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614370484; bh=SLFVfueHHBuPgIzgkJ/zQ4s3BlBjQXSfPRXCKTSivUI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=ceH89062r1wbrna4G7ZQF4NeIcRzN+4ROBVab1OkWlXT3vh8U9ukyLTksAHVtvy+wjV7gTe1kFlp3jJ5o4WvQdiiJP9IWKlsMdF5zQDGgitaxup3qKrZ0H9/P6UaGlxzM5MUB1pcjx9EaFpE+PgM0+d1cWvZZCPQ9i0AELO5+kHqgUxPsJujrJetWlvTsJPlcEGufFHOLOFpxByXXgtaLAT6OHXxWijPOBMfj2iYalAQDOTFJo8DX8JRv23bmzIkN+LQr9MQcOh34/I+oUbkU3ZFTTO5BfyJu+GpBi9IwcyTuRT4wGuMSCX1F0VWFm55K5mOYNjaRloJsK9T11pXFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614370484; bh=Uxks17nQEF/fTS7ZlrxOmhvjE1dpncjEO50bfXXtZVz=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=I5yfhxesrko9IcH+K8QK9BwCIQp2/MDxC25k5q7/XdwOqSqwf7VIU61l+g3qSj3/k4lJNiKsDvBkbyotzhCPtZ2EqXtzGNZtRQz9sOtoBTZEnLLStCNCIuAzRW7e2FiIvR7YFm8Fz0XVoiCzq72Pj/nkUopPpwkxYLovDmUi0Grjp4jLgqqLY25fkyKR/85qx6aRyz9G50XGllZm9HML9tvXKHxWBlrYg1kjVS1ybNiaUja5iSHlqi0knMHRNHhhAWEAYSkcd5JkpNt4X1K4+Cx5901oANwiIJFLHvlLoUY9euKVagMm8f+pFbYEzkcURecrVXqgeX2EaytNtsBwyA== X-YMail-OSG: KDaKH.QVM1kYn5jAs6JSFhxt3Z2bgVnTeiknyBLrsX5ZyrSgqKiYxkkJ.RbkOgl WpsGi9H1.srf2imC9hH4QTk8Cz1D0BXIVrGnnEVDPy10hXBKpHy05i2gaEFWz6GPskR_qoiboRvi pWB1s2cgV2OdJzkznrQ6yOWJJwVWGs0BDyNGsGwlgk3cRJ40H.z9ZYR9jrzQ51DkEkM0MTq7mR46 NrI2HSuwCR64DinrzKNA9EyQmFqJlni9_KBZfFMmu2KtuS4CFbWGlT39_xe.NYsroBFipYwlGc.o NszwYM_oINdGiX8.jqp_JyFxNGUeydDm0lWN5yfiHl0FcvJ1TgUq.o9JzsPcgOyQekdCynWDFkHN osTO0eJ8t4uqd762Q7znbSeEtZTZ8xJgQBbQ5_.X.2qnIya_KHMlqHGnqQPqYmZTbXVxTKB0qN3m EUMHxPjPi5UxrDYtSQ64LSRxy71Kcs9KF1i6fWnJBjV8frK77Muz7y7l1uPWAsPGr44aZLTFGDUF IlMEj3Z.FuiakYkZJZj8lzvh5aSiCoXSdM.85MLCwYqvwh6BYlF6VZvGvrEVBk3wXc.5xCJc7.0Z PR7T1oyGQEajtlT0C2dUT9kluy59ISbxO.RXRsrHE0hToCBJK08a_3TYA_93ouu5.yUTH3vCx2hb CUdcNz5u38dMeLdkvr_yy42cSSz.elkeivZQYfD7EVvILkWUw_CtdhfCKWKzwphgLVBLa.WNWLbK 2HYTTFjQIyTPfqFwoTB5.ixDn6pnDQpffTKABHRM1rowitHDMWQe5uTiNURT4eexPpImBn9KFky7 4XlnlSfjaKc0KByQlrIQq1CR2XFXM8jVuaNdRicln_2u_qqmCQ5LhvVQV1m6KtxZzsB_yuimzxbF C4GHfiSJxbl87Z8ERMkLiUNDj7bgRTNyiJ7hVMQYyFsPujFsVDWRnA1sUzM81cHO349CifUp7s8T xA9nFuGs2heKh6iTqN9JwKdt56L1D0lmwKrVrEsKIfZR7e8aSMiTjvDMEPEZ4ctN__xUG5LPf8zO 9JovjaDYpEJqHQYb_PGq5Z0IOf4sVH459K8VGpGC_LS3Gx889e5rh__XOuAZqCBkuflgXDtomJPr 9Pgwaed_hbTXkDusF6Qt3eJLgBciIpQmr7KEfV03I3J9vPb9A9qiLwlYE0GuYn8nCwM1Bew79iaT 69Th9G0RfaU9CgbVOr0wveS65m6NAxsGWXl77DaihLreRDQ6xiZDvNnFN7Z8rqjTbvmXn6J2dKPf EbF4ZE8StQ4xkcpSc5hDF2QZOdO40FflIKOk9RFqg_jjpXCmd3.GY2_pxh7sBqw4tmu84tdhDS1T JrMC2xuJUZcSD9L7l2qes81j6z9H476dS0T.x4WaNflGLBjf_i130IlUB4Edphk1pZWdYg7IXwwy kXVPOkBD2YG0p6_ibYusnNzSOfbUqh_WImiPax._t3Kuiz.4TC4bvFllMMVr5vQ4estYbTUwYS9h a.9xcoG3j6KN6erEhdYBV4YFwZi0Dz7O6VJCMGh9sUcas1whX63JuUJdqgbGzSbWpeVZa8.lXVU9 _GJqfI7UrT5OM.V1vag3Q7iz_ARJzHh9p4xhMeMuhG1M.xhh2_yEtyaVonCx.zN.2J04y55tve7t aYLf2wx1aHQcREuWNNIB.X13sOY307H42yH0rMqgksdn5s565XDC.vlcdkV7cobDH5bjG6QmFOT0 zveD93dH2UIvVdCuSoFC9UKeLP1_HDIbnKMkbRAzW6jfhlKgsMfPAUODJNyxMp7NQqhXDvodcKRp 0XYpLCmcBgd0eugm3jdQkgu0hg.2k43NR.IVXMTWEM7a3G6iH4zqfsMWykNfTu6fRcOYU8YwnnyY kp11DpiaxNCvmL5FSnKvS7.nhCYI5TsGKjGJ6_TN8WjLAuhLs8EuDP2GiwcQIMdNfTe5ZAKGjVSH yR6OiofxiSOTZn7SbGQPGEUDCs9.GaR_r4YmgXJeckPycMU_rs94Tw.1qcGGQAJOGa5v25xxp6pv yxPFq6vC3iKrYbNRcNkj6eUcvlZJ5W4idhooq.0e6cNu8ciJdZ9D7HwwT.i0MAFDlwz0Wj2CycvM HbzLfEdXl6iffEHgEoI3OySw9AdFmcP.hDoLXSDIJ1f4XfbQUGjXfW7aQGnLdLC9HNGKavu7IrRR eovjdpaAEcQ4E3JGOLCDC8dOrFhDn9Ke29bCO9XvLkRNc7ZQLaT1B0rMwFXYKSb.RCFbLJisiWp0 uq7D3PYhMN_FXy1oFw3OvRZ.o0sNK.FyrsuCHt0n9npFr63TpeKayuUYlrp4r_S06OmNqe7SDAFY lBGcIFaKARoXwNROPKkDZc1.GLNv9sh5bLEeq8QEFlAFxhpY0t4IUoTSaWGz2kSgMYQTLjPcPVm0 1A4Qg99RiDP3BwSAiR64hgkUmbIj9EWXIu_spTVrCg7kF0P98FVqi589EVCpvSySNBMCmM_adaVS O4QztpQujEpMfLdkl03Q7MDkmdRpVqIZp48gdx3xgl9u4r._ihjZPGMdlyeQ.vJ0HHYX79ufRZqw uVmrPkdcd2y.ORI9XoXWI0y3c1cSSukAAMsaNz93ZQqklE.CUIIRLXfWcovp.6ZPRNv.lCD3anwt po4ZkDZ8kSNH9TCejNiq.m127PHfpHZ2utkas_t7rUgU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 20:14:44 +0000 Date: Fri, 26 Feb 2021 20:14:36 +0000 (UTC) From: Greg Dennis Reply-To: Greg Dennis To: cabo@tzi.org, Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <1157333423.170620.1614370476963@mail.yahoo.com> In-Reply-To: References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_170619_456851359.1614370476962" X-Mailer: WebService/1.1.17828 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/6.19.4; Android/10; QKQ1.190716.003; OnePlus6; OnePlus; ONEPLUS A6003; 5.87; 2087x1080; ) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 20:14:48 -0000 ------=_Part_170619_456851359.1614370476962 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's likely the extent of backups for Slack.=C2=A0 I'm guessing that you'= re dissatisfied with this, which means that we're down to GitHub. However, I would argue also that not all conversations NEED to be archived.= =C2=A0 General questions, like those which appear on StackOverflow, occur i= n the Schema Slack ALL THE TIME, but these don't need to be archived.=C2=A0= We also use it as a space to work out details of new features before publi= cizing them.=C2=A0 It has its place. Greg =20 On Sat, 27 Feb 2021 at 9:06 am, Carsten Bormann wrote: On= 2021-02-26, at 20:58, Greg Dennis wrote: >=20 > It's my understanding that Slack backs up everything so that WHEN you dec= ide to pay for it, you get all of your "lost" history back. That is not answering my question.=C2=A0 We need to have backups that are i= ndependent of the vicissitudes of corporate odysseys.=C2=A0=20 Gr=C3=BC=C3=9Fe, Carsten --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_170619_456851359.1614370476962 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's likely the extent of backups for Slack.  I'm guessing that you'= re dissatisfied with this, which means that we're down to GitHub.

However, I would argue also that not all con= versations NEED to be archived.  General questions, like those which a= ppear on StackOverflow, occur in the Schema Slack ALL THE TIME, but these d= on't need to be archived.  We also use it as a space to work out detai= ls of new features before publicizing them.  It has its place.

Greg


On Sat, 27 Feb 20= 21 at 9:06 am, Carsten Bormann
<cabo@tzi.org> wrote:
=
On 2021-02-26, at 20:58, Greg Dennis <gregsdennis@yahoo.com> wrote:
> <= br clear=3D"none">> It's my understanding that Slack backs up everything= so that WHEN you decide to pay for it, you get all of your "lost" history = back.

That is not answering my questio= n.  We need to have backups that are independent of the vicissitudes o= f corporate odysseys. 
=

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


--
Jsonpath mailing list<= br clear=3D"none">Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath

------=_Part_170619_456851359.1614370476962-- From nobody Fri Feb 26 12:28:09 2021 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 28BC13A16B1 for ; Fri, 26 Feb 2021 12:28:08 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 fWgwPgeRA_m0 for ; Fri, 26 Feb 2021 12:28:06 -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 14FC13A16B0 for ; Fri, 26 Feb 2021 12:28:05 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnLnc3532zyVb; Fri, 26 Feb 2021 21:28:04 +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: <1157333423.170620.1614370476963@mail.yahoo.com> Date: Fri, 26 Feb 2021 21:28:04 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636064083.809738-4dd68a8f00685c88655429204f65994d Content-Transfer-Encoding: quoted-printable Message-Id: <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 20:28:08 -0000 On 2021-02-26, at 21:14, Greg Dennis = wrote: >=20 > That's likely the extent of backups for Slack. I'm guessing that = you're dissatisfied with this, which means that we're down to GitHub. We built something for (the non-git parts of) github; we might build = something for slack. I=E2=80=99m just trying to find out if there = already is anything we can use. (We created a whole WG for understanding how to use github in the IETF; = we might want to do the same for slack at some point.) > However, I would argue also that not all conversations NEED to be = archived. General questions, like those which appear on StackOverflow, = occur in the Schema Slack ALL THE TIME, but these don't need to be = archived. We also use it as a space to work out details of new features = before publicizing them. It has its place. I don=E2=80=99t think that works. Before long, someone will claim that = issue X was discussed in slack and doesn=E2=80=99t need to be = rediscussed in the archived media. Or, worse, some key people will have followed that conversation, agree = on the archival media, and the whole background is lost when (not: if) = slack experiences the next corporate upset. Writing specifications in an IETF context leads to a surprising need for = longevity. I only recently spent a few hours digging out some detail about RFC 3095 = that we nailed down around September 2000. Fortunately, someone had = pulled a copy of the archive on a mail server we used at the time (most = IETF mail has since migrated to the IETF). Being able to trace back discussions to an archived context is core to = the value of building standards for decades. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 13:42:21 2021 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 B15623A0C5C for ; Fri, 26 Feb 2021 13:42:20 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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 (2048-bit key) header.d=yahoo.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 MEiDB1upGBp2 for ; Fri, 26 Feb 2021 13:42:19 -0800 (PST) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (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 CCFF93A0C56 for ; Fri, 26 Feb 2021 13:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614375736; bh=LiqqnKD76NsjiY/FhIMwQEik/mxpaBgwItOjMSoxOII=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=WAtqA9wv3jdPJBSMQF6zJZvHYVrfjzE53OGnyQ5gYyfZWSMMrMXc14NTIl44TFqmt76KeuTmzT7ha77RLNRdy0WpCY+D1rVjMPqLCPyAqpuQ1IODiejlP5hOwagfaRFGoWWKX28U6H/uFFsmkvAxoPwE/jiFJ3THeNapQnHyox1Ag8qDbxEpUKTfz/oEXCw3Fxno5T3pN0p0K6GZ4bmC0NHRQ9RYNLDD/DWcJw1P7s5jiRpayOpT/0lOO/g93T6GuyibYaN53NpiqDtmkq70fMhozjkH2uM7pArJi6GwAddu4yaw2yOqhW/dWqNP28r5ADX1IxE/8Dcl3fCykszBbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614375736; bh=afZqB2RrsaHbZR9TDu8DN91IurmjRCsTpHjCgpKUkvm=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=V5I5i84npJEmNII5uQrMchUE4PgQGkwuaeThMdZ5eOtEnwiJKoGp0YPH9FUjB13KU5O4Yv8IeGeu3Z3NN77B4Nt2mnQHdHRsesew/IzbT3qonhfcU+sPhDId7R01QqLpPeEDW+xvDHZDevKEiNiNIHyq7udMmLfOSEbjS5gARt8umsQWP+PtCGFqgo4ZlZtyzHCITRcjV/V1SiR/wksseUG5RsiSz+S/NOmO6FHb6IE/cB8Bu7aRwSE4XFNzbNl1rl/devik9EOjoS/ZqGJ0WnAYLyRuqyC9Io2SpZjvl5ZeNOFMj3GqTFuxmJaA9YcRL89BAUAr5A1oZFRbmcAeCQ== X-YMail-OSG: m3IT7vQVM1lLfgrtLYn271czUMeprKKCAyKAZV2lmymDHPZjI0fl4ruX582tz4s SYJmy_d5lGqMr5IGpEYF5xHuOXQ0k.48gVoEqMvM0OmR2fyIrj82W19K5QW9MTX6i.dTvxxCzXip Twl7Zbnk1Yk8Fr.w7uHA7IbWlMkzkMUL_8cgMbHAN3NFbYlnlTNKbwfgZejLVsT3Pav1zlJuhhrz nAMu5qmHm0qbbd4zQeGPtrpJbdz0xwFKfjx.rzd.9LXE4aZxAbijwwJ77UiZz2mmel.fqXy3MX1d REUw4Sj03ShJLLJqD7FMJrGeuhMQOwYR8.rzRz68UqjL4CGn94STlmEMf6pP.eM63pm_Cu0NWNPS mwJBMaYS34DalVCm6AQnJ4FSU_arNktEI.GrDEbaX1gFv97xTwNmwO_obYcDvPS5_aR00PhDf4qY 2RHTx6i_O_U589biu4wVegSJAS5oWxdA0u5GNOa9k.B8eLmFr7MzLZe.fQTx2OrmYEorLxcMXsk. Q6lD3MwZmjA_2id2BukytwBkG2dLkI0LODVE3wBCGhPWtjqc1sm6PagsVIKGBueRrCJl_rOF0ZYB BpMbghCNCePMuvF_IcSY0gKajczXx1_LVBKc5jgLK.Wyk1FYNSQpn8sFYyrQwr0zs5GZIrLn5GU3 fEQWND4_._70UrtzjPUoIciut9ocMUL0k5Dfur1Gdt_9e4P84xRlNZAYWyp2Pey3WrAWdMF.iKaW KubVbay3BB49jwW0Vgf0dEwMgzfvKhM8wQ2sGUYGwz8tsRhbqrMkLEF7ZPQIo6svff80Samf7mLW .eePgy_aAi1f.WkdvkyPidAOW5a7upEpDpOR.XrRPNs2O8m9GkfaKdEUhWNJxxWduyT2pEmW_zHD .kh.COb.c2JRrSy7z.5FMYoHKILeUQ9mAnVIeKg6Atk.PGPnE7_CfUDovBifaJF.MhPfW5vBk_uK aDqu5TUPJKZRFJFWBhcOJIFXnVy4YkrBJP0qqtBhBGPoIddK_ly6mkvLolwZ.rT0NflfUSVCG2A7 D8ijEHaH4nVu15gEJ2aj6wTJnzpaWdo_41_giQRtQ.WMblm69pCI8XlzkWeYzLiN7EBiAKU0C9x0 VUR.nFQNgwshuV.9Y1jLDX_xPiWLYaGNYf8vZVsNnyVvWKKP_knsn3YlrWAaP1WUnKQW88.C20he BbwWd6LUmHZzgYFoKbz_pVdmXb8eXGI2LtGGwOkqY4KECthJ3D_lYfoTX8VTS4xmn.JBjODGrUul pKzHtb6gv2VkLBy2aFfW_eMLjtAQYk7ap.Y2_CzBOF4ThAIoeNzcqVAyCTgL7UfkvbIuiUhEZ.jV fS94GXgwSaERlq__VIt16Q5L2V11lPHyLMxuZr6gnsc3.KTq4I5smXf8VbIw1LVESUlAtMnfa9gc mpiPiwMHWZ4jEG1vtMin9.wP6wpbCmmLAmSBlyb.T2lGvfDCGY9pvpJ1OGBj2jZ3w5XggEe7WY.x AygpOyZHlQ7NVwscQoF95GyodxZCj379PW0A8Ztq5g3P6cIAmgctAf62XEjA8ZNNnOFT_K2Xis1v _jPJk3Ere1Sh_3Uw5Koj48nCHuCXHx0OyQKdq93Z8M7brUKD3Wmz8Smzdkts0IZwiy9B8jTzhADn 4U.itif6rIKyfJ98oU8OZhs0aYF3tPh.sbB8y2aOiUE06wkBJs7Y46ImV4sizRhySgN5WLyqMg30 _meqgRDXgatjNvA8_vTSf76AN0BbBp2S2xRC0.aIwf0iNWJfYtv8EZM04k_OwsR9Y.HZa6mtm28c .O05WfLK4We.T7MFum18vdtr.f_zoIXlFzyaxXI3GdTDkgx_sjr.T5TBfrtXYUq4c9PtIRE_And. 1eiRCpHvovcQUlRsBgUc0tR5Jg7pK_n2CnKeSW9UiH4oVJUd.W5ouaARlIjNJOl.i5NOjhzVDXsy MAcqcwiuush3YFn7y5Sb1Cgt81XyYg1dbMA70aevpedyafUtGQAxAZ5JGtAAJMTgt8yFy4JFTPOl vIumWHRNxItUxkzPaa7qYjNWGYY94GJ7X4VaeoeOXOu7XyfoIeSWWnVdxangYnAKOrGizU8phmV. tb28UpyemmDYeSFLgf6Ogub7RLbfz0paB5xC21P_hCeIPD.Ls7f_cWbvZ4kt1AzKFj9qUKMG5IYg L2xwsXA0zYVzRebQJbEY44i7Q43w1HtoYy3oQ_8BRoq6aa7qpQPiQpt07Y7z_wkXVruX_G8JJP6y tJTU.VN8Tugo5wInAe9ddTXXnFKInv_yrhoKpfFjyYp4.mgf_vRaYbCSzmYumw2TqCUnpdYM1nuT qo1lILF_zHI02JOq_8erdjwd4ZupnyE8T3VVkx3jrfJVl0ldDMGGLn4SLdKg1peaVPW5gX0dIlr1 YsmmIB6OWUhNOUz31XIjsUfHyFrlyayzB.Q0hpxQd.JuAIziuzN8AG39z4.fvR2dWQ6_GtL39frD IV3TpUXvmW3M4me3Owm_LAT4uR3l2pwYbg7JJc2cO2_hk4KcBQJw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 21:42:16 +0000 Date: Fri, 26 Feb 2021 21:42:12 +0000 (UTC) From: Greg Dennis To: Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <2126411059.183763.1614375732675@mail.yahoo.com> In-Reply-To: <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_183762_1262056885.1614375732672" X-Mailer: WebService/1.1.17828 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 21:42:21 -0000 ------=_Part_183762_1262056885.1614375732672 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > I don=E2=80=99t think that works.=C2=A0Before long, someone will claim t= hat issue X was discussed in slack and doesn=E2=80=99t need to be rediscuss= ed in the archived media. It hasn't been much of an issue for us in JSON Schema.=C2=A0 There have bee= n times when I'd have liked to find older conversations, but it's rare. But also, if I email you directly, it doesn't appear in the archive.=C2=A0 = We could have entire conversations and discuss decisions that only appear i= n an email chain between us. Furthermore, if I just need clarification on a topic, I don't need (or nece= ssarily want) that publicized.=C2=A0 It's much better in a medium like Slac= k.=C2=A0 (If that conversation leads to a change in the spec, then that cha= nge should be discussed publicly, possibly quoting a non-archived conversat= ion as necessary.) Lastly, in my experience conversations can become quite heated.=C2=A0 This = is stuff you really don't want archived as much of it is unhelpful. The difference is that we want discussions that can influence the spec arch= ived.=C2=A0 Anything else is superfluous.=C2=A0 If we make a policy that su= ch conversations MUST be summarized (at least) in an archival medium (here = or GitHub), then both of our conditions are satisfied: you get archives of = the important stuff, and we also get an easier comms mechanism. Greg On Saturday, February 27, 2021, 09:28:12 AM GMT+13, Carsten Bormann wrote: =20 =20 On 2021-02-26, at 21:14, Greg Dennis wrote: >=20 > That's likely the extent of backups for Slack.=C2=A0 I'm guessing that yo= u're dissatisfied with this, which means that we're down to GitHub. We built something for (the non-git parts of) github; we might build someth= ing for slack.=C2=A0 I=E2=80=99m just trying to find out if there already i= s anything we can use. (We created a whole WG for understanding how to use github in the IETF; we = might want to do the same for slack at some point.) > However, I would argue also that not all conversations NEED to be archive= d.=C2=A0 General questions, like those which appear on StackOverflow, occur= in the Schema Slack ALL THE TIME, but these don't need to be archived.=C2= =A0 We also use it as a space to work out details of new features before pu= blicizing them.=C2=A0 It has its place. I don=E2=80=99t think that works.=C2=A0 Before long, someone will claim tha= t issue X was discussed in slack and doesn=E2=80=99t need to be rediscussed= in the archived media. Or, worse, some key people will have followed that conversation, agree on t= he archival media, and the whole background is lost when (not: if) slack ex= periences the next corporate upset. Writing specifications in an IETF context leads to a surprising need for lo= ngevity. I only recently spent a few hours digging out some detail about RFC 3095 th= at we nailed down around September 2000.=C2=A0 Fortunately, someone had pul= led a copy of the archive on a mail server we used at the time (most IETF m= ail has since migrated to the IETF). Being able to trace back discussions to an archived context is core to the = value of building standards for decades. Gr=C3=BC=C3=9Fe, Carsten --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_183762_1262056885.1614375732672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div>
&= gt; I don=E2=80=99t think that works. Befor= e long, someone will claim that issue X was discussed in slack and doesn=E2= =80=99t need to be rediscussed in the archived media.<= /span>

It hasn't been much of an issue for us in JSON Schema= .  There have been times when I'd have liked to find older conversatio= ns, but it's rare.

But also, if I email you direct= ly, it doesn't appear in the archive.  We could have entire conversati= ons and discuss decisions that only appear in an email chain between us.

Furthermore, if I just need clarification on a top= ic, I don't need (or necessarily want) that publicized.  It's much bet= ter in a medium like Slack.  (If that conversation leads to a change i= n the spec, then that change should be discussed publicly, possibly quoting= a non-archived conversation as necessary.)

Lastly= , in my experience conversations can become quite heated.  This is stu= ff you really don't want archived as much of it is unhelpful.=
The difference = is that we want discussions that can influence the spec archived.  Any= thing else is superfluous.  If we make a policy that such conversation= s MUST be summarized (at least) in an archival medium (here or GitHub), the= n both of our conditions are satisfied: you get archives of the important s= tuff, and we also get an easier comms mechanism.

Greg

=20
=20
On Saturday, February 27, 2021, 09:28:12 AM GMT+13, Car= sten Bormann <cabo@tzi.org> wrote:


On 2021-02-26, at 21:14, Greg Dennis = <gregsdennis=3D40yahoo.com@dmarc.ietf.org> w= rote:
>
> That's likely the exte= nt of backups for Slack.  I'm guessing that you're dissatisfied with t= his, which means that we're down to GitHub.

We built something for (the non-git parts of) github; we might build = something for slack.  I=E2=80=99m just trying to find out if there alr= eady is anything we can use.
(We created a whole WG for u= nderstanding how to use github in the IETF; we might want to do the same fo= r slack at some point.)

> However, = I would argue also that not all conversations NEED to be archived.  Ge= neral questions, like those which appear on StackOverflow, occur in the Sch= ema Slack ALL THE TIME, but these don't need to be archived.  We also = use it as a space to work out details of new features before publicizing th= em.  It has its place.

I don=E2= =80=99t think that works.  Before long, someone will claim that issue = X was discussed in slack and doesn=E2=80=99t need to be rediscussed in the = archived media.
Or, worse, some key people will have foll= owed that conversation, agree on the archival media, and the whole backgrou= nd is lost when (not: if) slack experiences the next corporate upset.

Writing specifications in an IETF context l= eads to a surprising need for longevity.
I only recently = spent a few hours digging out some detail about RFC 3095 that we nailed dow= n around September 2000.  Fortunately, someone had pulled a copy of th= e archive on a mail server we used at the time (most IETF mail has since mi= grated to the IETF).
Being able to trace back discussions= to an archived context is core to the value of building standards for deca= des.

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

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
------=_Part_183762_1262056885.1614375732672-- From nobody Fri Feb 26 13:59:27 2021 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 234DE3A0C9D for ; Fri, 26 Feb 2021 13:59:25 -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 gy9lqXdYRRkX for ; Fri, 26 Feb 2021 13:59:21 -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 1007B3A0CEE for ; Fri, 26 Feb 2021 13:59:13 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnNpl5cMszyX1; Fri, 26 Feb 2021 22:59:11 +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: <2126411059.183763.1614375732675@mail.yahoo.com> Date: Fri, 26 Feb 2021 22:59:11 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636069550.4910049-f1be1337a72b58d89ecf5f986b88eb8f Content-Transfer-Encoding: quoted-printable Message-Id: <83EA4040-0E7D-4DDB-AF2C-DD8DD59B22B3@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> <2126411059.183763.1614375732675@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 21:59:25 -0000 Hi Greg, at this point I=E2=80=99m going to stop supplying additional input to = this discussion. I think I made my point why it is useful to automatically, effortlessly = archive the WG proceedings. We have a lot of manual =E2=80=9Cpolicies=E2=80=9D of the kind you are = suggesting. Of course, they are not working. Why should they? I did not provide an opinion on using slack (just in case you care: I = personally don=E2=80=99t like that specific tool, but the WG as a whole = has to choose mechanisms it is comfortable with, and I don=E2=80=99t = want to rain on the party of the people who do like it). This is for = the chairs to decide. I=E2=80=99d still need an answer for my question, which is whether it is = possible to maintain independent archive copies of slack discussions. = Maybe we can find out from other IETF groups that are contemplating = using slack. Gr=C3=BC=C3=9Fe, Carsten > On 2021-02-26, at 22:42, Greg Dennis wrote: >=20 > The difference is that we want discussions that can influence the spec = archived. Anything else is superfluous. If we make a policy that such = conversations MUST be summarized (at least) in an archival medium (here = or GitHub), then both of our conditions are satisfied: you get archives = of the important stuff, and we also get an easier comms mechanism. From nobody Fri Feb 26 14:23:35 2021 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 C7DC33A0DEA for ; Fri, 26 Feb 2021 14:23:34 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 Ymuu8Wt93F2a for ; Fri, 26 Feb 2021 14:23:32 -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 62BCB3A0DD4 for ; Fri, 26 Feb 2021 14:23:31 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnPLn65nCzyX1; Fri, 26 Feb 2021 23:23:29 +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: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> Date: Fri, 26 Feb 2021 23:23:29 +0100 Cc: jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 636071009.340467-b9d85c04dfc6f38f42561e68e52b097a Content-Transfer-Encoding: quoted-printable Message-Id: <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> To: =?utf-8?Q?Stefan_G=C3=B6ssner?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 22:23:35 -0000 Hi Stefan, > On 2021-02-26, at 19:30, Stefan G=C3=B6ssner = wrote: >=20 > Hello List, >=20 > It has been important to go through this list threads carefully. Great work, thank you! (And thank you for doing it in markdown, which made this collection of = various inputs quite readable.) I think there are a few cases where we have strong consensus and just = need to update the document (issues will come up when that is done, = because writing things up brings issues to the forefront, but it = doesn=E2=80=99t make sense to discuss them before draft text is written = down). The issue of =E2=80=9Cduplicates=E2=80=9D, collection/selection etc. = really is one of defining the processing model. (A *model*, so not = unduly restricting implementations, but guiding a common understanding = of what is going on nonetheless.) I=E2=80=99m still troubled imagining = a processing model that has all the properties that have been brought = up. So maybe we can focus on this for a while, maybe based on strawman = models that people bring up =E2=80=94 but not just by simply listing = desirable properties without knowing how they fit together. My 2 =C2=A2 for the moment. =20 I know that I need to ramp up my time budget for this group again=E2=80=A6= Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 14:42:48 2021 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 AE9583A10EB for ; Fri, 26 Feb 2021 14:42:46 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, XM_RANDOM=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 8JO3q_9VmY-S for ; Fri, 26 Feb 2021 14:42:45 -0800 (PST) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 183A23A10DA for ; Fri, 26 Feb 2021 14:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614379362; bh=EQIPBt2qqVvcgw2QQBIZAdiTpNgTlaU15UyhfB/UxN0=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=oayyQpW3bsJl+T/RFnS03DLfIx0OGVaX6rNDhsgs92Qh3lVBlfS62GC/JfEA17SlQLjqlesj28k7jBKEBiOpHkKiA2c2rVyHXIID/lRLI6RDXgnJ8jp++b24fIfeAJXZrZfz6WdLGnUWTpLAhc1L/PoZiTVNAor/1TuQrHn838I7WjLPBHMSqO/GmfOjBog7Dmq1l5lBLvSctobyAvZTlr8jXmnlgnQeAn3lXIYIArvJRHok47Dup26/vqCzuxLoiLjdM+XBBJDXAHxbwG05ZhrRqjZT5UHXIKSXP8a6TXb7HQOmEsL/LUcb7RFBgx5u2R8+CiW/d3u8yXtb2UeZjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614379362; bh=LWiGKNMTK0vwSu823Cz6tMSr2vgxV8RlBJTWFdw/10P=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=hxRdOFoNrEfzSbv1Cd5CjvuTYANiQZSvlAzAjwqdvPXTLyT1rS42AbMRtLhkuYCwOHChk3qw/idRQQ8LuziTMh1R0BV8V/RM4UOLUSol6E2ZvOaQQmjBeS6+j1/7KJNlkOi1L1R1KSzmTijll3DLh6dgDq4MVyRyFhQCmBGpIHFlwt9TxFPoQjOlc1kaiqAungDGdbHLGNOhXseTbPlcwDDAhu47XwK4G36lFqdZ7wVvdAzh8f4g3O6qzaSMAx5sGdxGxd+F9Nnv/cdVuwO9uLAnE/yokMkKslVVz3edr8yN+zqkfCqde0b37nkYbDOMuVY9n9ctF27KkT8hJ1F5oQ== X-YMail-OSG: r60gJ2oVM1kWT706QTlWd4B0yOUDurWnuOdFxjR03cDbxE2Sfp62iyclxF7I54e RLmpJfV5f77AloK3ZCWKs56wtQKlbnqEBKZp2SylunF7zCRlmbEjQobHWBOncFKB4aq4.YKHCYkG OBVt8zxCKs4TCivuqxLGbUL9hT3u2tJ8z8eHs4BqQpIHuxd3Ad9XGPYbiZdmAyRcskaMNt8TuXGT J6ClpfqPZ8h7qIaCosyuAYz4A8saopFwRi.li3dx7U3R0HNu.Wwv06fJdPr7SnNJ.gzFy82QGHXh fDTPwxnXJXQWX96zlz_GUJq1wOtz2Uiwhcd9YGZVyOtooQqogupSxnIlFv72IwrO71raMXDqOqfs Ie8mWfBRYzlGVn1VCUxuTyZcZvKdWiUkeuQoQdV1WslnQNZCXYAGDyAUn1AQ_uNuoEMeDFXjFSDR TtA4lI6ZGy_0iiTalJ7JUtOIPnTXMJNsOrnjDccb3dmqaavXmqjimkHpXWjAeWBHie10bvClWSJ3 SvAjLcZHMMJoGJaQKa5S6MweFf9pflkux_vzjDcVO6u9brmt5r.EZPwzql_RInm4sZETLHWhi8m6 SxolIxCwC_GQJmM2yEL2jA_zuyiPrsw_rGK2GuGMAVITQLtPuJbB4WGWjgiuRsUaGx7gTcygT3op vdWSNAiAqsRLOnPRWXfoHwkZgMyMglu4wNqAqoqbZeiKuhFe20dmAY3CnG7KsOThNyYjT1pGNh0u YlvFHMKFPVE9d0u0ipTRJ3csCuAV4UvvM_RQZOolpHUOqVaThs3zu0GNhCw88kr7oOJ4H6yGqWyj z0AQHM3kBgAaAoxAXEeS7Gw5RSVy5C1kivOPk6pXCkB9.ZAl9mfgcoLOEktc0kVgp5zclES_MJCK WFh5RpZCok6RmvN4Rhpk2iyW42n2Nk_eatHSvXd_fiwvjPaRjZLX2dhCU7x4Ui1FRyqc79QoinEb K1_0v1WAVoTC_SzClOodEj55n3IpKWdc0ndi5RTEXOoi6XoJEYPiCUTlA0YfY7lOsCUwJEC1IwA. eWyt0eX_ID2pSxb7DCFeST0SJjdJxLUlkHTiJtptG0F_uCps9laZkXwb0pJuc1yzMk5iUfQdio2F TzKLv2a9L5JoeauVvS58O9HDL8LHRwJMSwzp6HhQw3_1SCm0oqD_RPGT9aH8.mcQhSag_G8hPBrZ 8ME1TOhnot0kUsZJ5jxzPkjaXQragixBuUqTcoD32CjsTC3qETWOJ7QxL7k4.3wfWZFztglIlQ5B kCTnWrgSPY0amIJuX_D36jkkTizPV8KEabb4w1xIJ9QFyzNGTjwQukfW6qqbNOhT29rJrVCPNHNW JNOOs6TMPY6gEIl3WFz8U1DT3wVlfADIfesVNM4BsmTetB8E1AJpiG.7smIBE6jaFSYMZc48mjQ8 cPib_EqQB3RHu1HDRrP0y6ffWaISiBFkoLosBJ9j.O0qbe7VqjzMka4AyR0n46ku_fql9EdsfvKG bRk9cCMDsdkzHac.KDqZ_B96b9V.notRrwgWf2mAs_MhnQB494r5wrySrDUHdvTv4KziNtIJhw28 e1j0cOsYp2_8YV039fGv1g4QWtqv9OGOV0vJSWz88wz51geY2wEEFyF5bKCPMd6A0yl8.7tQeAJB oLBK.n63mrRoL6PCpNE4HOT.AjNNVEv_y27HxGtRS7MFqQvkHr7WJfi_oBccjNqIBgKM0a.dUhtx nE.s86jiCp_gckoq.iekOSLLLjCLRaxIZCfK602dGdQWmPIbFPoBM.4s2Th.bvDjIbK9vYboxIWl HizOg18pvysgzXIqLai6qtN5IdN019Q_94jLuPYh0L5BtuH.M9YMxERzXIsyD1skSQIji3W8HqH6 T.SrerP3VYiVv9zHicBgsS4e5p_u_mES2IPiJ_l7JbdNnJkn1xKflayAEOMuz57wK6fax22_7547 zEzPOYzz7fEW2pdh0TCN5Hv7Mezsc4d24dYt11OYUGW28zJRX48sHJ85Wwa0ic119Xq9wv3BtsxY XpPKzY29Nt2xoqj2zuXgdX03xMu3lmq3luxS1UTL3qAbH9z.qOs8GsU4bJatRLNvmN5PsxfObtib FNmTquluWokKuEeQC8EgVGtiGKycG2HpU54cs._VI3ekHsKQ5XI_eE0eH8iqNUdwzr81PcPFAJ3P 4I0aNeqN8ZLsPRE4vgv10RC2pDt0mUnFH0EtM3ltcmoRL.PKS3caUuv8bEUqSi3Mg67qevg6zr4Z 4slfku2FM21TdNc2p2wwfWTRrJ5C9szToc6sAcvxl2DwcFfL4m_uAn_CZX3xghZYw9jLdOCS5Mxi _5cvjzsTPinOCm3GdvYEDg9kn_1aiyEFt26un7WbGHJUZRVhwSJVNlp1xptjVWFmkZQwrshjXinB lYdoby7vYxHH60p4k261ZzvM2xwvjLuy28vHrVSLNB29dqu6rE5XtDBY_RoNQ0_2cfIwud7dzl6w vd0hsK.fvblqIxa7t4eI9EWxYBtvIwnQJyM917eH5omlqAglijD2SXNawdGg.UBmnAqDwW_LZZeQ L1YFqGIUHJMyQ9P0z0.2F_7ptYyAXX.RmcKlM0nqWxrRfef.r9p2H5THdnMq3eOGd4TIxCM3W962 SdBIa6MZTxiCUIuyZ5h1N5FZPF646zQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 22:42:42 +0000 Date: Fri, 26 Feb 2021 22:42:32 +0000 (UTC) From: Greg Dennis Reply-To: Greg Dennis To: Carsten Bormann , "jsonpath@ietf.org" Message-ID: <2033972809.167421.1614379352024@mail.yahoo.com> In-Reply-To: <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_167420_1984408882.1614379352023" X-Mailer: WebService/1.1.17828 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/6.19.4; Android/10; QKQ1.190716.003; OnePlus6; OnePlus; ONEPLUS A6003; 5.87; 2087x1080; ) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 22:42:47 -0000 ------=_Part_167420_1984408882.1614379352023 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's the copy in the primary branch in GitHub the current state of the spec= ?=C2=A0 If not, where can it be found? Greg =20 =20 On Sat, 27 Feb 2021 at 11:23 am, Carsten Bormann wrote: H= i Stefan, > On 2021-02-26, at 19:30, Stefan G=C3=B6ssner wrote: >=20 > Hello List, >=20 > It has been important to go through this list threads carefully. Great work, thank you! (And thank you for doing it in markdown, which made this collection of vari= ous inputs quite readable.) I think there are a few cases where we have strong consensus and just need = to update the document (issues will come up when that is done, because writ= ing things up brings issues to the forefront, but it doesn=E2=80=99t make s= ense to discuss them before draft text is written down). The issue of =E2=80=9Cduplicates=E2=80=9D, collection/selection etc. really= is one of defining the processing model.=C2=A0 (A *model*, so not unduly r= estricting implementations, but guiding a common understanding of what is g= oing on nonetheless.)=C2=A0 I=E2=80=99m still troubled imagining a processi= ng model that has all the properties that have been brought up.=C2=A0 So ma= ybe we can focus on this for a while, maybe based on strawman models that p= eople bring up =E2=80=94 but not just by simply listing desirable propertie= s without knowing how they fit together. My 2 =C2=A2 for the moment.=C2=A0=20 I know that I need to ramp up my time budget for this group again=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_167420_1984408882.1614379352023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's the copy in the primary branch in GitHub the current state of the spec= ?  If not, where can it be found?

Greg

= On Sat, 27 Feb 2021 at 11:23 am, Carsten Bormann
<cabo@tzi.org= > wrote:
Hi Stefan,

> On 2021-02-26, at 19:30, Stefan G=C3=B6ssner <stefan@goessner.net> wrote:
>
> Hello List,
>
&g= t; It has been important to go through this list threads carefully.

Great work, thank you!

(And thank you for doing it in markdown, which made this col= lection of various inputs quite readable.)

I think there are a few cases where we have strong consensus and just = need to update the document (issues will come up when that is done, because= writing things up brings issues to the forefront, but it doesn=E2=80=99t m= ake sense to discuss them before draft text is written down).

The issue of =E2=80=9Cduplicates=E2=80=9D, collecti= on/selection etc. really is one of defining the processing model.  (A = *model*, so not unduly restricting implementations, but guiding a common un= derstanding of what is going on nonetheless.)  I=E2=80=99m still troub= led imagining a processing model that has all the properties that have been= brought up.  So maybe we can focus on this for a while, maybe based o= n strawman models that people bring up =E2=80=94 but not just by simply lis= ting desirable properties without knowing how they fit together.

My 2 =C2=A2 for the moment. 
I know that I need to ramp up my time budget for this group again=E2= =80=A6

Gr=C3=BC=C3=9Fe, Carsten
------=_Part_167420_1984408882.1614379352023-- From nobody Fri Feb 26 14:47:37 2021 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 4B3EA3A11D3 for ; Fri, 26 Feb 2021 14:47:35 -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 q1c8xzPssbHE for ; Fri, 26 Feb 2021 14:47:33 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 1FC9E3A11D1 for ; Fri, 26 Feb 2021 14:47:33 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id h98so10041098wrh.11 for ; Fri, 26 Feb 2021 14:47:32 -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=IsrlIh7nrUcmnQ0og+CI54xWFqBsW0y/nOH1HrXXW20=; b=Yl2iJ3foZStWKEf3ymduv33JyZFoQ3ywuyF+lwMVdGi3k+xrJosr4J/YjJmraPt7dx Ae9ROKASHzlhwtLYjgPPW0C5q3LT+V1Sj+YdaNLw4hwuni0UYxfrTHHMDR/D1rhxmNNi jsEe4m85ZecxzW9BOOoi9Wvv3ihBmuMywT3rGWLJWRLZWad9WgGZ+Ba5l3NoG1+O6VJj eeSPdgFg5N5CKrNfG9frLK1gZtMWmBdcEZipHvoesZY2RHOfzvo+HhGXhx6Rptz59F5q 3IzavOz2bLucrTRNlt+9IzKbWlmGNB0GmVo92KckvVVkdX3J+lGmIvnbD6x+9v2oUVUl h/jQ== 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=IsrlIh7nrUcmnQ0og+CI54xWFqBsW0y/nOH1HrXXW20=; b=dNqHSFLvnZfXoee59g/hnDGMGv+uJUQzvW8HmXVk8ZPik6hfUUzpsiwU0Wv/c/ICKf yjpb7EMNwF6ddI9wD+AjsxTsUe2CjqDeswCZqqCjgwU/73zrSA5RkpP8PR9dxNoV6RYD POOPFRsZlpkLOIdMIwjYWSRqBsIVeX5ujGaBis6Z5XppaoQ/TXwn4sjqj0xhpg56krgC +6LMHIhLcr5JtPPRXrWFmRtFOS8Tjl1+KgDei27qhbQWo81RKrAiGjybSSK7c3T22GF8 ARjqBZgr216Yc1SmNmznorB233jxplLNwilThmxjGgqS8WsxI/1cYI5F5XBw+Sv6/r+9 WoTg== X-Gm-Message-State: AOAM53244aJUXMbhxJ7LLTDXWCpKLLMO0bHTYj1MuWVdUqjXOtGDaQeu Mwt/b7ULaBjLWdgoZz8bpaHPgfZc1Gk8u6+Jh0H07WHNNKZqRA== X-Google-Smtp-Source: ABdhPJy/OCzzXwBdj6C15UHG19brPv5gi+WBnm8z6ypyKUQBETQI078NY0xIAlomox6Tr0NTmf7RaFckdQq2Cn9/bfE= X-Received: by 2002:adf:f0cb:: with SMTP id x11mr4025064wro.206.1614379651153; Fri, 26 Feb 2021 14:47:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Fri, 26 Feb 2021 17:47:19 -0500 Message-ID: To: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jsonpath] Jsonpath Digest, Vol 8, Issue 4 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: Fri, 26 Feb 2021 22:47:35 -0000 > From: Greg Dennis > To: "jsonpath@ietf.org" , "Stefan G=C3=B6ssner" > > However it seems that the MD formatting ... has been lost > I feel that email is probably the least ideal format for conversations li= ke this. The thing is, we have a > wonderful GitHub repository (https://github.com/ietf-wg-jsonpath/draft-ie= tf-jsonpath-jsonpath) complete with > issues and PRs, mechanisms that are specifically DESIGNED for this sort o= f discourse. Agreed. Also note that GitHub supports a Discussions tab that has been enabled for many projects, see e.g. https://github.com/WebOfTrustInfo/Community/discussions. The Discussions tab supports MD and is ideal for collaborative threaded discussions, allowing the Issues tab to be reserved for referable issues. Anyone with access to the gh-community/discussions-feedback forum can request that a public repository be enabled for discussions. Daniel From nobody Fri Feb 26 14:52:50 2021 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 7A5563A124C for ; Fri, 26 Feb 2021 14:52:49 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 pHjqQ9TNRF28 for ; Fri, 26 Feb 2021 14:52:45 -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 A24033A1245 for ; Fri, 26 Feb 2021 14:52:45 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnQ0R3jYxzyXV; Fri, 26 Feb 2021 23:52:39 +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: <2033972809.167421.1614379352024@mail.yahoo.com> Date: Fri, 26 Feb 2021 23:52:39 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636072758.913331-cee6e5352272de2822f4c0bf3d076770 Content-Transfer-Encoding: quoted-printable Message-Id: <8E187A2A-3EE8-46E0-8737-272B1F3D267C@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> <2033972809.167421.1614379352024@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 22:52:50 -0000 On 2021-02-26, at 23:42, Greg Dennis = wrote: >=20 > It's the copy in the primary branch in GitHub the current state of the = spec? If not, where can it be found? There are various levels of draftiness. In increasing order: (0) RFC (which we don=E2=80=99t have yet :-) (1) https://datatracker.ietf.org/doc/draft-normington-jsonpath/ (The =E2=80=9CInternet-Draft=E2=80=9D, i.e., the official WG working = document.) (2) Main branch (previously caller master branch) of WG repo, https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath (The markdown document is the source, the other files are generated = versions. This hasn=E2=80=99t been converted to Martin Thomson=E2=80=99s template, = which keeps generated versions in a separate branch so the main branch = can be clean.) (3) The outstanding fixes in PR #46 https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/pull/46 I could continue hacking that PR, e.g, based on Stefan=E2=80=99s = summary, or the authors could merge it and then we could have separate = PRs to implement the items listed in Stefan=E2=80=99s summary. (I would = prefer the latter, as it is less work for everyone.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 15:29:16 2021 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 02E363A0EC1 for ; Fri, 26 Feb 2021 15:29:14 -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, HTML_MESSAGE=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 (2048-bit key) header.d=yahoo.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 VqDRGNNEkG3L for ; Fri, 26 Feb 2021 15:29:12 -0800 (PST) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 9C6D93A0E91 for ; Fri, 26 Feb 2021 15:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614382151; bh=2gpuzcyiNMYK8AU/Hvcp6qBbFZc5/Tc+5kaxec0fIe8=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=dMcsRyRNueb/2G1zgMA1oZZ1mkSr7OpBEnTWJtyRP/bgpJyG5jfgOErvyjyNVcuYRwQytKMe66X8D4Uc1I4mLd8k6H30S9ApraRh8in7Z866DtX1YgKYtmYQqe2utFTXzYdhH0LJu/i0Vydz40mPsmoutviR0/sA1fO3x/vtIhS1XyxeCxo1LArfnbl9glbOCDmm5lka98mJC2m8CAohupKrhOkq+ffeIYk7XJ0Vvvgdfl6RBDvl3fWfWvxcKO0TmM3hiik74asBaiLVDET/lEXQE/yJ/8fnAxd9fhAiEPh1tq37TO+r59GAoxcBPl+KFjnAtNouFDyZUvbge9ui7Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614382151; bh=OKTg15RCoUewlu5QoDMOYJAXeeN8rTubfgOJP3Bd8sz=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Qot+GCWRoqWTMZeMU0UgjEYaKBwqcDN3OaZUKG7h+hp98Zn/Bcfx6qvkEJNIkE/QkcPpUpOnQ+aTcPlYvZRwxqwPWG663dL9WOf5km90f6tjdhjXhAMrMBSKcVYuSI580R9Lcif/EpFb5wCzWHbmZaRVIFu8Kz51xOvg9+6+tKBuAJTA4sXelZh6g9yMf6Bc941zoXfxpIzqI/lDB/WC390wkjmxb7bh5ABsrIxRc3ROBHiH8VRQ9FTb6iHy9L0SQMYjZNyq67XFFjj1Lk+i4dK0PdNpfWo6NiR6xyeR3GqK3MhZk8d2C+aldKmleGhQVACvzNq8RFrBDVkFagIREA== X-YMail-OSG: zzl7r5wVM1lBaQutK4NWHOgP96k.quGGN5vjejtCsXuDtTlQAeI5R5jlAE1ba9G 7F6HwACOf3wFT1zVhzuWWqq5a6UyjiHNGzaqbKSpooKesoVz1MxbABPkRrRp79NMyoCcCJU5OyXo Tti39Uj.AXucfeMq1RxineS0p1twLFc2A9vgqydzl7zPjiBjePLog4DE4QqYePipmssJX6nx8PqH _vluEI8vwQJKJirZOwaJaPfMBTq.hbLjJNCInYtQilAMWo0a3ZraY8LKfhdJ98vV.OzRsylXf1iY HmFlpOxUBMQ4rAZByJTogSMx4WPpHKUa78rQlkj91..ZJdoqw2i1hm1E4NhzkOI0e7cPhfV3MDCV 5YgrWLfiKfsjNldnOg6Eim.JxSRL_Yijip41KwXu0pP9TBOFD2GRtqpeiOfcV64Vl94qSBp83T3i Ta311abJAnVFVk3O_Skax8RF.xcXuy51aIFTocq1lkqKJ7QEHqJ.x3k88lwfqxO7ecqImHHrzI8I OHVGQ2CorBbWO3yuETuPdhqYjnYFj7ccsVVRfbMjGA_x7zXbzk_V8wmHgXUfkZcesv.iCXEa2xcq 8IpuKCfaTuI3iscQ2YtRlcshMiZN4DQc9cY30.lUOyQlZ4VFCrF5xKgunxUWjtxG.rUIzQNwQq47 iDqqcgVHwGZBF89hgpwe_AKbGIY22CDvuF55oLImj8jcu0lKUuyrXyo63i2uFldzKhNy5hO_lXAX KUTy76InQxyEwUJ0eHxm6Rx94zdvRehJgcJHOtkTcKHlJpnQuRnSBrQnAzzuNUm8wF_0umg98k7o PIRj8tBS3A6Vh4WkG8d_2wJIxSzZRoIJ9eUiJ1PBD0B8roUmr71n1rhC2xKjKwDP.nwB51qIhC._ WUWPcul.SJby37XhPxwMc5m904MwOIbikYGOvA_QtKqLlnH39C.TjP0LqgcRZKq.whMYaLjzTVNT giTlZFqYhCISlXZyeNQIlWpenSIUAFCreR52s0e2su8EvMMST25YYyKrVBc81U22bBtoTAzydGng fvb8J3tkPS5hE.hCFM7o08h9VQCg2o6whlyfl2pSN6q4fVdFA3eLe3xvhsNYZJWSKVX06V9d0yCq adpBivt745ZwkylJNn98wASUXNVqiamQlEE7SLFapYLX6DUzDQLy4e_SyoBVmzdTXfVpkuLW6OZq 8b.ASPzOrkBeBk_qY1Wy_WGErCBovtxQoMokj9Lle_sSG2jStkZ.bqo9CsTNTuWgNNysCwx6GXEo 9WdsUdyCMtnVhnR_fnTeqVyWUro1MBBujWkE400Clatmhhwv1.itSLlqcCQjTrw.dzltrcq0rqlS RLB1qkX5rB_afb0Es0I.Hx1_9n0EyXGgTu3cJoglDtUuEQwetYxCcPB02hNeLhMkA13zUK4fza9J EeEQ2aN_rUSIACglbBoQhVqlGLivN.l9E7z1VZJBT2la0DTTqgFkANT1FDdbnGVtLpu.nJD.baZb mCSl9RJZCqnN3280PMOERiGUBJtw1QNnxAeSvbp0bpLzVBmjIdoaDk04y33VYcVbbpnVBjH5hmWN TlS4nZBwAFe3IwToo3DF330ZyUTm5ac3F1p7dEEtkoXe3ZLOizSCwAR5Cfyd97YT1dNrScxksLfk GJ077Ql2EbuHJB_ShUpY.j9k6.WdfNyi3x_qlQfkZPcWKR3GsSvTcSx9EiezOOj7VJDbj98q88VX lqXljrWiHsDzPovrVwpZQ6dPuODP_7Vy7UqZ8MlsuKloVQ4mup3MHIQ_4amcXViDhIpPst61rsWj J6zjNc6XZ9Y8ID3uBv7V5qUKI2hqMhOgfTpvsc.Tb3X8DZlSceCSA3R90pJ6wpH3YV2xi62RQYUH WEI9.mV.1hrc_NfdlDr_WH5EdNhELHDQp40FEw5IGdW6mEEKgVOVAdbc64dBZnUvGEXJ5PVXhjAS .o2Vx.lTGypcsKXkmOLegyKSxe9Ja5D.I.qYVSVhrw8Im6.G9f05U9dImKUz4bFeMMcjulZEk4zc bBHpIAxCD_7mxpX9Xt7AwTOcUfLTB4JB4aw09OsMtJVbWY6OZYNXloYP9Cl.VvCn3YnUxTjtI1QM 7nPPkl4pVllXBLYt6idlnEimGxY2QdpYgMIoClWMsEg0dy6nBGc5bgdXvvooqY7j8NgizMX0pC9X K1yNAMeoiTCtNj7GgHBtQ5cFhcV6g0QU6wamx.atPjET0p5Xc3uBHdPHQH6vwacWD7tukr6ioiYb HhV_Aj6WeS6gZnRtwI2WZu3wVG3fiIdLql2oS01mMnAiSyyi8nFAhpUxg2hzBRByCUVxrKTDs7.Q UM9.5Lbi1peF6pp5TBMcbxYEaoL1pyU4Z_aPI2lkhr8OJfSB8k1Ww0CwhEb2tkAWOkHj0oBNMGB1 T2k7ZroFYg30BcjU5dc5KuacN7QAXGrv.LuXqmX.61xaIY3RHEjoZNsOB2MuawZGc1ZQQCthkY1L mTs8XulIf6qo65GoSQs4XRiLtZ52IzWFyBBBtpXjpwCjBbImNqRDpTvmqhuuSkNdZrBF4ppa41I0 A X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 23:29:11 +0000 Date: Fri, 26 Feb 2021 23:29:09 +0000 (UTC) From: Greg Dennis To: "jsonpath@ietf.org" , Daniel P Message-ID: <399853217.176463.1614382149416@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_176462_508372610.1614382149414" X-Mailer: WebService/1.1.17828 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Archived-At: Subject: Re: [Jsonpath] Jsonpath Digest, Vol 8, Issue 4 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: Fri, 26 Feb 2021 23:29:14 -0000 ------=_Part_176462_508372610.1614382149414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a fantastic idea!=C2=A0 (Provided it satisfies the archival requir= ement.) Greg On Saturday, February 27, 2021, 11:47:40 AM GMT+13, Daniel P wrote: =20 =20 > From: Greg Dennis > To: "jsonpath@ietf.org" , "Stefan G=C3=B6ssner" > > However it seems that the MD formatting ... has been lost > I feel that email is probably the least ideal format for conversations li= ke this.=C2=A0 The thing is, we have a > wonderful GitHub repository (https://github.com/ietf-wg-jsonpath/draft-ie= tf-jsonpath-jsonpath) complete with > issues and PRs, mechanisms that are specifically DESIGNED for this sort o= f discourse. Agreed. Also note that GitHub supports a Discussions tab that has been enabled for many projects, see e.g. https://github.com/WebOfTrustInfo/Community/discussions. The Discussions tab supports MD and is ideal for collaborative threaded discussions, allowing the Issues tab to be reserved for referable issues.=C2=A0 Anyone with access to the gh-community/discussions-feedback forum can request that a public repository be enabled for discussions. Daniel --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_176462_508372610.1614382149414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a fantastic idea!&nb= sp; (Provided it satisfies the archival requirement.)

Gre= g

=20
=20
On Saturday, February 27, 2021, 11:47:40 AM GMT+13, Dan= iel P <danielaparker@gmail.com> wrote:


> From: Greg Dennis <gregsdenn= is@yahoo.com>

> issues and PRs,= mechanisms that are specifically DESIGNED for this sort of discourse.
<= /div>

Agreed. Also note that Git= Hub supports a Discussions tab that has been
enab= led for many projects, see e.g.
Discussions tab supports MD and is ideal for
collaborative threaded discussions, allowing the I= ssues tab to be
reserved for referable issues.&nb= sp; Anyone with
access to the gh-community/discus= sions-feedback forum can request that
a public re= pository be enabled for
discussions.

Daniel
<= br>
--
Jsonpath mailing li= st
<= a href=3D"https://www.ietf.org/mailman/listinfo/jsonpath" rel=3D"nofollow" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/jsonpath
------=_Part_176462_508372610.1614382149414-- From nobody Fri Feb 26 15:36:21 2021 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 538973A13F2 for ; Fri, 26 Feb 2021 15: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, HTML_MESSAGE=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 (2048-bit key) header.d=yahoo.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 j-V8VfNVUQd1 for ; Fri, 26 Feb 2021 15:36:18 -0800 (PST) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 68CB73A1301 for ; Fri, 26 Feb 2021 15:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614382577; bh=AH0ncRa7NZbT8SIRAJj+iKxXovbe07Uj76B6MNFxuAc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=gi1TCdFe5WVVn+HYlkGB6LuTS+5/4X/nHYe0ng93oycaicEqrWvgDWeVXpgSNWsG3Ioos0HyPlqgT32GiJqQp1i1kGzwZE4V6fBon+Yh/LU2r8XGSgdxE4HEw1mwRLMPj3aSJ3JNrFeZA2OSsNtBb6sI75IOYxjvb80sHChUU5gYvfCo3GrPKw09Zz367HloMbISk85bw7YF1f3lFoh0yCpqE/AUvNbz40kL3q0HYU/hofWQHkCbSnXsLX0N0u+Ne49DLDZ5gSS2amFACByxUDWZ9SFDhLXlQk+l7n604Yz9hKlKaQcBYJjsVVXNFVB0uHR+cSNilrUnlQqtGNQfIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614382577; bh=8mlq/cS24Qk0JqKAbnvWkmK0leNRDiaWSHx/z2w64mk=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=dFsHEdzNgxpOoGesLcyqPVZSK9l8XuyjQ51bJKBecGGZf2CcvFAtqLESGMcNaXAgoE1z2YY5OMU/QEwmutdZ/jbatr7tSuRkc1LpfVg3L+6+jrWU6Nj9th7z611JiIcJbnHNZQpoB0nENSPgvTYlodZXkaeEElIb0w0TCtBl0pS5rM6abXtH7OpcrKWxtxXRNdmK3RtoybcJVMYreJwrHOu3Ktt0uuXTue8XJw/yOu8yQE41Ks1FKZwETQgovfFLNcdwUX3/yeCDRmxZYbzB3OmG9y3r+4YiEbFVLwpmsosobrKXIiVQWLtYjtm9iWLGOHtwZrhSGIus3Y9F16GzPg== X-YMail-OSG: t8_pI6oVM1k69hUWFNTk0a7GkvFOeySXe0T6UYJMBDuok1cMoDdXJc967wnwOGc k1utE73_aKnLl5FNKFTHjJcKYqVikKH4sHOj9BRVegYrd3i.AhUM._BiV8X12n8IIbRrmFfMhtCj h6re_ccQX2T4sH.S6dYXrbh3_OMlMVQgEAJx8LCHvu883_YcM_fbKAIo5.gLxdAJx6uwFSHm36S8 eDTGyL0HgVtGqXCW5n.HDAH.G56Os8RshxFQQyqHSXD1BwF77Hq.5VeEg7l2FrOtd63pusMOZApo WX2S2OD8X7Up584_gWlgfGoEdYcBL3v8RULXpTOXsf3LtP9bkkKlTaqBWyErpXWkFg8LvkNqynvy WwmBNZExmvpIm4DV08H1Xw6UzgIUQ9ROLbqEu_AEPeccfY5oKAs8T4sbVVgGw4WkL0WHJdY6lIZ8 eQf_FpqjaK8R5hIBFT27a9c72a66_4eW.BxypaEJsOQMXC2lA_itJM9oMcM52OGiAaDBXhLEb28G jylS2lLR.pFd8uKBzibGh4paLzBHu7a6_3dc93vB6Tywi_dVhrfUO5x3ZXH.njqLP1otQZi5pWR6 Qq277uvpShPO5nOiSBiAEUZcVE5VWZGoBPvrAR.EKpNZ09Jr0QQU.Doy2gQA2Hwtaudfav1FCO6w CINzZ8TP0WrOZ5XCebLuXTabgIQnQboD09LBXk2f7mPmDnyS.PgZ3r0k2TlHmwrjwgBPSo91PpmT 5vPTMmoTkXRMbLu7ZrQi6Jjb6b8j2E7MdurpaAcd7ajoi9EjbTLBm366qxwqBJz_HsZ1.L0WC_Ne H_ek7VvB3a118IbNP.O4zPfqAZzn1U5GjlgBJgUmUFD01WajJZJl8L2jNS7ArUMTVkL4VR2wbO_n oQw_jbkN7Y7_KLnBCpNjRHT44sqGZ5CundQTD92kZEyf_PsZuCkKYc2ExByJQWwhdxAbsGmk0LW1 uUWS2g1.kvgtwWNsqRviBFMsIDxAEqgSlrpCRakldSPYKw8nNtxTt4WpGxr234blSxfQUnT1g8_a 0U0wCv4YlxrazR774VvMFh_av4zTVugW7Cj8UPJz6_SZPNEY2_I1eNYFKT.DxJzMUhopCy7u3ce4 TJI9WFn6y_VLpQPDBrJXDUjIn44B0kcLlS4T9qi7BURbgK6ETrsvLKXv05Mw010XJ5Eog7KaMeC0 7XoY2uV3CE8ITlTkcGR9Eg2d4dqRlAeHQP8yCK4qi8G..p618JQc01VRo2ZTbk9AfM_cXj0MfZOL uZ62HWMN5CylM77ZywlN8RFSLeRj2zFX_XfS25TcyxSzShGEqdVGuU1FmLU66pOfIiMvh9c3aocg Q.aOejh4q6DHDwyJ9gCGcdwgE1JbOuJ8peDVPSH5nPDuYbLMhxwlPP6jqPRxXWl7H.uZHKW5fCG2 cM2oeNk1Wed8VIVoeIT1SD4195ajjl4.rrZ64YiChnrMmOJ2gcKDv0AEoQgeVmI6hQ92HRX0UHtY xWGlbCSkh6m6K2icHsj3bfeA6j43gZX887IPyxT_TxUSE57s6GW2PiNoRbe3Wyd7v2UxfL92Spdv I7bdyNe3EUhPU4Qmlna4twkgGbvWrSB2x.dnUoekP22PEJfyVxwTPCD6leFpBKKlbtjmkTCyEQy1 WHFCzQgLmzTk2WvZbmylGwIoZKEqHWE9PYRk372YluQ2FMwIrrYLh5rOY4fJPhPmTm3MWxDOYmc4 YuoFkyYKBxbDOXYTO.uJycyhvfF8k37EyBOvVIaa.AgEwsmSgr4.SKh0li0Uuga6GKwK5XyEBq3O Cf2HGiPG0B4cOta75gjBLtFSqbVCZnnhUOXw_ZCfoU8IQytU51EYdP0BDeF9QHS1VZLhzsdDeI.o INfxhsU3ooq09tQZMPNIav.LYJWvandYbzyWOH4sVbLl8T6pQje.ZikKPKCRBUD6lMxK2YB4XMGM XFwauUVHbtp7EXfQBatFBiqAwWnYfSrtUBXe5RGkDnptAXc7hWkQDdCtwn953HIFvEDc6Ue.qQyg JkEwQ8hQlHhF5JQyK1s1Jqa61QQINnk2kKDqudkGajNxQVJQn9fce.kpLZnmUIianceHRC9Ti.Tc EKaxpcNMxN2NiGdCqUsG67_Y8fxtU3OtXtSTwkw6llqihmFSUsdyhU9WXeZBUh7tNkqEQtMqZIyx lR3j_P1JVJlsau1E.jMBCgB91SJPw7Ic1RmSST9VV1KydjlQd.IUjXL0UwCZyGPwjtLrxQKYgjGt e_OPtBql3L7H_tkQd.FKQ1hSN01qrMRLf3AkLgB30fdmdEnTsIySzeqY0cvDhLzZfaLk.9y8rPO0 5wDH2pFhFY1shAYxLq3E0JmdGkCJ5Ir97w4u27lQ.B5zVq84sWfb_wiwM_O1I.DSYOROkgNb5uo_ 1JIK1TIkjp6GMO1ZoCsWEY7NKCtwHs71RN8RhiFcd.Jo8lMww9VAJp1TRPstuiWy_akzRvZ8yGvq .rSxX2PUNhwnNDC014aPdcfGD4uPtoqlMYALtd10e6XhMDnOsiNO2ZQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Feb 2021 23:36:17 +0000 Date: Fri, 26 Feb 2021 23:36:16 +0000 (UTC) From: Greg Dennis To: Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <1553067654.207468.1614382576960@mail.yahoo.com> In-Reply-To: <8E187A2A-3EE8-46E0-8737-272B1F3D267C@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> <2033972809.167421.1614379352024@mail.yahoo.com> <8E187A2A-3EE8-46E0-8737-272B1F3D267C@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_207467_1644235946.1614382576958" X-Mailer: WebService/1.1.17828 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Fri, 26 Feb 2021 23:36:20 -0000 ------=_Part_207467_1644235946.1614382576958 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you.=C2=A0 It should be noted that there are a lot of outstanding qu= estions/comments on the PR (3) as well as it containing merge conflicts. I'd like to have a poke around these documents and see if there's anything = more to address that hasn't been already. Greg On Saturday, February 27, 2021, 11:52:42 AM GMT+13, Carsten Bormann wrote: =20 =20 On 2021-02-26, at 23:42, Greg Dennis wrote: >=20 > It's the copy in the primary branch in GitHub the current state of the sp= ec?=C2=A0 If not, where can it be found? There are various levels of draftiness. In increasing order: (0) RFC (which we don=E2=80=99t have yet :-) (1) https://datatracker.ietf.org/doc/draft-normington-jsonpath/ (The =E2=80=9CInternet-Draft=E2=80=9D, i.e., the official WG working docume= nt.) (2) Main branch (previously caller master branch) of WG repo, https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath (The markdown document is the source, the other files are generated version= s. This hasn=E2=80=99t been converted to Martin Thomson=E2=80=99s template, wh= ich keeps generated versions in a separate branch so the main branch can be= clean.) (3) The outstanding fixes in PR #46 https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/pull/46 I could continue hacking that PR, e.g, based on Stefan=E2=80=99s summary, o= r the authors could merge it and then we could have separate PRs to impleme= nt the items listed in Stefan=E2=80=99s summary.=C2=A0 (I would prefer the = latter, as it is less work for everyone.) Gr=C3=BC=C3=9Fe, Carsten =20 ------=_Part_207467_1644235946.1614382576958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you.  It should b= e noted that there are a lot of outstanding questions/comments on the PR (3= ) as well as it containing merge conflicts.

I'd like to h= ave a poke around these documents and see if there's anything more to addre= ss that hasn't been already.
Greg

=20
=20
On Saturday, February 27, 2021, 11:52:42 AM GMT+13, Car= sten Bormann <cabo@tzi.org> wrote:


On 2021-02-26, at 23:42, Greg Dennis = <gregsdennis=3D40yahoo.com@dmarc.ietf.org> w= rote:
>
> It's the copy in the p= rimary branch in GitHub the current state of the spec?  If not, where = can it be found?

There are various lev= els of draftiness.

In increasing order= :

(0)
RFC (which we = don=E2=80=99t have yet :-)

(1)
https://datatrack= er.ietf.org/doc/draft-normington-jsonpath/
(The =E2= =80=9CInternet-Draft=E2=80=9D, i.e., the official WG working document.)

(2)
Main branch (previo= usly caller master branch) of WG repo,
https://github.com/ietf-wg-jsonpath/draft= -ietf-jsonpath-jsonpath
(The markdown document is the= source, the other files are generated versions.
This has= n=E2=80=99t been converted to Martin Thomson=E2=80=99s template, which keep= s generated versions in a separate branch so the main branch can be clean.)=

(3)
The outstanding= fixes in PR #46
https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath= -jsonpath/pull/46

I could continue= hacking that PR, e.g, based on Stefan=E2=80=99s summary, or the authors co= uld merge it and then we could have separate PRs to implement the items lis= ted in Stefan=E2=80=99s summary.  (I would prefer the latter, as it is= less work for everyone.)


Gr=C3=BC=C3=9Fe, C= arsten

------=_Part_207467_1644235946.1614382576958-- From nobody Fri Feb 26 15:40:35 2021 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 0C4E23A13FC for ; Fri, 26 Feb 2021 15:40:34 -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_H3=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 ZjULFcMx2v-8 for ; Fri, 26 Feb 2021 15:40:31 -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 94EEB3A13F8 for ; Fri, 26 Feb 2021 15:40:31 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnR3c6PNVzyVW; Sat, 27 Feb 2021 00:40:28 +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: <399853217.176463.1614382149416@mail.yahoo.com> Date: Sat, 27 Feb 2021 00:40:28 +0100 Cc: "jsonpath@ietf.org" , Daniel P X-Mao-Original-Outgoing-Id: 636075627.573054-05f6ec7e989ff1ca9f3a2ed5cdab4665 Content-Transfer-Encoding: quoted-printable Message-Id: <5D89E655-3F21-48FF-AA1B-BB5C87593467@tzi.org> References: <399853217.176463.1614382149416@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Jsonpath Digest, Vol 8, Issue 4 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: Fri, 26 Feb 2021 23:40:34 -0000 On 2021-02-27, at 00:29, Greg Dennis = wrote: >=20 > archival requirement I asked=E2=80=A6 https://github.com/martinthomson/i-d-template/issues/268 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 17:05:15 2021 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 17A8A3A1540 for ; Fri, 26 Feb 2021 17:05:14 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 6CMdmhMXW-Tw for ; Fri, 26 Feb 2021 17:05: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 E1BA63A1391 for ; Fri, 26 Feb 2021 17:05:10 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnSxC4HHZzyTG; Sat, 27 Feb 2021 02:05:03 +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: <1553067654.207468.1614382576960@mail.yahoo.com> Date: Sat, 27 Feb 2021 02:05:03 +0100 Cc: "jsonpath@ietf.org" X-Mao-Original-Outgoing-Id: 636080703.0739-ccca4966a945709b24ec2d8d931bf182 Content-Transfer-Encoding: quoted-printable Message-Id: <2B8A58C5-A307-465A-A5BE-B172D37AA500@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> <2033972809.167421.1614379352024@mail.yahoo.com> <8E187A2A-3EE8-46E0-8737-272B1F3D267C@tzi.org> <1553067654.207468.1614382576960@mail.yahoo.com> To: Greg Dennis X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 01:05:14 -0000 On 2021-02-27, at 00:36, Greg Dennis = wrote: >=20 > Thank you. It should be noted that there are a lot of outstanding = questions/comments on the PR (3) as well as it containing merge = conflicts. Fixed. Can we merge? I=E2=80=99d like to go through Stefan=E2=80=99s = items next, as separate PRs if possible. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 17:21:18 2021 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 DDD0E3A1592 for ; Fri, 26 Feb 2021 17:21:16 -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, HTML_MESSAGE=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 (2048-bit key) header.d=yahoo.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 XaV8Vc6_KtX5 for ; Fri, 26 Feb 2021 17:21:15 -0800 (PST) Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 706523A158E for ; Fri, 26 Feb 2021 17:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614388874; bh=UvUtfbgEbFfWdSfEIYFdTemCF765VtStVFhK1F1eie4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=ojUilaVYyaZP1Phj+0/+zIAcYhyzXeu9CIMpvkb4Ty6m31oz3ue532Mn4LF6h9PC66pCI/mtu2Jlk55b1YMwPgloqT0fkLYJ8mIkGXpqXmrKGVFV9Al/lVB6+suJ9ymu1DNQ1IlWbxXKsXCoXFFqv+qC1LnCF8f6ihKH928xrea6o+3Qx5OU4/GZMQu8zt6boHcIVqH8IYiLm9v1b9r0xr+0nFA0Ps3txjwyRBPsOk9UXgHfb882r5+i70Gi/GVNFoRzwV2MrUiOQRLdGO57OMEIp30+uj2Se1MDGOPJqNZL9YHJ0q7gDbyhlVeoGzG9/K5kGi/fG5KzZVG2BQpBZg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614388874; bh=PwY7RPjGBIGDuxGvwHE90j+PCFbgBchUB2Xf45Te6XD=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=jUaMZduYBMtQ5aleBMwrKGpnDLncBae7KNhfKnqhtfYVXQodBmIZyUnsqcojuorz23HPJHkcRnqkcDR7t8YlgLCkLJYmhhTv7+XZaQGvaGvoUnpk2ilioow3y+8g2DHTX00NEHxyaJwG3hKuUmuQIAu+IyHAc+rCaqetcnqCuEaE+6O0N1SHOQzw/SMwJXkm8mnm+5cIwYMWD3j8B05ucrj20Uf7DR2HsDaPoSVzKunPafAXnLRJxAsqan4wgAbS6tf+xaqSpBR6jCXA/UQp87/2toccH2V2qoTQTWzlwod5RYn+MjevEMrIIx+JsQ9en0GII1nmi9EbDsVAjON22w== X-YMail-OSG: yzPdcZIVM1nuJ5E9b.TPuRR5c9HjSczwUQNqr_dKN1MjzM.khG_CqU0tBu_rB0h ixF70Jdns7KnL1WTKqHi2VbDcvLViQ.cHl1JVfikG2dy5RunWPr8bb5RKSQbYXJiMv8Rw94M6kLk olQ_hSRG17VFGzAWGVRq7yX_lcFSX.kSz.5b27j4.1vWc7OV.jQLCgB_jy7MxV5eJn2GHnqGG662 TGR1tp67HjHq.elsK2QyWuT8FDaLmR6.r0ApnnFU62XJsACmzZBGm0p5rphGkZfQ.ewtd6YVMYqw y92MX7SU6RQxUJ7SHkCts3iDjmbwGSqe22Ki0H_GMk0iOErc54d1JVQevkaiUPDi0wzQyTuGnFnM 0sZJMinyiAWQWd9sYsQdqSGn5aAKIa_E70SHYHgo07Wqj2bgHF3BkZvQ8X_ukD9_.Ad3hN96UBlg BtnSOHe7QCnqfkNOw5yo3nAdnYFEb7LYJmuAg0tW5cOPSUbNVGWyM4nSoKw5bBVG2p.8zjk7NpEg Slsd0Lpjuv2SQK1TvtAFf807F3cI4rf0ZJnd.MrkbQhIfx2ObPd0X69C4erT.XNQTCW21j8WpJ4V 32o3Ao_7eY_EOX2jkzp3iovI67dUNkYPiItHe4w8SO4BOuNSgF0XidZEfsUA4iVmerojad7sEQHy 7Uf_BfqnZqBACH9YVKNjlbSHwIE40XV8qOcVqpuB1eoKqoVLwCxU5B_6KOErVcpaPYjJLcQPojyy 8RooQ4oZNjZCgV7TBy6fKpTzBJA.kTxpyWYyXJptbO.DE2rCU5Bs5_CT8vwwIxbLYqc_Q_kTY2lo Djkuspz605h2DwHSLVKafKU2Nmt8fYNqStFAZDYUXy.4BDuiEy0WyhsNU.MzMQoFzxFAiSipS1C7 GIU.sZp.tr.dtEU4_SbDkQQfojdmyuAteW9TONVjwGFf0OeCTxRmK5GixHAmRLP7WhGvIRHaXGTM gOGCQd5jlvzIYH0VoRqiFyOsLXH50JZH2g.JcT55I2UACURsoH_oXO1.37jrDDtM1br1T1J7rHvY Pz6roil_Liel3rGHt8VAG9eeTUBdcQ8IAao6G4G9T95GKI9fkiVAhtpFRY_HAmrpXebf.KZLza_a 44qrmzV6yA2m95.PFnWnqSacG1llEDwbP3rjP4Fas6im5CxX6Tq7CnDtogoQ.ElokOWrVqQ_r8.p 9elca3m2L2f.e3ReJiVeBACueIGb4vHd53x8eiVgRdqd7HiW4.i5edVQI7svsa62iO1nno02F6R_ 2EW_E9tViOd3uBDbfJsicLN5JwIPYM94yEoVJe38p_TWBAeVQZXcp2WTr5NJWcHgXiZAkLAFFX4o naNwy7pm3ScQilFQpX.V.sc40YfgeKTlaLKrYW_PZVd6GJRgNgKII6OLhP6ZA9l8hv6KnmkQBicl 9A_cSYBZx_XZM3B_MTXTYVnucBv0_napXxIyB1zpnXBgNzg86u1y8uXFiGeekYjHs9SP_eJkweP4 y_JGZrMtdzkYh_wP5weYwbUB4Knv0hdSZKdJeVxgMMQsADVGU6FI.kiW2OF5Bjh0FC3i4STtSSr2 Z1wCi5J7.ZQPtcjuScn053RX74ZL1aaJeCCkD5ER7OJEEf4ks1T09cWCylbXa7g9wbO5qAnpMGhO l9q90K22kHhGTE8uA.92Q9ZUXy.AMjvtatqafobyoBIJL0AbJURzcnBlYWXDKmy8BgCS0ztbGKyv H63VAhMk.EUnPcTzFAb3HF4.b_XtpRw8Je.m6K_BFq6jYx.9RrY5YG_qiJWMSNetcasqqww4CBcG nTeT1hlwvV3TB86mQ1QafrApabzygl6NzZd99.zcsQMaD.YWrhWfLUy8VK2LnVqUaa7Gie.RkqFG rnVBEREQSKJwOV.J0u7KiqQRYYorDcDa1MNGItCp7zNpUsEhWaFJWVxdrjprBdN0Vu7j9WuVeuL6 gK59jX_udQn4sshNtRfXDck6Cj5ffA1QvNAPIn34IROmnGnLuhSdrvPaP7dc9MGEB7l0mSQDvVUA CGnyPhowbZNHof3pnPRCrvMc0UDSe0wiqK61UX9uU1Q7KMIbMdGzYTuoYD9BbBMehATBmkUGYGIn SChUu1CFNaU4YhknPaQH2_HposmVrmdq5xT4dNBTtW11Usl4phTtWJGggCdWyP9scWniUPTbHEQv dz5pV1i3u.O5Bc_c_s.D5TFqHquFIfZzflPcAsnjPMfeWaBY19g6Glp1ioJ6r3s8RyUFUEJk58Lf rbGzQYFjxskQmRXtRWR8z0zqHQEym0we1v2mE_PPgsJxrt7PH50dsPrxLg_yi3P0xO5IQKMowKDi MppUm4kaDZfxGFeRtyIAt402puWFvsER1qS6xGIBClK_eoO9t341z22qXT5P1wHMWQfJg9rVCM6B z5H.0abX4P8a3DwQLBvnz8JLOLEfEt.rbXFmyDHv0H31viHVwPb0Vs_haftngDSnkgjQYShoc5Kc XC.X65wu84VWwhdLzQUFrjt2q7E0qNFSacD4VWNwSV550Rph6UMhfli4sk5BfnFLTA2IzJq.AYt5 WoUP8b6X9e2w_WsjK_EMi6SXg.BIrqU1dXfCaHqjlswxeAiMIw0vq3qQ8 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sat, 27 Feb 2021 01:21:14 +0000 Date: Sat, 27 Feb 2021 01:21:11 +0000 (UTC) From: Greg Dennis To: Greg Dennis , Carsten Bormann Cc: "jsonpath@ietf.org" Message-ID: <1806358092.186139.1614388871798@mail.yahoo.com> In-Reply-To: <2B8A58C5-A307-465A-A5BE-B172D37AA500@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <8D239BDC-2FEA-41D7-B5CB-04161659FD09@tzi.org> <2033972809.167421.1614379352024@mail.yahoo.com> <8E187A2A-3EE8-46E0-8737-272B1F3D267C@tzi.org> <1553067654.207468.1614382576960@mail.yahoo.com> <2B8A58C5-A307-465A-A5BE-B172D37AA500@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_186138_1442477428.1614388871797" X-Mailer: WebService/1.1.17828 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 01:21:17 -0000 ------=_Part_186138_1442477428.1614388871797 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've approved the PR. On Saturday, February 27, 2021, 02:05:20 PM GMT+13, Carsten Bormann wrote: =20 =20 On 2021-02-27, at 00:36, Greg Dennis wrote: >=20 > Thank you.=C2=A0 It should be noted that there are a lot of outstanding q= uestions/comments on the PR (3) as well as it containing merge conflicts. Fixed.=C2=A0 Can we merge?=C2=A0 I=E2=80=99d like to go through Stefan=E2= =80=99s items next, as separate PRs if possible. Gr=C3=BC=C3=9Fe, Carsten --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_186138_1442477428.1614388871797 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've approved the PR.
<= div>
=20
=20
On Saturday, February 27, 2021, 02:05:20 PM GMT+13, Car= sten Bormann <cabo@tzi.org> wrote:


On 2021-02-27, at 00:36, Greg Dennis = <gregsdennis=3D40yahoo.com@dmarc.ietf.org> w= rote:
>
> Thank you.  It sh= ould be noted that there are a lot of outstanding questions/comments on the= PR (3) as well as it containing merge conflicts.

Fixed.  Can we merge?  I=E2=80=99d like to go through= Stefan=E2=80=99s items next, as separate PRs if possible.


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

--
Jsonpath mailing list
Jsonpath@ietf.org
= https://www.ietf.org/mailman/listinfo/jsonpath
=
------=_Part_186138_1442477428.1614388871797-- From nobody Sat Feb 27 00:44:36 2021 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 8ED663A14B6 for ; Sat, 27 Feb 2021 00:44: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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 b2bCZBT9q624 for ; Sat, 27 Feb 2021 00:44:32 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 8582D3A0B5F for ; Sat, 27 Feb 2021 00:44:31 -0800 (PST) Received: from [192.168.178.20] ([87.123.195.171]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N79q8-1lsgJk3Vq0-017SqS for ; Sat, 27 Feb 2021 09:44:28 +0100 From: =?UTF-8?Q?Stefan_G=c3=b6ssner?= To: jsonpath@ietf.org References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> Message-ID: Date: Sat, 27 Feb 2021 09:44:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> Content-Type: multipart/alternative; boundary="------------1BB1DBF874F44B3F8AC6B340" X-Provags-ID: V03:K1:FOCX5VKsYG0iZHu57JWLconX8PANiWWTXwBsz64VEA8S86e7h2F LOK6XG+Pn3pQmMaSWIBwIMZ1Ws/QDzAffcoUsq0vWi2c1AXItT45J3iugMP3RqlB908SHFa BGvHzIvjMEgniFkJ/4TU9k7sMTl7DWWu/0jSi3ccXyY3uFAY+SQ7TrUidWdHdP62XYt8BsC Ho+MYZqBU0NyC2kHyz8DQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:BLZyWi9HFNI=:60GTyk2VO4Wo4r8fmh/hGX eXEzfJj6jN9xcOQlrr4bH96x2rcqlR/8dMw+mpzGiWpYVP7sSJVbyV46Z6u1172ydlYhV5rIv tUb6AwhERgt1O9NVZamAQ00BNQboe2yWXeWYoHyEnKu3ylHuJtkN5NvGj45x7XWIh9dWtVFRd jDfUnZt7nXQkBdwA3JdGepGXxc8PR+2bkEw5cS0lsyCDCrY1ChBHt7X1g0XWc2JNrrdQfCaaz N2xmi606MegWV8MxFgvYOExp4ikEQwH8Wn3f2w1s1MhD4pTU6PJtzWFW/GiiV6oEbjLdNpnfe wgkanKLiZtUQK9TPXFQ+NHCsvTjqyEhjl98hf7/B1Ex2eCWlnIkXyVdea+Eb0A78Z+i4GMcIl 5/xKZiwQcA036Bj0sYA/v1YPCwgJarhxsgW8YHB1E12as4CkFWWE0JUYFzj3asLxZJPsG9vpx D+kyE41RJUviPi1cdpaN02t+/OxIVR0= Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 08:44:36 -0000 This is a multi-part message in MIME format. --------------1BB1DBF874F44B3F8AC6B340 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I copied these comments forward to Github ... for better reading and further commenting. https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/54 I would also like to try out that cool Github discussion tab, Daniel wrote about. thanks -- sg Am 26.02.2021 um 19:30 schrieb Stefan Gössner: > Hello List, > > It has been important to go through this list threads carefully. In > fact I should have done that at first. Now I can understand the > current draft and appreciate the work already done much better. > > I collected some citations (important from my point of view) with > comments already in Markdown. > > > ## Title of the specification > > > JSONPath: A query language for JSON data. > *(Carsten Bormann)* > > > I think I’d slightly prefer the term “syntax” to “language” because > “query language” has a smell of various things that end with the > letters “Q” and “L”.  But not passionate about that. > *(Tim Bray)* > > > JSONPath: A query syntax for JSON. > > Another wild-card idea: JSONPath: Query expressions for jSON > *(Tim Bray)* > > > The beauty of this is that the plural form “query expressions” > implies a set of expressions, so it implies “language”.  It’s indeed > more than the grammar/syntax of those, so why not talk about the > expressions as a whole.  This also makes it possible to just use “for > JSON”, without going into detail what these query expressions operate on. > *(Carsten Bormann)* > > There seems to be an agreement for "*JSONPath: Query expressions for > JSON*". I like that also. > > ## Terminology > > > 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. > *(Daniel P)* > > > 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). > > > > … oh, and I forgot the very useful "member". > *(Tim Bray)* > > > … and “element” (the things in arrays). *(Carsten Bormann)* > > > 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 “the > values inside that tree” is not going to be felt as equivalent to “the > set of all subtrees of that tree, including the tree itself”.  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 “value”. > *(Carsten Bormann)* > > > I think the key difficulty is whether each (key, value) pair in an > object is "a thing" that can be identified and manipulated and > potentially returned. (If we're talking analogies, then it's analogous > to an attribute node in the XDM model). > *(Michael Kay)* > > > ECMA-404 uses "name/value pair", which is what I understand the term > "member" to mean (Douglas Crockford uses "member"). > *(Daniel P)* > > > I think the term “union” is poor. If we think of it as concatenation > of results, then the result is as expected. > *(Glyn Normington)* > > I understand, that within RFC8259 we have JSON values of different > types. They are structured somehow, which is not so much of interest > here. > > But while querying that structure with JSONPath it is vitally > important to identify that hierarchical structure as a tree. So in > fact we build up a higher-level construct here. We also need to call > "the things" in the tree somehow. I was able to identify > > * "node" or "item" of a tree > * "member" of an object > * "name/value" or "key/value" pair alias "member" > * "element" of an array > > but could not see an agreement here. > > I agree to Glyn calling the term "union" poor (s. below). > > > ## Differentiation from JSON Pointer (JSONPath draft charter) > > > I anticipate being asked "Why is JSON Pointer not sufficient?" > Indeed its abstract says: > > > >   JSON Pointer defines a string syntax for identifying a specific > value within a JavaScript Object Notation (JSON) document. > > > >... which sounds awfully similar.  If we could include a sentence about > that, or a link to an answer, that might be helpful. > *(Murray S. Kucherawy)* > > > No - it's not similar in concept, they're separate things. If you > really wanted to mention JSON Pointer, you could say something like > "Note that while JSON Pointer (RFC xxxx) is already standardised, it > is designed to provide a reference to a single, specific part of a > JSON document, whereas JSONPath provides the ability to query a > document and potentially return multiple values." > *(Mark Nottingham)* > > >The short answer is that JSON pointer is good if you already know the > structure of the JSON data item you want to point into, and you want > to point to exactly one position in there.  If you need to do > something that is closer to a “search” (which might also result in > multiple positions), JSONPath gives you more rope. > *(Carsten Bormann)* > > +1 > > ## References to XPath > > > 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)* > > > 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. > *(Glyn Normington)* > > > Someone on StackOverflow today asked a question about JSONPath; they > called it (and tagged it) XPath, we really don't want that kind of > confusion. > > > > In addition, the reference to the XPath specification in 6.2 is out > of date, and the comparison with XPath in Table 2 is very approximate > and the terminology inaccurate: for example there is a mention of > "node sets", which exist in XPath 1.0 but not in XPath 2.0, yet the > citation is to XPath 2.0. For someone who knows the semantics of XPath > the comparison raises all sorts of questions about sorting of results > into document order, elimination of duplicates etc, which are > complications this spec can well do without. (Though some answers are > needed, for example if ..store..price matches the same price in more > than one way, do you get more than one result? And if not, what does > "the same price" actually mean?) > *(Michael Kay)* > > It seemed to be important in 2007, while argumenting to have something > like XPath for JSON. If nowadays the terminology used has changed > significantly with XPath 2.0 and 3.0, we better leave that comparison > table 2 out. I am quite passionless here. > > ## Array Slice Operator > > > Thanks! The ABNF for an array slice in that reference > > ``` > > integer = [%x2D] (%x30 / (%x31-39 *%x30-39)) > > > > array-slice = [ integer ] ws %x3A ws [ integer ] > >                     [ ws %x3A ws [ integer ] ] > >                              ; start:end or start:end:step > > ``` > > is consistent with JMESPath, Python, and my understanding of > ECMASCRIPT 4. > > *(Daniel P)* > > > 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. > *(Glyn Normington)* > > It's good having read this thread and thus understand the current > draft much better. I like the decision to be consistent with Python > and also getting an empty selection set with `step=0`. > > FYI: there is a recent proposal for adding slice notation syntax to > JavaScript, currently at stage 1 of the TC39 process. > > https://github.com/tc39/proposal-slice-notation > > Interestingly it won't have a step argument ... > > https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-step-argument-like-python-does > > > ... because of syntax collision with the new `this-binding` syntax > proposal `::` > > https://github.com/tc39/proposal-bind-operator > > However, we should not let us influence by this. > > ## Unions > > > I don't think any implementation would remove duplicates from a path > such as `"$.store.book"`. I believe this is only somewhat controversial > in the context of unions [,]. The name "union" suggests that distinct > values be returned, compare with SQL unions. But Stefan Goessner's > implementation doesn't do that, it concatenates all results that meet > each criteria. There are a few JSONPath implementations that produce > real unions with no duplicates instead of concatenated results, but I > don't think that's the consensus. > *(Daniel P)* > > > I think the term “union” is poor. If we think of it as concatenation > of results, then the result is as expected. > *(Glyn Normington)* > > > I agree with that comment, but it's partly because I'm used to SQL > UNION, > which is different. I prefer the JMESPath term for an analogous > construct, > MultiSelect List, > https://jmespath.org/specification.html#multiselect-list. > *(Daniel P)* > > Introducing the union operator `[,]` simply was meant an analogon to > XPath's operator `'|'`. I cannot tell, if it was a simple combination > of node sets in Xpath 1.0 or a true union without duplicates. I > obviously was not aware of that subtle (essential ?) union > characteristic. > > So I fully agree to Glyn Normington's '... the term “union” is poor' > statement. Are there some better alternative terms, perhaps > 'multi-index operator', 'index list', 'subscript list', etc.? > > ## Duplicates and Ordering > > > It was my impression that we were talking about duplicated nodes not > duplicated values: > > > > Given th array [10,20,30] > > > > $..[0,1,0] > > > > Would yield only two results [10, 20] > > > > (Not that I'm advocating for removing duplicates, personally I think we > shouldn't) > *(Marko Mikulicic)* > > > You’re framing this as “removing duplicates”. > Another view is that [10, 20, 10] would be “adding duplicates” (copies > of the same node). Related are ordering issues: > > > > `$..[1,0] ➔ [20, 10] Or [10, 20]` > > > > I would expect the spec will leaves implementations some leeway > here, but that should be based on an examination of existing > implementations. > *(Carsten Bormann)* > > > The mental model that leads to omitting duplicate nodes in the > output is > "selection": if you take an input array and select nodes with index > 0,1 or > 0, you get only 2 results (since selecting an index twice has no effect). > > > >OTOH, if you opt for a "collect" model, whenever you encounter a node > that > matches that query you add it to the result stream, thus the same > nodes can > be present multiple times in the result. > > > >I have a slight preference for the "collect" model, because the general > case in jsonpath is to collect things that appear at various points in > the > json tree. For example: > > > >`{"a": {"b": 1, "c": 2}, "d": 3},  $.a.b yields [1] and not > {"a":{"b":1}}` > > > >(i.e. jsonpath is not a filter and view operation but a pick and gather > operation) > *(Marko Mikulicic)* > > > In implementations that support paths (the majority don't), the query > function takes a parameter that indicates values or paths. In both > cases the query returns a JSON array of JSON values, in the latter > case, a JSON array of normalized paths. > *(Daniel P)* > > I must confess to never having thought about duplicates, let alone > wanting to eliminate them. So I do like Marko's comparison of > 'selection-model' vs. 'collection-model' a lot. I would opt for the > latter. In this sense the result of a 'JSONPath query expression' > should be termed a 'collection'. > > Regarding ordering I see something like a 'natural ordering', > according to which > > `$..[0,1] ➔ [10, 20]` > `$..[1,0] ➔ [20, 10]` > > would result with the example above. > > I do understand the use cases for reordering, duplicates removal, > filtering, etc.. But this can always be seen as a postprocessing step > on the resulting collection by handing it over to accompanying tools > (think of pipe operator). > > Of course this cannot work on the result collection of values alone > (s. duplicate nodes vs. duplicate values above), it rather requires a > collection of (normalized) pathes. In this sense, I like this view: > > > In my opinion the right balance between powerfulness and enabling > simple implementations has been so far one of the key factors that > made JSONPath popular over other alternatives, even if it lacks > support for aggregation functions. > *(Davide Bettio)* > > ## Filter Expressions > > > Related to that, it would be helpful to determine if JSONPath filters > apply to both JSON objects and arrays, or only to JSON arrays. > *(Daniel P)* > > > I would support restricting filters to arrays, if others agree. > *(Glyn Normington)* > > I tend to let implementations and their "normative force of the > factual" decide here or in doubt agree to Glyn's restriction to arrays. > > I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` > addresses the array itself and implies that array has a `length` > property. In filter expression examples `'@'` more consistently > addresses the current array element. > > The invocation of 'the underlying scripting engine' wasn't meant a > serious normative aspect, but rather a quick and dirty solution for > JavaScript and PHP implementations at that time. > > > ### Corner Case > > > Consider this perfectly legal JSON object > > > > ```{ "ab": 0,  "'a.b": 1,  "a-b": 2, "a": { "b": 3 } }``` > > > >So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd > like to say `$.a-b` but lots of libraries will refuse it because > `"a-b"` is not a legal JavaScript "name" construct, that's why you > have to say `$['a-b']`. > > > > But suppose your library would accept `$.a-b`.  Then `$.a-b` and > `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't. > *(Tim Bray)* > > Hmm ... this seems to be a hint to better exclude `'-'` from > dot-child-selector syntax. I think I have read more discussion about > that, currently don't know where. > > ## Respect Implementations > > > As I mentioned in the session, I think there's a non-trivial amount > of risk here that some implementations won't be willing or able to > move away from their current behaviours, even if interoperability > would improve if they did so. However, there are ways to mitigate that > (e.g., a separate 'rfcxxxx compliant' mode). Even so, it will be > important to get good participation from as many current implementers > as possible. > *(Mark Nottingham)* > > > The WG will develop a standards-track JSONPath specification that > is technically sound and complete, based on the common semantics > and other aspects of existing implementations.  Where there are > differences, the working group will analyze those differences and > make choices that rough consensus considers technically best, with > an aim toward minimizing disruption among the different JSONPath > implementations. > *(Barry Leiba)* > > > I'm OK with this, but for context: I've been a pretty intense > JSONPath user > in recent years, and AFAIK the spec, and the implementations, are mostly > OK, so the choice between "make JSONPath good" and "don't invalidate > implementations" is unlikely to come up. If it did, my predisposition > would > be to err on the side of not breaking implementations, but I don't think > that's inconsistent with Barry's text. > *(Tim Bray)* > > +1 to all. > > ## Error Handling > > > My mental model at the moment is that a JSONPath expression can be > valid or erroneous; application of a valid expression yields a result > (which may be empty), but does not raise errors. That may not be the > right model for all applications. > *(Carsten Bormann)* > > > The  general approach that I've seen several times (including my > Elixir implementation) is that an error is raised when there is a > syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises > an error. Conversely a valid expression applied to a bogus input never > raises an error (e.g. `$.foo.bar on "test" evals as []`). > *(Davide Bettio)* > > > 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)* > > > 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. > *(Carsten Bormann)* > > I like and totally agree with the *forgiving mental model*, so having  > only syntax errors, which do not dependent on data. > > Thanks > -- > sg --------------1BB1DBF874F44B3F8AC6B340 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I copied these comments forward to Github ... for better reading and further commenting.

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/54

I would also like to try out that cool Github discussion tab, Daniel wrote about.

thanks
--
sg


Am 26.02.2021 um 19:30 schrieb Stefan Gössner:
Hello List,

It has been important to go through this list threads carefully. In fact I should have done that at first. Now I can understand the current draft and appreciate the work already done much better.

I collected some citations (important from my point of view) with comments already in Markdown.


## Title of the specification

> JSONPath: A query language for JSON data.
*(Carsten Bormann)*

> I think I’d slightly prefer the term “syntax” to “language” because “query language” has a smell of various things that end with the letters “Q” and “L”.  But not passionate about that.
*(Tim Bray)*

> JSONPath: A query syntax for JSON.
> Another wild-card idea: JSONPath: Query expressions for jSON
*(Tim Bray)*

> The beauty of this is that the plural form “query expressions” implies a set of expressions, so it implies “language”.  It’s indeed more than the grammar/syntax of those, so why not talk about the expressions as a whole.  This also makes it possible to just use “for JSON”, without going into detail what these query expressions operate on.
*(Carsten Bormann)*

There seems to be an agreement for "*JSONPath: Query expressions for JSON*". I like that also.

## Terminology

> 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.
*(Daniel P)*

> 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).
>
> … oh, and I forgot the very useful "member".
*(Tim Bray)*

> … and “element” (the things in arrays). *(Carsten Bormann)*

> 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 “the values inside that tree” is not going to be felt as equivalent to “the set of all subtrees of that tree, including the tree itself”.  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 “value”.
*(Carsten Bormann)*

> I think the key difficulty is whether each (key, value) pair in an object is "a thing" that can be identified and manipulated and potentially returned. (If we're talking analogies, then it's analogous to an attribute node in the XDM model).
*(Michael Kay)*

> ECMA-404 uses "name/value pair", which is what I understand the term
"member" to mean (Douglas Crockford uses "member").
*(Daniel P)*

> I think the term “union” is poor. If we think of it as concatenation of results, then the result is as expected.
*(Glyn Normington)*

I understand, that within RFC8259 we have JSON values of different types. They are structured somehow, which is not so much of interest here.

But while querying that structure with JSONPath it is vitally important to identify that hierarchical structure as a tree. So in fact we build up a higher-level construct here. We also need to call "the things" in the tree somehow. I was able to identify

* "node" or "item" of a tree
* "member" of an object
* "name/value" or "key/value" pair alias "member"
* "element" of an array

but could not see an agreement here.

I agree to Glyn calling the term "union" poor (s. below).


## Differentiation from JSON Pointer (JSONPath draft charter)

> I anticipate being asked "Why is JSON Pointer not sufficient?" Indeed its abstract says:
>
>   JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.
>
>... which sounds awfully similar.  If we could include a sentence about
that, or a link to an answer, that might be helpful.
*(Murray S. Kucherawy)*

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

>The short answer is that JSON pointer is good if you already know the structure of the JSON data item you want to point into, and you want to point to exactly one position in there.  If you need to do something that is closer to a “search” (which might also result in multiple positions), JSONPath gives you more rope.
*(Carsten Bormann)*

+1

## References to XPath

> 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)*

> 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.
*(Glyn Normington)*

> Someone on StackOverflow today asked a question about JSONPath; they called it (and tagged it) XPath, we really don't want that kind of confusion.
>
> In addition, the reference to the XPath specification in 6.2 is out of date, and the comparison with XPath in Table 2 is very approximate and the terminology inaccurate: for example there is a mention of "node sets", which exist in XPath 1.0 but not in XPath 2.0, yet the citation is to XPath 2.0. For someone who knows the semantics of XPath the comparison raises all sorts of questions about sorting of results into document order, elimination of duplicates etc, which are complications this spec can well do without. (Though some answers are needed, for example if ..store..price matches the same price in more than one way, do you get more than one result? And if not, what does "the same price" actually mean?)
*(Michael Kay)*

It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here.

## Array Slice Operator

> Thanks! The ABNF for an array slice in that reference
> ```
> integer = [%x2D] (%x30 / (%x31-39 *%x30-39))
>
> array-slice = [ integer ] ws %x3A ws [ integer ]
>                     [ ws %x3A ws [ integer ] ]
>                              ; start:end or start:end:step
> ```
> is consistent with JMESPath, Python, and my understanding of
ECMASCRIPT 4.
> *(Daniel P)*

> 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.
*(Glyn Normington)*

It's good having read this thread and thus understand the current draft much better. I like the decision to be consistent with Python and also getting an empty selection set with `step=0`.

FYI: there is a recent proposal for adding slice notation syntax to JavaScript, currently at stage 1 of the TC39 process.

https://github.com/tc39/proposal-slice-notation

Interestingly it won't have a step argument ...

https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-step-argument-like-python-does

... because of syntax collision with the new `this-binding` syntax proposal `::`

https://github.com/tc39/proposal-bind-operator

However, we should not let us influence by this.

## Unions

> I don't think any implementation would remove duplicates from a path
such as `"$.store.book"`. I believe this is only somewhat controversial
in the context of unions [,]. The name "union" suggests that distinct
values be returned, compare with SQL unions. But Stefan Goessner's
implementation doesn't do that, it concatenates all results that meet
each criteria. There are a few JSONPath implementations that produce
real unions with no duplicates instead of concatenated results, but I
don't think that's the consensus.
*(Daniel P)*

> I think the term “union” is poor. If we think of it as concatenation of results, then the result is as expected.
*(Glyn Normington)*

> I agree with that comment, but it's partly because I'm used to SQL UNION,
which is different. I prefer the JMESPath term for an analogous construct,
MultiSelect List, https://jmespath.org/specification.html#multiselect-list.
*(Daniel P)*

Introducing the union operator `[,]` simply was meant an analogon to XPath's operator `'|'`. I cannot tell, if it was a simple combination of node sets in Xpath 1.0 or a true union without duplicates. I obviously was not aware of that subtle (essential ?) union characteristic.

So I fully agree to Glyn Normington's '... the term “union” is poor' statement. Are there some better alternative terms, perhaps 'multi-index operator', 'index list', 'subscript list', etc.?

## Duplicates and Ordering

> It was my impression that we were talking about duplicated nodes not
duplicated values:
>
> Given th array [10,20,30]
>
> $..[0,1,0]
>
> Would yield only two results [10, 20]
>
> (Not that I'm advocating for removing duplicates, personally I think we
shouldn't)
*(Marko Mikulicic)*

> You’re framing this as “removing duplicates”.
Another view is that [10, 20, 10] would be “adding duplicates” (copies of the same node). Related are ordering issues:
>
> `$..[1,0] ➔ [20, 10] Or [10, 20]`
>
> I would expect the spec will leaves implementations some leeway here, but that should be based on an examination of existing implementations.
*(Carsten Bormann)*

> The mental model that leads to omitting duplicate nodes in the output is
"selection": if you take an input array and select nodes with index 0,1 or
0, you get only 2 results (since selecting an index twice has no effect).
>
>OTOH, if you opt for a "collect" model, whenever you encounter a node that
matches that query you add it to the result stream, thus the same nodes can
be present multiple times in the result.
>
>I have a slight preference for the "collect" model, because the general
case in jsonpath is to collect things that appear at various points in the
json tree. For example:
>
>`{"a": {"b": 1, "c": 2}, "d": 3},  $.a.b yields [1] and not {"a":{"b":1}}`
>
>(i.e. jsonpath is not a filter and view operation but a pick and gather
operation)
*(Marko Mikulicic)*

> In implementations that support paths (the majority don't), the query
function takes a parameter that indicates values or paths. In both
cases the query returns a JSON array of JSON values, in the latter
case, a JSON array of normalized paths.
*(Daniel P)*

I must confess to never having thought about duplicates, let alone wanting to eliminate them. So I do like Marko's comparison of 'selection-model' vs. 'collection-model' a lot. I would opt for the latter. In this sense the result of a 'JSONPath query expression' should be termed a 'collection'.

Regarding ordering I see something like a 'natural ordering', according to which

`$..[0,1] ➔ [10, 20]`
`$..[1,0] ➔ [20, 10]`

would result with the example above.

I do understand the use cases for reordering, duplicates removal, filtering, etc.. But this can always be seen as a postprocessing step on the resulting collection by handing it over to accompanying tools (think of pipe operator).

Of course this cannot work on the result collection of values alone (s. duplicate nodes vs. duplicate values above), it rather requires a collection of (normalized) pathes. In this sense, I like this view:

> In my opinion the right balance between powerfulness and enabling
simple implementations has been so far one of the key factors that
made JSONPath popular over other alternatives, even if it lacks
support for aggregation functions.
*(Davide Bettio)*

## Filter Expressions

> Related to that, it would be helpful to determine if JSONPath filters
apply to both JSON objects and arrays, or only to JSON arrays.
*(Daniel P)*

> I would support restricting filters to arrays, if others agree.
*(Glyn Normington)*

I tend to let implementations and their "normative force of the factual" decide here or in doubt agree to Glyn's restriction to arrays.

I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` addresses the array itself and implies that array has a `length` property. In filter expression examples `'@'` more consistently addresses the current array element.

The invocation of 'the underlying scripting engine' wasn't meant a serious normative aspect, but rather a quick and dirty solution for JavaScript and PHP implementations at that time.


### Corner Case

> Consider this perfectly legal JSON object
>
> ```{ "ab": 0,  "'a.b": 1,  "a-b": 2, "a": { "b": 3 } }```
>
>So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd like to say `$.a-b` but lots of libraries will refuse it because `"a-b"` is not a legal JavaScript "name" construct, that's why you have to say `$['a-b']`.
>
> But suppose your library would accept `$.a-b`.  Then `$.a-b` and `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't.
*(Tim Bray)*

Hmm ... this seems to be a hint to better exclude `'-'` from dot-child-selector syntax. I think I have read more discussion about that, currently don't know where.

## Respect Implementations

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

> The WG will develop a standards-track JSONPath specification that
is technically sound and complete, based on the common semantics
and other aspects of existing implementations.  Where there are
differences, the working group will analyze those differences and
make choices that rough consensus considers technically best, with
an aim toward minimizing disruption among the different JSONPath
implementations.
*(Barry Leiba)*

> I'm OK with this, but for context: I've been a pretty intense JSONPath user
in recent years, and AFAIK the spec, and the implementations, are mostly
OK, so the choice between "make JSONPath good" and "don't invalidate
implementations" is unlikely to come up. If it did, my predisposition would
be to err on the side of not breaking implementations, but I don't think
that's inconsistent with Barry's text.
*(Tim Bray)*

+1 to all.

## Error Handling

> My mental model at the moment is that a JSONPath expression can be valid or erroneous; application of a valid expression yields a result (which may be empty), but does not raise errors.  That may not be the right model for all applications.
*(Carsten Bormann)*

> The  general approach that I've seen several times (including my
Elixir implementation) is that an error is raised when there is a
syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises
an error. Conversely a valid expression applied to a bogus input never
raises an error (e.g. `$.foo.bar on "test" evals as []`).
*(Davide Bettio)*

> 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)*

> 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.
*(Carsten Bormann)*

I like and totally agree with the *forgiving mental model*, so having  only syntax errors, which do not dependent on data.

Thanks
--
sg

--------------1BB1DBF874F44B3F8AC6B340-- From nobody Sat Feb 27 06:16:41 2021 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 A49E53A190F for ; Sat, 27 Feb 2021 06:16:39 -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 fNDs3tt3jND8 for ; Sat, 27 Feb 2021 06:16:38 -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 345CC3A0942 for ; Sat, 27 Feb 2021 06:16:38 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id n4so11366948wrx.1 for ; Sat, 27 Feb 2021 06:16:38 -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=zqoNk4omKKDnmQeaRJJZOGWaZD+iAkTU9D7uhTrP9nU=; b=L5bnZbe4xDGqtaYXmm5P8Ivmz4Sq/5fmvkts3qlZYitAzH8kbdXBLiStMBwmn8eCkl jaDzPwFaVC9Uh6/r1JiP2Sz7fJ2/qeB4gB5QXAmlDa40DtJAicOofUbZTUHE2/P4/H/y 6hABJtJNIRgg41jHZGDe+lvf+pcoyGND3UIdEcR67h/8RVi698ys8FLgvZwEdor7sXZq 9rw9iTK+Vf5/WWQLuA/jM3CnzSdA/eB1beduuIaJj7sN7LsHnMvdKAoG9yiVcqZ/fb/m 4LDfN6pQIhl02SmiTOtmpYGJctAzTulbEp0Q2FNn672rgKJ3svS6+61o5ngj0gmYKogt Oo5g== 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=zqoNk4omKKDnmQeaRJJZOGWaZD+iAkTU9D7uhTrP9nU=; b=CxaqV2a3h7aD82F+RwxRugG1B1XTiUrv80H+bVwJHwqOr2blH6MlWCuwlDJjvdHZFJ dnKqFTYAh5X+jDxTEIzZOqi6V8C0tQ9/mMEoBZVT5iCd1EoTPbL8i1aISN1rreCuM/UR Jc60Ray80pJZP31UemylhOXq/krAUvbRp4y5Ijnt2LyQ+dTEaBpRFx5UNnJ/WPQBBwa3 4lATHzZ6Io+dYzzaRo0A8NZeAc2QPLJ6RPaum+pCoP31l78fQH6aKGI3qW4JwFh3ysJH 74DY6nbj6jmPa9MogQjBTTDF+87TTFSiWh7Dyti5DXGFwqeq9/nLbWvPJpAgs4vF6bU2 dOGg== X-Gm-Message-State: AOAM530a9W2H1r3D0DUQkHrfCgiIhNnG8XNM8cxxGXM9XJP54suUAevf UPC6f2/PRrSxJWfUCwAk4/YA/ebrM9uGTj1YONwEvDbU/lI= X-Google-Smtp-Source: ABdhPJyQKGbxwiEHb6lellJtSF8V5TX+UVplyaFvJluyHWrdI8oTO3XxQIxLAAZ9UPc1Icv/maC3refovQVs4zScNM0= X-Received: by 2002:a5d:4ac4:: with SMTP id y4mr8203619wrs.86.1614435396174; Sat, 27 Feb 2021 06:16:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Sat, 27 Feb 2021 09:16:24 -0500 Message-ID: To: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 14:16:40 -0000 > From: "Stefan G=C3=B6ssner" > I copied these comments forward to Github ... for better reading and furt= her commenting. > > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/5= 4 > > I would also like to try out that cool Github discussion tab, Daniel wrot= e about. > I took the liberty of making a request to enable discussions for the repository. Once enabled, it will show up as an option under Settings/Features, and whoever's administering the site can check it, which will make the tab visible. Daniel From nobody Sat Feb 27 07:43:48 2021 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 1CC613A0BC5 for ; Sat, 27 Feb 2021 07:43:47 -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 Or95cCzALXWU for ; Sat, 27 Feb 2021 07:43:42 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E534E3A0BC2 for ; Sat, 27 Feb 2021 07:43:41 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id q23so14132187lji.8 for ; Sat, 27 Feb 2021 07:43:41 -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=tk03jgcT5I7gXoZl2Qe1oWDvdwhCJg6R3zddjm//QM4=; b=A7NDrs9paNyI1N9RDFgn7856lL8L8yErAVVi72PiGuMG9qMPD5KO9hG1KCIERRs+l7 qXUoNdWn/zmyeIncCmB/8FR7fds9NgSuOB7KnVyHpUkkr12OLuWEM9U6FTEmYvOFQJoP X5ZDNDpI1UyGRJarpJXyp/3/yk/hnjJxn+wR3fQNmULyGho8fEdd4OZJxi8llVumYs// jx26UITHwpOeLdcG24OdS6SSKnDCfrDhTyJOiF7IIkr1npWTnSr3VFGcydRcqeO11a8Y zvN99z83UPwT1FO7PuanlLxGxcsefCmBZF8yUwRizhr/yw7OTuINvAkqhXhF69LqbDVZ H7yA== 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=tk03jgcT5I7gXoZl2Qe1oWDvdwhCJg6R3zddjm//QM4=; b=LKNrFyY3H8UdFYqXw3TUEq+oLZtl9wup9mhHUwKUFhhskNsvu06699hALqMyexQEmz P6uA9faxD4hsY5u/N4s2NIPa8KKAhWrSkPjzxtt93mBBKynml3a6biXPsuXjFmLokXvu Uw4x0cG+tBsv1EGMI5jzWV5j8S+O29l04iUN1rU0Ru4WVUBtfenlOgND+9cxoD/YqgqE mHNiIFyFkDR6sOMPU3gqMqaFdZeHmZkYkje7bqkHpIMRbYFdhP0oo9Z+YUDkEkKRj6CX +bj7c92xsI4Ky4jBTk6Iv2vUr1QoG4gdQIMiQhOA4v5VqFkNp1gs1ZiXmvLTIVcPKwu0 Xhng== X-Gm-Message-State: AOAM532jf+1GyaVEdCNSDy8D2r2hvpW+y54ARhR2KvkGn0+xMCLNJxzL y8hEfqYEDdMvjZp9ydiVQNTgyqIHxlPTlW+R6+ReYw== X-Google-Smtp-Source: ABdhPJw6vmWqTrp6DqT30izBrq/oxC/Y8jyU4gVdLY/bBboRzwChK7vRMz1y1NfO8WkdjcdxMNutQaz/bd8N8Disegg= X-Received: by 2002:a05:651c:2125:: with SMTP id a37mr4570601ljq.19.1614440619596; Sat, 27 Feb 2021 07:43:39 -0800 (PST) MIME-Version: 1.0 References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> In-Reply-To: From: Tim Bray Date: Sat, 27 Feb 2021 07:43:28 -0800 Message-ID: To: =?UTF-8?Q?Stefan_G=C3=B6ssner?= Cc: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4742d05bc533fb7" Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 15:43:47 -0000 --000000000000a4742d05bc533fb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On behalf of James and mysell, co-chair hats on: First of all, thanks to Stefan for pulling together that nice list of issues. It needs to be broken up into a bunch of separate issues we can argue about and resolve. If either Stefan or Marko wants to do that fine, otherwise I will in the next couple of days. Secondly, on the subject of WG communication: The WG mailing list isn't optional, there are those who will want to participate and not deal with GitHub etc, they're within their rights. It's archived and searchable and paid for by IETF. The use of GitHub is something of an open question, but it has been successfully applied in multiple WGs, including some of our most highly-trafficked and contentious, to the extent that there are RFCs [8874 , 8875 ] covering how to do it. For the purposes of WG work, James and I would like to combine the mailing list and GitHub in the way that seems to have proven to work. We can't forbid anyone from having Slack conversations but that's entirely optional, you don't have to go there to participate in the WG. On Sat, Feb 27, 2021 at 12:44 AM Stefan G=C3=B6ssner = wrote: > I copied these comments forward to Github ... for better reading and > further commenting. > > https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-jsonpath/issues/5= 4 > > I would also like to try out that cool Github discussion tab, Daniel wrot= e > about. > > thanks > -- > sg > > > Am 26.02.2021 um 19:30 schrieb Stefan G=C3=B6ssner: > > Hello List, > > It has been important to go through this list threads carefully. In fact = I > should have done that at first. Now I can understand the current draft an= d > appreciate the work already done much better. > > I collected some citations (important from my point of view) with comment= s > already in Markdown. > > > ## Title of the specification > > > JSONPath: A query language for JSON data. > *(Carsten Bormann)* > > > I think I=E2=80=99d slightly prefer the term =E2=80=9Csyntax=E2=80=9D t= o =E2=80=9Clanguage=E2=80=9D because > =E2=80=9Cquery language=E2=80=9D has a smell of various things that end w= ith the letters > =E2=80=9CQ=E2=80=9D and =E2=80=9CL=E2=80=9D. But not passionate about th= at. > *(Tim Bray)* > > > JSONPath: A query syntax for JSON. > > Another wild-card idea: JSONPath: Query expressions for jSON > *(Tim Bray)* > > > The beauty of this is that the plural form =E2=80=9Cquery expressions= =E2=80=9D implies a > set of expressions, so it implies =E2=80=9Clanguage=E2=80=9D. It=E2=80= =99s indeed more than the > grammar/syntax of those, so why not talk about the expressions as a whole= . > This also makes it possible to just use =E2=80=9Cfor JSON=E2=80=9D, witho= ut going into > detail what these query expressions operate on. > *(Carsten Bormann)* > > There seems to be an agreement for "*JSONPath: Query expressions for > JSON*". I like that also. > > ## Terminology > > > 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. > *(Daniel P)* > > > 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). > > > > =E2=80=A6 oh, and I forgot the very useful "member". > *(Tim Bray)* > > > =E2=80=A6 and =E2=80=9Celement=E2=80=9D (the things in arrays). *(Carst= en Bormann)* > > > 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=9Cth= e 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 v= alue 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. > *(Carsten Bormann)* > > > I think the key difficulty is whether each (key, value) pair in an > object is "a thing" that can be identified and manipulated and potentiall= y > returned. (If we're talking analogies, then it's analogous to an attribut= e > node in the XDM model). > *(Michael Kay)* > > > ECMA-404 uses "name/value pair", which is what I understand the term > "member" to mean (Douglas Crockford uses "member"). > *(Daniel P)* > > > I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of it as = concatenation of > results, then the result is as expected. > *(Glyn Normington)* > > I understand, that within RFC8259 we have JSON values of different types. > They are structured somehow, which is not so much of interest here. > > But while querying that structure with JSONPath it is vitally important t= o > identify that hierarchical structure as a tree. So in fact we build up a > higher-level construct here. We also need to call "the things" in the tre= e > somehow. I was able to identify > > * "node" or "item" of a tree > * "member" of an object > * "name/value" or "key/value" pair alias "member" > * "element" of an array > > but could not see an agreement here. > > I agree to Glyn calling the term "union" poor (s. below). > > > ## Differentiation from JSON Pointer (JSONPath draft charter) > > > I anticipate being asked "Why is JSON Pointer not sufficient?" Indeed > its abstract says: > > > > JSON Pointer defines a string syntax for identifying a specific value > within a JavaScript Object Notation (JSON) document. > > > >... which sounds awfully similar. If we could include a sentence about > that, or a link to an answer, that might be helpful. > *(Murray S. Kucherawy)* > > > No - it's not similar in concept, they're separate things. If you reall= y > wanted to mention JSON Pointer, you could say something like "Note that > while JSON Pointer (RFC xxxx) is already standardised, it is designed to > provide a reference to a single, specific part of a JSON document, wherea= s > JSONPath provides the ability to query a document and potentially return > multiple values." > *(Mark Nottingham)* > > >The short answer is that JSON pointer is good if you already know the > structure of the JSON data item you want to point into, and you want to > point to exactly one position in there. If you need to do something that > is closer to a =E2=80=9Csearch=E2=80=9D (which might also result in multi= ple positions), > JSONPath gives you more rope. > *(Carsten Bormann)* > > +1 > > ## References to XPath > > > 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)* > > > 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. > *(Glyn Normington)* > > > Someone on StackOverflow today asked a question about JSONPath; they > called it (and tagged it) XPath, we really don't want that kind of > confusion. > > > > In addition, the reference to the XPath specification in 6.2 is out of > date, and the comparison with XPath in Table 2 is very approximate and th= e > terminology inaccurate: for example there is a mention of "node sets", > which exist in XPath 1.0 but not in XPath 2.0, yet the citation is to XPa= th > 2.0. For someone who knows the semantics of XPath the comparison raises a= ll > sorts of questions about sorting of results into document order, > elimination of duplicates etc, which are complications this spec can well > do without. (Though some answers are needed, for example if ..store..pric= e > matches the same price in more than one way, do you get more than one > result? And if not, what does "the same price" actually mean?) > *(Michael Kay)* > > It seemed to be important in 2007, while argumenting to have something > like XPath for JSON. If nowadays the terminology used has changed > significantly with XPath 2.0 and 3.0, we better leave that comparison tab= le > 2 out. I am quite passionless here. > > ## Array Slice Operator > > > Thanks! The ABNF for an array slice in that reference > > ``` > > integer =3D [%x2D] (%x30 / (%x31-39 *%x30-39)) > > > > array-slice =3D [ integer ] ws %x3A ws [ integer ] > > [ ws %x3A ws [ integer ] ] > > ; start:end or start:end:step > > ``` > > is consistent with JMESPath, Python, and my understanding of > ECMASCRIPT 4. > > *(Daniel P)* > > > 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. > *(Glyn Normington)* > > It's good having read this thread and thus understand the current draft > much better. I like the decision to be consistent with Python and also > getting an empty selection set with `step=3D0`. > > FYI: there is a recent proposal for adding slice notation syntax to > JavaScript, currently at stage 1 of the TC39 process. > > https://github.com/tc39/proposal-slice-notation > > Interestingly it won't have a step argument ... > > > https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a= -step-argument-like-python-does > > ... because of syntax collision with the new `this-binding` syntax > proposal `::` > > https://github.com/tc39/proposal-bind-operator > > However, we should not let us influence by this. > > ## Unions > > > I don't think any implementation would remove duplicates from a path > such as `"$.store.book"`. I believe this is only somewhat controversial > in the context of unions [,]. The name "union" suggests that distinct > values be returned, compare with SQL unions. But Stefan Goessner's > implementation doesn't do that, it concatenates all results that meet > each criteria. There are a few JSONPath implementations that produce > real unions with no duplicates instead of concatenated results, but I > don't think that's the consensus. > *(Daniel P)* > > > I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of it as = concatenation of > results, then the result is as expected. > *(Glyn Normington)* > > > I agree with that comment, but it's partly because I'm used to SQL > UNION, > which is different. I prefer the JMESPath term for an analogous construct= , > MultiSelect List, https://jmespath.org/specification.html#multiselect-lis= t. > > *(Daniel P)* > > Introducing the union operator `[,]` simply was meant an analogon to > XPath's operator `'|'`. I cannot tell, if it was a simple combination of > node sets in Xpath 1.0 or a true union without duplicates. I obviously wa= s > not aware of that subtle (essential ?) union characteristic. > > So I fully agree to Glyn Normington's '... the term =E2=80=9Cunion=E2=80= =9D is poor' > statement. Are there some better alternative terms, perhaps 'multi-index > operator', 'index list', 'subscript list', etc.? > > ## Duplicates and Ordering > > > It was my impression that we were talking about duplicated nodes not > duplicated values: > > > > Given th array [10,20,30] > > > > $..[0,1,0] > > > > Would yield only two results [10, 20] > > > > (Not that I'm advocating for removing duplicates, personally I think we > shouldn't) > *(Marko Mikulicic)* > > > You=E2=80=99re framing this as =E2=80=9Cremoving duplicates=E2=80=9D. > Another view is that [10, 20, 10] would be =E2=80=9Cadding duplicates=E2= =80=9D (copies of > the same node). Related are ordering issues: > > > > `$..[1,0] =E2=9E=94 [20, 10] Or [10, 20]` > > > > I would expect the spec will leaves implementations some leeway here, > but that should be based on an examination of existing implementations. > *(Carsten Bormann)* > > > The mental model that leads to omitting duplicate nodes in the output i= s > "selection": if you take an input array and select nodes with index 0,1 o= r > 0, you get only 2 results (since selecting an index twice has no effect). > > > >OTOH, if you opt for a "collect" model, whenever you encounter a node > that > matches that query you add it to the result stream, thus the same nodes > can > be present multiple times in the result. > > > >I have a slight preference for the "collect" model, because the general > case in jsonpath is to collect things that appear at various points in th= e > json tree. For example: > > > >`{"a": {"b": 1, "c": 2}, "d": 3}, $.a.b yields [1] and not > {"a":{"b":1}}` > > > >(i.e. jsonpath is not a filter and view operation but a pick and gather > operation) > *(Marko Mikulicic)* > > > In implementations that support paths (the majority don't), the query > function takes a parameter that indicates values or paths. In both > cases the query returns a JSON array of JSON values, in the latter > case, a JSON array of normalized paths. > *(Daniel P)* > > I must confess to never having thought about duplicates, let alone wantin= g > to eliminate them. So I do like Marko's comparison of 'selection-model' v= s. > 'collection-model' a lot. I would opt for the latter. In this sense the > result of a 'JSONPath query expression' should be termed a 'collection'. > > Regarding ordering I see something like a 'natural ordering', according t= o > which > > `$..[0,1] =E2=9E=94 [10, 20]` > `$..[1,0] =E2=9E=94 [20, 10]` > > would result with the example above. > > I do understand the use cases for reordering, duplicates removal, > filtering, etc.. But this can always be seen as a postprocessing step on > the resulting collection by handing it over to accompanying tools (think = of > pipe operator). > > Of course this cannot work on the result collection of values alone (s. > duplicate nodes vs. duplicate values above), it rather requires a > collection of (normalized) pathes. In this sense, I like this view: > > > In my opinion the right balance between powerfulness and enabling > simple implementations has been so far one of the key factors that > made JSONPath popular over other alternatives, even if it lacks > support for aggregation functions. > *(Davide Bettio)* > > ## Filter Expressions > > > Related to that, it would be helpful to determine if JSONPath filters > apply to both JSON objects and arrays, or only to JSON arrays. > *(Daniel P)* > > > I would support restricting filters to arrays, if others agree. > *(Glyn Normington)* > > I tend to let implementations and their "normative force of the factual" > decide here or in doubt agree to Glyn's restriction to arrays. > > I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` > addresses the array itself and implies that array has a `length` property= . > In filter expression examples `'@'` more consistently addresses the curre= nt > array element. > > The invocation of 'the underlying scripting engine' wasn't meant a seriou= s > normative aspect, but rather a quick and dirty solution for JavaScript an= d > PHP implementations at that time. > > > ### Corner Case > > > Consider this perfectly legal JSON object > > > > ```{ "ab": 0, "'a.b": 1, "a-b": 2, "a": { "b": 3 } }``` > > > >So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-b']` is 2. You'd > like to say `$.a-b` but lots of libraries will refuse it because `"a-b"` = is > not a legal JavaScript "name" construct, that's why you have to say > `$['a-b']`. > > > > But suppose your library would accept `$.a-b`. Then `$.a-b` and > `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b']` wouldn't. > *(Tim Bray)* > > Hmm ... this seems to be a hint to better exclude `'-'` from > dot-child-selector syntax. I think I have read more discussion about that= , > currently don't know where. > > ## Respect Implementations > > > As I mentioned in the session, I think there's a non-trivial amount of > risk here that some implementations won't be willing or able to move away > from their current behaviours, even if interoperability would improve if > they did so. However, there are ways to mitigate that (e.g., a separate > 'rfcxxxx compliant' mode). Even so, it will be important to get good > participation from as many current implementers as possible. > *(Mark Nottingham)* > > > The WG will develop a standards-track JSONPath specification that > is technically sound and complete, based on the common semantics > and other aspects of existing implementations. Where there are > differences, the working group will analyze those differences and > make choices that rough consensus considers technically best, with > an aim toward minimizing disruption among the different JSONPath > implementations. > *(Barry Leiba)* > > > I'm OK with this, but for context: I've been a pretty intense JSONPath > user > in recent years, and AFAIK the spec, and the implementations, are mostly > OK, so the choice between "make JSONPath good" and "don't invalidate > implementations" is unlikely to come up. If it did, my predisposition > would > be to err on the side of not breaking implementations, but I don't think > that's inconsistent with Barry's text. > *(Tim Bray)* > > +1 to all. > > ## Error Handling > > > My mental model at the moment is that a JSONPath expression can be vali= d > or erroneous; application of a valid expression yields a result (which ma= y > be empty), but does not raise errors. That may not be the right model fo= r > all applications. > *(Carsten Bormann)* > > > The general approach that I've seen several times (including my > Elixir implementation) is that an error is raised when there is a > syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises > an error. Conversely a valid expression applied to a bogus input never > raises an error (e.g. `$.foo.bar on "test" evals as []`). > *(Davide Bettio)* > > > 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)* > > > 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. > *(Carsten Bormann)* > > I like and totally agree with the **forgiving mental model**, so having > only syntax errors, which do not dependent on data. > > Thanks > -- > sg > > > -- > Jsonpath mailing list > Jsonpath@ietf.org > https://www.ietf.org/mailman/listinfo/jsonpath > --000000000000a4742d05bc533fb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On be= half of James and mysell, co-chair hats on: First of all, thanks to Stefan = for pulling together that nice list of issues.=C2=A0 It needs to be broken = up into a bunch of separate issues we can argue about and resolve.=C2=A0 If= either Stefan or Marko wants to do that fine, otherwise I will in the next= couple of days.

Second= ly, on the subject of WG communication:=C2=A0

The WG mailing list isn't optional, there are th= ose who will want to participate and not deal with GitHub etc, they're = within their rights.=C2=A0 It's archived and searchable and paid for by= IETF.=C2=A0
<= br>
The use of= GitHub is something of an open question, but it has been successfully appl= ied in multiple WGs, including some of our most highly-trafficked and conte= ntious, to the extent that there are RFCs [8874,=C2=A08875] covering how to do it.=C2= =A0 For the purposes of WG work, James and I would like to combine the mail= ing list and GitHub in the way that seems to have proven to work.=C2=A0 We = can't forbid anyone from having Slack conversations but that's enti= rely optional, you don't have to go there to participate in the WG. =C2= =A0

On Sat, Feb 27, 2021 at 12:44 AM Stefan G=C3=B6ssner &= lt;stefan@goessner= .net> wrote:
=20 =20 =20
I copied these comments forward to Github ... for better reading and further commenting.

https://github.com/ietf-wg-jsonpath/draft-iet= f-jsonpath-jsonpath/issues/54

I would also like to try out that cool Github discussion tab, Daniel wrote about.

thanks
--
sg


Am 26.02.2021 um 19:30 schrieb Stefan G=C3=B6ssner:
Hello List,

It has been important to go through this list threads carefully. In fact I should have done that at first. Now I can understand the current draft and appreciate the work already done much better.

I collected some citations (important from my point of view) with comments already in Markdown.


## Title of the specification

> JSONPath: A query language for JSON data.
*(Carsten Bormann)*

> I think I=E2=80=99d slightly prefer the term =E2=80=9Csyntax=E2= =80=9D to =E2=80=9Clanguage=E2=80=9D because =E2=80=9Cquery language=E2=80=9D has a smell of various thing= s that end with the letters =E2=80=9CQ=E2=80=9D and =E2=80=9CL=E2=80=9D.=C2=A0 B= ut not passionate about that.
*(Tim Bray)*

> JSONPath: A query syntax for JSON.
> Another wild-card idea: JSONPath: Query expressions for jSON
*(Tim Bray)*

> The beauty of this is that the plural form =E2=80=9Cquery expressions=E2=80=9D implies a set of expressions, so it implies =E2=80=9Clanguage=E2=80=9D.=C2=A0 It=E2=80=99s indeed more than the g= rammar/syntax of those, so why not talk about the expressions as a whole.=C2=A0 This also makes = it possible to just use =E2=80=9Cfor JSON=E2=80=9D, without going into d= etail what these query expressions operate on.
*(Carsten Bormann)*

There seems to be an agreement for "*JSONPath: Query expressions for JSON*". I like that also.

## Terminology

> My own view is that the terminology should stay consistent with RFC
8259, and that the word "object" should not be used for ite= ms that are
not JSON objects in the sense of RFC 8259.
*(Daniel P)*

> 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.=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 (and build up to higher-level
constructs as required for JSONPath).
>
> =E2=80=A6 oh, and I forgot the very useful "member".
*(Tim Bray)*

> =E2=80=A6 and =E2=80=9Celement=E2=80=9D (the things in arrays). = *(Carsten Bormann)*

> The problem with JSON value is that it also can be quite confusing due to the usual use of that term.=C2=A0 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, inclu= ding the tree itself=E2=80=9D.=C2=A0 But if JSON value is the only term we= have, it has to be.=C2=A0 Hence my preference to talk about data items when I mean the items themselves and not their =E2=80=9Cvalue=E2=80=9D.
*(Carsten Bormann)*

> I think the key difficulty is whether each (key, value) pair in an object is "a thing" that can be identified and manipu= lated and potentially returned. (If we're talking analogies, then it= 9;s analogous to an attribute node in the XDM model).
*(Michael Kay)*

> ECMA-404 uses "name/value pair", which is what I under= stand the term
"member" to mean (Douglas Crockford uses "member"= ).
*(Daniel P)*

> I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of= it as concatenation of results, then the result is as expected.
*(Glyn Normington)*

I understand, that within RFC8259 we have JSON values of different types. They are structured somehow, which is not so much of interest here.

But while querying that structure with JSONPath it is vitally important to identify that hierarchical structure as a tree. So in fact we build up a higher-level construct here. We also need to call "the things" in the tree somehow. I was able to identi= fy

* "node" or "item" of a tree
* "member" of an object
* "name/value" or "key/value" pair alias "me= mber"
* "element" of an array

but could not see an agreement here.

I agree to Glyn calling the term "union" poor (s. below).


## Differentiation from JSON Pointer (JSONPath draft charter)

> I anticipate being asked "Why is JSON Pointer not sufficient?" Indeed its abstract says:
>
>=C2=A0=C2=A0 JSON Pointer defines a string syntax for identifying= a specific value within a JavaScript Object Notation (JSON) document.
>
>... which sounds awfully similar.=C2=A0 If we could include a sentence about
that, or a link to an answer, that might be helpful.
*(Murray S. Kucherawy)*

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

>The short answer is that JSON pointer is good if you already know the structure of the JSON data item you want to point into, and you want to point to exactly one position in there.=C2=A0 If you need to do something that is closer to a =E2=80=9Csearch=E2=80=9D (wh= ich might also result in multiple positions), JSONPath gives you more rope.
*(Carsten Bormann)*

+1

## References to XPath

> 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)*

> 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.
*(Glyn Normington)*

> Someone on StackOverflow today asked a question about JSONPath; they called it (and tagged it) XPath, we really don't want that kind of confusion.
>
> In addition, the reference to the XPath specification in 6.2 is out of date, and the comparison with XPath in Table 2 is very approximate and the terminology inaccurate: for example there is a mention of "node sets", which exist in XPath 1.0 but not in= XPath 2.0, yet the citation is to XPath 2.0. For someone who knows the semantics of XPath the comparison raises all sorts of questions about sorting of results into document order, elimination of duplicates etc, which are complications this spec can well do without. (Though some answers are needed, for example if ..store..price matches the same price in more than one way, do you get more than one result? And if not, what does "the same price&= quot; actually mean?)
*(Michael Kay)*

It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here.

## Array Slice Operator

> Thanks! The ABNF for an array slice in that reference
> ```
> integer =3D [%x2D] (%x30 / (%x31-39 *%x30-39))
>
> array-slice =3D [ integer ] ws %x3A ws [ integer ]
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ ws %x3A ws [ in= teger ] ]
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; start:end or start:end:step
> ```
> is consistent with JMESPath, Python, and my understanding of
ECMASCRIPT 4.
> *(Daniel P)*

> 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.
*(Glyn Normington)*

It's good having read this thread and thus understand the current draft much better. I like the decision to be consistent with Python and also getting an empty selection set with `step=3D0`.

FYI: there is a recent proposal for adding slice notation syntax to JavaScript, currently at stage 1 of the TC39 process.

https://github.com/tc39/proposal-slice-notation

Interestingly it won't have a step argument ...

https://g= ithub.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-step-argum= ent-like-python-does

... because of syntax collision with the new `this-binding` syntax proposal `::`

https://github.com/tc39/proposal-bind-operator

However, we should not let us influence by this.

## Unions

> I don't think any implementation would remove duplicates fro= m a path
such as `"$.store.book"`. I believe this is only somewhat controversial
in the context of unions [,]. The name "union" suggests tha= t distinct
values be returned, compare with SQL unions. But Stefan Goessner'= s
implementation doesn't do that, it concatenates all results that meet
each criteria. There are a few JSONPath implementations that produce
real unions with no duplicates instead of concatenated results, but I
don't think that's the consensus.
*(Daniel P)*

> I think the term =E2=80=9Cunion=E2=80=9D is poor. If we think of= it as concatenation of results, then the result is as expected.
*(Glyn Normington)*

> I agree with that comment, but it's partly because I'm u= sed to SQL UNION,
which is different. I prefer the JMESPath term for an analogous construct,
MultiSelect List, https://jmespath.org/specification.html= #multiselect-list.
*(Daniel P)*

Introducing the union operator `[,]` simply was meant an analogon to XPath's operator `'|'`. I cannot tell, if it was a sim= ple combination of node sets in Xpath 1.0 or a true union without duplicates. I obviously was not aware of that subtle (essential ?) union characteristic.

So I fully agree to Glyn Normington's '... the term =E2=80=9C= union=E2=80=9D is poor' statement. Are there some better alternative terms, perhaps 'multi-index operator', 'index list', 'subscript = list', etc.?

## Duplicates and Ordering

> It was my impression that we were talking about duplicated nodes not
duplicated values:
>
> Given th array [10,20,30]
>
> $..[0,1,0]
>
> Would yield only two results [10, 20]
>
> (Not that I'm advocating for removing duplicates, personally I think we
shouldn't)
*(Marko Mikulicic)*

> You=E2=80=99re framing this as =E2=80=9Cremoving duplicates=E2= =80=9D.
Another view is that [10, 20, 10] would be =E2=80=9Cadding duplicates= =E2=80=9D (copies of the same node). Related are ordering issues:
>
> `$..[1,0] =E2=9E=94 [20, 10] Or [10, 20]`
>
> I would expect the spec will leaves implementations some leeway here, but that should be based on an examination of existing implementations.
*(Carsten Bormann)*

> The mental model that leads to omitting duplicate nodes in the output is
"selection": if you take an input array and select nodes wi= th index 0,1 or
0, you get only 2 results (since selecting an index twice has no effect).
>
>OTOH, if you opt for a "collect" model, whenever you en= counter a node that
matches that query you add it to the result stream, thus the same nodes can
be present multiple times in the result.
>
>I have a slight preference for the "collect" model, bec= ause the general
case in jsonpath is to collect things that appear at various points in the
json tree. For example:
>
>`{"a": {"b": 1, "c": 2}, "d&qu= ot;: 3},=C2=A0 $.a.b yields [1] and not {"a":{"b":1}}`
>
>(i.e. jsonpath is not a filter and view operation but a pick and gather
operation)
*(Marko Mikulicic)*

> In implementations that support paths (the majority don't), the query
function takes a parameter that indicates values or paths. In both
cases the query returns a JSON array of JSON values, in the latter
case, a JSON array of normalized paths.
*(Daniel P)*

I must confess to never having thought about duplicates, let alone wanting to eliminate them. So I do like Marko's comparison of 'selection-model' vs. 'collection-model' a lot. I wou= ld opt for the latter. In this sense the result of a 'JSONPath query expression' should be termed a 'collection'.

Regarding ordering I see something like a 'natural ordering', according to which

`$..[0,1] =E2=9E=94 [10, 20]`
`$..[1,0] =E2=9E=94 [20, 10]`

would result with the example above.

I do understand the use cases for reordering, duplicates removal, filtering, etc.. But this can always be seen as a postprocessing step on the resulting collection by handing it over to accompanying tools (think of pipe operator).

Of course this cannot work on the result collection of values alone (s. duplicate nodes vs. duplicate values above), it rather requires a collection of (normalized) pathes. In this sense, I like this view:

> In my opinion the right balance between powerfulness and enabling
simple implementations has been so far one of the key factors that
made JSONPath popular over other alternatives, even if it lacks
support for aggregation functions.
*(Davide Bettio)*

## Filter Expressions

> Related to that, it would be helpful to determine if JSONPath filters
apply to both JSON objects and arrays, or only to JSON arrays.
*(Daniel P)*

> I would support restricting filters to arrays, if others agree.
*(Glyn Normington)*

I tend to let implementations and their "normative force of the factual" decide here or in doubt agree to Glyn's restriction= to arrays.

I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` addresses the array itself and implies that array has a `length` property. In filter expression examples `'@'` more consistently addresses the current array element.

The invocation of 'the underlying scripting engine' wasn'= t meant a serious normative aspect, but rather a quick and dirty solution for JavaScript and PHP implementations at that time.


### Corner Case

> Consider this perfectly legal JSON object
>
> ```{ "ab": 0,=C2=A0 "'a.b": 1,=C2=A0 &qu= ot;a-b": 2, "a": { "b": 3 } }```
>
>So `$.ab` is 0, `$.a.b` is 3, `$['a.b']` is 1, `$['a-= b']` is 2. You'd like to say `$.a-b` but lots of libraries will refuse it because `"a-b"` is not a legal JavaScript "name" = construct, that's why you have to say `$['a-b']`.
>
> But suppose your library would accept `$.a-b`.=C2=A0 Then `$.a-b= ` and `$['a-b']` would be synonyms, but `$.a.b` and `$['a.b= ']` wouldn't.
*(Tim Bray)*

Hmm ... this seems to be a hint to better exclude `'-'` from dot-child-selector syntax. I think I have read more discussion about that, currently don't know where.

## Respect Implementations

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

> The WG will develop a standards-track JSONPath specification that
is technically sound and complete, based on the common semantics
and other aspects of existing implementations.=C2=A0 Where there are
differences, the working group will analyze those differences and
make choices that rough consensus considers technically best, with
an aim toward minimizing disruption among the different JSONPath
implementations.
*(Barry Leiba)*

> I'm OK with this, but for context: I've been a pretty in= tense JSONPath user
in recent years, and AFAIK the spec, and the implementations, are mostly
OK, so the choice between "make JSONPath good" and "do= n't invalidate
implementations" is unlikely to come up. If it did, my predisposition would
be to err on the side of not breaking implementations, but I don'= t think
that's inconsistent with Barry's text.
*(Tim Bray)*

+1 to all.

## Error Handling

> My mental model at the moment is that a JSONPath expression can be valid or erroneous; application of a valid expression yields a result (which may be empty), but does not raise errors.=C2= =A0 That may not be the right model for all applications.
*(Carsten Bormann)*

> The=C2=A0 general approach that I've seen several times (inc= luding my
Elixir implementation) is that an error is raised when there is a
syntax error, therefore an invalid expression (e.g. $.foo[[5]) raises
an error. Conversely a valid expression applied to a bogus input never
raises an error (e.g. `$.foo.bar on "test" evals as []`).
*(Davide Bettio)*

> On the whole I think JSONPath is designed to be "forgiving&= quot;, 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)*

> 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.
*(Carsten Bormann)*

I like and totally agree with the *forgiving mental m= odel*, so having=C2=A0 only syntax errors, which do not dependent on data.

Thanks
--
sg

--
Jsonpath mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
--000000000000a4742d05bc533fb7-- From nobody Sat Feb 27 09:18:54 2021 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 362AE3A0EB5 for ; Sat, 27 Feb 2021 09:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 wRxnXYv7fyVu for ; Sat, 27 Feb 2021 09:18:51 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 87C083A0EAF for ; Sat, 27 Feb 2021 09:18:51 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id bd6so1717910edb.10 for ; Sat, 27 Feb 2021 09:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=2OJsVkOg65Wg3idc0h7ry6OX8aAT4VjC6NBYrLNPSfw=; b=qXzIi5Taz9XCFBkzlewTGTAsDmKOFnUJvakfkQ4UPPxhnV+ybDOOr88vQeY2TpMCkK dPnyJzimcz5vBsZtfBIc3orLvaFaef9kj0LVPBeqMofeoJN9IkRkwcvsQ9MHN7bSRgE1 BrMFfbDCAdqG/S6CQWuo5kDMtHaE2amSDcYyFpi+X0zbLAyLK+gkU7c4z7p+bmQSjbdD 368FZpy1IuUPnVFTqHt7xVH+laEpN/r6ZJwGuvGsoVzc2+PznGjPqg2E31nzNHBF3FRN lAUVxKYoPkwRX6VgINxxObN2LuATYwusZNisu97K9oxlBHYEfGd/FruHmUe16XndEGn4 VD3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2OJsVkOg65Wg3idc0h7ry6OX8aAT4VjC6NBYrLNPSfw=; b=HN5/DVpOOIM2TgPNzn3BQLIWdnMU9c5cUz1AN5jw0VvkmfQZuk2E3RB4dW75zdQq7n umKHtDIapTJxk+YdxQ2x1WQzMJjAx0cP4nDzAIw1UvNPeVYap0VTjR4WZmCWsVkGxrTe Ky12ZOG3Bp9zm4IVQLe9/qdkJKRPFQHY84aq+jGDZIVesI5bGh+vhfUJy67HtcNwR6j0 sjbC9zOOuIvZ3WaadBGjixL7b1Apoq5LuYZTpDs9Pf2kKuJ9CW/uEbmL5dNbRDZf1AmQ 2vnvDEHW5IdYFzAofIoF2JWG6TE2b/KoAS2IZv8Q5VGS9cdoU8by/yZfFUdU2XDubw/+ nlyQ== X-Gm-Message-State: AOAM531AvhU/hAjqA22mNr4bTvejmYLIiwgDoycY6EZtB+IgHP0yN1Y8 wcubYNwnAPJJJ1NbwRLeqTHPAu3nODU= X-Google-Smtp-Source: ABdhPJz45zC+BieXqp3zBZYyzpxV+9kRsaXUvwYbihCb9eV066x6NKkxGW8BJ0fWhhKdJSlVH7oUQg== X-Received: by 2002:aa7:cc03:: with SMTP id q3mr9017566edt.366.1614446329576; Sat, 27 Feb 2021 09:18:49 -0800 (PST) Received: from [192.168.1.95] (71.224.125.91.dyn.plus.net. [91.125.224.71]) by smtp.gmail.com with ESMTPSA id n24sm8936840edr.62.2021.02.27.09.18.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Feb 2021 09:18:49 -0800 (PST) To: jsonpath@ietf.org References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> <2126411059.183763.1614375732675@mail.yahoo.com> <83EA4040-0E7D-4DDB-AF2C-DD8DD59B22B3@tzi.org> From: Glyn Normington Message-ID: Date: Sat, 27 Feb 2021 17:18:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <83EA4040-0E7D-4DDB-AF2C-DD8DD59B22B3@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 17:18:53 -0000 I created the jsonpath-standard Slack workspace merely to get a conversation going about standardising JSONPath. I've toyed with deleting that workspace, but one or two people seem to find it useful, so I've held off. However Slack is not great for several reasons including: * it's ephemeral (since we can't pay for a license indefinitely and there is no "free" for open source, etc. pricing option) * its contents don't show up in internet searches * access to it depends on proprietary code which will probably be superseded by something else in a decade or two, if not sooner. https://github.com/dutchcoders/slackarchive could be part of a solution to some of these problems, but it would need investment and would also need hosting somewhere, such as at the IETF. On 26/02/2021 21:59, Carsten Bormann wrote: > Hi Greg, > > at this point I’m going to stop supplying additional input to this discussion. > > I think I made my point why it is useful to automatically, effortlessly archive the WG proceedings. > We have a lot of manual “policies” of the kind you are suggesting. > Of course, they are not working. Why should they? > > I did not provide an opinion on using slack (just in case you care: I personally don’t like that specific tool, but the WG as a whole has to choose mechanisms it is comfortable with, and I don’t want to rain on the party of the people who do like it). This is for the chairs to decide. > > I’d still need an answer for my question, which is whether it is possible to maintain independent archive copies of slack discussions. Maybe we can find out from other IETF groups that are contemplating using slack. > > Grüße, Carsten > > >> On 2021-02-26, at 22:42, Greg Dennis wrote: >> >> The difference is that we want discussions that can influence the spec archived. Anything else is superfluous. If we make a policy that such conversations MUST be summarized (at least) in an archival medium (here or GitHub), then both of our conditions are satisfied: you get archives of the important stuff, and we also get an easier comms mechanism. From nobody Sat Feb 27 11:14:32 2021 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 226EB3A12C0 for ; Sat, 27 Feb 2021 11:14:31 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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 Yy1SSOHAUxS6 for ; Sat, 27 Feb 2021 11:14: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 3B8883A12BE for ; Sat, 27 Feb 2021 11:14:26 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4Dnx693bSwzyhc; Sat, 27 Feb 2021 20:14: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: Sat, 27 Feb 2021 20:14:25 +0100 Cc: jsonpath@ietf.org X-Mao-Original-Outgoing-Id: 636146065.032149-6fad5cffda7f1dd1fdf2a3cc3f5f5bbb Content-Transfer-Encoding: quoted-printable Message-Id: <380AD158-6728-4289-BEA2-61121E2A5EA2@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> <2126411059.183763.1614375732675@mail.yahoo.com> <83EA4040-0E7D-4DDB-AF2C-DD8DD59B22B3@tzi.org> To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 19:14:31 -0000 On 2021-02-27, at 18:18, Glyn Normington = wrote: >=20 > I've toyed with deleting that workspace, but one or two people seem to = find it useful, so I've held off. Fragmentation is a big problem in standardization groups. It should not be stimulated lightly. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Feb 27 12:37:38 2021 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 78B063A13DD for ; Sat, 27 Feb 2021 12:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.181 X-Spam-Level: X-Spam-Status: No, score=-0.181 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.915, XM_RANDOM=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 9RK5nzuwpvkn for ; Sat, 27 Feb 2021 12:37:35 -0800 (PST) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (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 C7AB43A13DA for ; Sat, 27 Feb 2021 12:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614458253; bh=WmubyzsjPu7OCHbg6LlffpoDsRPMEyO+vplFjNHTfy4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=C4yEwAVTGdlkcYO0uJ3DPrqKeTM9r7q7Rzb8dYyhCeSYZJP3QT3inc9gXBDxvjiMzP3t0SVCQTUvWxSk+H2or69aoQaVfyvmbKRfQXXP7WULIdpTUskn4bO7YgyUZzDrciR/CRIqeLj3CeCpZ4IIPUZTNrKrmr6XcsrJS4AafmbLvVsoKfRtWfKclpDKpu5mvO/Rd36ABQ4JMAXCLHp9Z/5Hbt+/R7w0LSKWPKUpquDpQGdd0Vs/sBapCHNwlPqA1XCny3TBJ3PWhSXk6kLbmPdDpt7WyU+YMaNKHanDWWiCnonRzhsb1cUFY8Mj6/Uu07WHFlG+nbxo9RlF3YPWZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614458253; bh=QHGmOPNWAaERWpmGw7v1GLaYmdmwzG2QnFNX98bMIES=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=GQDNnXby3hqgMp4uiBmMktunc2lx4f0nhDoy4mB36nv4exX+hGGPYVRBjrryHRL4UF+8pCBHRzWmffrk7SKe5zQZfBY7CSfIVa0B/SfmIgVJJwoDxm6aZWTnHina1ja8R8huh3OFFMabupBD4jSAHwwUC+7Gl7QF56Sab7nESvhxAXKQgdpIeqH2ylFTsdo8J9ikTJ5jWqFYUoxmK3Q82XXb0u/9+dm42r5/PNWU7/ScAcD4wzdCLxF3MmW9QW8B3sMTJV8I7CKRFY4l6R7ILmzmZpaqS29wdrb6GX5RXpjC+mBUlGeAPUwdwJOvczHNr9RDI7xzGgFzqwt3Vh2zXQ== X-YMail-OSG: 8MjHtXcVM1lcGQls__HCCss9mHZK9QNn4eN95N7Ca76KQdXwCicKXFFjjIQHXwM zfsNPE5OcV1ZXMLKLa7LCViNnJIvrBo2wih1UWfqfSn9UQsDOp64Byvew14rhm_sCzdM8kGHdHj_ VzhF1xJ5kXrLVm37AnF4jWqNfMouqcX3d3Rx.Io19ubfV_AX3p9CnAAf3lE6KVT8oc1G2vFX2c0g TxyYbkAd.cknLMnzQIWPG8CiiEqkOzD4NbVqShPWFfL4rB0WZizdIoQx.iFHrd3MXa91GR5QUEwV Xs7gTeBgS9k4enVv7j6MHUzDiuHAZVFV_ojO0EmREQZRKGPXp5kpGbzwFgbrzzhsyr6_9t8zSvLW zxKMQgXz84L56XiBCEZhMqxuWoFYMDwEl6NAqKUlxEa8H_4RAPd0Qm7Sll.e9AaPki_GcBxOcuXJ XtATQ6QDhgEAw.B8lGIRC2u1RIlEhXVJAxYzNsa0cBg2GUR4EuwDErip83GU5kQD1tQxsFeRC4GT MZnI5w7.XVO96ROEJlS2JqxKsuTZVlknUOqHPlesh4b7EWU1VmOXC5YyE8dcSe3IYXS_ykgyZCt7 rN5lzDqZET0m160Be2Fg8mKHP6NJ63cLisTbGPWSpE.ybSvp02heEWZH._BxOlpsK_vyd1bmjvBA 9uhwiCgQ807ofQs7d437ShO0fI9N3cEkwdodxCPmZYk4d0wfC2UbdVLsLW3C4QvkHi43BQiWQurk 5mrtHiV5PlrdIH0.0227W4RO2XvdjDlZH_0DAFV.uJgoIp26nGiirwC5OoG.h9tDIcc8nSV7bC4P kWSqa2UV99FuCUbb_UR6fJ4TlGKWG30Gv7eXNphaOKvwJrCejK3xbLQZO5T0BJPJLJd89uEZbubO LMFhikZ_XKvdx2xxE_3gApq4rJAuPUBjCMFrirYWzBhddpAUYEklqK6sXzMkyEPeHEXJ_duVSBRV AZtMgpdPsrNivDOj.AT.yY2gA1w9BdaAVbtfwjSfUkoMbUUoOTViru9Ul7NjmQToWGVxR2JRscum Kg1_pE2W7VDAYP7jaI5WIVqdR_givwk7tVliAVabcdavCS5b140DjFXenICCyq6b.9HpFY5_czyc uqLuNmIl1AzmUN0HiI1Ga6e6veWrHIatkSoPnAQgWkCr7xq4zqKBppj.AFl2.xRxcyJQb61jH5cb jwMVVpFt5aWh3GuPHe6knnm8ma59RU_1E.ZOZBa5Yo3biK9PH2ObiBWnLDTd0nU555p6QRTzcHhV Fvcmp7RlRVMLg9qD1d6YxAh6T.I37FPZnieJIVHur0N8ND96KK4DlA69H0pdvMAlcj6TZV90JGce j3GNH5ymAUQf58PL.B1NXaKSn_k8ojfUVHC7b6RxaSw9w9ZA0vgA8qa8Zoc4mAe.PvpF2KqaTleO YoD8KjS9xyTETt4VG4ywVydkCj7ioP_5oywVw0jBXKIBgdUWRfBVJ4G2uXEu_cHk_lUMq1RvFlug TmVGQgDKyUCwOGc0DV4xqJ..gM6vTVKScId_aPhhoi03mZJBxLyUmJ.fQ92VREtHLcgWbpfMe0f4 mNypvNs_OHVN_ay7gz8h_ADLJReQ4nLjOut2Mmvwzu9Sy_edHXEiiV5Ht1BzWO4wkP06hoLa0bUF B6dIvOjmL2Dn5w7BrUY3lX7RDbLLM1lRMqCFSZvSyiZIX6hBroP_EDIq7m.K2fst3vjvlldCQOKn GkDcy9c2kQp0.FX8fJi2C3v1vDh7PNaDqEh4fACswfsZLLgVreBgx_LSJMXsOChZMEj..27abj52 yJpsAumYaP5UCrxbbm.8Pccfx88SPEdXeovd4DFH8RlljsKWAOThpufnHRTLX745Z4iYJPMZ0ovD rHAVx8Vlg_jGa8G0s48x2eupqZeGgcE4307scIrqnLMPXblIzrUTM9zXlVC9ZqDpU02xF8yZmH.I i41Aqndtudo9EMj7p4WCgQrQwdKhBc5mjuhncCY65waRFc3IxYri7Y4z7u4leru460bX8J2H7DTt vff4FFGdTDkNKyDRnW31W3LsMnniXkniVIGPLs91TzwTd55QWh9bp5TaWyRZE8LfIuAnKfO.u28o 5JJ6JtzaL8sPZVrDfqPiMq7owYkZft1p_U5uOEKen0Jvh24rKjnpbqPFxUKXNRskF8cd2mkwjX5R 8zEIH.vlx4IwmyJwBcjTaXZGAnxuAEtdZ_Thf5PNvUHheNFZo.ctEt_11VmoveQZbfYez9Yiv271 SjaHl_4BeHWc4bSaFCg8.pv68WrzxBeEsYAIBAGOatoIsZoBL7Isw2p_ADe2ikrJ_XpcoSKRjBKZ .jtYLt.i7RqIQWwxRXx7BS_cFB1bN25hr1N3o.lA.VK1X7D9z3PDV_U_D.8m05ui4BJxHWWQSHjy vTNdDtJ0hFoxYOOLnh683wg0KJ5zrWVRFjnxEp2kUbpeMf2DQxNM1ZyDdBKZJqV8K21PqXJMJBcH HGugdmRB5gpwIIESaXIsv.i5Z68B5uGHgaAig.6ZIzswZiv.SHvH7nAZehetHNzR.fopLH0t0F.j so7gmbKqItQJz14ew2b4Dhr3tx8I5y36RbOEmaIxPCmK7VTAQx6foDgYKh3ECy77cN2DHE3zovpX IbIuEFSb75Xg1pCv_qj1C9YBHx6FALKObWLWdArO5mIE30VI0JfMFxISepkP3nIMaPmL0yIu36Lt Y7VYWTg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Sat, 27 Feb 2021 20:37:33 +0000 Date: Sat, 27 Feb 2021 20:37:26 +0000 (UTC) From: Greg Dennis Reply-To: Greg Dennis To: cabo@tzi.org, Carsten Bormann , Glyn Normington Cc: jsonpath@ietf.org Message-ID: <473018687.319278.1614458246139@mail.yahoo.com> In-Reply-To: <380AD158-6728-4289-BEA2-61121E2A5EA2@tzi.org> References: <98ed1a4f-82fd-3f94-a707-8569f89a5041@goessner.net> <502566941.150044.1614366732927@mail.yahoo.com> <280EE68C-F1A7-4863-8F5F-7F544F431973@tzi.org> <350059548.134171.1614369123233@mail.yahoo.com> <1576492499.98241.1614369511559@mail.yahoo.com> <1157333423.170620.1614370476963@mail.yahoo.com> <93F527B6-CC03-475D-93E1-AAC9CEB4B5A8@tzi.org> <2126411059.183763.1614375732675@mail.yahoo.com> <83EA4040-0E7D-4DDB-AF2C-DD8DD59B22B3@tzi.org> <380AD158-6728-4289-BEA2-61121E2A5EA2@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_319277_2087990325.1614458246138" X-Mailer: WebService/1.1.17828 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/6.19.4; Android/10; QKQ1.190716.003; OnePlus6; OnePlus; ONEPLUS A6003; 5.87; 2087x1080; ) Archived-At: Subject: Re: [Jsonpath] Some Comments ... 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: Sat, 27 Feb 2021 20:37:36 -0000 ------=_Part_319277_2087990325.1614458246138 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All of those points against Slack are valid.=C2=A0 However, I have found th= at it has been invaluable in building a community around JSON Schema that o= therwise wouldn't have existed. - End users get to ask questions, even if just curious and want to explore = the technology.- Implementation providers (like myself) get to share approa= ches, which results in stronger implementations.- Unrelated personal conver= sations occur that help people get to know each other (this DEFINITELY does= n't need to be archived).=C2=A0 This is often facilitated by private channe= ls and conversations. The point behind the Slack workspace is that it builds community.=C2=A0 Com= munity is essential to the success of a project like this.=C2=A0 If you hav= e issue with Slack specifically, whatever, but there needs to be SOME casua= l space for off-hand discussion.=C2=A0 Gitter or Discourse are also great o= ptions for this.=C2=A0 An email list will NOT create a community like these= tools can. I've built relationships with the maintainers that I never would have had w= ithout a more social discussion platform.=C2=A0 I've even earned their trus= t and become a co-author of the spec myself. If you're worried about discussions that need to be archived occurring over= these tools, we need to be open, explicit, and strict about pushing people= to move to an archival medium.=C2=A0 It's not a difficult thing to do, and= I'm happy to help enforce such a policy.=C2=A0 As I mentioned, we have bee= n doing this for years at JSON Schema.=C2=A0 We're aware that conversations= disappear after some time, and it's actually a driver for us to make sure = important issues get out to GitHub. Your welcome to come see for yourself.=C2=A0 https://join.slack.com/t/json-= schema/shared_invite/zt-8o78yech-XtsW6g9hrqe0SVq94Jim8Q Greg=20 =20 On Sun, 28 Feb 2021 at 8:14 am, Carsten Bormann wrote: On= 2021-02-27, at 18:18, Glyn Normington wro= te: >=20 > I've toyed with deleting that workspace, but one or two people seem to fi= nd it useful, so I've held off. Fragmentation is a big problem in standardization groups. It should not be stimulated lightly. Gr=C3=BC=C3=9Fe, Carsten --=20 Jsonpath mailing list Jsonpath@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath =20 ------=_Part_319277_2087990325.1614458246138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All of those points against Slack are valid.  However, I have found th= at it has been invaluable in building a community around JSON Schema that o= therwise wouldn't have existed.

- E= nd users get to ask questions, even if just curious and want to explore the= technology.
- Im= plementation providers (like myself) get to share approaches, which results= in stronger implementations.
- Unrelated personal conversations occur that help people get = to know each other (this DEFINITELY doesn't need to be archived).  Thi= s is often facilitated by private channels and conversations.

The point behind the Slack workspace is t= hat it builds community.  Community is essential to the success of a p= roject like this.  If you have issue with Slack specifically, whatever= , but there needs to be SOME casual space for off-hand discussion.  Gi= tter or Discourse are also great options for this.  An email list will= NOT create a community like these tools can.

I've built relationships with the maintainers that I never= would have had without a more social discussion platform.  I've even = earned their trust and become a co-author of the spec myself.

If you're worried about discussions that = need to be archived occurring over these tools, we need to be open, explici= t, and strict about pushing people to move to an archival medium.  It'= s not a difficult thing to do, and I'm happy to help enforce such a policy.=   As I mentioned, we have been doing this for years at JSON Schema.&nb= sp; We're aware that conversations disappear after some time, and it's actu= ally a driver for us to make sure important issues get out to GitHub.
=

Your welcome to come see for yours= elf.  https://join.slack.com/t/json-schema/shared_invite/zt-8o78yech-X= tsW6g9hrqe0SVq94Jim8Q

Greg

On Sun, 28 Feb 2021 at 8:14 am, Carsten Bormann
<cabo@tzi.org> wrote:
On 2021-02-= 27, at 18:18, Glyn Normington <g= lyn.normington.work@gmail.com> wrote:
>
> I've toyed with deleting that workspace, but one or two pe= ople seem to find it useful, so I've held off.

Fragmentation is a big problem in standardization groups.
It should not be stimulated lightly.


Gr=C3=BC=C3=9Fe, C= arsten

--
Jsonpath = mailing list
Jsonpath@ietf.org
https://www.ietf.org/mailman/listinfo/jsonpath
------=_Part_319277_2087990325.1614458246138-- From nobody Sat Feb 27 14:00:02 2021 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 DFEB63A150A for ; Sat, 27 Feb 2021 14:00:00 -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, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 hnartjYPVCib for ; Sat, 27 Feb 2021 13:59:59 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 124713A14EF for ; Sat, 27 Feb 2021 13:59:58 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id u11so4684387wmq.5 for ; Sat, 27 Feb 2021 13:59: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; bh=uZa/E3rVscuLAm1m/Io1YUIPMzzhTY9l/BUmIQZQd5g=; b=kfZwhlhCodYKITm+XMYvfedezvBp1OrOhbepj9qoe3yPoOPFdqBQzDeeZPaBEMtcdD glHvKUq4tVmfKzDj0dNNboq0xge7S/mz9oqry+wEKk/oNbxKEhrnuH28k/ob1bu+5L7x JR8jnYVcZMFhI1ZHGe4th/O0PDXODhMpoCkMVEwqOGUTvw80S1m6qGCACMyCvKckGhmh hoauTeShF0D1uQONr+4JaB3t25shlmxJczsOqRJ+/Voe9dDT6kfyXpzuYUT97UbD7WWR 9hTrrIjcfU53am+uy92Pv2XnQVX9MlYn2Nz/gjrUv8HmI05HV3u+29XkERNJ8q9qDPKk 1j9w== 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=uZa/E3rVscuLAm1m/Io1YUIPMzzhTY9l/BUmIQZQd5g=; b=JKDgSPDVYuPLlDCVYpIUhDkBR/B9BOlyuBLfQJmS93Up3KVF+wDSo8dlU5wi2W0USN 4+nGck10ezolaCozJ6pUuFNsi8TWE5fQhw84kcnmeGYhDFfs19ZOL1cKm+PhV0vMXT5P 9PljhQDnh0tU1Da4RPQGKEV8yc7N9Y97ZtlKDEkJYtj/54ttW/sVyVPJ010x9/WSDefm XoJjFSzh9LDyaUU1Mwboq3F7OMSDFCvdS8fXO3AwXUlV98lZyIA32+6DXvwzcsBf7DXP Fx3AQFT/tZZi/zIljbxEqdbRQhA6NKnOqK4a5xQHS9AUJ4PoscwcJQKi17pe9QCjlOA9 dBfw== X-Gm-Message-State: AOAM5339eWpDotMlT+w9BTuoTZp0Biz/KUUOAxuKAPiVvAH2crYGiuqf PdA9lPV+aCs1P6wKTH7J1feXqmsVpB+AAkEeYlnLqbnsQl8Hwg== X-Google-Smtp-Source: ABdhPJyniWro+SPwgwL6Y3/FOVOsI2fcKTcRuev9aIf9Qf/xyidAknk0n1Z0EviKXhkpoPvtm1KSXNt3ox04K1IrCZ8= X-Received: by 2002:a05:600c:2298:: with SMTP id 24mr8974467wmf.136.1614463196866; Sat, 27 Feb 2021 13:59:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Sat, 27 Feb 2021 16:59:45 -0500 Message-ID: To: jsonpath@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a2d9f05bc58812e" Archived-At: Subject: [Jsonpath] @ and the current element 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: Sat, 27 Feb 2021 22:00:01 -0000 --0000000000005a2d9f05bc58812e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Am 26.02.2021 um 19:30 schrieb Stefan G=C3=B6ssner: > > I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` > addresses > the array itself and implies that array has a `length` > property. In filter expression examples `'@'` more consistently addresses the > current array element. For a contrary opinion, I think it's a good thing that there's a precedent to regard the current element within the square brackets notation, when it isn't a filter expression [?()], as the array or object itself. Admittedly, not much would be lost if the original @.length example, supported by about a dozen implementations in Burgmer's comparisons, were not permitted. But there are other possible uses. A JSONPath question that arises from time to time is whether it is possible to have a JSONPath union of multiple different paths, for example, see https://stackoverflow.com/questions/55497833/jsonpath-union-of-multiple-dif= ferent-paths/55505099#55505099. A handful of JSONPath implementations support a limited form of that by allowing dots between literals inside the bracket notation, and at least one implementation (possibly a minority of one) supports full path expressions with notation like $..['name',@.address.city] That particular implementation finds that that feature gets used a lot, judging from feedback. For comparison, in JMESPath, a loosely comparable (only loosely) construct to a JSONPath union is a MultiSelect List. Each expression in a MultiSelect List [expr-1,expr-2,...,expr-n] is evaluated against the "current node", which in this context is the array or object itself. On the other hand, within a JMESPath filter expression [? expression], the "current node" is the current array element, as it is in JSONPath filters. Daniel --0000000000005a2d9f05bc58812e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Am 26.02.2021 um 19:= 30 schrieb Stefan G=C3=B6ssner:
>
> I am very unhappy with conf= using `$..book[(@.length-1)]`, where `'@'`=C2=A0
> addresses > the array itself and implies = that array has a `length`
> property. In filter expression examples `= '@'` more consistently addresses the
> current array element.=

For a contrary opinion, I think it's a good thing that there= 9;s a precedent to regard the current element within the square brackets no= tation, when it isn't a filter expression [?()], as the array or object= itself.=C2=A0 Admittedly, not much would be lost if the original @.length = example, supported by about a dozen implementations in Burgmer's compar= isons, were not permitted. But there are other possible uses.

A JSON= Path question that arises from time to time is whether it is possible tohave a JSONPath union of multiple different paths, for example, see=C2=A0 https://stackoverflow.com/questi= ons/55497833/jsonpath-union-of-multiple-different-paths/55505099#55505099. A handful of JSONPath implementations support a limited form of that by= allowing dots between literals inside the bracket notation, and at least o= ne implementation (possibly a minority of one) supports full path expressio= ns with notation like


--0000000000005a2d9f05bc58812e-- From nobody Sun Feb 28 12:48:11 2021 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 AC1D93A1C2A for ; Sun, 28 Feb 2021 12:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lihHo-3obF9z for ; Sun, 28 Feb 2021 12:48:07 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 DB9633A1C2C for ; Sun, 28 Feb 2021 12:48:06 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id h98so13958306wrh.11 for ; Sun, 28 Feb 2021 12:48:06 -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=UzAmK8A+qk6Gcjk1U4V2hwxmZj02NLR4codMNFq5LL0=; b=lwUV1JdboNIDhLlE0jVvtpvDZI6iNPeXbsu5pXAHHM1XYmtJDAqa11Kk2R6bQ8eWWD ifq3jd7i4rNhm6Yq77AL4g/CJ/BfzPL1m4A5rGTRxDDeClfVeCsG7J4ZhQ7bUUjGl8b6 tWV/t3oajnU5aHsURhr7toG2HwFbMZTgEfPkrWaw492bDekt2YGwUSjXo9G123dvHfSo 9oh/DawVRokZtk/WhFLq87SWNqF2C026GXFni67qVumQI6mBlTwlGSociZVBckWUBGp+ wjNEC4qpKI9VbzXtFi761wknFwdbPDvlrTvZ3InYkALJMV7EbGnX5gz3HZ3q3sqZmhwB ZNeg== 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=UzAmK8A+qk6Gcjk1U4V2hwxmZj02NLR4codMNFq5LL0=; b=I3fRLR+SXQYSv2LQgkhC1iUHYP2sj1C52W/QKQmLC3x8mCM/Srbs7hXlPByg8PXvVG KFaEv3O9ZywHYBrLVjE25uHF08qmu3bQXFRst8Tpw34xmxv8nqf6dEiYBDbXgm8l0RpV g7PS0IgtiMnW06+Sl0zzOWPNw9zXahlcd+XLbLydslAsHfwo0ZUlscDmmqd9hHyEksEj eugRgih0DyBr9gEH4hl6TgoeoltDTgHqF5FyK4aZHuEpPIwAcw1FqOsvWE+SbL0q83vo pFbxglMe6VClsRE7IzoLffGev+QEiDwU4kqKsnhwRAH7pVt/tPwjc4N88J/uljovV4l8 O8Jw== X-Gm-Message-State: AOAM531nO9RBnziJNEk35jkJxJe5yBBl5eGOBiGfd7i+sIwGDNsZSfF3 /pcnKRXu3PDurva+fOCXTsBywmMt2YA4TRc4f9nBxoQkmBc= X-Google-Smtp-Source: ABdhPJyH/zvsDPOV1VQW9ALNw3ENhxiIjE0m8UwIY8ftTRhgOsxYHxxNgcwIB9qtxmgDo6LUsg0b1kZxsxEfgy+JAdU= X-Received: by 2002:a5d:4ac4:: with SMTP id y4mr13305359wrs.86.1614545283133; Sun, 28 Feb 2021 12:48:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel P Date: Sun, 28 Feb 2021 15:47:51 -0500 Message-ID: To: jsonpath@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jsonpath] @ and the current element 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: Sun, 28 Feb 2021 20:48:10 -0000 Am 26.02.2021 um 19:30 schrieb Stefan G=C3=B6ssner: > > I am very unhappy with confusing `$..book[(@.length-1)]`, where `'@'` > addresses the array itself and implies that array has a `length` > property. In filter expression examples `'@'` more consistently addresses= the > current array element. > If I may be permitted to make a second comment on this point. I don't see any confusion or difficulty. "@" does not represent the "curren= t array element", it simply represents the current item, whatever that may happen to be. Given an "?", the processing model requires an iteration over the elements of the then current item (the array); the expression following the "?" is evaluated with each of those elements, and an "@" appearing in that expression is substituted for with those elements. But given "[(", no iteration is implied, hence no change to the current item. Daniel