Re: [Json] Proposed Wording for New WG Charter

Nico Williams <> Thu, 20 March 2014 15:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 56BA31A03FD for <>; Thu, 20 Mar 2014 08:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.778
X-Spam-Level: **
X-Spam-Status: No, score=2.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Um3QTXxuleZX for <>; Thu, 20 Mar 2014 08:16:03 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id D10DE1A069C for <>; Thu, 20 Mar 2014 08:15:59 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id F347A318064; Thu, 20 Mar 2014 08:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s=; bh=DYWt/VqCa56+STad0yNRyq7peGs=; b=Nu3DryOm2n4 zsE9JaSFFegvYE9Onni5LxjpvxGEfSatxkgLF2T2taMnbDtjPpUXSanzrFfQauiH bNIuDwmaeNOJrgtj2Sk3Ip4ydZ0ZlDwLdL3tf/HGwbzw1T6hhSvEFLOm8Es5F9wu aSZu+HmSrv59b4zP8WMdgqRGoEyt+AMQ=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 97701318057; Thu, 20 Mar 2014 08:15:50 -0700 (PDT)
Date: Thu, 20 Mar 2014 10:15:47 -0500
From: Nico Williams <>
To: "\"Martin J. Dürst\"" <>
Message-ID: <20140320151545.GD3471@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Cc: IETF JSON WG <>, Matt Miller <>
Subject: Re: [Json] Proposed Wording for New WG Charter
X-Mailman-Version: 2.1.15
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: Thu, 20 Mar 2014 15:16:05 -0000

On Tue, Mar 18, 2014 at 01:01:28PM +0900, "Martin J. Dürst" wrote:
> >The WG will work on a format for a streamable sequence of JSON texts.
> >The work will start from draft-williams-json-text-sequence-00.
> There have been various discussions about such an idea, and various
> details of it, on the WG list. However, as far as I'm aware, the
> question of whether this should be part of the WG's work wasn't
> brought up, and has not been discussed. I'm therefore quite
> surprised to see this here, and request that it be retracted and if
> necessary discussed separately before being included in a charter
> proposal.

I'm somewhat surprised as well.  I do think the call by the chairs that
there was consensus for it is plausible, but it's true that it was never
stated that it was being considered as a work item, and that might
actually change the consensus.

> As to substance, I strongly oppose the addition of this work item to
> the WG charter. In my understanding, the need for such a format is
> marginal at best (*), and putting it on the WG charter would tie up
> significant resources that can be better used elsewhere.
> Standardizing such a format would also cause needless confusion in
> the JSON ecosystem. (#)
> (*) In particular in open exchange on the Internet.

That may be.  I don't have apps to point to that use this now over -say-
HTTP.  I do have apps that use JSON sequences internally and as file
formats.  I would like to be able to use JSON sequences over HTTP, but
wishing ain't getting and for all I know it may never happen.  OTOH, I
think a number of people have agreed that JSON sequences have useful
properties, so there appears to be enough interest.

> (#) I can already hear questions and discussions such as "Should we
> use an array or a sequence here?" and "What about sequences inside
> arrays?" and so on.

Re (#): Sequences are of JSON texts, and JSON texts are well-defined
enough that it's clear that sequences cannot appear in JSON texts.  Full

The idea is twofold: to obtain a happy middle between streaming and
non-streaming parsing of sequences (arrays if you prefer) of values, and
to not require a closing array/sequence token (']') because it may never
arrive (e.g., in the case of a logfile).

In particular, the ability to construct a streaming JSON sequence
parsers out of off-the-shelf non-streaming (but incremental[*]) JSON
text parsers is quite convenient given that a) all-streaming-all-the-
time text parsing is inconvenient, b) non-streaming parsers abound.


[*] Non-streaming parsers that require a fully-formed text be provided
    as input (e.g., json.loads()), cannot be efficiently used to parse
    sequences without the encoder having made it easier for the sequence
    parser to identify the ends of the texts.