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

Matthew Morley <> Tue, 08 January 2013 06:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AA5C21F878F for <>; Mon, 7 Jan 2013 22:26:32 -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 mFcD3fPfjMBC for <>; Mon, 7 Jan 2013 22:26:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A54A621F87B9 for <>; Mon, 7 Jan 2013 22:26:30 -0800 (PST)
Received: by with SMTP id fq12so68984lab.25 for <>; Mon, 07 Jan 2013 22:26:29 -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=tVGR3V0bZ63/hoDM4AfDUCweXtPnFIX93lv4LwUUXP4=; b=BmOAZHXKHRe7BlE40oJku1EYGdg89ZGHvrbkb16xGTpMflkRQ7EcIQ5AthCR3DZVer ryJANI3c0+GVAhCDbHTWnYVD/GuAoYAnWdT1FcLmqMxGuqUh/TWPEiuV7Sg0cv8ONy2u CS53U7PbBXDKHA02H+P5g6dv+SsovSaoEWnaEoLoE5cuI72VUSc0eaAHU2JdqpMNhlcC qlP25ieMyHoOVNVoj7yTSrfurNB8p/yXiqzypzccP0RModsVVnoO9J7/eVj4/MfaqEmI qHJBjZ+yAKOF7qJKzo3h7/kFXHBDjaGz3nsrMTQePaTcAQoWy+KD5gtPnurO632+jcXK oVcg==
MIME-Version: 1.0
Received: by with SMTP id hw18mr60995840lab.22.1357626389332; Mon, 07 Jan 2013 22:26:29 -0800 (PST)
Received: by with HTTP; Mon, 7 Jan 2013 22:26:29 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <1357515310.6827.23.camel@polyglot> <> <> <> <>
Date: Tue, 08 Jan 2013 01:26:29 -0500
X-Google-Sender-Auth: Hp6htB9KvhJjezXNY49bilk8pH4
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Matthew Morley <>
To: Conal Tuohy <>
Content-Type: multipart/alternative; boundary="bcaec54d4de8ac81d404d2c10686"
X-Gm-Message-State: ALoCoQlfvtJDe0WAn2WPaespR/qfQDLE4XU9DrGet7bjr48ai5GXp+bRPDB/vGr3swhE4Qlmu2Vt
X-Mailman-Approved-At: Tue, 08 Jan 2013 09:25:48 -0800
Cc: IESG <>, Mark Nottingham <>, 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: Tue, 08 Jan 2013 06:26:32 -0000

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