IETF Logo Mail Archive

[Json] Re: [art] Re: ECMA and JSON Schema

"Henry S. Thompson" <ht@inf.ed.ac.uk> Wed, 17 September 2025 12:59 UTC

Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: json@mail2.ietf.org
Delivered-To: json@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7C36E64393B7; Wed, 17 Sep 2025 05:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpQoBYHIjChu; Wed, 17 Sep 2025 05:59:31 -0700 (PDT)
Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EAF0A6439330; Wed, 17 Sep 2025 05:59:30 -0700 (PDT)
Received: from flakey.inf.ed.ac.uk (flakey.inf.ed.ac.uk [129.215.202.88]) by loire.is.ed.ac.uk (8.15.2/8.15.2) with ESMTPS id 58HCxDYQ1074755 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 17 Sep 2025 13:59:13 +0100
Received: from lochinver.inf.ed.ac.uk (lochinver.inf.ed.ac.uk [129.215.24.150]) by flakey.inf.ed.ac.uk (8.15.2/8.15.2) with ESMTP id 58HCxC2J890274; Wed, 17 Sep 2025 13:59:12 +0100
Received: by lochinver.inf.ed.ac.uk (Postfix, from userid 27024) id CF8435C11B3; Wed, 17 Sep 2025 13:59:12 +0100 (BST)
To: Phillip Hallam-Baker <ietf@hallambaker.com>
References: <4f4b1323-85d9-4157-bcfb-95d58abd59cd@hxr.us> <CAMm+LwiM6nXzS8t9F0N2NK5yPAry7EDMWMvDBkERwvxZB_5_eQ@mail.gmail.com>
From: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Date: Wed, 17 Sep 2025 13:59:12 +0100
In-Reply-To: <CAMm+LwiM6nXzS8t9F0N2NK5yPAry7EDMWMvDBkERwvxZB_5_eQ@mail.gmail.com> (Phillip Hallam-Baker's message of "Wed\, 10 Sep 2025 15\:02\:19 -0400")
Message-ID: <f5b7bxxxmjj.fsf@lochinver.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b35 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Edinburgh-Scanned: at loire.is.ed.ac.uk
Message-ID-Hash: ZKQOZMMSLEZH6B253IWDIAVTJ5PVMS7A
X-Message-ID-Hash: ZKQOZMMSLEZH6B253IWDIAVTJ5PVMS7A
X-MailFrom: ht@inf.ed.ac.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-json.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Andy Newton <andy@hxr.us>, art@ietf.org, json@ietf.org, json-structure@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Json] Re: [art] Re: ECMA and JSON Schema
List-Id: "JavaScript Object Notation (JSON) WG mailing list" <json.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/hREo_eL88Q2erS9hxb3hZDnRqQQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Owner: <mailto:json-owner@ietf.org>
List-Post: <mailto:json@ietf.org>
List-Subscribe: <mailto:json-join@ietf.org>
List-Unsubscribe: <mailto:json-leave@ietf.org>

Phillip Hallam-Baker writes:

> ...
> What I want from a schema language for serialization is:
>
> ...
>
> XML Schema is a pig to work with because it cares about the order in
> which I specify elements and has this arbitrary element/attribute
> distinction. It is a document serialization format and is a really
> painful way to describe data structures.

That's because it's designed to validate serialisations, which is what
you _said_ you're interested in above, but it seems to me your
conflating two different aspects of serialisation:

 1) Specifying the mapping from a not-necessarily linear data model to
    a linear format (e.g. JSON or XML);
 2) Specifying a particular sub-class of format-conformant documents.

Only the latter is the proper domain of a schema language, IMO.

> ...
>
> 2) Does not support validation.
>
> Like referential transparency, canonicalization and many other
> things people obsess over, validation has no place in a
> serialization format. It is a misfeature that carries huge
> implementation overhead and delivers no value.

No wonder you don't like XML Schema, or XML DTDs either, I bet.

Because they were explicitly designed for the purpose of validation.
A major use case they address is one of arms-length exchange of
data-model serialisations. As Dan Connolly succinctly put it:
"Validate at trust boundaries".  If I plan to provide a service for
requests expressed as a serialised data-model, it is in both my and my
customers' interest to validate those requests.

Given the commercial weight that JSON is carrying these days, it's
entirely reasonable for those who use it for such purposes to want to
validate at trust boundaries, for which they need a schema language.

ht [Interest declaration:  I was one of the editors of the XML Schema specs.]
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND
                           e-mail: ht@inf.ed.ac.uk
                      URL: https://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

v2.35.0 | Report a Bug | By Email | System Status