Re: [Json] Proposed minimal change for duplicate names in objects

Nico Williams <> Fri, 05 July 2013 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0A1511E8109 for <>; Thu, 4 Jul 2013 19:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FNXJqnEE7eLi for <>; Thu, 4 Jul 2013 19:52:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BE92711E821F for <>; Thu, 4 Jul 2013 19:52:08 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B2AB867C06E for <>; Thu, 4 Jul 2013 19:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=JQD0hCdGd37NnRsDiXBh swXZV4A=; b=OBAZC2fCjJJ7qC8SxU9SgSzAnGro+7uiL5oyDjwPpwL7xKiR68ZR 87lEI+qgDGT5AcvHPEMrWbMZeUrJZpO/yS5IVhCRplchXAfaAGquv4fePmuaVtPA NhqMJetVTuvqeiejlC40YwLP9AX7lv1TXIY8kf7ZW/UDc31fD+H+FRI=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 58EA267C06D for <>; Thu, 4 Jul 2013 19:52:04 -0700 (PDT)
Received: by with SMTP id e11so1547225wgh.18 for <>; Thu, 04 Jul 2013 19:52:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyyTAFELgipx2Er+WjRYLW1Igltslhz5eGtxRMipS4g=; b=gXW+ZfA30OQXpV4h0G/qnpBExWtB+lz2iauLBssAjLIAQ6xeZHXhZcQCXBr1iTHY0b m0rgyDDCTprSUFGKYix/VkvQF/+l4FLUS29/jpApJWJsGhowAbL8uWBmCrOnF82qlwgt Kz+7gJJTVdEi+x7yeW0WHjQw3IkLfnPEghi9tnFK1pwg4HEynPBXpG25Eotuvqb5NPnC 8lH3Npo2AuZkQTBK4SH4JRLuzakoGnEp/73i44EEAhOyL/XM34UhCTJON6QEZS0QwyNZ 6MCCJVuHZXdmhDNBy+3QDF3Ddoy32M2fQdFlYsA2V3iI4Mz0pr6zb9xPxvdwbbT2gzVY pOSg==
MIME-Version: 1.0
X-Received: by with SMTP id bh5mr5052310wjc.30.1372992722490; Thu, 04 Jul 2013 19:52:02 -0700 (PDT)
Received: by with HTTP; Thu, 4 Jul 2013 19:52:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 4 Jul 2013 21:52:02 -0500
Message-ID: <>
From: Nico Williams <>
To: Tatu Saloranta <>
Content-Type: text/plain; charset=UTF-8
Cc: Pete Resnick <>, Paul Hoffman <>, Eliot Lear <>, " WG" <>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jul 2013 02:52:14 -0000

On Thu, Jul 4, 2013 at 5:17 PM, Tatu Saloranta <> wrote:
> On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <> wrote:
>> I think we're very likely to get consensus for SHOULD language with an
>> out for streaming generators/parsers pushing the MUST to the
>> application.
>> We could force MUST with an out for streaming generators/parsers
>> pushing the MUST to the application, but it'd leave some implementors
>> on the rough side of consensus and unhappy.
> One problem I have had is assumption that we only have 2 layers
> (application, parser/generator). While it simplifies language, it makes it
> difficult to define whether combination of parser and deserializer (as well
> as serializer and generator) should be considered "parser" (and "generator")
> in specifications or not.
> Perhaps "application" here would then refer to serialization library and
> application code?

There can be many layers.

One application I work with is a Ruby on Rails app with a DB
underneath.  In one client I have to read a very large subset of the
DB and the run with that and an audit feed from the same DB.  A JSON
streaming generator and parser that ignored duplicate names would work
just fine because schema is enforced on the *write* side and so there
can be no duplicate names, and *nothing* but the write side need ever
concern itself with duplicate names.  There's quite a few moving
pieces and layers in this one app, but only one piece that ensures
properly-formed data -- outside that piece there is no relevance to
duplicate name handling for there can't be duplicate names.

I don't think it'd be critical to wordsmith the RFC so that this app
can work with streaming generators/parsers that are oblivious to
duplicate names, but it'd be nice to.  One way to do it is to use the
passive voice.  Otherwise there might have to be a [what do we call
this?] consideration for application deverlopers using streaming
encoders/parsers that are duplicate name oblivious.  There's a
trade-off between writing very generic text (but in a passive voice)
and having to cover a number [possibly lots] of specific cases.

> I would be happy with "SHOULD" at parser/generator level, and even "MUST"
> for serializer/deserializer level, since those are cases that are easy to
> support efficiently.

That's not really enough for my use case.

> At the same time, given such separation of processing layers, nothing
> prevents applications from doing custom serialization/deserialization, and
> by-passing strict checks. I don't personally mind that -- as long as
> ramifications are made clear, it's their responsibility -- but I don't think
> is universally agreed view.

Right, "strict checks" somewhere.  Just not necessarily in the
generator nor parser.