IETF Logo Mail Archive

Re: [Json] Schemas & so on

Erik Wilde <erik.wilde@dret.net> Tue, 03 May 2016 17:40 UTC

Return-Path: <erik.wilde@dret.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 4AC9612DCA2 for <json@ietfa.amsl.com>; Tue, 3 May 2016 10:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.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 xxlJo8KLeURs for <json@ietfa.amsl.com>; Tue, 3 May 2016 10:40:34 -0700 (PDT)
Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A438F12D7A3 for <json@ietf.org>; Tue, 3 May 2016 10:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cNuU/t0ko/9OOo1ZwtrVsQ16NMvljWoZDC+VfpWleN4=; b=WQ4XInsuB+Ap7HHoEOfPuQTEg1 qsaO1iP3HEEG2XyA8pLu1A3tgJ/jTBtwBpt5nlWtylTZcqpWyUNAKDssfAYW48SwpVGFbGa6yyqEi 6VhBku+7H9YkugnNzjd/42bdSP3eBzwEZwzRHLPbiCTIG1xcE6huKyqrEgMkyKEhb/9wNjTRZO4pt K07vymz62KwsET5D0TlYhIF62DnxAMQlfUzrJxg1l5tMS4H6f4Dh/vh9IeC453TyrAPEIMz5zDNRx zhPJMhFsi979Xpk4fOLM5C4CjTiGUkrrb7Jc6tBKvHu9GqmRI0vWSQgmz63g/twMUDK5QulGXnFro NcKHykUg==;
Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:62372 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <erik.wilde@dret.net>) id 1axeJF-0006NX-Gl; Tue, 03 May 2016 13:40:33 -0400
To: John Cowan <cowan@mercury.ccil.org>, Phillip Hallam-Baker <ietf@hallambaker.com>
References: <CAHBU6itCV9MXmALdKtE9-vjUPG6-6ZqdqzrmZkcEzSUysi3S-w@mail.gmail.com> <AC93811D-A16A-4527-B2EB-C6A9FC6D4F17@mnot.net> <20160503010109.GA17482@mercury.ccil.org> <CAMm+LwjVnh5H4REM9tUJjb7QvL2arxjkhjWybHerxbXUvkcMdA@mail.gmail.com> <20160503172537.GM29513@mercury.ccil.org>
From: Erik Wilde <erik.wilde@dret.net>
Message-ID: <77fdbae1-98cd-96cc-64e3-7ad321433684@dret.net>
Date: Tue, 03 May 2016 10:40:32 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160503172537.GM29513@mercury.ccil.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dret.net
X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net
X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/5fEwH9iQmQbGkf7pJhzJYL_At4g>
Cc: Mark Nottingham <mnot@mnot.net>, 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 17:40:36 -0000

On 2016-05-03 10:25, John Cowan wrote:
> Phillip Hallam-Baker scripsit:
>> I don't see any need to specify upper or lower bounds on integers. We don't
>> do this in C, C# or any major programming language.
>> We do specify bounds on representation, int32, uint32 etc. But that is more
>> a matter of convenience and space management.
>
> That seems to me to be a distinction without a difference.  We need to
> specify the bounds on specific JSON numbers so that we know that we can
> safely deserialize them to language-specific types.  I agree that we don't
> need arbitrary bounds like -1..52 very much, but 0..255 is another matter.
> It would probably be enough to allow a fixed set of bounds like u8, s8, ...
> u64, s64, f32, f64.

when it comes to datatypes and how values are being used, things get 
complicated relatively quickly. for example, even if you allow 0..255 as 
the datatype for a member, would it still be permissible to use 
"0000000000000042" as its value? it depends, right?

this is the part where XSD took a deep dive (making it complex but 
powerful) and separated the lexical space and the value space:

https://www.w3.org/TR/xmlschema-2/#typesystem

i am not saying that this complexity is what we want, but just pointing 
out that if we want some datatype facility, this is a slippery slope, 
and finding the sweet spot is not a trivial exercise.

cheers,

dret.

-- 
erik wilde | mailto:erik.wilde@dret.net |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

v2.23.0 | Report a Bug | By Email