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

Tatu Saloranta <> Sun, 07 July 2013 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C16DA11E80F3 for <>; Sun, 7 Jul 2013 11:07:55 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZS7zkwZz1KZ for <>; Sun, 7 Jul 2013 11:07:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::231]) by (Postfix) with ESMTP id 676C711E80EE for <>; Sun, 7 Jul 2013 11:07:54 -0700 (PDT)
Received: by with SMTP id a12so3184768wgh.16 for <>; Sun, 07 Jul 2013 11:07:53 -0700 (PDT)
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=BwbssAqOogAf4Ky+4jrIXA8ApP4h87lnQcjlw4SzaAw=; b=SfbJktAVTuncPpATYkx90deHFqBh+wxGFbfH0FxQuI3ehYXULppAbAuqK9A5wqcMQQ D4hWjLUmk/x8xKeo44mfNJ2xoAZXDwojm8GPdErSeTHCIDoNCu4UPTlN87Iqz3/bICNw TpLMefZnHxtU86cv59BLkjbStF1GSdB1VgGQeEmM/0nYagPavxi4xB14l6iFK8GoELE9 5ZgJ7XElMMcyNOyOVW0h5vlxeGisFzvu4RxDro8a4qOLJT0rfMwVBa/G/1CGzA2nCX7R NYuVmswhFRippRWZqG/WLFsqHJJzrgI8YXkRKEcdD+cEYDMGi/FOCHxzC5X0WCJQGNSJ NL0A==
MIME-Version: 1.0
X-Received: by with SMTP id ma17mr9879099wic.7.1373220473429; Sun, 07 Jul 2013 11:07:53 -0700 (PDT)
Received: by with HTTP; Sun, 7 Jul 2013 11:07:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$> <> <> <> <> <> <>
Date: Sun, 7 Jul 2013 11:07:53 -0700
Message-ID: <>
From: Tatu Saloranta <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary=001a11c3808e84689204e0efcecc
Cc: Jim Schaad <>, Tim Bray <>, "" <>
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: Sun, 07 Jul 2013 18:07:55 -0000

On Sat, Jul 6, 2013 at 11:25 PM, Nico Williams <>wrote;wrote:

> On Sat, Jul 6, 2013 at 11:58 PM, Tim Bray <> wrote:
> > I’ll assume you’re right when you say dupe detection has been measured as
> > expensive at run time, but I’m thinking that if I were writing a reader
> I'd
> > implement a hash table with a test-and-set method, so I admit I'm
> surprised
> > by the finding.  I think I’d need to see a little more research before
> I’d
> > accept that as a given.  -T
> Dunno about Tatu, but I think the vast majority of JSON usage must be
> coupled either with generic hash tables (objects/dicts/maps/whatever)
> or structs (with associated schema).  For the latter dup detection may
> well be more expensive than not, but probably not that much more
> expensive.  For the former dup detection is essentially free.

Yes (for second case, schema typically coming from Java class definitions,
I did not imply that overhead here would be significant.

> For other use cases, like Stephen Dolan's "launch missiles" example,
> dup detection might well be expensive, but maybe JSON is the wrong
> tool for those use cases.
> The CPU cost of dup detection doesn't concern me.  It's the
> architectural implication that does: minimal state streaming parsers
> are out.

> I have to ask myself: are there use cases where I would want a minimal
> state streaming parser?  and do I mind losing the ability to have such
> a thing?  My personal, tentative answers: "yes" and "probably not,
> maybe in such a case I should not use JSON".  Others will no doubt
> have different answers, which brings us to...
I would just note that at this point JSON is very competive,
performance-wise, exceeding performance of other textual formats, and
competing well with binary formats as well. In fact, I rarely see
compelling reason to even consider binary formats, unless payload size is
significant factor.
If this aspect was lost due to clarification for solving a problem that has
more to do with concerns for _possible_ security issues, that would be sad.

End users rarely have real need for minimal-state parsing. It is
framework-builders -- such as, say Solr, Elastic Search, Hadoop, JAX-RS
implementations (these for Java, similar for other platforms) -- that care
as performance implications there have more effect. And they are the ones
that have legitimate use for minimal-state components.

I assume all of above is understood by now, so apologies if I sound like a
broken record here.

> ...more retreading.
> I still think the best thing to do is note the divergent
> interpretations and publish Internet JSON.
I agree.

-+ Tatu +-