Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence

Tim Bray <tbray@textuality.com> Fri, 23 May 2014 17:02 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34E71A06E7 for <json@ietfa.amsl.com>; Fri, 23 May 2014 10:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnKRpeLYrvpy for <json@ietfa.amsl.com>; Fri, 23 May 2014 10:02:58 -0700 (PDT)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC421A01FF for <json@ietf.org>; Fri, 23 May 2014 10:02:58 -0700 (PDT)
Received: by mail-ve0-f173.google.com with SMTP id pa12so6634872veb.18 for <json@ietf.org>; Fri, 23 May 2014 10:02:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k5i4GASFGA1jaEGws3HCdxQ0RA0+R32aqov50ayYHw4=; b=Gdnr5z041vLnL1/t11PtoIclpIdX7PSjK+u6+KBAkEaBpZBP5eJSfI52V95M/U/w+V 3MmyfFNEW51P4zjcNJVlzsXJhLCKSL499ftgSNOu9zxfFfIngddxxuw8AXNeTjo6YfKd AjFqTjvQCTLqDN+Yxydct9LRgWI2JDGN0/46BRAXf1dxzRkfMbxYmKWakPnHaKGo8OZ5 ASvVfm1WqY28Lf7bk/sEdu6RUbYxQOnTdRhaU/mNQbLFHDW7mKyqnGuLvArrdcWAUi88 oi9o1hiTBSmCTNNl0dtI3mwhKphXAr5Qdgo7zineWSNalz9M6UE/51YNbxMNs2/Eq7Zp xQZw==
X-Gm-Message-State: ALoCoQl0YJI7FVXMArklLGH8DTJ2puJ3vxuLDhzmAbEkABLde7VTuCgg/Hx8nqeSIMHQHu4WQ/FY
X-Received: by 10.220.105.4 with SMTP id r4mr5328453vco.27.1400864575361; Fri, 23 May 2014 10:02:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Fri, 23 May 2014 10:02:35 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAK3OfOg088r=4VMv6PJxb97oJ6ctoUvwgkmGzi58ZkpisjoaoA@mail.gmail.com>
References: <F6B74FE0-AEBE-43CC-BDE6-BA443BC04F2D@vpnc.org> <CAHBU6itW=UQq=w_wFwYJkZLT2GotUg_J1LGs-Fhcqg_vBd4+6A@mail.gmail.com> <20140523013240.GF15289@mercury.ccil.org> <CAK3OfOg088r=4VMv6PJxb97oJ6ctoUvwgkmGzi58ZkpisjoaoA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 23 May 2014 12:02:35 -0500
Message-ID: <CAHBU6it6agso2L8iFcsxCUWK36ccy8BYcXE+40DQhgXS5LuaKQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="089e0122f33264aee904fa143342"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/lYD-ievmSq30dnkVZ3ytW9AGupw
Cc: John Cowan <cowan@mercury.ccil.org>, Paul Hoffman <paul.hoffman@vpnc.org>, IETF JSON WG <json@ietf.org>
Subject: Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 23 May 2014 17:03:00 -0000

Clearly the current language is confusing readers of the spec. So I suggest
that you be careful to define specialized terms that you are going to use
in the spec.  An even better solution would be to structure the spec to
avoid having to bring in this level of implementation idiosyncrasy.

The more I think about the resync-after-error problem, the unhappier I get.
 If the JSON texts in sequences were required to be JSON objects, and
required to start on new lines, this would be immensely easier for
implementors.


On Fri, May 23, 2014 at 11:01 AM, Nico Williams <nico@cryptonector.com>wrote:

> On Thu, May 22, 2014 at 8:32 PM, John Cowan <cowan@mercury.ccil.org>
> wrote:
> > Tim Bray scripsit:
> >> The second sentence is klunky and I don’t understand what it’s trying
> >> to say.  I suggest attaching the first sentence to the previous para
> >> and just losing the 2nd sentence.
> >
> > The key to understanding the second sentence is that "online" means what
> > you and I call "streaming".
>
> I classify JSON parsers as follows:
>
>  - streaming -> consume input text incrementally AND produce results
> incrementally (e.g., a path+value pair for each scalar value in a
> text)
>
>  - online -> consume input text incrementally (but -perhaps- produces
> one value for a complete parsed text)
>
>  - not-online -> consumes input text non-incrementally, must be
> provided complete texts
>
> Streaming parsers are also online parsers in my classification.
>
> Perhaps I'm using the wrong terminology, but I've yet to see a
> standard classification of JSON parsers that captures these
> distinctions.
>
> The value of JSON text sequences comes from not having to use a
> streaming parser (since they can be unwieldy).  There is also value on
> the encoding side: not having to use a streaming encoder, nor manually
> emit an opening '[' and ','s between texts.
>
> A real-world example of this is jq (https://stedolan.github.io/jq),
> which has an online-but-streaming parser, and which naturally supports
> JSON text sequences.  jq can consume (and produce) JSON text sequences
> in a "streaming" manner even though its JSON parser and encoder are
> not streaming.
>
> Nico
> --
>



-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)