Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward)

Phillip Hallam-Baker <> Thu, 20 February 2014 17:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CB92B1A0222 for <>; Thu, 20 Feb 2014 09:23:26 -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 OKYQhsvZYfx6 for <>; Thu, 20 Feb 2014 09:23:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) by (Postfix) with ESMTP id D2FEE1A021B for <>; Thu, 20 Feb 2014 09:23:23 -0800 (PST)
Received: by with SMTP id 10so1505134lbg.22 for <>; Thu, 20 Feb 2014 09:23:19 -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=CpaqKoavXoxjmfbpNNAg6Sn0cRyBxBAs62SoH5aSfP8=; b=ngMtb0h7TdXIhHX9HHacdZLbwtFmOR0VUt9A0nFGZAJLKbmidmqluQ7eKavP61DASJ mXTxlJTY4uQ1xQIKiQnTRRLt41LPPjpurPU7RyTzre0UMUDuFrW+yVl1uV9brgZU/1/U /G59x6df1IZLE3jp9zcq0G0ZZMTf4KCMWz4iVevgXC+IXt5rLieaK/MUIhqYS2FlClFg Xg+aqbPBWOVf4i9wnSm5mPUIXj7IGOfevdAkIGuqt+x4H/zSLs8ygZg7/ts1b6P9fqd0 spYO76g3SFrEpd+bVLI2o2NSEVeTM9uAxwJ/HXbVCQ30n1C2Dwapp/u2Wzzo81p2dbBC i5PA==
MIME-Version: 1.0
X-Received: by with SMTP id nx8mr1718423lbb.37.1392916999470; Thu, 20 Feb 2014 09:23:19 -0800 (PST)
Received: by with HTTP; Thu, 20 Feb 2014 09:23:19 -0800 (PST)
In-Reply-To: <FE06CD427A4044B995F57C4926A1C8C2@codalogic>
References: <> <> <> <> <> <> <> <> <> <357740A8AA0F4316BE630917321FAB4D@codalogic> <B1EBE05A69362F001777F807@cyrus.local> <47BB9131737D42218A6382DEF45BBE2C@codalogic> <> <AF211B67DB3D453D9DE8F8FA53886F73@codalogic> <> <FE06CD427A4044B995F57C4926A1C8C2@codalogic>
Date: Thu, 20 Feb 2014 12:23:19 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Pete Cordell <>
Content-Type: multipart/alternative; boundary=047d7b343d68f4854d04f2d9c204
Cc: Carsten Bormann <>, JSON WG <>
Subject: Re: [Json] Schema Requirements (Was: Re: 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: Thu, 20 Feb 2014 17:23:27 -0000

On Thu, Feb 20, 2014 at 11:55 AM, Pete Cordell <>wrote;wrote:

> My position is that, having recognised that Dates represent a case where
> microformats are useful, perhaps we should not assume that these are the
> only cases.  IP addresses?  Crypto OIDs?  Dates on Mars?

All I am saying is that it is a slippery slope.

There are two ways to go down a slippery slope, not at all or on skis.

Skis: I will add a new type, 'Format <Name>' that declares a string with
the named sub-format which can be documented elsewhere in ABNF.

This also solves my 50 shades of yuck problem trying to parse HTTP headers
with all the mindboggling syntax baroqueness. Sometimes a label has quotes,
sometimes not, sometimes angle braces. There is no logic at all just like
there is no logic to the choice of attributes or elements in XML2RFC format.

Exactly.  It's saying there's something special here that is beyond my (the
> JSON schema's) ability to define.  It's also admitting that it's a rare
> case and the JSON schema doesn't want to be able to define it.  However,
> just because it doesn't want to do it, doesn't mean it wants to prevent you
> from defining something if it's useful to you.  EBNF with narrative in an
> RFC would be a suitable way to define it's format.

Or a reference to some other spec where it was predefined.

That would also provide a way to deal with enumerations which I have
currently punted on.