Re: [apps-discuss] draft-pbryan-zyp-json-pointer progress

"Paul C. Bryan" <> Fri, 30 December 2011 05:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF1B21F845F for <>; Thu, 29 Dec 2011 21:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNOPn7m3U6Km for <>; Thu, 29 Dec 2011 21:12:21 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id A1BD421F845E for <>; Thu, 29 Dec 2011 21:12:20 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 30 Dec 2011 05:12:20 UTC
Received: by ghbz2 with SMTP id z2so4093635ghb.24 for <>; Thu, 29 Dec 2011 21:11:51 -0800 (PST)
Received: by with SMTP id h24mr49418272yhi.78.1325221911335; Thu, 29 Dec 2011 21:11:51 -0800 (PST)
Received: from [] ( []) by with ESMTPS id u9sm71672082anh.20.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 21:11:50 -0800 (PST)
Message-ID: <1325221908.18477.13.camel@neutron>
From: "Paul C. Bryan" <>
To: IETF Apps Discuss <>
Date: Thu, 29 Dec 2011 21:11:48 -0800
In-Reply-To: <>
References: <> <1321903463.1990.16.camel@neutron> <> <1321905599.1990.23.camel@neutron> <> <1321906189.1990.26.camel@neutron> <> <> <1321912269.1990.32.camel@neutron> <> <1321923360.1990.34.camel@neutron> <1321923443.1990.35.camel@neutron> <>
Content-Type: multipart/alternative; boundary="=-mx65IWuFnU2s4Fs3x8dy"
X-Mailer: Evolution 3.2.2-1
Mime-Version: 1.0
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer progress
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Dec 2011 05:12:22 -0000

On Thu, 2011-12-29 at 15:04 +0100, Julian Reschke wrote:

> just checking: do we have a plan for the I18N issues?

I believe the consensus is that a pointer should be Unicode;

1. If it's a JSON string value, then JSON encoding applies.
2. If it's a URI fragment identifier, then URI percent-encoding applies.

The outstanding issue to address is cases where a member name contains
reference token prefix "/" character(s). In light of this, using some
sort of escape character makes the most sense; which character to use is
the question. U+FFFD was mentioned. Any further thoughts?  

> Also, while discussing this on the Jackrabbit mailing list, one 
> potential issue was brought up:
> If we do not special-case array addressing, a given pointer, such as
>   /foo/bar/1
> can identify two different things, either[1] or["1"].

This topic has come up multiple times; it's true that .../1 is ambiguous
until you resolve a pointer against a concrete JSON value. What's not
been obvious to date is how identifying the type of value in the pointer
is of use. I could imagine cases where you would want to create missing
intermediate values while traversing a pointer, at which point .../1 is
problematic as it would imply the creation of a sparse array. If there
is a strong drive to identify types in pointers, I'm definitely
interested in understanding the case further.

> Of course this is only a problem when looking at a pointer in
> isolation 
> (without knowing the object to apply it to), but I think it's worth 
> thinking about.
> Best regards, Julian
> PS: and yes, the downside of using brackets would be that we need to 
> escape more characters.

Yes, ouch.


P.S. I'm planning on publishing new (APPSAWG) drafts for JSON Patch and
JSON Pointer in the next few days, in time for review in the new
year. :-)