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
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Manger, James H
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Abdussalam Baryun
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Murray S. Kucherawy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Carsten Bormann
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Paul C. Bryan
- RE: [apps-discuss] Last Call: <draft-ietf-appsawg… Markus Lanthaler
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Conal Tuohy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Matthew Morley
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Jared Rosoff
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… James M Snell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Hector Santos
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Robert Sayre