IETF Logo Mail Archive

Re: [Json] Call for real-world examples of how parsers deal with duplicate keys

Nico Williams <nico@cryptonector.com> Thu, 06 June 2013 22:35 UTC

Return-Path: <nico@cryptonector.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 6F2E921F99AB for <json@ietfa.amsl.com>; Thu, 6 Jun 2013 15:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 cLmKoQMAOjtZ for <json@ietfa.amsl.com>; Thu, 6 Jun 2013 15:35:04 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AC3CA21F8956 for <json@ietf.org>; Thu, 6 Jun 2013 15:35:04 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 664D327BC061 for <json@ietf.org>; Thu, 6 Jun 2013 15:35:04 -0700 (PDT)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 123F027BC05D for <json@ietf.org>; Thu, 6 Jun 2013 15:35:03 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id p60so850453wes.27 for <json@ietf.org>; Thu, 06 Jun 2013 15:35:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPdAPxVw4j6DD5WPZ6HU5GjQR+A3eTP8KBdIwUwgbhc=; b=DZy15LDrbGTQBxmJ5BTBaAKztEGlPr57KgLBEOiQcnWxhYRZvRzbR8Nbq23xUNjU4Y FyGZF9pwdagtVYVz0y82DMJRQb9PzvzfH5DjV+LbkA4+PDQbKcTmeMsfpQQddhzd2ILK NHsU+Ph5HADX8M722f6+5iJIznWALkbkdWKy4cXmLSNk5MMRJbhA1Jc6eW6ngJ88BV/g gSKg+vjqavL5p+WkCjBVWbz/rYZyaZts1krZsHCeQHHzodAeV4pUvLtNt6QiOXrQnpTP g6iSQNF+M0N3ujdwZqn++bRY3qPC1RSDcSvL6K6UIWHLkWtQn48CF3lLyyD2o7X9sj27 N8tA==
MIME-Version: 1.0
X-Received: by 10.194.79.74 with SMTP id h10mr2423775wjx.84.1370558102860; Thu, 06 Jun 2013 15:35:02 -0700 (PDT)
Received: by 10.216.63.136 with HTTP; Thu, 6 Jun 2013 15:35:02 -0700 (PDT)
In-Reply-To: <CAGrxA26H7joheXdrp2+KGcZ0wewCxVVWfcmxtqHA=q3hOXHndQ@mail.gmail.com>
References: <C79C116D-16A4-41BA-9E5A-1055E6B9C941@vpnc.org> <CAGrxA26H7joheXdrp2+KGcZ0wewCxVVWfcmxtqHA=q3hOXHndQ@mail.gmail.com>
Date: Thu, 06 Jun 2013 17:35:02 -0500
Message-ID: <CAK3OfOj2xhNa5EyuG2H-rD3mJXd6NuszZUTvTJAMFCJj8DUpVA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tatu Saloranta <tsaloranta@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Call for real-world examples of how parsers deal with duplicate keys
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <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, 06 Jun 2013 22:35:10 -0000

On Thu, Jun 6, 2013 at 2:37 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
> On Java, Jackson library:
>
> - Exposes both entries (key/value pairs) at streaming parsing level

I don't think we should disqualify that sort of streaming parser implementation.

This leads me to conclude that we should distinguish between streaming
and stateful parsers (my terms; please suggest better ones).  Stateful
parsers MUST accept only the last value, while streaming parsers MAY
(and probably always will) accept all duplicate keys' values.

Nico
--

v2.23.0 | Report a Bug | By Email