Re: [Json] JSON Schema Language

John Cowan <cowan@ccil.org> Wed, 08 May 2019 02:15 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 46498120073 for <json@ietfa.amsl.com>; Tue, 7 May 2019 19:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.com
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 37_QYC5uwJWJ for <json@ietfa.amsl.com>; Tue, 7 May 2019 19:15:41 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7156612002E for <json@ietf.org>; Tue, 7 May 2019 19:15:41 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id f2so1043824wmj.3 for <json@ietf.org>; Tue, 07 May 2019 19:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wbrXhuB/zfQVfAZ8wR90OCHnLV9uwd5pzGZNkRQJmHI=; b=dSl7i0QJvMDWtURAAbPAIU9dQq5oNySG8W/caiXSgXzn9zMJgfMuJ8TBrrj9TKoeYf xfouqQg84+rTpgwcn6JHs76R/o8TGbMLWPKOWkGTSlRG1vYIC90cceXBZbEMCiO/oFmp A92XAlecAUYKvu+JKesctxEIQ9Vg/vdAaV/n7YTcpD+bUnznXeHREZQm8WemSDT4k5U/ Z/GVy6XCc3T+lABDbgvSG9ESqAHLlVBYUeQRi1as7xfCPxBMS8OeORgVaXcKsSivYZnr mAsmXDBvSHKPsraOM4H3Rxed0We6RCQ9Zww6g9zlo+0UqP25j/TMDHTK+pL0MLQEmbjp pQPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wbrXhuB/zfQVfAZ8wR90OCHnLV9uwd5pzGZNkRQJmHI=; b=oHYQGVqOyiO/zBeQl1Rg05BiWS/p7n8VOj6rirfa/UyhxWCBhiP8hl3pEcStQpSduY GgYzJQWZmRNsjtmrcm3Ba8zte0hqcfJ9iLiXHr3G917uYuk0u83QKpGzyd/oVE2fsrtq SqPrhdo98DogngJpTxAke0YLd566FubmxGLmdP19UYrb9PXyCVROZv7iZTzZppLXWRIy tT8J85U5t4ltb+wkoBi65t9HOG5AaTKPHKzoKpHZyo8wCSWf20bjVYsK16jtlI2U4fni GdsqfaNEoN/LS3AITFhbl0KOEvjYvnbZk8xfr3KjKE6zmmstlQ1PEdKnSaO5TXwqbGyh 7pTw==
X-Gm-Message-State: APjAAAX4ONU6SjA5awKMP+9YjyIO6qGsvby7JdzXZDl6aXeCDD0pEeq3 K4AplHb6GwIVqbzP0oR+DSNyfcxKCGQceyCusNvlKg==
X-Google-Smtp-Source: APXvYqzi6P/kPkGd1DrWMhWSb4noq94s6ae3kKK4AjJBqWGJpaLtomMPZzl3lIOUndzNGBodUWzaivKzxVKtT7LdW6o=
X-Received: by 2002:a1c:7008:: with SMTP id l8mr939438wmc.49.1557281739808; Tue, 07 May 2019 19:15:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAJK=1RjV1uv0eOdtFZ8cKn-FfCwCiGP5r2hOz1UamiM6YV4H1A@mail.gmail.com> <CAHBU6itE8kub1qtdRoW8BqxaOmzMv=vUo1aDeuAr3HX141NUGg@mail.gmail.com> <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <CEF72901-5077-4305-BA68-60624DCE952D@bzfx.net> <CAMm+Lwi4niziaJMuL2Zqe1eX-hQkv6J10xXMd2gxf5J4X8j8Cg@mail.gmail.com>
In-Reply-To: <CAMm+Lwi4niziaJMuL2Zqe1eX-hQkv6J10xXMd2gxf5J4X8j8Cg@mail.gmail.com>
From: John Cowan <cowan@ccil.org>
Date: Tue, 07 May 2019 22:15:27 -0400
Message-ID: <CAD2gp_QqMUj7opWnhQktTL5Kx5T98v0MLd0k2HngnKVBd7PYBw@mail.gmail.com>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Cc: Austin Wright <aaa@bzfx.net>, Nico Williams <nico@cryptonector.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eabcdc058856e8ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/K6nS1vHHGtKHFXN72tg6yXH_ysg>
Subject: Re: [Json] JSON Schema Language
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 May 2019 02:15:44 -0000

On Tue, May 7, 2019 at 5:30 PM Phillip Hallam-Baker <ietf@hallambaker.com>
wrote:

1) The lexical analyzer may distinguish integers and floats and this may
> cause a schema driven parser to reject legitimate number because it is
> encoded as a double. (e.g. 1.0)
>
> 2) There may be precision loss because the number is presented in
> exponential form (1.0E20)
>
> 3) There may be precision loss because the integer is larger than the
> floating point mantissa can hold.
>

JSON encodes absolutely no information about whether its numbers are to be
interpreted as exact or inexact.  1.23 may be an exact number equivalent to
123 divided by 100, and 1.0E20 may by the same token be the exact integer
100,000,000,000,000,000,000.   Per contra, 12 could be an inexact number
that happens to have been rounded to the nearest integer.  We are so used
to the idea that dots and Es *mean* inexact, and their absence *means*
exact, and that all our numbers are *inherently* bounded in range and (if
non-integral) precision, that we think these things must be requirements of
our data notation.  But they aren't.

I agree.. And I think most others here agree. The problem is that when we
> go down the 'schema' road, we tend to end up with schema languages that
> become baroque and more hassle than they are worth.


The conclusion I drew from the XML Schema debacle is that schema languages
get wrong-footed when they try to do two things at once: validating purely
syntactically (as Relax NG does) and validating for data binding,
especially to rigid static languages.

Pretty much every programming language out there today will cause all
> calculations to be performed in Intel 80 bit floating point until the data
> has to be stored in a program data value when the mantissa will be
> truncated at 52 bits and stored in a double.


Practically every programming language can handle arbitrary size, aribtrary
precision exact numbers, either as built-ins or through a library.


John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
De plichten van een docent zijn divers, die van het gehoor ook.
      --Edsger Dijkstra