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

Barry Leiba <barryleiba@computer.org> Wed, 12 December 2012 01:01 UTC

Return-Path: <barryleiba@gmail.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 B560621E8096; Tue, 11 Dec 2012 17:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.078
X-Spam-Level:
X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 rVn+ZYcNjl1g; Tue, 11 Dec 2012 17:01:20 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7111E80A3; Tue, 11 Dec 2012 17:01:19 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so109444vcb.31 for <multiple recipients>; Tue, 11 Dec 2012 17:01:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k4wXQ6CxOlbWIm4oeubuVGaYhzbDAMzedR2sckPxsCc=; b=Am8uPWc/xqa0DKKfthjE1wQf9RKsulrDlqzaLDbZWlIrjYOzyhe5BLPpryIRZbQKts 8qbiEoi2Qp72OYl1qqE9laGiSRgswieivoQht2OMlR23ObAB0Ln0YX8eVuwDTV01n64v bBS81UG1cyKLnU8b3WdmsDZ/PUvprUlUqDDBtqLBOAJcn/QgEHMjYp3gF1KDSUAbLSZg IG+ls98GIlgeNJVzx+4ozfOp8cKAoBAP+/MMh0x1GoJkcYtxKTJYFDOsNql4Qzgtbc9T Fz47pzUIepAmhVF2yj8mJOKqigPyVs0IPIXN+PSUqt3W8NcXO0Tg4wUkgaseyHUfmzV5 5piA==
MIME-Version: 1.0
Received: by 10.58.221.130 with SMTP id qe2mr20064vec.14.1355274079499; Tue, 11 Dec 2012 17:01:19 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.58.28.231 with HTTP; Tue, 11 Dec 2012 17:01:19 -0800 (PST)
In-Reply-To: <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net>
References: <20121211150005.28209.96763.idtracker@ietfa.amsl.com> <CAC4RtVBNxQu03hZxFZiRg-7s2G_KYKFJjUUvSC_UUFwE_FZFdg@mail.gmail.com> <3448719B-185A-476A-A927-25A68D4B4358@mnot.net> <CALaySJ+BMsBJt7wWHN90itdPcqUqSd0gMh_YzmHZpN=8jcKJJA@mail.gmail.com> <82A453F8-9F1A-4427-B238-A63B43447F21@mnot.net>
Date: Tue, 11 Dec 2012 20:01:19 -0500
X-Google-Sender-Auth: Q6Kuj75c1hGr8oVPhvVkbv8YXb4
Message-ID: <CALaySJJ33RjEJRNbY3-PREMbE76SyFi+hpQg2BwgFd8N2DOWNw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard
From: Barry Leiba <barryleiba@computer.org>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF discussion list <ietf@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
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: Wed, 12 Dec 2012 01:01:20 -0000

> So, do you have a suggestion?

I do, and it's buried in there:

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

Turning that into a text suggestion, it would be this (which
represents a change to the protocol, so the working group would have
to accept it):

OLD
   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.

   o  A member to add to an existing object - whereupon the supplied
      value is added to that object at the indicated location.  If the
      member already exists, it is replaced by the specified value.
NEW
   When the operation is applied, the target location MUST reference one
   of:

   o  A member to add to an existing object - whereupon the supplied
      value is added to that object at the indicated location.  It is an error
      for the specified member to already exist.
END

OLD
   For example, "add"ing to the path "/a/b" to 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.
NEW
   For example, given the following starting document:

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

   o  "add"ing to the path "/a/b" is not an error, because "/a" exists,
      and "b" will be added to its value.

   o  "add"ing to the path "/q/b" is an error, because "/q" does not
      exist.  But "/q" can be added first, followed by "add"ing "/q/b".

   o  "add"ing to the path "/a" or "/a/foo" is an error, because "/a"
      and "/a/foo" both exist already, and cannot be added.
END

I understand that this will change implementations -- patches that
used to use "add" will now have to use "replace", and there's now no
way to do "add this if it's not already there, and replace it if it is
already there".  Perhaps there's a need to add something with those
semantics.  On the other hand, as the text stands now, there's no way
to do "add this only if it's not already there", because "test" can't
test for existence.

Barry