Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

James M Snell <jasnell@gmail.com> Fri, 14 December 2012 17:43 UTC

Return-Path: <jasnell@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 42CFB21F852D; Fri, 14 Dec 2012 09:43:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.695
X-Spam-Level:
X-Spam-Status: No, score=-3.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 YD95+H-+2lU8; Fri, 14 Dec 2012 09:43:21 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 035CE21F8501; Fri, 14 Dec 2012 09:43:18 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id z13so3404145iaz.31 for <multiple recipients>; Fri, 14 Dec 2012 09:43:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0w8DafvQpeVofSm3ieh73xHdc/q4au1yO8kZ4sI8kaU=; b=RAsUK7u9o6MJARv91zS/V9BYhAKPCVlt+p0ROBmZX/BffbXkYafNPs7GK90HdMHE9e aGxsAyNwfUbqFxLQH3LUwUKAzNJPzWh67bYZe3MhqAnrWC6YacUfjHofOGFzwfVqG6RE qgHyaTbd/txGuoTGOBEzxcm29bhJXxxJC5nz1IfW7GycYEPFnKAhhd6swa+05zO+PLZq /YtZxIjGdEMPqoilByDbZBQ0UGRS3DeBTLGYvQuJn1TH9yOsAKG3rO6BVCNtpCwd2Bne SHuxms8CdUr8WXuhAUOzElBboOZqHvhyMozzuBLwgHzZATSURvDoIG20Q7f5DuuChp8W Jkgg==
Received: by 10.50.151.238 with SMTP id ut14mr2350608igb.72.1355506998679; Fri, 14 Dec 2012 09:43:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 09:42:58 -0800 (PST)
In-Reply-To: <50cb641d.87cd0e0a.7f49.7549SMTPIN_ADDED_BROKEN@mx.google.com>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbeNsZ_rBWRjou=VG+hBhUKaOz+y1a0sSChwWiHte9znnQ@mail.gmail.com> <50cb5f33.295eb40a.7e3d.ffff919fSMTPIN_ADDED_BROKEN@mx.google.com> <CABP7Rbf9cZb1uJrkenxrGH06h-hsWSbG5PXyV6W-3Tm7aER4Ng@mail.gmail.com> <50cb641d.87cd0e0a.7f49.7549SMTPIN_ADDED_BROKEN@mx.google.com>
From: James M Snell <jasnell@gmail.com>
Date: Fri, 14 Dec 2012 09:42:58 -0800
Message-ID: <CABP7RbdXLTXhVO-HS++_Krf1EgQU+pTNRJpxu0s3Bn=NW1p8cQ@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary="e89a8f3b9f7d25978304d0d39110"
X-Mailman-Approved-At: Sun, 16 Dec 2012 08:01:45 -0800
Cc: IETF Discussion <ietf@ietf.org>, IETF Apps Discuss <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: Fri, 14 Dec 2012 17:43:22 -0000

The author just needs to be aware of the current state of the object being
patched. Using conditional requests mechanisms can make it more reliable.


On Fri, Dec 14, 2012 at 9:38 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> On Friday, December 14, 2012 6:19 PM, James M Snell wrote:
>
> > > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote:
> > >
> > > Hmm.. I think that’s quite problematic. Especially considering
> > > how JSON Pointer is used in JSON Patch.
> >
> > How so? Doesn't appear to be a problem in practice.
>
> Since it doesn't express the authors intent. For example, assume you have
> a JSON Patch document like the following:
>
>    [
>      { "op": "test", "path": "/1", "value": 68 },
>      { "op": "add", "path": "/2", "value": 105 }
>    ]
>
> What would you expect it to do? I think almost everyone would say that it
> set the third element of an array to 105 iff the second value is 68. So you
> might expect to get back an array on success but what you really get back
> might be something like this:
>
> {
>   "some": "value",
>   "1": 68,
>   "some other": "value",
>   "and": "finally",
>   "2": 105
> }
>
> Maybe having something like ~2 to express that a number is to be treated
> as an array index would solve it!?
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>