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

Robert Sayre <sayrer@gmail.com> Mon, 17 December 2012 04:36 UTC

Return-Path: <sayrer@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 9EE8121F8942; Sun, 16 Dec 2012 20:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CfZihLLkO+VK; Sun, 16 Dec 2012 20:36:20 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48B5321F8938; Sun, 16 Dec 2012 20:36:20 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id r3so2616998wey.31 for <multiple recipients>; Sun, 16 Dec 2012 20:36:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GnRoInqjd7m2nYXc/NT6NIXevyMJ2gW4lBkFEtgK0RU=; b=iRw4LU4XLoCD+H3W/i6Q1lzVMcVx36bNwqW8hZamohMO4NCnDi4Z2dzGCjko+Owv9Z 7TFVfEeDpn3jKpk4xVbIwaOBmawFnKNMmS6651yMaGR+F2zQT9YT8/jZW8kszvrQAJau 5oq8e5cW1GEZbO6bJFzvznOUfRGuGyVIgex8/sCwzT2tt3jEW3GR0AKIF2/5nwlhT3yA X+Q6G3m2hodu6jbDVgA36bBxpPOA6nh2XUK9lhD1nkW2SaorZA60Bt7nZzRF5dCIL/1B wQzjiF2fhLoarDDcSDdejDyjivQA2roR8RUVUcGXnpCjvuB84OOr9+Q4y6pM7fMlOE5N OL2w==
MIME-Version: 1.0
Received: by 10.194.78.162 with SMTP id c2mr14467013wjx.46.1355718979294; Sun, 16 Dec 2012 20:36:19 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sun, 16 Dec 2012 20:36:19 -0800 (PST)
In-Reply-To: <CAOXDeqpPE4eNy_qJpDPdPHbCQakG9-hDcNZ3Sj9r4kWedByVzQ@mail.gmail.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> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SxZRc3B_HCbw76kLe2dsRSr43r-gLpfMVnCUfJTrZdTLA@mail.gmail.com> <CABP7RbfA33huBFadMeXTTEt=MkjW8-d4DFH7+GLXGurnm9sSRw@mail.gmail.com> <CAOXDeqpPE4eNy_qJpDPdPHbCQakG9-hDcNZ3Sj9r4kWedByVzQ@mail.gmail.com>
Date: Sun, 16 Dec 2012 20:36:19 -0800
Message-ID: <CAChr6SwtS_=iS-k4mJm1vHjEvvGVzay5jDYeGheqsPZqO-89CQ@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Robert Sayre <sayrer@gmail.com>
To: Matthew Morley <matt@mpcm.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: James M Snell <jasnell@gmail.com>, 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: Mon, 17 Dec 2012 04:36:21 -0000

The cost of fixing it seems low, either by changing the path syntax of
JSON pointer or changing the names of operations applied to arrays.
Array-like objects are common enough in JavaScript to make this a
worry. The other suggestions either assume a particular policy for
concurrent edits or require more machinery (test operation etc).
Wouldn't it be simpler to make the patch format more precise?

- Rob

