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

James M Snell <> Tue, 08 January 2013 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78DAA21F84E0; Tue, 8 Jan 2013 09:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.036
X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vywmc-YQNH+b; Tue, 8 Jan 2013 09:07:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DB80821F84C0; Tue, 8 Jan 2013 09:07:11 -0800 (PST)
Received: by with SMTP id o25so561155iad.10 for <multiple recipients>; Tue, 08 Jan 2013 09:07:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a8mUXHBc/lhQAOsrQLKZhHZSou57RXlD5TzUU91Kv9M=; b=BYM2as89e5+kSXXnASNb/uq4X3C+CRDwFYwZUxCqp2Eg5S5Ff25aR3RBXIQy/0aGfA OnIY13hbaCFeo/Qw5574i+76p9EsOy+qwrVODOYrpeAFTEx/BGNedMDLYMF33bUSDIAn MqInw15BhMoXKOQAjKImejhfa+DkJbPjUuYhI0eRAvFRJOZjRZiKYXmBPqcme1FKK75p xEnhAqHWbKBctl2/tfSf3JIyHE+nLlxwBPEjIZVgWPuiJnxjQBNgRPMg849AdtcrhASP BUfGjtC9GNaH1ffAB5NX091eaumfiHlc/hAalstWa40dzsn9kgP2L0qPjLb0fRSNyIhs TqsQ==
Received: by with SMTP id uj14mr9636735igb.19.1357664831403; Tue, 08 Jan 2013 09:07:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 Jan 2013 09:06:50 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <1357515310.6827.23.camel@polyglot> <> <> <> <> <> <>
From: James M Snell <>
Date: Tue, 08 Jan 2013 09:06:50 -0800
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
To: Jared Rosoff <>
Content-Type: multipart/alternative; boundary="f46d043d644bfff78a04d2c9f9f6"
Cc: Mark Nottingham <>, IETF Discussion <>, Matthew Morley <>, IETF Apps Discuss <>, IESG <>
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: Tue, 08 Jan 2013 17:07:13 -0000

Fortunately the JSON-Patch syntax is designed such that it is possible to
extend the range of defined operations without breaking basic structure...
much as I have done with the json-predicates draft. You would need to
define a new media type to associate with the extensions but that's not

Consider something along the lines of.. application/json-patch-ext...

  {"op": "unset", "path": "/a/b"},
  {"op": "inc", "path": "/a/c"},
  {"op": "push", "path": "/a/d", "value": 1}

- James

On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff <> wrote:

> hi team, i'm new to the discussion here, but wanted to jump in. i work on
> mongodb, a json database, and i wanted to share how we deal with these
> issues.
> mongodb uses almost the same notation for pointers ("a.b.c" instead of
> "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
> refers to the 0th element of the array called "a"). and this works fine in
> practice. (ref:
> )
> our update syntax is different tho. the verbs in mongodb updates for json
> documents are more specific:
> set / unset / rename (operations on fields)
> inc (increment integer values)
> push / pop / pull (operations on arrays)
> addToSet / removeFromSet (operations on arrays)
> (ref
> since update operations are more specific and type dependent, it's easy to
> throw an error if an unexpected type is encountered (e.g. try to push onto
> a field that has a non-array value) and to act smartly on empty fields ( if
> path to push is empty, we assume it should be an array, create it, and then
> push the value onto it).
> i concur the the pointer syntax is fine and ambiguity comes from the
> definition of operators in json patch.
> -j
> On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <> wrote:
>> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <>wrote:
>>>  On 07/01/13 13:23, Matthew Morley wrote:
>>> For me the deficiency is not in the pointer, but patch format being
>>> generated.
>>> One approach is to push that *one* test, structure conformity, into the
>>> pointer syntax. Another is via the type operation.
>>> If a vague patch is generated, vague results are to be expected.
>>> It seems to me, on the contrary, that the deficiency is in the pointer
>>> syntax, and I think it would be a mistake to try to work around that
>>> deficiency in JSON Patch. Because aren't there other things which one might
>>> do with JSON Pointer than use it with JSON Patch? There's been mention of
>>> having it registered as a URI fragment identifier syntax for JSON for
>>> example. JSON Pointers could then end up all over the place, outside of
>>> patches. IMHO JSON Pointer needs to be taken seriously as a technology in
>>> its own right.
>> Couldn't agree more about it being taken seriously in its own right. :)
>> JSON Pointer for me exists outside of JSON Patch, always has and will do
>> the way we think about structures. As it represents both a resolution path
>> and an identity string (both ends of the path concept). I see value from
>> the identity view, in describing a location that is aware of being inside
>> an array.
>> But JSON Pointer should not be changed just because of issues with JSON
>> Patch, especially when JSON Patch is attempting to address those issues
>> with other mechanisms within the specification. That is all I was trying to
>> express. The syntax change should be for other reasons, if it is going to
>> be made.
>> My personal experience (for what its worth): In the past I've tried a
>> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
>> times to address the same issues suggested here. Though my experiences
>> pushed me towards a single syntax using a.b.c.0, and thus my support for
>> /a/b/c/0 over /a/b/c:0.
>> The system at first used the . or : syntax, combined with dynamic tokens,
>> being pointers themselves, to resolve other pointers. So it was not
>> reasonable to know ahead of time if an end point was an array or an object.
>>  "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the
>> value at d.e.f at the time of resolution. Especially with many layers of
>> tokens to resolve, and changing data structures.
>> I found in practice, it didn't really matter, so the choice of . or : was
>> phased out. At the end of the day the two syntaxes point to mutually
>> exclusive points within the data, so that `meta data` about the structure
>> was removed from the syntax we used. It didn't add value, even if it added
>> clarity at times. We also had functions at the end of paths, but that goes
>> beyond the JSON focus of the JSON Pointer goals, so those points are not
>> relevant here.
>> This discussion thread seems to be getting overly complicated, but JSON
>> Pointer changes should come from the JSON Pointer view point and that
>> specifications goals, not from short comings in JSON Patch.
>> --
>> Matthew P. C. Morley
>> _______________________________________________
>> apps-discuss mailing list
> _______________________________________________
> apps-discuss mailing list