Re: [Json] Nudging the English-language vs. formalisms discussion forward

Phillip Hallam-Baker <> Wed, 19 February 2014 16:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CEBA1A05E1 for <>; Wed, 19 Feb 2014 08:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OmWVIFvCdb2Y for <>; Wed, 19 Feb 2014 08:52:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) by (Postfix) with ESMTP id 291BF1A05CF for <>; Wed, 19 Feb 2014 08:52:20 -0800 (PST)
Received: by with SMTP id c11so483245lbj.2 for <>; Wed, 19 Feb 2014 08:52:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Txo5Nn8IOIYDlPY9KaV8od0HdNNHDs/mNFjhwV6RA1s=; b=VKyR9EcXu0HFW88+kpjgMFVaAt3oE2V4CfC4hHmKqqAZ1DHbVuQJrq1tkG+wWtJZOd Zdu49zrLaTZG8HO8X0eHCkxtiz1Cp0zmxN2fC2AYpO1scICUvQutusbHXN6equ6oX+GR Ne+152CBsddBZeu2y2IFZpSqeqdhArjW6/HzVtJseiVKDm8MEzFBa7riKrwxETOQM2qm 1oAfjg/GBOk9loVnUholQUScq9hWwBAYEXi8FYIh2bPe/9u4WZ1PTlsfAlubTAOXmnXW MCnY1+Dq5VgZMkA3IyF202wlC7NUBnAGi3b9Hb4KsqCUYFCrQ1JRmJyTljAVhkDOQGKq gyDg==
MIME-Version: 1.0
X-Received: by with SMTP id d5mr1005914lag.89.1392828737175; Wed, 19 Feb 2014 08:52:17 -0800 (PST)
Received: by with HTTP; Wed, 19 Feb 2014 08:52:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 19 Feb 2014 11:52:17 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Tim Bray <>
Content-Type: multipart/alternative; boundary=089e0160bbe21cc47104f2c53656
Cc: Paul Hoffman <>, JSON WG <>
Subject: Re: [Json] Nudging the English-language vs. formalisms discussion forward
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: Wed, 19 Feb 2014 16:52:25 -0000

On Wed, Feb 19, 2014 at 11:05 AM, Tim Bray <> wrote:

> I feel that successful Internet interoperation is achieved at the level of
> syntax; clear specification of which bytes should be sent and which
> returned.  Many times over the years I've heard assertions that if you get
> the data model right, then the syntax is ephemeral: JSON or XML or ASN.1,
> who cares? I've never found that notion remotely plausible, as there always
> impedence mismatches.  You end up having to fight over another syntax to
> describe the model before you can fight about the syntax you're going to
> send over the wire.

The point is to focus the discussion on the data going over the wire rather
than the syntax.

When the discussion is about syntax, that is usually a specification smell.
Take HTTP's weak e-tags

ETag: W/"who/ordered/this"

Now syntax is the very least of the issues that ETags raise. But the resort
to this particular syntax should have at least been a hint of the problems
to come.

Another peculiarity of the HTTP spec, there are two encodings for dates
that parsers must support. Both contain completely useless information (why
does a machine need to know the day of the week anyway). Both are
needlessly verbose but we are talking about compressing headers rather than
not sending irrelevant data. If people had not got into the weeds on syntax
we might have come up with a better caching model.

I don't see the value in having multiple encodings for a Web Service. But I
would much rather do that than end up with two separate specifications
because one group wanted ASN.1 and the other XML or some people want JSON
and others must have XML.

XML Web services have a whole ecology that some people are very heavily
bought into. They really can't use a specification that doesn't play nice
with that system.

JSON is the future for new work. But just as the PKIX people had a point
when they asked for an ASN.1 version of KEYPROV, there are going to be
people whose existing infrastructure is XML who want to make use of work
being done by a WG producing a JSON spec.

The point is that the function of this group and any other platform level
group is to support the work of the IETF WGs and the other groups that want
to build on top. If we can provide them with a mechanism that allows them
to provide a smooth transition path to the common encoding syntax, that
helps them meet their goals.