On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley <matt@mpcm.com> wrote:
> I am usually lurking and struggling to keep up with these posts. But, I
> concur with James, this really is a non-issue in practice.
>
> The JSON Pointer expresses a path down a JSON object to a specific context.
> The Patch expresses a change within or to that context.
> Everything about the both standards is about that end context.
>
> If you want to confirm the type of the context before applying a patch, this
> should probably be part of a test operation. I'm not sure if this is
> possible at this point (?), but that is where the logic should exist.
>
>
>
> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <jasnell@gmail.com> wrote:
>>
>>
>>
>>
>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <sayrer@gmail.com> wrote:
>>>
>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>> <markus.lanthaler@gmx.net> wrote:
>>> >
>>> > Hmm.. I think that’s quite problematic. Especially considering how JSON
>>> > Pointer is used in JSON Patch.
>>>
>>> I agree--I provided the same feedback privately. It seems
>>> straightforwardly unsound.
>>>
>>
>> In practice it doesn't seem to be much of an issue.
>>
>> Specifically, if I GET an existing document and get an etag with the JSON,
>> then make some changes and send a PATCH with If-Match, the fact that any
>> given pointer could point to an array or object member doesn't really matter
>> much.
>>
>> For example:
>>
>>   >  GET /the/doc HTTP/1.1
>>
>>   <  HTTP/1.1 200 OK
>>      ETag: "my-document-tag"
>>      Content-Type: application/json
>>
>>      {"1":"foo"}
>>
>>   >  PATCH /the/doc HTTP/1.1
>>      If-Match: "my-document-etag"
>>      Content-Type: application/json-patch
>>
>>      [{"op":"add","path":"/2","value":"bar"}]
>>
>> Generally speaking, someone should not be using PATCH to perform a partial
>> modification if they don't already have some knowledge in advance what they
>> are modifying. The only time the apparent ambiguity becomes an issue is when
>> a client is blindly sending a patch to an unknown endpoint... in which case,
>> you get whatever you end up with.
>>
>> - James
>>
>>
>>>
>>> - Rob
>>>
>>>
>>> >
>>> > --
>>> >
>>> > Markus Lanthaler
>>> >
>>> > @markuslanthaler
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > From: James M Snell [mailto:jasnell@gmail.com]
>>> > Sent: Friday, December 14, 2012 5:41 PM
>>> > To: Markus Lanthaler
>>> > Cc: IETF Discussion; IETF Apps Discuss
>>> > Subject: Re: [apps-discuss] Last Call:
>>> > <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
>>> >
>>> >
>>> >
>>> > JSON Pointer does not distinguish between objects and arrays. That is
>>> > not determined until the pointer is applied to an actual object instance...
>>> > the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>> >
>>> >
>>> >
>>> > On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>> > <markus.lanthaler@gmx.net> wrote:
>>> >
>>> > I've asked that before but didn't get an answer. So let me ask again
>>> > (even
>>> > though I'm quite sure it has already been asked by somebody else).
>>> >
>>> > How does JSON Pointer distinguish between objects and arrays? E.g.
>>> > consider
>>> > the following JSON document:
>>> >
>>> > {
>>> >   "foo": "bar",
>>> >   "1": "baz"
>>> > }
>>> >
>>> > As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even
>>> > though that's probably not what the author intended. Is there a way to
>>> > avoid
>>> > that?
>>> >
>>> >
>>> > Thanks,
>>> > Markus
>>> >
>>> >
>>> >
>>> > --
>>> > Markus Lanthaler
>>> > @markuslanthaler
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > -----Original Message-----
>>> > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>> > > bounces@ietf.org] On Behalf Of The IESG
>>> > > Sent: Tuesday, December 11, 2012 4:01 PM
>>> > > To: IETF-Announce
>>> > > Cc: apps-discuss@ietf.org
>>> > > Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-
>>> > > 07.txt> (JSON Pointer) to Proposed Standard
>>> > >
>>> > >
>>> > > The IESG has received a request from the Applications Area Working
>>> > > Group
>>> > > WG (appsawg) to consider the following document:
>>> > > - 'JSON Pointer'
>>> > >   <draft-ietf-appsawg-json-pointer-07.txt> as Proposed Standard
>>> > >
>>> > > The IESG plans to make a decision in the next few weeks, and solicits
>>> > > final comments on this action. Please send substantive comments to
>>> > > the
>>> > > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments
>>> > > may
>>> > > be
>>> > > sent to iesg@ietf.org instead. In either case, please retain the
>>> > > beginning of the Subject line to allow automated sorting.
>>> > >
>>> > > Abstract
>>> > >
>>> > >
>>> > >    JSON Pointer defines a string syntax for identifying a specific
>>> > > value
>>> > >    within a JSON document.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > The file can be obtained via
>>> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
>>> > >
>>> > > IESG discussion can be tracked via
>>> > >
>>> > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
>>> > >
>>> > >
>>> > > No IPR declarations have been submitted directly on this I-D.
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > apps-discuss mailing list
>>> > > apps-discuss@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/apps-discuss
>>> >
>>> > _______________________________________________
>>> > apps-discuss mailing list
>>> > apps-discuss@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > apps-discuss mailing list
>>> > apps-discuss@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>> >
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>
>
> --
> Matthew P. C. Morley