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 10:01 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 D254421F8A6B; Mon, 17 Dec 2012 02:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_45=0.6, 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 bkR4QSNJZlE7; Mon, 17 Dec 2012 02:01:28 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 086DC21F842B; Mon, 17 Dec 2012 02:01:27 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hj13so1794096wib.13 for <multiple recipients>; Mon, 17 Dec 2012 02:01:27 -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=6oM4a7Ql/IhvEkMqKzq6CR/2utGalGeLqJHkLpoQrHY=; b=frcxaD1uQ1FSCm9pleQ2/EzcFmEyJmNBIlKhDrrbcGlxnSTPatWj0WwYufj7z5QTWo bnAZJHiGf+8EBEGrPKEI2dCLFVXoPVNd1LgIVnJhwt8l9Q6M68BFW+PNCrOp8oOWg/IO fSKG8n/gyr6qw/fuBYLFJIpyNkVdRF4FMkkh3jSNXnaT88jjqaRkMhLTyLn/c3yOKSpK cJNZ6lPQT8NpR8Q/4wuqdzl4T0WSIoowkr42IwX1lpTnjOVqU7QKrK7estC7BPmR+oGc CYGPBmjPGbbLj4W/sdDFKZow/+nVOGKEED36FlmF/l8rny5426kkeNtTdJb2Dpvr7zvA Hofg==
MIME-Version: 1.0
Received: by 10.180.72.232 with SMTP id g8mr14601997wiv.0.1355738487127; Mon, 17 Dec 2012 02:01:27 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Mon, 17 Dec 2012 02:01:27 -0800 (PST)
In-Reply-To: <EABB8F51-C3B4-49F5-8672-5C2ABAC7043A@mnot.net>
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> <CAChr6SwtS_=iS-k4mJm1vHjEvvGVzay5jDYeGheqsPZqO-89CQ@mail.gmail.com> <EABB8F51-C3B4-49F5-8672-5C2ABAC7043A@mnot.net>
Date: Mon, 17 Dec 2012 02:01:27 -0800
Message-ID: <CAChr6Sy-Xc8vC6FabFmdseR7xfQ-6t9hARunWjYgt6FqjmoBWg@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: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Matthew Morley <matt@mpcm.com>, IETF Apps Discuss <apps-discuss@ietf.org>, IETF Discussion <ietf@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 10:01:33 -0000

On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Robert,
>
> This was discussed extensively in the Working Group.

Presumably every line of the document was discussed by the WG at some
point. This phase of review is wider, and this point has been raised
separately three times, so perhaps the WG should take another look.
One thing that strikes me about the arguments in favor of the status
quo is that they seem non-technical. Is there a technical case for
leaving this ambiguity in the patch format?

> The root of the issue was that some people reflexively felt that this was necessary, but upon reflection, we decided it wasn't; although it seems "natural" to some, especially those coming from a static language background, it didn't provide any utility.

I'm approaching it as an implementor in JavaScript that happens to
have spent some on the ECMAScript committee and implemented the native
JSON.parse and JSON.stringify methods for Mozilla Firefox. I think
this issue leaves open a chance for data corruption with no real
upside. I could understand leaving it be if making arrays explicit in
the patch format were complex or onerous, but I don't think anyone is
arguing that.

>
> You might argue that someone who (for example) adds to "/foo/1" in the mistaken belief that it's an array, when in fact it's an object, will get surprising results. That's true, but if we were to solve this problem, that person would still need to understand the underlying semantics of "foo" to do anything useful to it -- and I'm not hearing anyone complain about that (I hope).

The first case that can come up is editing documents that have been
refactored. It's quite common to refactor JSON documents as below when
a little extra metadata is needed for a collection:

{ "foo":[1,2,3] }

then becomes

{
  "foo":
  "bar": "baz",
  "members": [1,2,3]
}

now, an operation on /foo/1 is quite a different thing in the second
document. It's not too hard to see how a client that's been out of
contact with the server for a while could send an addition to /foo
intended for the array that's been moved down to "members". Now, there
are ways to catch this if you're willing to bloat the patch document
with other checks, or by insisting on a matching ETag. But one of the
nice things about patch formats is that you can try for more
optimistic concurrent editing. This ambiguity in the patch format
makes it needlessly more costly to detect unsound edits.

Another source of bugs from JavaScript side of things will be
"array-like" objects. These are really quite common (jQuery lists,
arguments object, etc), and authors very often don't realize they
won't be serialized as an array. To be sure, this is a bug on the
author's side, but some checks in the patch format would really help.
They'll probably become even more common as ES6 is standardizing
iterators http://wiki.ecmascript.org/doku.php?id=harmony:iterators.
Here's an example in a JS REPL using the arguments object (but keep in
mind there are many other objects out there that behave this way).

> function foo(list) { console.log(JSON.stringify(list)) }
> function bar(a,b,c) { foo(arguments) }
> bar("a", "b", "c");
{"0":"a","1":"b","2":"c"}

>
> Put another way -- do you really think

Yes, really.

> that people PATCHing something as if it's an array (when in fact it's an object) is a significant, real-world problem, given that the patch author already has to understand the semantics of the document they're patching?

I don't see that requirement in the draft, and I certainly wouldn't
bet on it being true in all cases. Wasn't one of the motivating
use-cases for this patch format CouchDB? That software operates on
arbitrary, user-defined JSON documents.

- Rob

> I don't, and the WG didn't either.
>
> Regards,
>
>
> On 17/12/2012, at 3:36 PM, Robert Sayre <sayrer@gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>