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

Barry Leiba <> Tue, 11 December 2012 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82B4021F881A; Tue, 11 Dec 2012 07:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.094
X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 XC9xQD2jWMhQ; Tue, 11 Dec 2012 07:25:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 84E0C21F8815; Tue, 11 Dec 2012 07:25:58 -0800 (PST)
Received: by with SMTP id y2so3319883lbk.31 for <multiple recipients>; Tue, 11 Dec 2012 07:25:57 -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:content-type; bh=fTJ65mUqmvsYLh3gEWkY6L7PMonGsKL1RCQ1ayttsjo=; b=fltTwEZmb0i14mbPls9Timwe1Kq70cqhJx8A2Se3zI3hl/f/Rf+SfRFAr2f3f53lQ7 P0gF2uMlRu9Dw0fReTJ2luYq6xHJPg9HKlE9j2YyFL1CtZGt/ClcjpNL0pBXWRTPIokY RbD12kNcGSIpTGe7wGEngKFZ30JMq8697xLrKFz39FpzUlAbmSqwORiQqqE5eHtw+efo QHb/pS0H8f9ged19mCM/lkZjT32Pors2URlMWq59qvRimuP+gXownnlwgijfsqEZVbTl rvXZMASpB/caKSGvxJ9w/V+Gc0l7MvAqdK2Stxhtp3OLJzNJoS9wqFADZpbrxel9vApz l4aQ==
MIME-Version: 1.0
Received: by with SMTP id z2mr7677167lbf.125.1355239557492; Tue, 11 Dec 2012 07:25:57 -0800 (PST)
Received: by with HTTP; Tue, 11 Dec 2012 07:25:57 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 11 Dec 2012 10:25:57 -0500
X-Google-Sender-Auth: N71ui7HSiSdpSu_2bo6qGeIvU_4
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard
From: Barry Leiba <>
To: IETF discussion list <>, "" <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Tue, 11 Dec 2012 15:25:59 -0000

> Abstract
>    JSON Patch defines the media type "application/json-patch", a JSON
>    document structure for expressing a sequence of operations to apply
>    to a JSON document, suitable for use with the HTTP PATCH method.

I've reviewed JSON Patch and JSON Pointer as responsible AD, and am
very happy with the documents -- this is good work, well written.  I
came up with one issue that I want to discuss as part of last call:

   4.1.  add

   The "add" operation adds a new value at the target location.  The
   operation object MUST contain a "value" member that specifies the
   value to be added.

   For example:

   { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }

   When the operation is applied, the target location MUST reference one

   o  The root of the target document - whereupon the specified value
      becomes the entire content of the target document.

Now, what this means is that if we start with this:

{ "a": { "num": 1 } }

and we apply this:

{ "op": "add", "path": "", "value": [ "foo", "bar" ] }

we end up with this:

[ "foo", "bar" ]

This doesn't strike me as having any sense of an "add" operation -- it
appears to be a special case that doesn't fit.  In any other
situation, using any other path, the operation either adds something
to what's already there, or it fails.  But when the path is "", it's

So, three questions:

1. Do I have this right, or am I mistaken about the result of that operation?

2. Assuming I have it right, can someone explain why it's this way?

3. Can someone explain why this is the right way to specify it, rather
than using "replace" for this?