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

Julian Reschke <julian.reschke@gmx.de> Fri, 30 December 2011 08:26 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02521F87D3 for <apps-discuss@ietfa.amsl.com>; Fri, 30 Dec 2011 00:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.328
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfCtp8-fRDS8 for <apps-discuss@ietfa.amsl.com>; Fri, 30 Dec 2011 00:26:26 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2F3A621F87FA for <apps-discuss@ietf.org>; Fri, 30 Dec 2011 00:26:26 -0800 (PST)
Received: (qmail invoked by alias); 30 Dec 2011 08:26:24 -0000
Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp026) with SMTP; 30 Dec 2011 09:26:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+V9W8eT52VGZPWy0slJoK5Fefz4GQUYunC40Bs9b nMRBMWAqOQilbk
Message-ID: <4EFD75AD.6090602@gmx.de>
Date: Fri, 30 Dec 2011 09:26:21 +0100
From: Julian Reschke <julian.reschke@gmx.de>
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" <paul.bryan@forgerock.com>
References: <4ECA5C66.1040305@gmx.de> <1321903463.1990.16.camel@neutron> <4ECAA9FE.6080802@gmx.de> <1321905599.1990.23.camel@neutron> <4ECAAF39.8000702@gmx.de> <1321906189.1990.26.camel@neutron> <4ECAB0BC.0@gmx.de> <6462023D-F767-45DE-9AF0-011CC48374CF@mnot.net> <1321912269.1990.32.camel@neutron> <E880E90A-332F-4D2F-9B20-7B7ADD03FE27@mnot.net> <1321923360.1990.34.camel@neutron> <1321923443.1990.35.camel@neutron> <4EFC737F.3050803@gmx.de> <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 <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-pbryan-zyp-json-pointer progress
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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.

+1

> 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 foo.bar[1] or foo.bar.["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. :-)

Thanks!

Best regards, Julian