Re: draft-ietf-appsawg-json-pointer-07 - array index for end ofarray

Bill McQuillan <> Tue, 18 December 2012 00:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6E8F21E8037 for <>; Mon, 17 Dec 2012 16:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gBKGc+ui88CJ for <>; Mon, 17 Dec 2012 16:55:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9CE5221E804A for <>; Mon, 17 Dec 2012 16:55:30 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 33F05A46E; Mon, 17 Dec 2012 19:55:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=QmVVlyOffVWT GNlZZccT9EH25yU=; b=d5y1QFgGg5Jlmq6+xFilXb37mqAnIuiME97gDmwKs5y2 61FfecvsNSbygAOSxHgowCAAOGms8D28Fd0vMqB+afslzYnIjx3i98RBSE4a9wR9 PySYBWN1FoSoSN7Uc2NTPf2SWrh6GBHonEzrBJ3HV7QzNZnfeE8PdPv95UJSud0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=hgxlzp ezLO0UmqCIUvwrSvm5Bl+PSYqZHubtMVa7qW003oWow2fWd4kliY4DHEuvOtOZuc nAv3yuLNvD5Xh32GWk3oGADRXyJIjy52Cwq09YpdEy3UAJxU6kjrU4RZQgWBkga+ 0zA/M2jlB1TXtvg4TXxAN8AWZWEAx1SwOuigU=
Received: from (unknown []) by (Postfix) with ESMTP id 21504A46C; Mon, 17 Dec 2012 19:55:29 -0500 (EST)
Received: from BQ07NB (unknown []) by (Postfix) with ESMTPA id 40413A46B; Mon, 17 Dec 2012 19:55:28 -0500 (EST)
Date: Mon, 17 Dec 2012 16:55:26 -0800
From: Bill McQuillan <>
X-Priority: 3 (Normal)
Message-ID: <>
To: IETF Discussion <>
Subject: Re: draft-ietf-appsawg-json-pointer-07 - array index for end ofarray
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 9DBE5696-48AD-11E2-BA53-F0CE2E706CDE-02871704!
Cc: Barry Leiba <>, "David J. Biesack" <>
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, 18 Dec 2012 00:55:45 -0000

ISTM that if the person constructing the pointer wants to append 
to an array and knows the size of the array (as pointed out in 
another thread) he should be able to use "/foo/<len>" where <len> 
is the index of the element just after the last existing one in 
the array. No need for "/foo/-" or any negative integers. The only 
requirement is to allow that one extra index to be used without 

On Mon, 2012-12-17, Mark Nottingham wrote:
> I disagree. Adding a capability for other indices down the
> road is NOT compatible for existing uses, so adding it will
> cause confusion ("are you using the old JSON Pointer or the new one?") and interop problems.

> IIRC the discussion in the WG went much along these lines, and
> led to us explicitly choosing a single character, rather than a
> misleading "-1" construct. I'd be more comfortable with
> changing the character to something even further away, rather
> than making this construct even more confusing. 

> The other way we could go would be to do full negative
> indexing; we don't have any use cases for that, and it
> increases complexity a bit, but at least it would be unsurprising.

> On 18/12/2012, at 6:54 AM, Barry Leiba
> <> wrote:

>>>> This was discussed in the Working Group, but it wasn't felt that the added
>>>> complexity was worth it; there's a strong feeling that this spec should be as
>>>> simple as possible.
>>> Might I suggest, however, using -1 instead of "-" to refer to the last item in an
>>> array, as this provides two benefits:
>>> 1) Allows for adding the complexity down the road in a compatible way, should
>>>   there be need
>>> 2) Uniformity; i.e. always using integer values for referring to array elements.
>> I have to say that this suggestion sounds very compelling to me, for
>> both reasons.  I know there's a bunch of running code out there, but
>> this (and perhaps teasing apart the "add" and "insert" concepts into
>> separate verbs) seems worth the bother.
>> Barry, as participant

> --
> Mark Nottingham

Bill McQuillan <>