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

Matthew Morley <> Wed, 19 December 2012 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2D9F21F8830 for <>; Tue, 18 Dec 2012 17:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gtPyp6WMv8Lc for <>; Tue, 18 Dec 2012 17:00:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 79E0D21F8828 for <>; Tue, 18 Dec 2012 17:00:41 -0800 (PST)
Received: by with SMTP id b25so775567qca.3 for <>; Tue, 18 Dec 2012 17:00:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=9M1apTBEubjLeegQH0OaUH+Wd2s4r6m/WT1J/J/FK+c=; b=a+Tx5kZnNPuQkFwWU8lRgEdOikKzRXSaGn9Gx9UpuR0yMP53SUOE+Nis2mJGlFs5Uz 3Zazv7yvpzzTjHOU5jo2wU5N+z2/vkF/R3XMsXDJkDkSebkbMnuhF3XN+CziJRChfm8n q3oekPYs5tGFTMEKUGhs5j0qNFEmoMiaYll/k7cIcy59EUmbC/1tj8w59b01il5/yzWU 89n+2+59sGnwynxx/qJjncdizlY/Rm5y4lnvdILRUGaj5m5+bXH/J5tXHBNoIdRQpAgs XeEPCPMerpfi6DBMkVDrDXWHzC6TS09u4hMOBrxr2ZB2xraqzfynNRzQK3Py26rX0bdv DPPg==
MIME-Version: 1.0
Received: by with SMTP id r4mr1719933qaa.21.1355878840835; Tue, 18 Dec 2012 17:00:40 -0800 (PST)
Received: by with HTTP; Tue, 18 Dec 2012 17:00:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 18 Dec 2012 20:00:40 -0500
X-Google-Sender-Auth: o_OH8K1GwtwGxS518AQm2VuXJ0U
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Matthew Morley <>
To: James M Snell <>
Content-Type: multipart/alternative; boundary="14dae9399b01aa9f7204d12a249b"
X-Gm-Message-State: ALoCoQl50EfprhqU77gLCu7KqKFPVlD4dmi2rVDQfQuHU1z4JR/7Z9vgdtb66rbmeqSbINAJgFsU
X-Mailman-Approved-At: Thu, 20 Dec 2012 08:17:04 -0800
Cc: Mark Nottingham <>, "Manger, James H" <>, IETF Discussion <>, IETF Apps Discuss <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Dec 2012 01:00:42 -0000

I do not feel there is a gain from adjusting the syntax, in the role of
JSON Pointer as a stand alone specification. The addition of such a change
adds an implied checking of a list vs a collection, as part of pointer

If you are using the pointer as a means to get a value, it makes little
difference in the fact that the value either exists at the end of that path
or it doesn't.  (Get me the value at /a/b/c/2)

If you are using the pointer as a method of identity, again it makes little
difference as only one point can presented by that pointer. (You are at

For me, these are the primary uses of the JSON Pointer specification.
Rarely is the underlying structure, in practice, of consequence.

Something like JSON-Schema is much better for testing the shapes of JSON

However, I can see the point in such a change when paired with JSON-Patch.
But I still feel that even this is more of an attempt to overload the role
of the pointer, to make it carry additional meaning that should be
expressed in either the test or the operation keywords of that particular

My vote is to leave the specification syntax as is, and keep it simple to
produce and consume, even at the cost of not being able to infer the
structure of any given step in the pointer without the actual json object
being traversed.

Matthew P. C. Morley

On Tue, Dec 18, 2012 at 12:24 AM, James M Snell <> wrote:

> What I'm not clear on, however, is what significant benefit making this
> kind of change would provide. Yes, the syntax can be more verbose and exact
> but it's not clear that the change is worth the cost.
> Robert mentioned that the addition of the json-predicates test doubled the
> size of the json-patch file, and yes, I get that.. but if we're talking
> about sending a two-object json-patch document to modify a JSON document
> many times larger than that, it's still worth the extra handful of bytes it
> takes. Sure, if we had a complex patch document consisting of large amounts
> of json-patch and json-predicate objects being applied to an arbitrarily
> structured document, I could understand the concern, but in that case one
> would have to question the wisdom of doing a partial update in the first
> place. JSON-Patch documents are best served small and simple, and the
> inclusion of a json-predicate or two per instance is not going to blow the
> budget on bits on the wire.
> So the key question becomes: what added benefit does a more verbose
> pointer syntax provide us? And is there a concrete need for that benefit
> that can be demonstrated?
> - James
> On Mon, Dec 17, 2012 at 9:12 PM, Manger, James H <
>> wrote:
>> If we were starting from scratch and defining JSON Pointer again I would
>> argue for distinguishing array indices and object names in the syntax. For
>> instance, prefix an object name with "/" and an array index with ":".
>>    json-pointer = *segment
>>    segment = "/" name  /  ":" index
>>    name = *( unescaped / escaped )
>>    unescaped = %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF
>>    escaped = "~" ( "0" / "1" / "2" )
>>    index = "0" / %x31-39 *(%x30-39) / "-"
>> 1. It makes parsing marginally harder: you cannot just split on "/" and
>> unescape each segment.
>> 2. It doesn't make much difference for selecting a value from some JSON,
>> or for finding a spot to insert a new value.
>> 3. It would allow you to automatically create object *or array* ancestors
>> when setting a new value (eg adding 23 at /a:0/b:0 to {} could give
>> {"a":[{"b":[23]}]}).
>> 4. It might encourage better validation of pointers, but that is probably
>> wishful thinking.
>> But JSON Pointer drafts have used the /{name|index} format for a year.
>> There are a bunch of implementations. The difference is minor in most
>> circumstances. So while I would be happy to change, I am also comfortable
>> staying with the current pointer syntax.
>> > There's no good reason for it to be that way, is there?
>> I don't think so.
>> --
>> James Manger
> _______________________________________________
> apps-discuss mailing list