Re: [Json] Possible next work for the WG

Tim Bray <> Wed, 16 October 2013 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9214D21F8EC3 for <>; Wed, 16 Oct 2013 10:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r54SeCwyFj8l for <>; Wed, 16 Oct 2013 10:24:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7331F11E81DA for <>; Wed, 16 Oct 2013 10:24:22 -0700 (PDT)
Received: by with SMTP id jy13so599515veb.9 for <>; Wed, 16 Oct 2013 10:24:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zPMo3j0SYLBlOgaOq7XN8XKRy9NB3YX4ZT7wT4AbYqE=; b=KO4ASIEfIX7R85kTeq/oUC/O5UZqE2rPLIsUs+tnd12JQDTcnRKdH7OId20Br6zaUR UnFUjmuARK0xWimDXyzkdMbI0Oo6T+G549kTc/wChBv0Cvzzwh3IIChKGjvdmQIbAtNJ V+f80KgMQviSX5+rMgiZDNDBPVD/824PkT8jmrZIcTuoA551ktT9cfzR7x+n6DcdlFjP 8TJzujZgtTyMExuzv72x0cJTtFn6dOvr/WoODchlXaHOVYE8hgbb9X/i5o2dcew5wdzK O0H7xTIo13ArcX7LSIz+gVU1xClX7xP5PoVlUN3Ha5ifMzLRE0hc5UlADQYHaX2aVOt9 x56g==
X-Gm-Message-State: ALoCoQnRJHwWve0ut1A/LFCXFYoTzwMpK64/rR5/fPM8uWoCGd6uBVEifExFe/qdb6FDE2pYN5hp
MIME-Version: 1.0
X-Received: by with SMTP id ef2mr3235816vcb.7.1381944253893; Wed, 16 Oct 2013 10:24:13 -0700 (PDT)
Received: by with HTTP; Wed, 16 Oct 2013 10:24:13 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
Date: Wed, 16 Oct 2013 10:24:13 -0700
Message-ID: <>
From: Tim Bray <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary=001a1132e6e25a5dca04e8def8f0
Cc: JSON WG <>
Subject: Re: [Json] Possible next work for the WG
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: Wed, 16 Oct 2013 17:25:00 -0000

On Tue, Oct 15, 2013 at 7:51 PM, Paul Hoffman <> wrote:

> - I-JSON (a profile of JSON with some interoperability issues nailed down)

This, frankly, is the only real reason I’ve invested work in this group and
agreed to edit the -bis.  I want something that people who really rely on
getting clean JSON can point to and say “do this” and not have to write any
extra rules.

- Best practices document for JSON implementers and folks who use JSON in
> protocols

Nothing wrong with the idea, but I think that if we do the -bis and then
I-JSON, it’d be superfluous.

> - Canonicalization rules so that two JSON texts can be compared for
> equality

History would seem to show that this requires substantial effort and has
very modest pay-off. Also, there are lots of success stories around
digitally-signed JSON already in deployment, which seems to weaken one of
the use-cases for canonicalization.  I’d argue for passing on it.

> - Requirements for JSON schema (which will be needed before the WG
> considers working on an actual schema)

I would argue against this because designing schema languages is a crushing
amount of work and easy to get wrong.  Also, in the domain I care about
(RESTful protocol payloads) the benefit seems small.  There is a certain
amount of code you could remove, I suppose, of the form

if json['person']['id-num'] == nil
  // reject transaction with an error message about how the id-num is

but pushing the Sysiphean schema-language-design rock up the hill feels
like hitting a beetle with a boulder.

> The chairs request general comments on these or additional topics for the
> WG. If there is interest, we will re-open the topics on separate threads,
> and then put together a proposal for rechartering. If people really want
> this WG to shut down after 4627bis is done without doing additional work,
> that is a valid view as well.
> Note that we have also heard requests for non-compatible additions to the
> JSON syntax, particularly for comments and byte-oriented data. If the WG
> wanted to adopt this work, we would probably need to talk with our ADs and
> the IAB because that might be better handled by Ecma in a possible revsion
> to ECMA-404.
> --Matt Miller and Paul Hoffman
> _______________________________________________
> json mailing list