IETF Logo Mail Archive

Re: [Json] Counterproposal #2 on work items

Francis Galiegue <fgaliegue@gmail.com> Thu, 21 February 2013 01:20 UTC

Return-Path: <fgaliegue@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2521F8CD2 for <json@ietfa.amsl.com>; Wed, 20 Feb 2013 17:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m57WkE2RSNNZ for <json@ietfa.amsl.com>; Wed, 20 Feb 2013 17:20:35 -0800 (PST)
Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5715821F8CD1 for <json@ietf.org>; Wed, 20 Feb 2013 17:20:35 -0800 (PST)
Received: by mail-ea0-f178.google.com with SMTP id a14so3657045eaa.23 for <json@ietf.org>; Wed, 20 Feb 2013 17:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bfnvlwDL/CxD0EjYf7QwMwYW5r0Z0iTL27ix8c4PUvE=; b=TiWFMCogjSq6YTCz1/s9Ius4PuMYJFQzGElex7OIpTDFJsZzpUi9kdqhsPdNPTVHVg XYw4I6zzvNFDgDJFIftlzbJevx43zWEs6GVyap4mV0N7dJYY9YdcefwdRTZIsA1P/ki5 geQIU2gjLyvoOEpTDOfDhz5GDPCU9sqwKL7rPdOHfzjTgzH0N23oOmUenqAUiB9r23k8 XwkFexwBWacKOvaQfqurqOLuOtwBYbIXNX6QFCWU/2vceG4TFH7ChkDJtOVHVanDaAjk IGN/l+ZatvZKxnShslmrelIfHFjraN9ZscYSxtYH3Q+uB0qLXmnGJ9ViJnW32flBnNpO ESTA==
MIME-Version: 1.0
X-Received: by 10.14.183.198 with SMTP id q46mr75516943eem.1.1361409634334; Wed, 20 Feb 2013 17:20:34 -0800 (PST)
Received: by 10.14.1.7 with HTTP; Wed, 20 Feb 2013 17:20:34 -0800 (PST)
In-Reply-To: <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com>
References: <CALcybBC87P7FT7n5d8xmXMxSFU1LBS9eJUsRX4hfYP5CUJr3QA@mail.gmail.com> <A723FC6ECC552A4D8C8249D9E07425A70F89B751@xmb-rcd-x10.cisco.com> <CALcybBBSL3w1-JRzUVWMmfS+jzytKNOv6omD1cR+_CLjze6WsA@mail.gmail.com> <12CE5BFB-49C5-48D0-96DF-F78F0D60578A@yahoo.com>
Date: Thu, 21 Feb 2013 02:20:34 +0100
Message-ID: <CALcybBCJ=z6u=1CGURB4ECoOaOA1igDy0H64fRm5Sj1HWQcRCg@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: Vinny A <jsontest@yahoo.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Tim Bray <tbray@textuality.com>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Counterproposal #2 on work items
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 01:20:36 -0000

On Thu, Feb 21, 2013 at 2:12 AM, Vinny A <jsontest@yahoo.com> wrote:
> On Feb 20, 2013, at 2:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
>> Duplicate keys in an object, on the other hand, are indeed an
>> important subject
>
>
> There's a lot of interesting discussion in this thread, but I'd like to see more on duplicate keys. Various parsers either throw errors or record the last key:value pair when encountering duplicate keys, and I'd like to see a recommendation consensus.
>
> One parser I've seen took a fascinating approach: it copied all values of a shared key and added them to an array, keyed to the duplicate key.
>

Isn't that org.json? I recall having seen that as well... I know for
sure that Jackson picks the last key/value pair. But the problem is
indeed that the "append to an array" parser does nothing illegal per
se -- basically, as RFC 4627 stands today, the behaviour of parsers
with regards to duplicate object member names is undefined.

And some existing I-Ds, such as JSON Patch, as a result, have felt
compelled to say that a JSON Patch operation, for instance, must have
one and only one member named "op". Which imposes constraints on
_parsing_ that RFC 4627 does not...

-- 
Francis Galiegue, fgaliegue@gmail.com
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

v2.23.0 | Report a Bug | By Email