Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)

Nico Williams <nico@cryptonector.com> Tue, 11 March 2014 17:10 UTC

Return-Path: <nico@cryptonector.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 AC8001A0640 for <json@ietfa.amsl.com>; Tue, 11 Mar 2014 10:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 TycqlfRNQWOw for <json@ietfa.amsl.com>; Tue, 11 Mar 2014 10:10:26 -0700 (PDT)
Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD91A0481 for <json@ietf.org>; Tue, 11 Mar 2014 10:10:26 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 150E628420 for <json@ietf.org>; Tue, 11 Mar 2014 10:10:21 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C25FD21DE6A for <json@ietf.org>; Tue, 11 Mar 2014 10:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=X3UJsO4jaNknF2jduwfVUh+quEg=; b=XlJ4bmnUDUd MMck8ln+Thp+k2o63pc8MVUj4kBTbxxyfzkPDOv/TjXwwwQ06mKxnhTSAkwn/rNW pn9KId2vpqbPyU1heaPFJrPLsZdZIzNIaCyKj3jDvGgZRUgcwjX43wXbeQ6/4pXS Vfo2R+uHkcvjJ2UH6ZPK1wNdDIMi5FXo=
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 6506521DE58 for <json@ietf.org>; Tue, 11 Mar 2014 10:10:20 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so10442006wes.1 for <json@ietf.org>; Tue, 11 Mar 2014 10:10:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v1QjCEcX0WDKE8S93MQiw6ZcqXNymom+qPQ01xNBsoM=; b=cQ67esC8jze3p43Ji6QJEOmazc7/7ZrVHiUL6ITyjvox6gI0Dd0T3zqzjAmz+GhWXV E1YMJPfhxW8ehbfAHW7WqCVIT+DgwK8acuagwvF43gkq5D8IitiHKkLb9kMBseNmXmgm BLLiEXAiLRW8o+HQkVPQb9esJIElUpdlGSFJm7GOP9gGJe5HHrYr8p7t8lXDSVOP2t2b ePRCJFghv4GOcfyo8fle/nfFeLLNMfyUt1mD5BIjDs/hKNzmqAsv9aiH4iI1JQ3tDRXZ p1yxJW2TKegU1/7CK798l38v+Km+JdpMUlyFexe956JdQmMtLH+nnuoofi0pR5H8tOqr o1pw==
MIME-Version: 1.0
X-Received: by 10.194.57.239 with SMTP id l15mr14982510wjq.40.1394557819345; Tue, 11 Mar 2014 10:10:19 -0700 (PDT)
Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 10:10:19 -0700 (PDT)
In-Reply-To: <CAHBU6iuRyRd95Wa_omGS1_T52t+s0AKjWPUW21EAh2ySHuFp=A@mail.gmail.com>
References: <CAK3OfOj_XQJq-JKAjNdH-GuH0_UwZfeWntgyyizMpTLmSaWQoA@mail.gmail.com> <CAK3OfOio58+1yuxQOcvWep1CADMfE1PVC48XDid0dWvd8=SVjA@mail.gmail.com> <CAOXDeqoYb=NXz4ikMxAg3EHFA+903bFgdpR_BL-K18U2oYriXQ@mail.gmail.com> <CAK3OfOiPDfWpOZgExTmwwq6WFcuVbyi_z3C0=M9RhQveBhV_+w@mail.gmail.com> <CAHBU6iuRyRd95Wa_omGS1_T52t+s0AKjWPUW21EAh2ySHuFp=A@mail.gmail.com>
Date: Tue, 11 Mar 2014 12:10:19 -0500
Message-ID: <CAK3OfOje8516q_2L7_3PsBa13_UGMZhKXrWbe3GCWEbHVsKnnQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/json/Z50Zea0FcLn8_4KWZ0DHjAz9rhQ
Cc: "json@ietf.org" <json@ietf.org>, Matthew Morley <matt@mpcm.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values)
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: Tue, 11 Mar 2014 17:10:27 -0000

On Tue, Mar 11, 2014 at 11:48 AM, Tim Bray <tbray@textuality.com> wrote:
> Heh, I wonder if there’d be any chance of getting consensus.  I can’t
> imagine ever using anything but Object Object Object with optional
> whitespace separator; unless we all agree on that going in I’d pessimistic
> about anyone convincing anyone else...

As I recall you opposed as strenuously the top-level value type change
in the RFC you edited.  And yet look where we are...

Alright, let's talk examples.  Suppose I have a JSON text sequence,
all of them objects.  And I want to extract a number from each, to be
output in a sequence, natch.  Why would I?  Because I'm processing
data in a sequence of filters, and one stage will be applying some
statistical analysis to just those numbers.  What's wrong with that?
It's perfectly natural to do that with -you see it coming, I know- jq.

Anyone who is adept/experienced with the Unix shell pipeline concept
will tend to like this approach.  (It's one reason I like jq.)

But more importantly, what do you care?!  Why should your lack of a
use for anything other than a sequence of objects constrain me to the
same?  On what principle?  Once you agree to the optional whitespace
and make it required when following an otherwise ambiguous value
(true, false, null, numeric), we're there, we have agreement.  You can
stick to object sequences, and I can use sequences of numbers if it be
convenient for me.

Perhaps you might say that the separator whitespace ought to be
optional always, and that fundamentally limits sequences to arrays,
objects, and strings.  That'd be a principle we could argue about
(whether to adopt it or not), but even that wouldn't justify limiting
sequences to objects.

I'm struggling to think of a principle that would justify your
favorite constraint, and I can't think of one.  What am I missing?

Nico
--