Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard

Barry Leiba <> Wed, 12 December 2012 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FEEA1F0CB0; Tue, 11 Dec 2012 16:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.079
X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P2ScwGrbMjrM; Tue, 11 Dec 2012 16:24:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BB2E521F8696; Tue, 11 Dec 2012 16:24:28 -0800 (PST)
Received: by with SMTP id fc26so74385vbb.31 for <multiple recipients>; Tue, 11 Dec 2012 16:24:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CgbVZrq+Ps7iZDZTFuRGomU80q7gsfP+CFICGJI+7PI=; b=b+d2OVmKq+hvJN0Vp+FYoKYr3oKG1DPOcSS2HDYTtsTG2ySuW8lbpk6akkteMIlI57 OEuf4GDmwLaYCyhNDsjYMcOpBVHZlgYIWMJKMCmZ+9vrSFLsfuTslFaOIqJScvYa2Qgq mi8EbCTx83237wlticnlSN8xbbk6/4Kjr1QazP+cLcjeg7FLtpLLZN2reOQoTpCoI3iB PIRiNrS9V5Th+Qh0IRyQA3LcA6iLTgqV7EVj4V0oBvqLxha9qh/cifojaiBDkI7anIej XmZQHDxrqVl/HBtGs0r8ivIZ2iLMsZ6CSsysctj2mAZnIHR/u4DUafS2l9+lznOvXSTj nGNA==
MIME-Version: 1.0
Received: by with SMTP id a7mr6711146vcx.19.1355271868191; Tue, 11 Dec 2012 16:24:28 -0800 (PST)
Received: by with HTTP; Tue, 11 Dec 2012 16:24:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 11 Dec 2012 19:24:27 -0500
X-Google-Sender-Auth: VLCsbCAtuoXLafFeQtdZKpgMUMU
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard
From: Barry Leiba <>
To: Mark Nottingham <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF discussion list <>, "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2012 00:24:29 -0000

> "add" has the semantics of "make the value *this*".

Yeh, I guess the problem I have with that is that that's not the
semantics most of us attach to the concept of "add a thing to a set".
And it bothers me that "add to an object" and "add to an array" have
different semantics.

That difference is unsettling.  It's OK to have "add" on an array have
the semantics of "insert", especially because there's no "insert"
action.  But having "add" on an object have the semantics of "replace"
seems bad, partly because it's inconsistent with the semantics it has
on an array and because there's already a "replace" action.

If I have { "baz": "qux", "foo": "bar" }, these two do exactly the same thing:

case 1a: [{ "op": "add", "path": "/baz", "value": "blarg" }]

case 1b: [{ "op": "replace", "path": "/baz", "value": "blarg" }]

Both result in { "baz": "blarg", "foo": "bar" }

While these are different:

case 2a: [{ "op": "add", "path": "/hah", "value": "blarg" }]

case 2b: [{ "op": "replace", "path": "/hah", "value": "blarg" }]

Case 2a results in { "baz": "blarg", "foo": "bar", "hah": "blarg" },
and 2b is an error.

Case 1 just seems wrong.  The "add" in 1a should be an error, and then
life would make sense.

> As has already been mentioned, there are multiple tools in the box.

Stretching the analogy, having the wrench act as a hammer in some
cases does not make for a particularly well defined, robust tool box.