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

Julian Reschke <> Fri, 30 December 2011 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F02521F87D3 for <>; Fri, 30 Dec 2011 00:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.328
X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cfCtp8-fRDS8 for <>; Fri, 30 Dec 2011 00:26:26 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 2F3A621F87FA for <>; Fri, 30 Dec 2011 00:26:26 -0800 (PST)
Received: (qmail invoked by alias); 30 Dec 2011 08:26:24 -0000
Received: from (EHLO []) [] by (mp026) with SMTP; 30 Dec 2011 09:26:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+V9W8eT52VGZPWy0slJoK5Fefz4GQUYunC40Bs9b nMRBMWAqOQilbk
Message-ID: <>
Date: Fri, 30 Dec 2011 09:26:21 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Paul C. Bryan" <>
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> <> <1325221908.18477.13.camel@neutron>
In-Reply-To: <1325221908.18477.13.camel@neutron>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss <>
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 08:26:27 -0000

On 2011-12-30 06:11, Paul C. Bryan wrote:
> 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; ramifications:
> 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?

Using a fixed replacement works for me. The alternative that was 
mentioned was a control character such as US (0x1f).

>> 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.

I agree with the analysis. Right now I can't provide a use case that 
would require removing the ambiguity, but I have the feeling that this 
will cause pain later on. Sorry for not having something more concrete...

>> 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.
> Paul
> 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. :-)


Best regards, Julian