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

Pier-Luc Thériault <pier-luc@sarkass.com> Tue, 11 December 2012 23:33 UTC

Return-Path: <pier-luc@sarkass.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233E321E8094 for <ietf@ietfa.amsl.com>; Tue, 11 Dec 2012 15:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6N6cpgNucJC for <ietf@ietfa.amsl.com>; Tue, 11 Dec 2012 15:33:35 -0800 (PST)
Received: from toroondcbmts07-srv.bellnexxia.net (toroondcbmts07-srv.bellnexxia.net [207.236.237.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2424E21E8093 for <ietf@ietf.org>; Tue, 11 Dec 2012 15:33:35 -0800 (PST)
Received: from toip59-bus.srvr.bell.ca ([67.69.240.186]) by toroondcbmts07-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20121211233330.PFHU8942.toroondcbmts07-srv.bellnexxia.net@toip59-bus.srvr.bell.ca> for <ietf@ietf.org>; Tue, 11 Dec 2012 18:33:30 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmYCAAq7x1C4keta/2dsb2JhbAANOINIux6DEQEBAQMBOEARCyEWDwkDAgECAUUTCAKIBxKnc4MwkEKNZIMpA4hgjkOSPQ
X-IronPort-AV: E=Sophos;i="4.84,262,1355115600"; d="scan'208";a="44286045"
Received: from bas13-quebec14-3096570714.dsl.bell.ca (HELO [192.168.2.8]) ([184.145.235.90]) by toip59-bus.srvr.bell.ca with ESMTP; 11 Dec 2012 18:33:30 -0500
Message-ID: <50C7C2AB.4080206@sarkass.com>
Date: Tue, 11 Dec 2012 18:32:59 -0500
From: Pier-Luc Thériault <pier-luc@sarkass.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard
References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <CAC4RtVBNxQu03hZxFZiRg-7s2G_KYKFJjUUvSC_UUFwE_FZFdg@mail.gmail.com>
In-Reply-To: <CAC4RtVBNxQu03hZxFZiRg-7s2G_KYKFJjUUvSC_UUFwE_FZFdg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 23:33:36 -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.
> ...
>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/
> 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
>     of:
>
>     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
> anomalous.
>
> So, three questions:
>
> 1. Do I have this right, or am I mistaken about the result of that operation?
Yes, it's the good result
>
> 2. Assuming I have it right, can someone explain why it's this way?
It's the same as adding a value at any existing path
>
> 3. Can someone explain why this is the right way to specify it, rather
> than using "replace" for this?
It's not the right way, it's a right way. You can use replace to be sure 
that there's a root but there's always a root. Personally I would use 
replace
>
> Barry
>