IETF Logo Mail Archive

Re: [Json] Schemas & so on

John Cowan <cowan@mercury.ccil.org> Tue, 03 May 2016 13:17 UTC

Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29CC12D1E2 for <json@ietfa.amsl.com>; Tue, 3 May 2016 06:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level:
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NOfy31aqn4Xv for <json@ietfa.amsl.com>; Tue, 3 May 2016 06:17:47 -0700 (PDT)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5822C12D097 for <json@ietf.org>; Tue, 3 May 2016 06:17:47 -0700 (PDT)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1axaCv-0003AB-AK; Tue, 03 May 2016 09:17:45 -0400
Date: Tue, 03 May 2016 09:17:45 -0400
From: John Cowan <cowan@mercury.ccil.org>
To: Mark Nottingham <mnot@mnot.net>
Message-ID: <20160503131744.GB22066@mercury.ccil.org>
References: <CAHBU6itCV9MXmALdKtE9-vjUPG6-6ZqdqzrmZkcEzSUysi3S-w@mail.gmail.com> <AC93811D-A16A-4527-B2EB-C6A9FC6D4F17@mnot.net> <20160503010109.GA17482@mercury.ccil.org> <EC4D5AC6-2730-4D6A-BE43-91197602C4CC@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <EC4D5AC6-2730-4D6A-BE43-91197602C4CC@mnot.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/HSsi5VYPdcOqBp9OIJnWxhm9KP8>
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Schemas & so on
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 03 May 2016 13:17:48 -0000

Mark Nottingham scripsit:

> Forbidding unrecognised keys isn't very JSONic, and arguably gets us
> into the same quagmire that XSD became.

Well, it's not a very important point to me.  But I had thought that
fitting JSON into statically typed records (classes, structs, whatever)
was an important use case, and for that, unrecognized keys are nothing
but a nuisance.

I'll mention that I became convinced of the need for some kind of JSON
validation when I saw a tool that consumed externally specified JSON fail
because the producer had switched the capitalization conventions of a
single key, probably by accident.  The result was that all output from the
tool suddenly went to 'undefined', because there was no validation step
to ensure that the key on which the tool depended was actually present.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
A rabbi whose congregation doesn't want to drive him out of town isn't
a rabbi, and a rabbi who lets them do it isn't a man.    --Jewish saying

v2.23.0 | Report a Bug | By Email