Re: [Json] JSON Patch and null arrays

Mark Nottingham <mnot@mnot.net> Mon, 06 January 2020 06:11 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3587B1200E6 for <json@ietfa.amsl.com>; Sun, 5 Jan 2020 22:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=3AF61qJ3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sJlyi8vA
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 yh0aV_OOH6UK for <json@ietfa.amsl.com>; Sun, 5 Jan 2020 22:11:54 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694A9120098 for <json@ietf.org>; Sun, 5 Jan 2020 22:11:54 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 71E8421F14; Mon, 6 Jan 2020 01:11:53 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 06 Jan 2020 01:11:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=u N8xY+EaowOR8UubYPemTOKD5mcntFz99xSx1uoHQiE=; b=3AF61qJ3NRZytNfYL gRzlO07M12JQFbcWd6gIApMWENv1jAM3b7EQ45VuUGbWBzW7DlkWszQyVJbemd5k 6ou3YZ2cobzNTzjm2UXH3T+f5CK4dSURXX6pcOrz1Is4aVUZe3Dw8VMQpq5JripO bsgE7AMfExEH2aWISGYoqFmJsOSTwXFPKS7dqQXj08hOkHpbb5W1HnsLIkn94jP5 IJcon8lAELu3tc4inBVGAoOvzwwBSu9Iuf8/xBZrLtP+qd4ODRFAvY1yFn4zhdVr dE2VYtX2AYoZ3AKRXV5ddGFktAhp9oSSlwVeDZyuivxrEohZfrdMjo6AgJt8yF2e iwYKw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uN8xY+EaowOR8UubYPemTOKD5mcntFz99xSx1uoHQ iE=; b=sJlyi8vAZyY+F2nzsFnLOUniyC6PNaH1N0LpUkXAiF4xXtRXt+AYZybKH 3Ap39Wy8/tvuLSxhdQgcPLG124Tln8GcdXl9IN6cOimTe9VlJYXnuQmMa/PS0woS mFRxDmRM8ktlBxFwYUocfM+NMXR1QWTmfpJGsn8pcaRSMNgMaSmu5LW0bRw+pJfh D337l7+2BcMBAKRC8iK1OJbbINN5Zk5VFMgMo8OEcskAiwoTfJzqoEREsnl+ZgvP TfRE0GLNrO3smFEvI7SMpdHxGIM8GMp8TkDrXi2oFEMSMxe1ycWMAmjexVPicoO0 OEJz4NcUE+WPBf3MLfmzrWl5G/Ilw==
X-ME-Sender: <xms:qM8SXp3oOkHkp5R-Ao0KMl3rC1TifZtjzrhpqEZz6XvSxyKtFYXSfQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdegledgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtne cukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghmpehmrghilhhfrhhomhep mhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:qM8SXkUO8-qPoYK27jvwdTlm07BOpbGilHWbfWel40a7LnSQ2GPY-Q> <xmx:qM8SXk7-lScvbdsGw49XDs_rANzkFQcOZFbEk_VS-6nmFZ0Xg3nCmg> <xmx:qM8SXrJkPsAGWKug1-3ntnmn6hC8urJpN--0lpdSOj8HvWX8lj_xTg> <xmx:qc8SXvGCzAEFLUx6--X3KVUcOCID_YvJ70IM87OnuMzL1elL8WJwQQ>
Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A3BF30602DB; Mon, 6 Jan 2020 01:11:51 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAEwFaXL-Bd54UyBnazm_9W96WOXZpkQLqjccudJ=8mtAH69yeg@mail.gmail.com>
Date: Mon, 06 Jan 2020 17:11:48 +1100
Cc: json@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <87710AB0-B000-42B6-8800-D6FFC3393DDF@mnot.net>
References: <CAEwFaXL-Bd54UyBnazm_9W96WOXZpkQLqjccudJ=8mtAH69yeg@mail.gmail.com>
To: Ron Alleva <ronallevatech@gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/FQkonfWIbU4myFVRYgwD7Lnt8OM>
Subject: Re: [Json] JSON Patch and null arrays
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 06:11:56 -0000

Hi Ron,

I agree that it would be friendly for this to be the case, but that's not how we wrote the spec:

~~~
   Because this operation is designed to add to existing objects and
   arrays, its target location will often not exist.  Although the
   pointer's error handling algorithm will thus be invoked, this
   specification defines the error handling behavior for "add" pointers
   to ignore that error and add the value as specified.

   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist.
~~~

-- https://tools.ietf.org/html/rfc6902#section-4.1

Changing this now would hurt interoperability, so the right thing to do IMO is to continue to require separate operations.

Cheers,


> On 6 Dec 2019, at 10:22 am, Ron Alleva <ronallevatech@gmail.com> wrote:
> 
> Hi all,
> 
> I’ve been trying to find a good answer around the internet, but I’ve come up short. To describe the question in a JSON patch test, I’m wondering if this should be a valid test: 
> 
> { "comment": "Add array element to null",
> "doc": {"foo": 1},
> "patch": [{"op": "add", "path": “/bar/-", "value": 1}],
> "expected": {"foo": 1, "bar": [1]} } 
> 
> What should “expected” be in this case? Some libraries seem to implement what is above, but I’ve seen other libraries that insist you must create the array first, and only then you can add to it, so the above would result in an error. 
> 
> The most “user friendly” approach I believe would be the above test case. In this case, the client does not have to retrieve and interpret the object to determine if it has to create the array first, it can just add elements.
> 
> Is there any opinion on what is a valid interpretation on the spec with regards to this? Is it just “undefined” because we can’t know that bar is intended to be an array?
> 
> Thanks in advanced,
> 
> Ron
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

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