Re: [apps-discuss] merge-patch: nulls in arrays

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 22 May 2013 00:44 UTC

Return-Path: <James.H.Manger@team.telstra.com>
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 0068021F9180 for <apps-discuss@ietfa.amsl.com>; Tue, 21 May 2013 17:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 mDQd2pwiHXeO for <apps-discuss@ietfa.amsl.com>; Tue, 21 May 2013 17:43:52 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7F83121F90EB for <apps-discuss@ietf.org>; Tue, 21 May 2013 17:43:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,717,1363093200"; d="scan'208";a="130190670"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 22 May 2013 10:43:50 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7082"; a="138151774"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 22 May 2013 10:43:50 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 22 May 2013 10:43:50 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: James M Snell <jasnell@gmail.com>
Date: Wed, 22 May 2013 10:43:48 +1000
Thread-Topic: merge-patch: nulls in arrays
Thread-Index: Ac5WNQ2Gz4R4HtEDSUOE5qSey86UagARxvJQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A7E2142@WSMSG3153V.srv.dir.telstra.com>
References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> <CABP7RbepmzSWRbWX_6r6hynGgrjz4OFq=WYbhLgz3HFNEp4O6w@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> <CABP7Rbf_M6xVCQAfsyd8_jsAv3sdeD4cjSiKWYktXnx1ccCmuA@mail.gmail.com>
In-Reply-To: <CABP7Rbf_M6xVCQAfsyd8_jsAv3sdeD4cjSiKWYktXnx1ccCmuA@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] merge-patch: nulls in arrays
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: Wed, 22 May 2013 00:44:02 -0000

> <James.H.Manger@team.telstra.com> wrote:
> [snip]
> >
> > It is pointless making the receiver of a patch remove nulls-within-
> an-array just to get a result that is identical to the sender of the
> patch simply not including those nulls-within-an-array in the first
> place.
> >
> > The spec says "JSON arrays are treated the same as JSON primitives".
> This should be reflected in the processing rules (and then the test
> case). Implementations shouldn't need to look inside arrays.

James Snell wrote:
> The spec also states that Null specifically that "The JSON null value
> is given a special meaning to indicate the removal of an existing
> value". A merge-patch document should not include any null values
> unless it is specifically intending to remove something from the target
> document. The fact that nulls in arrays were not appropriately dealt
> with previously is a spec bug, not a feature ;-) ...


Removing nulls in arrays means the patch process can be described in 2 stages:

Stage 1: Walk through objects and arrays in the patch removing any nulls inside arrays, resulting in a modified patch.

Stage 2: Walk through objects in the document and modified patch together -- adding, replacing or deleting object elements.

Stage 1 adds zero functionality. Starting with the modified patch achieves an identical result. Stage 1 does adds extra work (extra code, extra time) for the patch processor. No (legitimate) patches will ever include nulls-in-arrays that they have zero impact on the result. The likely consequence is that the extra code to remove those null will be implemented poorly, if at all.

Stage 1 removes some functionality. It further restricts the JSON values that can be created by a merge-patch.

If the rationale is that "all nulls are special", then silently removing them from patches is not appropriate. It would be more appropriate to change stage 1 to throw an error if a patch includes any nulls in an array.

Dropping stage 1 is the sensible approach.

--
James Manger