Re: [Json] JSON Schema Language

Austin Wright <aaa@bzfx.net> Sun, 05 May 2019 02:51 UTC

Return-Path: <aaa@bzfx.net>
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 B1F8912034C for <json@ietfa.amsl.com>; Sat, 4 May 2019 19:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net
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 H2vJqFuC1ED7 for <json@ietfa.amsl.com>; Sat, 4 May 2019 19:51:53 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 8CD26120337 for <json@ietf.org>; Sat, 4 May 2019 19:51:53 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id e6so4693160pgc.4 for <json@ietf.org>; Sat, 04 May 2019 19:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gQNV4mlMqVKduXdXzpluCIS3jhpyZ4kkAYe/njDoWnI=; b=fJ8eBL92NqlN1PNxdevNtsMy3V0velcg0bxMwsZuf9FpflFvwurRxQ67tnztt5l2+H TgY3ujU+HEc/TNHPMIS93Qhl5BniBBNYyfYktVLUSfsgmr8KWX2bGCdXP6x5aQMXVnuu 0qxtJkT++rx+5bh/2hWzcsNw5W5dNOYKZNlKk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gQNV4mlMqVKduXdXzpluCIS3jhpyZ4kkAYe/njDoWnI=; b=OettjrAYBQojaXMu3oHh5HuvDW4dKIri5aWIqiXzJPaJ+BSRKUdgODG2XuAHFXAGT0 YwNQLys/YNtDCkrMUpZs3V2qI5HEq8I0HE0z4i6C2I/KpL82AQvbbYX6m6/vRNf5BuSW 7peg3eFV2ljMV1OnluM3O/tIJecNw/Z7qKoaT1r534RlGXJiL1pui2CzxMhfKza1DhK7 x1fif3JFmaK62Tw6WJ7uB/Ap1AKegUJNLqoGYe/HjQaWPcubtcaxsbyJTA44ayvMh2K0 2phLCqeBDf/qfjABjKa3ItRrXz2vDFDkvi/tt1Gu6XbBVcp7p7lB0t+DJPlL8EwHHVkY Bz8A==
X-Gm-Message-State: APjAAAWDis2KJFWKTY7BKfYs7Ts5EumQp2LXMX8mawx7Dbor9N2nhDpD HRmPkDeJKTNl7ThIV6NK+nr1KA==
X-Google-Smtp-Source: APXvYqwMZJOsSgEvMUhslxhIBDgqeCohtJuzMuoA8YX5mwFcGmGdMnG8bJ8Qp4mThExQ4XuBQYxrhg==
X-Received: by 2002:a63:5947:: with SMTP id j7mr22488700pgm.62.1557024712853; Sat, 04 May 2019 19:51:52 -0700 (PDT)
Received: from [192.168.0.13] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id d3sm7965146pfn.113.2019.05.04.19.51.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 19:51:52 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Austin Wright <aaa@bzfx.net>
In-Reply-To: <DA1767B8-22D6-4EA9-8112-4B36B79E9039@tzi.org>
Date: Sat, 04 May 2019 19:51:50 -0700
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, json@ietf.org, Ulysse Carion <ulysse@segment.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D21B379B-23CC-48B3-BE10-D2777308E2E0@bzfx.net>
References: <CAJK=1RjV1uv0eOdtFZ8cKn-FfCwCiGP5r2hOz1UamiM6YV4H1A@mail.gmail.com> <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <AD5ABD9C-F5F2-477D-B862-529C890D5472@bzfx.net> <DA1767B8-22D6-4EA9-8112-4B36B79E9039@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/gJISZ_wYFRG94Opxqb0CfFLckX4>
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: Sun, 05 May 2019 02:51:57 -0000


> On May 4, 2019, at 02:42, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Curious:
> 
> On that web page, it also says “For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.”
> 
> What does that mean?

It’s a non-normative suggestion with the aim of enhancing performance: Many programming languages distinguish between integers and IEEE floats by the presence of a decimal point. While JSON makes no such distinction (all numbers are arbitrary precision decimal), some parsers do make that distinction, and it’s slightly easier to determine if an int32_t is an integer than if a double is an integer.

Cheers,

Austin.

> 
> Grüße, Carsten
> 
> 
>> On May 4, 2019, at 11:36, Austin Wright <aaa@bzfx.net> wrote:
>> 
>> 
>> 
>>> On May 4, 2019, at 00:58, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> On May 4, 2019, at 06:47, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>>> 
>>>> Example: although 10.0 is a valid JSON Number, in system where you expect
>>>> an integer, this should be flagged as a syntax error.
>>> 
>>> 10.0 is an integer number.
>>> 
>>> “Schema Languages” operate at the data model level.  In the JSON data model, there is only one kind of number.  
>>> Of course, the JSON data model is not actually defined in a standard, which is one of the major shortcomings of JSON.
>>> 
>> 
>> JSON Schema handles this exactly the same way, defining a data model [1]. The lexical representation is surjective onto the data model: as you point out, 10.0 is the same as 10, which is an integer.
>> 
>> The one case where this might fall apart is if significant digits are important, such that 10.0 is different than 10.00 (i.e., 10.00 is more precise by an order of magnitude). However, I’m not aware of any JSON parsers that keep track of the precision of numbers, even ones that support arbitrary precision. I imagine scientific applications would want to store an explicit precision, since they’re not always powers-of-10 (e.g. {value: 32.0, precision: 0.5}).
>> 
>> [1] http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 "4.2.1. Instance Data Model"
>> 
>> Austin.
>