From nobody Sun May 1 01:59:26 2016 Return-Path: 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 4F55912D1E4 for ; Sun, 1 May 2016 01:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dilettant.eu 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 Gak2KSb5_Saz for ; Sun, 1 May 2016 01:59:21 -0700 (PDT) Received: from mailrelay11.public.one.com (mailrelay11.public.one.com [195.47.247.189]) (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 849C012D1DC for ; Sun, 1 May 2016 01:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dilettant.eu; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=YdHtKIss6q861hel/mxVZsVDZC7bVHpl+FnN1Ugvmh0=; b=xUX+rytj/BqlB7BNfEyVMUhKvikpr95byWqaqAuQG1Cep2ogyORQmkC5/HUlvO2Mj9J1pnaV52o/r AaZTe/MTfuW8SSYDSVialaSo3BgoPtJZum8zLYpJu/PIt2Wqjyjy6c08x9OA+BQ47kBgYmcbm/z+BH On1HPOwQ7l1OVdww= X-HalOne-Cookie: db3e58bffde9f0ed13578af2fc63b60f250b24cd X-HalOne-ID: fb7ee27e-0f7a-11e6-9f8d-b82a72d06996 Received: from newyork.local.box (unknown [37.201.168.194]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Sun, 1 May 2016 08:59:15 +0000 (UTC) References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> To: "json@ietf.org" From: Stefan Hagen Message-ID: <5725C566.9040606@dilettant.eu> Date: Sun, 1 May 2016 10:59:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 08:59:24 -0000 On 2016-APR-28 at 19:06 in some TZ Joe Hildebrand (jhildebr) wrote: > Going back to an earlier point in the thread: > > On 11/14/15, 11:10 AM, "Tim Bray" wrote: > >> So, is there a *real* reason why a normative reference might be useful? I think there might be, and it's purely rhetorical (in the formal sense, designed to support an argument): To make it clear to the world >> that all JSON is the same JSON no matter where it's specified. So I think it would be plausible to add the following to the second paragraph of section 1.2 of 7159 (for convenience: >> http://rfc7159.net/rfc7159#rfc.section.1.2 ): >> >> “The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term “JSON text” in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.” > > I like this text a lot. Adding a few more points would be useful, I believe: > > - The intent is that the grammar is the same between the two documents, although different descriptions are used. If there a difference is found between them, ECMA and the IETF will work together to update both documents. > > - If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible. > > - If either document is changed in the future, ECMA and the IETF will work together to ensure that the two documents stay aligned through the change. > > > There is liaison work to do to ensure that ECMA-404bis has similar language, but I wouldn't have any problem with us publishing a 7159bis draft that included language like this before ECMA is fully onboard. I like the proposed text with the ammendment from Joe. This includes the need for ensuring liaison work and the possibility to first include this text and second initiate the ongoing liaison work. Best, Stefan. -- Stefan Hagen read://hagen.link talk://eventually From nobody Sun May 1 05:15:03 2016 Return-Path: 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 1C9B412B03C for ; Sun, 1 May 2016 05:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mOPwHPs2mfaK for ; Sun, 1 May 2016 05:15:00 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 ECCF2128874 for ; Sun, 1 May 2016 05:14:59 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id e201so77421614wme.0 for ; Sun, 01 May 2016 05:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MjWa3hIS4FMxyPDUxi97BmksrF+x54W5IaMXwB8i2z0=; b=LcyRCsG5j3kyMnFeHKoq/SfTk/7Z3TuZXP/UBmJrMiFf0EiikgiKbX2iWPMydUCIZP myf1gK/d6zd+LLnXxWN9IZEzpJsRDbBMBpGey8ux82uCQ4lViF0w1xNPoHDknnYVDr+b uyNJIhKSnITfAVpRoC0qAht4m1Z+I+AuujKtFet61LhqvJeTAVJm74sAzEHsTbRH6L17 7qzYp9qp/udr9pzY5D2eFmiUK6jExo4fuzWuGXblJqdXuJgo2ISBSGocOCEzvWHPbu+q Y5RhB7yggOyPa4ibwF4a8r8QlgsB3RaESlt3rqUmPeekVc3HlRvcfd2f0sthh5bU440g sB6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MjWa3hIS4FMxyPDUxi97BmksrF+x54W5IaMXwB8i2z0=; b=lsKXkx2hZVwqB7VTSgunwEtWTrHnVBD/LKNf/DIpQlJQHGHNfjl4/9FXeQVojXn/sF uzPbO0bhULn0Y4M3auyBcjw/kTASRhuSroFqYRI/un4ccZCLUsNPBaMzN/06JrNjXGO8 ReISIignszodsGhVzdmMmKO2cjEevFrLUlhSV+Tz1Xt1Gx5ACvFjOkZzwmYs1XrrHh1y 0ma3PCxv6tUt+D7CdXMwgSXXwGFUARVBsRvsEL+Wq1oSngXzHolk7dJvpUgeoJbgfsgU P6pyKCYbDgKbl6G7AsoiODhS5k2l8kyCrgAKh473plYItsS2mMzHyuY7iRiNpMeGSbfM rRIA== X-Gm-Message-State: AOPr4FVI9wvK9/FiFQkaIslTNLAj16fH9M11VgcuC02mJ7iHQo1BczdBxLsbBJsReTBqlQ== X-Received: by 10.194.84.2 with SMTP id u2mr31139010wjy.61.1462104898538; Sun, 01 May 2016 05:14:58 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id e16sm13114369wmc.3.2016.05.01.05.14.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 05:14:57 -0700 (PDT) To: Stefan Hagen , "json@ietf.org" References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <5725C566.9040606@dilettant.eu> From: Anders Rundgren Message-ID: <31996bff-e42e-8ae8-2052-06bfc9386190@gmail.com> Date: Sun, 1 May 2016 14:14:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5725C566.9040606@dilettant.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 12:15:02 -0000 IMO, ES6's JSON serialization scheme will likely be way more significant than ECMA-404 (which I believe very few application developers have bothered looking into). Anders On 2016-05-01 10:59, Stefan Hagen wrote: > On 2016-APR-28 at 19:06 in some TZ Joe Hildebrand (jhildebr) wrote: >> Going back to an earlier point in the thread: >> >> On 11/14/15, 11:10 AM, "Tim Bray" wrote: >> >>> So, is there a *real* reason why a normative reference might be useful? I think there might be, and it's purely rhetorical (in the formal sense, designed to support an argument): To make it clear to the world >>> that all JSON is the same JSON no matter where it's specified. So I think it would be plausible to add the following to the second paragraph of section 1.2 of 7159 (for convenience: >>> http://rfc7159.net/rfc7159#rfc.section.1.2 ): >>> >>> “The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term “JSON text” in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability.” >> >> I like this text a lot. Adding a few more points would be useful, I believe: >> >> - The intent is that the grammar is the same between the two documents, although different descriptions are used. If there a difference is found between them, ECMA and the IETF will work together to update both documents. >> >> - If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible. >> >> - If either document is changed in the future, ECMA and the IETF will work together to ensure that the two documents stay aligned through the change. >> >> >> There is liaison work to do to ensure that ECMA-404bis has similar language, but I wouldn't have any problem with us publishing a 7159bis draft that included language like this before ECMA is fully onboard. > > I like the proposed text with the ammendment from Joe. > This includes the need for ensuring liaison work and the possibility to > first include this text and second initiate the ongoing liaison work. > > Best, > Stefan. > From nobody Sun May 1 05:23:03 2016 Return-Path: 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 C1D3B12B01E for ; Sun, 1 May 2016 05:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 QH9tF7tjxuSc for ; Sun, 1 May 2016 05:22:59 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0114.outbound.protection.outlook.com [104.47.92.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08201200A0 for ; Sun, 1 May 2016 05:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jIycASndHLeozGoXFyYux+ORsNI//1mg2AbB95xW7Vs=; b=X5Mt05Dq/7b1WHSPZ3rr4eXYY0G2HrETdeKXcaBL7rS2dvT4oIoMIdNgTaJj2VgddSutdW9qx4/e8m28G8sK42SK4wCrRaoYFwCWBLygnUKPbXHdwcE8pkSFZNq6K+5t1ZIvzdB79O1V7lYvL5GwadZvVw8oJEAnTryGmhXEGa4= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.1.2] (114.182.30.8) by TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) with Microsoft SMTP Server (TLS) id 15.1.477.8; Sun, 1 May 2016 12:22:54 +0000 To: Anders Rundgren , Stefan Hagen , "json@ietf.org" References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <5725C566.9040606@dilettant.eu> <31996bff-e42e-8ae8-2052-06bfc9386190@gmail.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <0ee4fb33-9f59-8885-7ce3-0577e7029770@it.aoyama.ac.jp> Date: Sun, 1 May 2016 21:22:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <31996bff-e42e-8ae8-2052-06bfc9386190@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [114.182.30.8] X-ClientProxiedBy: KAWPR01CA0043.jpnprd01.prod.outlook.com (10.165.48.153) To TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) X-MS-Office365-Filtering-Correlation-Id: 6d6ce659-f2f0-4a78-a58f-08d371bb52b5 X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 2:CybD49NTQ0IvtCEc55YPlhDVQx7nckWuZ2jU0zZ1wlrknf67btJLbaiQVwSyBK5jn5j/yMEyEWz1UMySZqbLltVIINZ6nLT5g8/evjgIXXxPaEG8Khi1lnrGqUPrWfwkH2ICLfmHgimY/zE+VUg8cRbI1mzrSoz8n+ArxjUVrQEAf/h2KQpU2SX3g2uEoxvC; 3:8cJtVhIzkF1wowcyrdXaNXBU2XLJavS8YhvEl8pHQ5b/0pFSuWil769/x/zc2hO/ElKNFoE1yCB+pCzyiBuTPkvN1DYf8oXfz5YozGS1vOupc57IElIcngJ+KT9S9UtQ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 25:axJ+tEnH6Xpy7RiX8lrH/ysEp2t9Fc3F+0NrdyQUB3C0YjNz5EB5PIsm3Qv9DtyBnCj3GIzLtnw4LDKSLTXGuQLZxO96xNNO7e+3Um9gLrL4kM1djxHqbW0yoohF9o/Dwl92TzpSGkWFiyLV1zGemroez4sNzorcEv9p7054U54POfscrA+El2ANN97Lhn+X3B9TXLgZh1GW0FVhimNMagTo9s9L6ga5dsyoJxaUa2DjRoHp1IJ8yRs1WzsUQBICzuRV1PocdnWm7DrVoq0dVz4y78B79OchwMMJ1ieL1Izme6qRfu1mR9cry9N/IlhkYwWEarRvLEvBo7vGuLSce3BIyhn2ngePpHOwRqE8Ar3a1E/MzrGsHlwMXOA3iaw4EJrwhk2f9SwQODlBBnJ/hH01kuw65O7sbyEjy/Fmc5rb9deA++GdUtNqObUs4dxyXfVKQ8LWQnVZ9LetEM/TAmH6SazdUKlvaZKIhTYtTNboAQHXXekzpYZ98qr6RaGzvv2jrvHIJxuas2oxlXUbohPdcSFiyFvkS7FJ98rkY61zmI8xOcRc+G9+d0SzJ9IilMS+cbG1gmqbtfQBHWHpXnYDxjAXo9CAVDjJUZhXIiBCiw8MFovUdoILd8VWA6R9lFGHIobRCcAS2KBXoMzeYA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046)(6042046); SRVR:TYXPR01MB0927; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 4:xCwn3F/i3n5hujJZ4HZUugADk0H0saqsfbxzQdJkuxTjQaN6jTaHsAjdFwppSKjAXs+m38nBwMR4Axwdt07teE7ClbqpLBopKVv5wdtYWcfcuHz0J+5heSleIlmAGocHaWzWo4VAQVFK3GDGkDYVotFG21lHKRIkUQZ1wCKXd2gswE6OqxpHQu3SCCk71j5jE4h8V2AOKuEjlb6Ak8ewdu26bVoRoGBHW4YsV9Pqsu6m5mTDKZEEX5Z83ufjqgXlLDTpw1C4VX3EH1jhWuv6a7ifmGXOFOyrzIh78aMFWVT4WcwiqbT+PVCgS7nM+4yNgFjE/Qj5QDVX05kklnsE1NGXymlbA5dNGqvTz0LOCzT1EVdi+fxKKX0AH1sdDuEqmc8SW9BxnOoZCM/Kjh+/kSNZHNFKklADMYpyuZ/4ZZVmNPxN4fngr1RNTTT3KNM6u6+R1vlO0Vz5Ypnt2OaNtg== X-Forefront-PRVS: 0929F1BAED X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(586003)(4001350100001)(1096002)(3846002)(6116002)(5004730100002)(47776003)(5001770100001)(65956001)(66066001)(76176999)(54356999)(65806001)(77096005)(4326007)(93886004)(2501003)(23676002)(2950100001)(64126003)(31686004)(92566002)(42186005)(81166005)(83506001)(5008740100001)(50466002)(86362001)(50986999)(31696002)(189998001)(117156001)(230700001)(33646002)(74482002)(2906002)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0927; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI3OzIzOjBUZVJ6dTBaVmZleUZQb05oWnZ6ZWRQbHAx?= =?utf-8?B?OGZ4ZHhDcXFVK1lBOFcyR0ZRNDZFM0xVSmhVbXdZVTlLRXAzWVBJSHkwUGI3?= =?utf-8?B?akhLQWo4QytxQ0s3eng3bzA5NWg3M2pwcThVeXFMV2FadFNmZmFRUlV5OGp5?= =?utf-8?B?VU9maUlsamJZM21vVjZrenVpYTNscTNweDRhdFF2NHhDb2ZFMS9waWl0aWVH?= =?utf-8?B?clJnNVdzS0Q1RDZvTURQOEsyTEtTV3JCTHhKUE51WVVRb0owMTlZNjZ5dE1X?= =?utf-8?B?SENZQmZrbHYxdTZac3VHZXJxdXZld3hSWG9OWDhnNFJmekQvOGVHZ3BOd2Jw?= =?utf-8?B?L3dFMTNEUlRZaVNGb2p0WVpqdGRLMmZIUFR1bWR0b29wVktHNEhSSENSdlRM?= =?utf-8?B?dkEzR0NXaGJGVEZpRHRxV1BNOFkwR2VxdWtnUHVkVVZXbENUejZjdnl6bHp1?= =?utf-8?B?d3VPN2Y5TkxpUVc5VDJyQ2RlbFJSazRQOG1GcWpUOFVGL2Q2b3d4Z2QyUm0w?= =?utf-8?B?cU5SWGVPWEZHTFJ3Mkg3S2c1M3RLcDFtZDNYMi9WUHR1NFBHcXp5aEp2YWJz?= =?utf-8?B?QTNhVnErYUxaY2liTHE3ZFpkVDFNMk9na05JSVhVOU0xbW5CSzhXYW9OWWVm?= =?utf-8?B?YjBQYlBQOUJZZWtnOWNhRWY0VWp1djRVQzlwVi9vVllabDNoQ3Y5dldXNGNm?= =?utf-8?B?bDNsaTVyUFdkaVZJUkNJbGk4SWU0a3Zjbmx5MjNJb3JLOTRKUTlZR0cvbGs5?= =?utf-8?B?eXk4dG1wdGVaRUllUktjdkRJeWM2TDNFT2xJN05tSVMyWmQ1QWdUTzRyRDlM?= =?utf-8?B?TmhibUdvb1BIdnkwR3pLek1mZUs2Wk1NallwWU1ZQVF0YlRvSFZILzkzb2Fm?= =?utf-8?B?dldtY2NPc0JWYWVyQmlOWFFra0M0QjZIZktML3dqOXJ3SzFxV2J0TXROa1d6?= =?utf-8?B?c3NLcWdRN1dHM2NFdkFybSs5aGswbU54Y2d1ZXIvMEpYOWtNbGgyYnhJN3BF?= =?utf-8?B?MTcrcGhQRStUbStpMFZFUmY1VFRiU0FVMVlON2Y0d21SS1BLN0poQzRZUHN5?= =?utf-8?B?cWh0V0NvWEkyRUZaSzJra1ZCYkZtUjNkTlNVR1ZaeXdqTzgzQmhqbU9MWTA5?= =?utf-8?B?SnJtelVReGg5VFViaTJTUkpnS3NPU29wTThvK04xVlpDdUkxRUp1Szl1ajlL?= =?utf-8?B?UWhoQkJ6d1JyOFc0L1owR1c2ZGpMd091dEFYa1RyUzljUm4vL015LzJ5am1B?= =?utf-8?B?RVVQTDFac2d3QThzVGRGckFWZWlCaTUrS1oxMCszcXBwS09aY0FveEE5Ylpq?= =?utf-8?B?TnhRTkJ0UVIrQVU5Smg1bGVkc2ppODQxS2pVOGUyb254Q1IrbUlMU3VUK0NF?= =?utf-8?B?ZTl6K0F0d0xWWG1GRGx3bG9DOUFPMmxENGJ3T1lJSUxEc0lSZXhnT0NzdzQv?= =?utf-8?Q?jNyWgK7DqZDQ2GDmJrWI5V01Qwo?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 5:h7kX3S6PY5J7JbHEtuDlMU6bRjDWe7s4iatCjJCLU18WkkEoJ4b5F569WbJ1ZOTVbEVeLiToi0eYRo7fZQeSUepO4A6bCPaUohAFaJRnPuwYD9w1W1VMVVSDcOmB7Z1gP6D5J6VloTtQFdU/i+IG8A==; 24:hPUvuiapf1ME2QnF/9z99DdjIbOUfRlz6jjc7oGq6MtHk9gwRzfi3zgNs6igU6IYntY1d71ZjdVKQ4d5ymFCWjhkCXBclXaR9X/wFYjI+3M=; 7:OQcggn1ldAqNIPdHS9bEmtrryklOPxWKEo4lOKWVKc0gH/HAcpl2EAEA7iOpmPCIKVyiJq6kEShji+NU3/fRKZfnfIpGC9gXdUT+zOr6vSbP84GtxJTr1zyhambF99qiRFli0rLFzC63kI1v086yymp3IzTQZL4nZw9qI/zfGc7ORdihspMvpqLD0delxbxm SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2016 12:22:54.8893 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0927 Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 12:23:02 -0000 On 2016/05/01 21:14, Anders Rundgren wrote: > IMO, ES6's JSON serialization scheme will likely be way more significant > than ECMA-404 > (which I believe very few application developers have bothered looking > into). Hello Anders, Can you provide some background? Is "ES6's JSON serialization scheme" a separate format, with changes from ECMA-404? Or are you just saying that the IETF better point to "ES6's JSON serialization scheme" than ECMA-404? I guess we should do that if that's what ECMA wants, but your "will likely be" doesn't really sound very definitive yet. Regards, Martin. From nobody Sun May 1 05:36:57 2016 Return-Path: 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 39A6D12D518 for ; Sun, 1 May 2016 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eziLzAPthAen for ; Sun, 1 May 2016 05:36:54 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 044181200A0 for ; Sun, 1 May 2016 05:36:53 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id a17so103762308wme.0 for ; Sun, 01 May 2016 05:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eOSxlEpjlj+BzQxYajcI8JFtrcGuG2wwk6ZV/2WgYKE=; b=esleY/oLTlzJzOgUjlZXIULSz83CVmVGzF+ebym1DRFIqAc4+TotIYOzo/m3N5pDcN FXPEH7NW1WpVh8n2OTuzNy3OK5zUCiO8DaDPI+7eQ2yBuo5my8DJyg8fbnXOmlYzKDqj vRnCIA9XOkfhVCM2wmgi6cOsKxzhrv6Cq7Sj5vosBG55pVeiIh70oog4q1Wpa98VNA72 MB276R+ZX5mxQ+M2Bl0ZBdo8v6je7jb1bHjd4w7k/gbMg1SKE+DtHFRhEEaNHViA7wEz gKPyhBPxo3rEvc9WQyK/8Hwr06YEzALylimuXQRtMLlsncUqdu3lgVQvDZi8J84n1fJY a4nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eOSxlEpjlj+BzQxYajcI8JFtrcGuG2wwk6ZV/2WgYKE=; b=DO1gGKYLUsvxZSYcBC63WTU3IYmVa6pEngSNqyc+y9HoLcxxaVZq5+Ju4Te6x/wNOy dC2GAgPAS6a2FCWgenK3Jm4zxnlH9tcnqCwBQFzIj7n9u/srPsuRY7jxe87bcB9Mmtzl V0SR9XUKM1lxqM6sz0EakBJfp82jcmLoJnkuIFCdVnqY9Y1nnKattv5Au4VDtjjEV/cz TOmu3WzDiwAa/6wPUm+PxC9cpsI19T8qP7PQI4GfMQAzAZ6IYFNlDwOCpxg3yyHvSJhK tQ8sEPgW8LBZedrzlrIZWyz+cehyj0kCpXqDP5Kqy7Ld4fBzmDGAIL9rQsSMj3MbXUG4 wAJg== X-Gm-Message-State: AOPr4FW9rKfpMGhHNEEQ1dw6F1Fe7kpj94m+/TZSqzagcMa4kIOvyZ2/hbidBK+DLIXskw== X-Received: by 10.194.184.38 with SMTP id er6mr30286312wjc.93.1462106212483; Sun, 01 May 2016 05:36:52 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id d79sm13143889wmi.23.2016.05.01.05.36.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 05:36:51 -0700 (PDT) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Stefan Hagen , "json@ietf.org" References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <5725C566.9040606@dilettant.eu> <31996bff-e42e-8ae8-2052-06bfc9386190@gmail.com> <0ee4fb33-9f59-8885-7ce3-0577e7029770@it.aoyama.ac.jp> From: Anders Rundgren Message-ID: <397a238d-4d50-a852-6e96-ccb7aa08148d@gmail.com> Date: Sun, 1 May 2016 14:36:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <0ee4fb33-9f59-8885-7ce3-0577e7029770@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 12:36:56 -0000 On 2016-05-01 14:22, Martin J. Dürst wrote: > On 2016/05/01 21:14, Anders Rundgren wrote: >> IMO, ES6's JSON serialization scheme will likely be way more significant >> than ECMA-404 >> (which I believe very few application developers have bothered looking >> into). > > Hello Anders, Hello Martin, First off I don't see the point with having multiple organizations specifying the JSON core format. AFAIK, JSON started its life as RFC4627 which later was upgraded by RFC7159. That is, ECMA-404 can safely be ignored. My reference to ES6 is not related to the JSON format, but how JSON parsers and serializers could (IMO SHOULD) be implemented in order to offer maximum interoperability as well as supporting digital signatures in a human-friendly way: https://cyberphone.github.io/openkeystore/resources/docs/jsonsignatures.html Anders > > Can you provide some background? Is "ES6's JSON serialization scheme" a > separate format, with changes from ECMA-404? > > Or are you just saying that the IETF better point to "ES6's JSON > serialization scheme" than ECMA-404? I guess we should do that if that's > what ECMA wants, but your "will likely be" doesn't really sound very > definitive yet. > > Regards, Martin. > From nobody Sun May 1 14:58:29 2016 Return-Path: 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 B7AAB12D193 for ; Sun, 1 May 2016 14:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 LVUyCWk-CT43 for ; Sun, 1 May 2016 14:58:25 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 7255A12D144 for ; Sun, 1 May 2016 14:58:25 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id 90so47092981qgz.1 for ; Sun, 01 May 2016 14:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=itNRvQapZTUmClg8s6e/QXrVy7LAKEf0Ybczw6C9kPM=; b=tVPKoCFVLX6LaysxNXanC73ucuWARWFx7KQaOxUIZOkmFLwq4m+PyPSTBdRLjp7jR9 bA8mSH1fAXn6RSsxWHplMqnP94ZqTf6YwL1bO5BBsug97+2y5pkhT6UpPVXJSMcPJEAg Ep3Zd+SdWGz/63+Jvy1zRpVsQhWYhqcrLedNNO+lVKZhQsxrEmaCZC7IYAAAPbKyR5Go sld0ivs+Zi+IGTUJfRFfvEm2+iCu2haewaHojzT631OvozuE/8XxvBdmX3afQq+0nvjI +d5gmyEnO9CTiTvdwFxSA5HQL8DRmETz6KzQSicQ8xmKOQbjJNjnpHM36dxU1OYAtSUO 4Ywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=itNRvQapZTUmClg8s6e/QXrVy7LAKEf0Ybczw6C9kPM=; b=DqfhdSQ2W5Il9mZ5/2tvvo+YVJFEP7UiPYjoUzyFp/KqWkJNMLD72zjiikBYnRe/JX bMGiDnjNxaAkW+ld0XRzuLOb+JKqLkox0O5SqtMeSh9GVfIEy9UY2s7lVmFjDmfLk/Ov GL7ZdARj8UU25b3ouTqPP9iLFjqMIgQQFSvEpcUL1ZOA46EihZT591UxO19J5q96mDUm RbvznUnkxHzZdMYb+4DSiABmtdMNucDF5G1BOGGXeuVlgUhz2sKM1MCkR9n6LUPcsGmO iWixhJVQT1tedFjdqrzsmtJvr+DtFCZ7cGu2aETR/vx6rAYTepdqHb23AKDfERIeoJWv yGWQ== X-Gm-Message-State: AOPr4FV+49VGrK/RBwzMRMm9xDhL3mzitJ8fvakg63xDfmiVaHoKoYgqzYTJqFyI5xS1OEATRwsZ01GuhdmsRQ== X-Received: by 10.140.94.169 with SMTP id g38mr28807722qge.35.1462136305807; Sun, 01 May 2016 13:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Sun, 1 May 2016 13:58:06 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> From: Tim Bray Date: Sun, 1 May 2016 13:58:06 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a113a368c1f095a0531ce2336 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 21:58:28 -0000 --001a113a368c1f095a0531ce2336 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Never seen anything quite like this in an RFC, but it doesn=E2=80=99t feel = crazy or damaging. I share the opinion expressed by others here that ECMA-404 is largely ignored and of marginal relevance, but I gather there=E2=80=99s a perceived= benefit in establishing that ECMA & IETF are in sync on this subject. On Thu, Apr 28, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Going back to an earlier point in the thread: > > On 11/14/15, 11:10 AM, "Tim Bray" wrote: > > >So, is there a *real* reason why a normative reference might be useful? = I > think there might be, and it's purely rhetorical (in the formal sense, > designed to support an argument): To make it clear to the world > > that all JSON is the same JSON no matter where it's specified. So I > think it would be plausible to add the following to the second paragraph = of > section 1.2 of 7159 (for convenience: > >http://rfc7159.net/rfc7159#rfc.section.1.2 ): > > > >=E2=80=9CThe reference to ECMA-404 in the previous sentence is normative= , not > with the usual meaning that implementors need to consult it in order to > understand this document, but to emphasize that there are no > inconsistencies in the definition of the term =E2=80=9CJSON text=E2=80=9D= in any of its > specifications. Note, however, that ECMA-404 allows several practices whi= ch > this specification recommends avoiding in the interests of maximal > interoperability.=E2=80=9D > > I like this text a lot. Adding a few more points would be useful, I > believe: > > - The intent is that the grammar is the same between the two documents, > although different descriptions are used. If there a difference is found > between them, ECMA and the IETF will work together to update both documen= ts. > > - If an error is found with either document, the other should be examined > to see if it has a similar error, and fixed if possible. > > - If either document is changed in the future, ECMA and the IETF will wor= k > together to ensure that the two documents stay aligned through the change= . > > > There is liaison work to do to ensure that ECMA-404bis has similar > language, but I wouldn't have any problem with us publishing a 7159bis > draft that included language like this before ECMA is fully onboard. > > -- > Joe Hildebrand > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a113a368c1f095a0531ce2336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nev= er seen anything quite like this in an RFC, but it doesn=E2=80=99t feel cra= zy or damaging. =C2=A0

I = share the opinion expressed by others here that ECMA-404 is largely ignored= and of marginal relevance, but I gather there=E2=80=99s a perceived benefi= t in establishing that ECMA & IETF are in sync on this subject.

On Thu, Apr 2= 8, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com>= ; wrote:
Going back to an earlier = point in the thread:

On 11/14/15, 11:10 AM, "Tim Bray" <tbray@textuality.com> wrote:

>So, is there a *real* reason why a normative reference might be useful?= I think there might be, and it's purely rhetorical (in the formal sens= e, designed to support an argument): To make it clear to the world
> that all JSON is the same JSON no matter where it's specified.=C2= =A0 So I think it would be plausible to add the following to the second par= agraph of section 1.2 of 7159 (for convenience:
>http://rfc7159.net/rfc7159#rfc.section.1.2 ):
>
>=E2=80=9CThe reference to ECMA-404 in the previous sentence is normativ= e, not with the usual meaning that implementors need to consult it in order= to understand this document, but to emphasize that there are no inconsiste= ncies in the definition of the term =E2=80=9CJSON text=E2=80=9D in any of i= ts specifications. Note, however, that ECMA-404 allows several practices wh= ich this specification recommends avoiding in the interests of maximal inte= roperability.=E2=80=9D

I like this text a lot.=C2=A0 Adding a few more points would be usef= ul, I believe:

- The intent is that the grammar is the same between the two documents, alt= hough different descriptions are used.=C2=A0 If there a difference is found= between them, ECMA and the IETF will work together to update both document= s.

- If an error is found with either document, the other should be examined t= o see if it has a similar error, and fixed if possible.

- If either document is changed in the future, ECMA and the IETF will work = together to ensure that the two documents stay aligned through the change.<= br>

There is liaison work to do to ensure that ECMA-404bis has similar l= anguage, but I wouldn't have any problem with us publishing a 7159bis d= raft that included language like this before ECMA is fully onboard.

--
Joe Hildebrand


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--001a113a368c1f095a0531ce2336-- From nobody Sun May 1 15:03:01 2016 Return-Path: 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 B184212D195 for ; Sun, 1 May 2016 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 QG3AS2JPPWuX for ; Sun, 1 May 2016 15:02:50 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 EB3D612D193 for ; Sun, 1 May 2016 15:02:49 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x7so66912156qkd.3 for ; Sun, 01 May 2016 15:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=d94jD9ma0GkgsY9GwunogVc5lw7D7Dyutdr2i1J8vvk=; b=yY/ZrgIHpvoT+8Ha7yZNh4r7WuBidqKXwdzLB36+/jSfLl1H3arnzfmUh3GLCffa1e 92NNbMAXsZaRAIA2audYHK+CsRMQteC/sjQByK7bAW/kkd+qS1sOEluigqDjk7ia9qL6 gBJkO2yPOkcm2ACKmfIyev5M9+9wMwVos5tAmgYd4jRH4JH1+fbPxEbC3tdxCiKM+gm8 5dveaAyJn+7Ln/kbm/NqXnAObMcNAgp0tUn7crcOCI0kbClQvBE+uAQChXCOJ1DlmlT9 rgALbMvMBSLnrZm5yp999xByYvEAoGN/9kOKLTMTWNU7w06B7JTcGD12fYn9pN6h5jk9 WwTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d94jD9ma0GkgsY9GwunogVc5lw7D7Dyutdr2i1J8vvk=; b=h5yD3dIqH58s8CodInN2q8n/SicgU18DaO113eoZMIZFbjZwBji2a8UIMpMDHXKHZz e1ByqHRXfund4k9K9kWQ9CLESU+wFs0V6tDF6KOpiMA2kXTKCejJ3vAumRuj1Nthj1eZ lCsQp+WevbgZr/hsSVGRh9AWR6oLEWW66WGkmhF7K2vvi/jwvsa8Wzf+PmPyd4yE8X/V k5F28bA5/FvOTV4xbUOxUo+4mwQUH58JN8BXn8jwYghM+Kud8LoGtJY9cvbV1iOtKxWl hE2+CI2SU5ExTyk1D+ZEiCnVoVdP8jyDVDdA9cX35VeUVZh7WG2ps8wcPz5T4PEcRJ8j toTw== X-Gm-Message-State: AOPr4FXkQ1AOJcG/atCEsfQABbDSHqhTDHWUCIe0/L1sZGvYb5xVQi6Eonb+10sXUZOioc/jb1l81KjC/Zur0A== X-Received: by 10.55.72.196 with SMTP id v187mr29513661qka.97.1462136150456; Sun, 01 May 2016 13:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Sun, 1 May 2016 13:55:31 -0700 (PDT) X-Originating-IP: [24.84.248.61] From: Tim Bray Date: Sun, 1 May 2016 13:55:31 -0700 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a114a7f88dc96b60531ce1927 Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 22:02:57 -0000 --001a114a7f88dc96b60531ce1927 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I find myself tasked with specifying a JSON-based DSL and preparing it for public release, with a validator and so on. I had never really concerned myself much with options for JSON language definition, but have discovered they=E2=80=99re not very good. The JSON Sc= hema project is not terribly appealing - opaque spec, poor documentation and tools - and smells of neglect (last I-D expired in 2013). It's been suggested that a good approach would be just to write a jq program that emits true or false. Is there good conventional wisdom about formally specifying a JSON dialect? --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a114a7f88dc96b60531ce1927 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I find myself= tasked with specifying a JSON-based DSL and preparing it for public releas= e, with a validator and so on. =C2=A0

I had never really concerned myself much with options for JSON= language definition, but have discovered they=E2=80=99re not very good.=C2= =A0 The JSON Schema project is not terribly appealing - opaque spec, poor d= ocumentation and tools - and smells of neglect (last I-D expired in 2013).= =C2=A0 It's been suggested that a good approach would be just to write = a jq program that emits true or false.

Is there good conventional wisdom about formally specifying a= JSON dialect?

--
- Tim Bray (If you=E2=80=99d like to send me a private = message, see https= ://keybase.io/timbray)
--001a114a7f88dc96b60531ce1927-- From nobody Sun May 1 16:18:47 2016 Return-Path: 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 BA87512D199 for ; Sun, 1 May 2016 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 J0FfAZRyRaQj for ; Sun, 1 May 2016 16:18:44 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0103.outbound.protection.outlook.com [104.47.93.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFA612B04F for ; Sun, 1 May 2016 16:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MHvyBboxn16t0ZsdUuJK0X0SBscS1hv3Eh8feXoXAbI=; b=jqD4AHW1MXuSQ4Nx1Bcwg5S3WfwffO8r+DgNDabTBxn7puzTClqOFznZuQnVm3h9+KWSfjOdhFe35ZRHehUoB6RRXZwgW+x6b98DqnIQwvuiBuGkxzHbU78sujZUeJcJGWyinycIfV1z5rHCXLv0mcIuIOFuUcPriYW2WdmEcS0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.1.2] (114.182.30.8) by OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sun, 1 May 2016 23:18:39 +0000 To: Tim Bray , "Joe Hildebrand (jhildebr)" References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <95df8fdb-dd63-a311-6df7-4eccd877a350@it.aoyama.ac.jp> Date: Mon, 2 May 2016 08:18:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [114.182.30.8] X-ClientProxiedBy: TY1PR01CA0032.jpnprd01.prod.outlook.com (10.164.162.142) To OSXPR01MB0920.jpnprd01.prod.outlook.com (10.167.148.150) X-MS-Office365-Filtering-Correlation-Id: a5d986c0-5277-433d-29f2-08d37216edf7 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 2:sLCswvdYZDiUsrABqpbWzkveUrMVJc+SmPBo4v486HQFy7J/7bz7/aWd8PN0UChXR6Bk8QKeL+4+VIKIceluVxfxktDrOMEa0Io/XKFi28Mn1uNGAB6eeqhsXKf6grmxBfvZed/T09ti/cGN1hbRt+/8YEvr02NgbBWWROLKIo3m/VqTuS5WrOSxTM+p365G; 3:NZSTwS9b7OADU4sSWxAR4xZr7Rhos7PO/xPys3PSYgBSuDNOfNl25QFSJbKf7c00jO39w2UlJHLo+VI/Cvt6j1jUvoA0NJ6XnR+ANEviljHXDLwZ7vOJXr2sc7s6Tkpy; 25:dcDRL2KiFdY2XUwRVw1JzNst/T06AeZa99Mf/9DrOeGKXO4cY9AJLteSVV5pxVfomux/Pi3/QMYWPd4HdtN4pSTEOMluu6Fx7JEUHFZ2XGLFRZ3Z0iAXP7h/796OC04TUg0tGz7pkGXxxG/Vem5+FVfqC5rIOL48VE9MmS/XBUl+SkDRyHlB76gMUXqGILb/lO569uZ4YtfSxPxDHOge6hTX67117SA/QPsGVNuOBZAzjHSgN/6PaXkN+W9Qb2Gn6lbV2LeGfgU8ddLx2sagpQYkazxYT7QEvbsrHhyVdU4yFYGVFkS6opyOJp1/5YXoE4g6L17ioeTGzH4RxxxH1Cre+csg2scFWuqtbbWSlHZkVXJdMTHer9D8o+qhQa/m2+Il7WCBAki7jC7+gp9pAXzQouvfBjdj+8Jjuu1unfm5McIV/g8cAhn0cPExU5UH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0920; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046)(6042046); SRVR:OSXPR01MB0920; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0920; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 4:9oasYraItvTh1FqupAypyvTxFe/Oo8ZZWIsB2CGGHCxIUR0TSutF14wq6BMTG+aaSF2JvM0Z/pQlHzoIEQzlUY66qidTRg3IbZmmyCGOTUzG9PXhb+WJTyJm9dfXD52W+4Qp8vlUQMegSlG0+agVCXRykgdvc7ZvzFhUwiJs+/CwUBwGMEmXlmZ7P9qzgfJagBvd4d2SCyjzSd6nT4Y+e/vNtlpNkCUzw5xvQ5BpcjiyYTf+8US0CwPwkuk0gSyLHJ9I9nZD1p7oKkWt+VnEJqQZbby9ntOWNHgU+2p6U15m5+rTBKLX0OdT/VwH9K6vAHG7xGb2oRBxXiZpNsuqRaEHyFfrRzkJS+XbF25DPceO/vgkWzr3Tg8UgLuRE202iw5bB+43owteClh/+dCpbOl+aBoMW6HxKbsn7J8ooE6Ga50wQvpfLXxIBOqFOz3SOvZmQBLBh5LE8asPiFEwNrPFjzmteJjlKwM2g3hkWk42mrpFUmEHR7cTPDYanku1 X-Forefront-PRVS: 0929F1BAED X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(4001350100001)(5001770100001)(189998001)(74482002)(586003)(50466002)(19580395003)(3846002)(19580405001)(83506001)(50986999)(77096005)(1096002)(15975445007)(76176999)(54356999)(2950100001)(2906002)(5004730100002)(33646002)(23676002)(92566002)(15395725005)(4326007)(561944003)(5008740100001)(86362001)(42186005)(31696002)(81166005)(6116002)(2870700001)(31686004)(93886004)(66066001)(65806001)(65956001)(47776003)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0920; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwOTIwOzIzOnF3SExQMGZRRkxXeDVnaTBIU2U0RktJb1Na?= =?utf-8?B?TFlTQ04xMDNheEhET1NJQjdaNzRoSEEyKzJESWo1ZzFTVE42MlR4RUM2dHNl?= =?utf-8?B?Q1haWnF5UWJCSWZQRWw5clMvdWE0QlNiRFMzRDUvVUZnUVJuUVMwODBDNDZa?= =?utf-8?B?Si9qZVIrTk9nUGN6WWRrOFlQWTBGWmV5NUJhK1RtaVVCRVZ2aXJLQ3lNSGJu?= =?utf-8?B?UjZjbW96V1FSQ2tJYklHT2drUkJTVjdyZGZQOXJqaGJsNHI0MG5nbS9ONTBx?= =?utf-8?B?L1FrNEs0OXNUZFU3NUVTd1phZUxjNDBzaWcwWk5zNkI0elVrUVF4SVVGM1Zm?= =?utf-8?B?bkpPblRYZ2wyZU1IcEFYUjlQRWNOL1hDM3l4b3lQR0xOWXRSRy9CaHdGcTV5?= =?utf-8?B?M3BydHBDZk5NUkI3WU91L0ZUQWR0ZkNkZmxqTUxDRFdiODJjSXNiNXlkWStU?= =?utf-8?B?Sy9VTmpZWC9OZm9aVnkyRmpzaVRyUGRGMTFUaFUrK21FSXFIQitFOFA0b1F3?= =?utf-8?B?OWVvWk5JWjFuakZZTit4T0NIelI0MFphMjVFMTV3Q1lmRzFNWHorM2dHKzZY?= =?utf-8?B?d2NRa0dJSmpLRENHbk5hQzZWa2FTRG55S0JGYUNoNzFmbWx3RmJCNktVajVJ?= =?utf-8?B?b0IzVlJQd3J6QzFhUEJibDVab3JMemE3N2FOWjE1Rm1MSnVuLysvUmlvVmRi?= =?utf-8?B?RzlpVEZaejgzL2s3Vkk0cXNmdjNQNG40UVpZYnVUYmsrY3hpUGRORklHUWQr?= =?utf-8?B?ZFNRVXBtTFJBa2toUUJ5OEczeGlyaGhHZFJPT2p5QkdVNXc2Q3JnU0Rrb08v?= =?utf-8?B?UkFpbWxjWHpNUElVakRBMFRxWHZNd05mY2kzU0tmSXZCc1FYWXBjaTFJeG45?= =?utf-8?B?NG5scld2M0JYN0pCdGh4ZGJJb3R1NTc5U3FWYjJROXJSeTZHMytkSEtLajE4?= =?utf-8?B?ZG54aU85VEZHYlpjVTU3SjJJMkNWemhrRFhWZzkrM2FmQUZKcEpxVGx1QzhR?= =?utf-8?B?d2tKbm5IK0hYcVhFS0ZiUEc2RFBZRnRrdFBLbGRhZ2ZhRTd5TkQ4RjZJbkFq?= =?utf-8?B?SFMvVEIxbGM2U0NGMENPV1hRZTF3eWhPMmdmS2pManBQUU8rbC9GcFVwNHN6?= =?utf-8?B?ZWNhRldTazZONmlFc2NKOGMrNG9lcU9BUXlWMmlSQjFFL09xQkZnbDVBcjln?= =?utf-8?B?aG9pckd6WHVvRVpWUU5VTHNaNjJuMlh5OU0vU0tEUmRqTUQrN0VSV2ZWZ1hN?= =?utf-8?B?Vjl1RFFCU1k2NWlvVGVFNnFDWTVtMjBocGRjamwwcGs5Vnc5U1hVMVZyUTdi?= =?utf-8?B?cnNqSFVlUEk3WFN5a05kd0JXcGh1TmxWQS9EcHNkNkpmTUpuUTdlTEtLZTZU?= =?utf-8?B?dDUyTDNtZDNVOGNYRkRTK3ZoT20vRFI2K1VRdTlWalFqQzZYeE9JZ2JQU0Nv?= =?utf-8?B?WU9URUN0RlhOR2llN09wdjF3dFQ5MkMvS0FCT0tQL1VwYW1Bd1h1RFQrOVlI?= =?utf-8?B?RVlEUkg4ZUxlRHlJV25oRS9ZaVl2c1Q1RzNqQTJTM2dDb2poTStWV2FrckQ5?= =?utf-8?Q?gvsvjwuhqLjrI3YxM1/b0LfdZxid7zRz6LKtCPGWzWHw=3D?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0920; 5:LMzav68oGbuYBNkCVzIpc2rdweNDqlsb0g7lVg3rKpywsHP5Jk1uKaSw2D3VUiSYsp6MUXJMlz/KLzMZBaO4NGQX9a6mySr57a6zeDnyOW9AyLNtuXVhgzHrm9om30Qr5CuHL2nUNIS1JvJsK10/NQ==; 24:hGzr9mif7npOe1F3Oy5wwity6yFmtYs059z/4Yznr2oPxh7jP6XeWFP4Y8cir4C45rLQXyngLCmLDfXf3XxAvx9Jg+l8ADDmzn1SOrOlm2I=; 7:hwOmP0vFBLP6wTi9ZgeX7SEWbXMEiaNoU3lfav6oSetHyd3L/8ddw8m01f15Mo9IQVlnGfGIbc+1bvO4qDPDlYxOueI8q1V0qw11bazqpS2IPoslUeWsgwTlkgwSIcXR9Efdk+axPqgfSQB1IpUILfhIIfuZ4n8xeEH1zUwBlYpzH69HWd0O3zLTT8Rpg4nO SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2016 23:18:39.5367 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0920 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:18:46 -0000 Just for the record, I also agree with Joe's text proposal. Regards, Martin. On 2016/05/02 05:58, Tim Bray wrote: > Never seen anything quite like this in an RFC, but it doesn’t feel crazy or > damaging. > > I share the opinion expressed by others here that ECMA-404 is largely > ignored and of marginal relevance, but I gather there’s a perceived benefit > in establishing that ECMA & IETF are in sync on this subject. > > On Thu, Apr 28, 2016 at 10:06 AM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > >> Going back to an earlier point in the thread: >> >> On 11/14/15, 11:10 AM, "Tim Bray" wrote: >> >>> So, is there a *real* reason why a normative reference might be useful? I >> think there might be, and it's purely rhetorical (in the formal sense, >> designed to support an argument): To make it clear to the world >>> that all JSON is the same JSON no matter where it's specified. So I >> think it would be plausible to add the following to the second paragraph of >> section 1.2 of 7159 (for convenience: >>> http://rfc7159.net/rfc7159#rfc.section.1.2 ): >>> >>> “The reference to ECMA-404 in the previous sentence is normative, not >> with the usual meaning that implementors need to consult it in order to >> understand this document, but to emphasize that there are no >> inconsistencies in the definition of the term “JSON text” in any of its >> specifications. Note, however, that ECMA-404 allows several practices which >> this specification recommends avoiding in the interests of maximal >> interoperability.” >> >> I like this text a lot. Adding a few more points would be useful, I >> believe: >> >> - The intent is that the grammar is the same between the two documents, >> although different descriptions are used. If there a difference is found >> between them, ECMA and the IETF will work together to update both documents. >> >> - If an error is found with either document, the other should be examined >> to see if it has a similar error, and fixed if possible. >> >> - If either document is changed in the future, ECMA and the IETF will work >> together to ensure that the two documents stay aligned through the change. >> >> >> There is liaison work to do to ensure that ECMA-404bis has similar >> language, but I wouldn't have any problem with us publishing a 7159bis >> draft that included language like this before ECMA is fully onboard. >> >> -- >> Joe Hildebrand >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun May 1 16:19:33 2016 Return-Path: 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 23E8712D53F for ; Sun, 1 May 2016 16:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 PydpFPvj8tXz for ; Sun, 1 May 2016 16:19:28 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1C12B04F for ; Sun, 1 May 2016 16:19:28 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,564,1454936400"; d="scan'208,217"; a="74602665" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 02 May 2016 09:19:26 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8152"; a="108281427" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 02 May 2016 09:19:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Mon, 2 May 2016 09:19:26 +1000 From: "Manger, James" To: Tim Bray , "Joe Hildebrand (jhildebr)" Date: Mon, 2 May 2016 09:19:24 +1000 Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AdGj9J3oi6sCAl2DSfWxPeIRXoK2FAACAajA Message-ID: <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BD0AFB47FWSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:19:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BD0AFB47FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U291bmRzIG1vcmUgaGFybWZ1bCB0aGFuIGhlbHBmdWwgdG8gYWdhaW4gY2hhbmdlIHRoZSBSRkMg bnVtYmVyIHRoYXQgZGVmaW5lcyBKU09OIOKAlCByZmM0NjI3LCByZmM3MTU4LCByZmM3MTU5LCBy ZmNYWFhYIOKAlCBmb3Igd2hhdCBpcyBzdXBwb3NlZCB0byBiZSBhIHNpbXBsZSBhbmQgc3RhYmxl IGZvcm1hdC4NClN0aWNrIHRoZSB0ZXh0IGluIGFzIGFuIGVycmF0YSBtYXJrZWQg4oCcaGVsZCBm b3IgZG9jdW1lbnQgdXBkYXRl4oCdOyBvciBzdGljayBpdCBpbiBpdHMgb3duIFJGQyB0aGF0IHVw ZGF0ZXMgcmZjNzE1OSAoYml0IHdlaXJkPyk7IG9yIGluIGEgbGlhaXNvbiBub3RlIHRvIEVDTUEu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbToganNvbiBbbWFpbHRvOmpzb24tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBNb25kYXksIDIgTWF5IDIwMTYg Njo1OCBBTQ0KVG86IEpvZSBIaWxkZWJyYW5kIChqaGlsZGVicikgPGpoaWxkZWJyQGNpc2NvLmNv bT4NCkNjOiBqc29uQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0pzb25dIE5vcm1hdGl2ZSByZWZl cmVuY2UgcmVhc29uaW5nIGFuZCBsb2dpc3RpY3MNCg0KTmV2ZXIgc2VlbiBhbnl0aGluZyBxdWl0 ZSBsaWtlIHRoaXMgaW4gYW4gUkZDLCBidXQgaXQgZG9lc27igJl0IGZlZWwgY3Jhenkgb3IgZGFt YWdpbmcuDQoNCkkgc2hhcmUgdGhlIG9waW5pb24gZXhwcmVzc2VkIGJ5IG90aGVycyBoZXJlIHRo YXQgRUNNQS00MDQgaXMgbGFyZ2VseSBpZ25vcmVkIGFuZCBvZiBtYXJnaW5hbCByZWxldmFuY2Us IGJ1dCBJIGdhdGhlciB0aGVyZeKAmXMgYSBwZXJjZWl2ZWQgYmVuZWZpdCBpbiBlc3RhYmxpc2hp bmcgdGhhdCBFQ01BICYgSUVURiBhcmUgaW4gc3luYyBvbiB0aGlzIHN1YmplY3QuDQoNCk9uIFRo dSwgQXByIDI4LCAyMDE2IGF0IDEwOjA2IEFNLCBKb2UgSGlsZGVicmFuZCAoamhpbGRlYnIpIDxq aGlsZGVickBjaXNjby5jb208bWFpbHRvOmpoaWxkZWJyQGNpc2NvLmNvbT4+IHdyb3RlOg0KR29p bmcgYmFjayB0byBhbiBlYXJsaWVyIHBvaW50IGluIHRoZSB0aHJlYWQ6DQoNCk9uIDExLzE0LzE1 LCAxMToxMCBBTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0eS5jb208bWFpbHRvOnRicmF5 QHRleHR1YWxpdHkuY29tPj4gd3JvdGU6DQoNCj5TbywgaXMgdGhlcmUgYSAqcmVhbCogcmVhc29u IHdoeSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgbWlnaHQgYmUgdXNlZnVsPyBJIHRoaW5rIHRoZXJl IG1pZ2h0IGJlLCBhbmQgaXQncyBwdXJlbHkgcmhldG9yaWNhbCAoaW4gdGhlIGZvcm1hbCBzZW5z ZSwgZGVzaWduZWQgdG8gc3VwcG9ydCBhbiBhcmd1bWVudCk6IFRvIG1ha2UgaXQgY2xlYXIgdG8g dGhlIHdvcmxkDQo+IHRoYXQgYWxsIEpTT04gaXMgdGhlIHNhbWUgSlNPTiBubyBtYXR0ZXIgd2hl cmUgaXQncyBzcGVjaWZpZWQuICBTbyBJIHRoaW5rIGl0IHdvdWxkIGJlIHBsYXVzaWJsZSB0byBh ZGQgdGhlIGZvbGxvd2luZyB0byB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDEuMiBv ZiA3MTU5IChmb3IgY29udmVuaWVuY2U6DQo+aHR0cDovL3JmYzcxNTkubmV0L3JmYzcxNTkjcmZj LnNlY3Rpb24uMS4yICk6DQo+DQo+4oCcVGhlIHJlZmVyZW5jZSB0byBFQ01BLTQwNCBpbiB0aGUg cHJldmlvdXMgc2VudGVuY2UgaXMgbm9ybWF0aXZlLCBub3Qgd2l0aCB0aGUgdXN1YWwgbWVhbmlu ZyB0aGF0IGltcGxlbWVudG9ycyBuZWVkIHRvIGNvbnN1bHQgaXQgaW4gb3JkZXIgdG8gdW5kZXJz dGFuZCB0aGlzIGRvY3VtZW50LCBidXQgdG8gZW1waGFzaXplIHRoYXQgdGhlcmUgYXJlIG5vIGlu Y29uc2lzdGVuY2llcyBpbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSDigJxKU09OIHRleHTi gJ0gaW4gYW55IG9mIGl0cyBzcGVjaWZpY2F0aW9ucy4gTm90ZSwgaG93ZXZlciwgdGhhdCBFQ01B LTQwNCBhbGxvd3Mgc2V2ZXJhbCBwcmFjdGljZXMgd2hpY2ggdGhpcyBzcGVjaWZpY2F0aW9uIHJl Y29tbWVuZHMgYXZvaWRpbmcgaW4gdGhlIGludGVyZXN0cyBvZiBtYXhpbWFsIGludGVyb3BlcmFi aWxpdHku4oCdDQoNCkkgbGlrZSB0aGlzIHRleHQgYSBsb3QuICBBZGRpbmcgYSBmZXcgbW9yZSBw b2ludHMgd291bGQgYmUgdXNlZnVsLCBJIGJlbGlldmU6DQoNCi0gVGhlIGludGVudCBpcyB0aGF0 IHRoZSBncmFtbWFyIGlzIHRoZSBzYW1lIGJldHdlZW4gdGhlIHR3byBkb2N1bWVudHMsIGFsdGhv dWdoIGRpZmZlcmVudCBkZXNjcmlwdGlvbnMgYXJlIHVzZWQuICBJZiB0aGVyZSBhIGRpZmZlcmVu Y2UgaXMgZm91bmQgYmV0d2VlbiB0aGVtLCBFQ01BIGFuZCB0aGUgSUVURiB3aWxsIHdvcmsgdG9n ZXRoZXIgdG8gdXBkYXRlIGJvdGggZG9jdW1lbnRzLg0KDQotIElmIGFuIGVycm9yIGlzIGZvdW5k IHdpdGggZWl0aGVyIGRvY3VtZW50LCB0aGUgb3RoZXIgc2hvdWxkIGJlIGV4YW1pbmVkIHRvIHNl ZSBpZiBpdCBoYXMgYSBzaW1pbGFyIGVycm9yLCBhbmQgZml4ZWQgaWYgcG9zc2libGUuDQoNCi0g SWYgZWl0aGVyIGRvY3VtZW50IGlzIGNoYW5nZWQgaW4gdGhlIGZ1dHVyZSwgRUNNQSBhbmQgdGhl IElFVEYgd2lsbCB3b3JrIHRvZ2V0aGVyIHRvIGVuc3VyZSB0aGF0IHRoZSB0d28gZG9jdW1lbnRz IHN0YXkgYWxpZ25lZCB0aHJvdWdoIHRoZSBjaGFuZ2UuDQoNCg0KVGhlcmUgaXMgbGlhaXNvbiB3 b3JrIHRvIGRvIHRvIGVuc3VyZSB0aGF0IEVDTUEtNDA0YmlzIGhhcyBzaW1pbGFyIGxhbmd1YWdl LCBidXQgSSB3b3VsZG4ndCBoYXZlIGFueSBwcm9ibGVtIHdpdGggdXMgcHVibGlzaGluZyBhIDcx NTliaXMgZHJhZnQgdGhhdCBpbmNsdWRlZCBsYW5ndWFnZSBsaWtlIHRoaXMgYmVmb3JlIEVDTUEg aXMgZnVsbHkgb25ib2FyZC4NCg0KLS0NCkpvZSBIaWxkZWJyYW5kDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpzb24gbWFpbGluZyBsaXN0DQpq c29uQGlldGYub3JnPG1haWx0bzpqc29uQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qc29uDQoNCg0KDQotLQ0KLSBUaW0gQnJheSAoSWYgeW914oCZZCBs aWtlIHRvIHNlbmQgbWUgYSBwcml2YXRlIG1lc3NhZ2UsIHNlZSBodHRwczovL2tleWJhc2UuaW8v dGltYnJheSkNCg== --_000_255B9BB34FB7D647A506DC292726F6E13BD0AFB47FWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpo b2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1B VSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Jz5Tb3VuZHMgbW9yZSBoYXJtZnVsIHRoYW4gaGVscGZ1bCB0byBhZ2FpbiBjaGFuZ2UgdGhlIFJG QyBudW1iZXIgdGhhdCBkZWZpbmVzIEpTT04g4oCUIHJmYzQ2MjcsIHJmYzcxNTgsIHJmYzcxNTks IHJmY1hYWFgg4oCUIGZvciB3aGF0IGlzIHN1cHBvc2VkIHRvIGJlIGEgc2ltcGxlIGFuZCBzdGFi bGUgZm9ybWF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+U3RpY2sgdGhlIHRleHQg aW4gYXMgYW4gZXJyYXRhIG1hcmtlZCDigJxoZWxkIGZvciBkb2N1bWVudCB1cGRhdGXigJ07IG9y IHN0aWNrIGl0IGluIGl0cyBvd24gUkZDIHRoYXQgdXBkYXRlcyByZmM3MTU5IChiaXQgd2VpcmQ/ KTsgb3IgaW4gYSBsaWFpc29uIG5vdGUgdG8gRUNNQS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+LS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZic+IGpz b24gW21haWx0bzpqc29uLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+VGlt IEJyYXk8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgMiBNYXkgMjAxNiA2OjU4IEFNPGJyPjxiPlRv OjwvYj4gSm9lIEhpbGRlYnJhbmQgKGpoaWxkZWJyKSAmbHQ7amhpbGRlYnJAY2lzY28uY29tJmd0 Ozxicj48Yj5DYzo8L2I+IGpzb25AaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbSnNv bl0gTm9ybWF0aXZlIHJlZmVyZW5jZSByZWFzb25pbmcgYW5kIGxvZ2lzdGljczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5OZXZlciBzZWVuIGFueXRoaW5nIHF1aXRlIGxpa2UgdGhp cyBpbiBhbiBSRkMsIGJ1dCBpdCBkb2VzbuKAmXQgZmVlbCBjcmF6eSBvciBkYW1hZ2luZy4gJm5i c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBzaGFyZSB0aGUgb3Bp bmlvbiBleHByZXNzZWQgYnkgb3RoZXJzIGhlcmUgdGhhdCBFQ01BLTQwNCBpcyBsYXJnZWx5IGln bm9yZWQgYW5kIG9mIG1hcmdpbmFsIHJlbGV2YW5jZSwgYnV0IEkgZ2F0aGVyIHRoZXJl4oCZcyBh IHBlcmNlaXZlZCBiZW5lZml0IGluIGVzdGFibGlzaGluZyB0aGF0IEVDTUEgJmFtcDsgSUVURiBh cmUgaW4gc3luYyBvbiB0aGlzIHN1YmplY3QuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+T24gVGh1LCBBcHIgMjgsIDIwMTYgYXQgMTA6MDYgQU0sIEpvZSBIaWxkZWJyYW5k IChqaGlsZGVicikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGlsZGVickBjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj5qaGlsZGVickBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20nPjxwIGNsYXNzPU1zb05vcm1hbD5Hb2luZyBiYWNrIHRvIGFuIGVhcmxpZXIg cG9pbnQgaW4gdGhlIHRocmVhZDo8YnI+PGJyPk9uIDExLzE0LzE1LCAxMToxMCBBTSwgJnF1b3Q7 VGltIEJyYXkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNvbSI+ dGJyYXlAdGV4dHVhbGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPiZndDtTbywgaXMgdGhl cmUgYSAqcmVhbCogcmVhc29uIHdoeSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgbWlnaHQgYmUgdXNl ZnVsPyBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlLCBhbmQgaXQncyBwdXJlbHkgcmhldG9yaWNhbCAo aW4gdGhlIGZvcm1hbCBzZW5zZSwgZGVzaWduZWQgdG8gc3VwcG9ydCBhbiBhcmd1bWVudCk6IFRv IG1ha2UgaXQgY2xlYXIgdG8gdGhlIHdvcmxkPGJyPiZndDsgdGhhdCBhbGwgSlNPTiBpcyB0aGUg c2FtZSBKU09OIG5vIG1hdHRlciB3aGVyZSBpdCdzIHNwZWNpZmllZC4mbmJzcDsgU28gSSB0aGlu ayBpdCB3b3VsZCBiZSBwbGF1c2libGUgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdG8gdGhlIHNlY29u ZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxLjIgb2YgNzE1OSAoZm9yIGNvbnZlbmllbmNlOjxicj4m Z3Q7PGEgaHJlZj0iaHR0cDovL3JmYzcxNTkubmV0L3JmYzcxNTkjcmZjLnNlY3Rpb24uMS4yIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3JmYzcxNTkubmV0L3JmYzcxNTkjcmZjLnNlY3Rpb24uMS4y PC9hPiApOjxicj4mZ3Q7PGJyPiZndDvigJxUaGUgcmVmZXJlbmNlIHRvIEVDTUEtNDA0IGluIHRo ZSBwcmV2aW91cyBzZW50ZW5jZSBpcyBub3JtYXRpdmUsIG5vdCB3aXRoIHRoZSB1c3VhbCBtZWFu aW5nIHRoYXQgaW1wbGVtZW50b3JzIG5lZWQgdG8gY29uc3VsdCBpdCBpbiBvcmRlciB0byB1bmRl cnN0YW5kIHRoaXMgZG9jdW1lbnQsIGJ1dCB0byBlbXBoYXNpemUgdGhhdCB0aGVyZSBhcmUgbm8g aW5jb25zaXN0ZW5jaWVzIGluIHRoZSBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtIOKAnEpTT04gdGV4 dOKAnSBpbiBhbnkgb2YgaXRzIHNwZWNpZmljYXRpb25zLiBOb3RlLCBob3dldmVyLCB0aGF0IEVD TUEtNDA0IGFsbG93cyBzZXZlcmFsIHByYWN0aWNlcyB3aGljaCB0aGlzIHNwZWNpZmljYXRpb24g cmVjb21tZW5kcyBhdm9pZGluZyBpbiB0aGUgaW50ZXJlc3RzIG9mIG1heGltYWwgaW50ZXJvcGVy YWJpbGl0eS7igJ08YnI+PGJyPkkgbGlrZSB0aGlzIHRleHQgYSBsb3QuJm5ic3A7IEFkZGluZyBh IGZldyBtb3JlIHBvaW50cyB3b3VsZCBiZSB1c2VmdWwsIEkgYmVsaWV2ZTo8YnI+PGJyPi0gVGhl IGludGVudCBpcyB0aGF0IHRoZSBncmFtbWFyIGlzIHRoZSBzYW1lIGJldHdlZW4gdGhlIHR3byBk b2N1bWVudHMsIGFsdGhvdWdoIGRpZmZlcmVudCBkZXNjcmlwdGlvbnMgYXJlIHVzZWQuJm5ic3A7 IElmIHRoZXJlIGEgZGlmZmVyZW5jZSBpcyBmb3VuZCBiZXR3ZWVuIHRoZW0sIEVDTUEgYW5kIHRo ZSBJRVRGIHdpbGwgd29yayB0b2dldGhlciB0byB1cGRhdGUgYm90aCBkb2N1bWVudHMuPGJyPjxi cj4tIElmIGFuIGVycm9yIGlzIGZvdW5kIHdpdGggZWl0aGVyIGRvY3VtZW50LCB0aGUgb3RoZXIg c2hvdWxkIGJlIGV4YW1pbmVkIHRvIHNlZSBpZiBpdCBoYXMgYSBzaW1pbGFyIGVycm9yLCBhbmQg Zml4ZWQgaWYgcG9zc2libGUuPGJyPjxicj4tIElmIGVpdGhlciBkb2N1bWVudCBpcyBjaGFuZ2Vk IGluIHRoZSBmdXR1cmUsIEVDTUEgYW5kIHRoZSBJRVRGIHdpbGwgd29yayB0b2dldGhlciB0byBl bnN1cmUgdGhhdCB0aGUgdHdvIGRvY3VtZW50cyBzdGF5IGFsaWduZWQgdGhyb3VnaCB0aGUgY2hh bmdlLjxicj48YnI+PGJyPlRoZXJlIGlzIGxpYWlzb24gd29yayB0byBkbyB0byBlbnN1cmUgdGhh dCBFQ01BLTQwNGJpcyBoYXMgc2ltaWxhciBsYW5ndWFnZSwgYnV0IEkgd291bGRuJ3QgaGF2ZSBh bnkgcHJvYmxlbSB3aXRoIHVzIHB1Ymxpc2hpbmcgYSA3MTU5YmlzIGRyYWZ0IHRoYXQgaW5jbHVk ZWQgbGFuZ3VhZ2UgbGlrZSB0aGlzIGJlZm9yZSBFQ01BIGlzIGZ1bGx5IG9uYm9hcmQuPGJyPjxz cGFuIHN0eWxlPSdjb2xvcjojODg4ODg4Jz48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPi0tPC9zcGFu Pjxicj48c3BhbiBjbGFzcz1ob2VuemI+Sm9lIEhpbGRlYnJhbmQ8L3NwYW4+PGJyPjxicj48YnI+ PHNwYW4gY2xhc3M9aG9lbnpiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxicj48c3BhbiBjbGFzcz1ob2VuemI+anNvbiBtYWlsaW5nIGxpc3Q8 L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWhvZW56Yj48YSBocmVmPSJtYWlsdG86anNvbkBpZXRmLm9y ZyI+anNvbkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWhvZW56Yj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb248L2E+PC9zcGFu Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxicj48YnIgY2xlYXI9YWxsPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8bzpw PjwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBUaW0gQnJheSAo SWYgeW914oCZZCBsaWtlIHRvIHNlbmQgbWUgYSBwcml2YXRlIG1lc3NhZ2UsIHNlZSA8YSBocmVm PSJodHRwczovL2tleWJhc2UuaW8vdGltYnJheSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8va2V5 YmFzZS5pby90aW1icmF5PC9hPik8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E13BD0AFB47FWSMSG3153Vsrv_-- From nobody Sun May 1 16:30:35 2016 Return-Path: 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 DE0E112B037 for ; Sun, 1 May 2016 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 wNNhe3QCONx8 for ; Sun, 1 May 2016 16:30:32 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0124.outbound.protection.outlook.com [104.47.125.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550CE12D199 for ; Sun, 1 May 2016 16:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AAGwi7U5YsgNE63HUY/UOtGSQEocPfibQs8Ozc/EjgQ=; b=HIkjtAIw1senIuqPrDpphCdryvLlM6QU+4asDmXTAjW1Wlp75a30kTuHZkzcPqdjK5ZorElrxvfSsJyqzeM69zuGljFdplIjLM5/YpwZs/ERANmUxDeYrf2q/9Eq9IkGN09Fqhf9JE2fqFB5pHCeNxa4Q5oGD3h2goxiOAepaPc= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.1.2] (114.182.30.8) by OS2PR01MB0916.jpnprd01.prod.outlook.com (10.167.178.22) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sun, 1 May 2016 23:30:27 +0000 To: Tim Bray , "json@ietf.org" References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> Date: Mon, 2 May 2016 08:30:23 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [114.182.30.8] X-ClientProxiedBy: TY1PR06CA0002.apcprd06.prod.outlook.com (10.164.91.12) To OS2PR01MB0916.jpnprd01.prod.outlook.com (10.167.178.22) X-MS-Office365-Filtering-Correlation-Id: 6c657a6c-ffe0-41b9-e9f9-08d3721893ec X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 2:yHeqnujDah69/nr1T7+DdsLZL/3JfNaPPyRtPMPQGRKLe3pri+pHG4TO4xnfTfwWcOd+o8OKjHnvwr+ag6OeJ5PuOXU9YbSoV1U9tS99r3/7QKXkkjnrIuCiTsYXyBOsDuDv5gWykVaQiFTcNFW6MYZc6mRq5MhQCpSkJy8TW6xte9SBDcY4QOo3/HCbI+KE; 3:WbZp8UtpskdfQFk4HY8NraEXI6V7hDq4vKOt25EFCGXb8QfTGWKzhVbgvxn1XnSfkKk7ZgiFBnb6RzXKfc0rM0SgQXRBJWKknRrgMDafup58YdY38M5N2ayLJuvewUVj X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0916; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 25:skk06pP0PfN3Cvh24DrTqggwHHlQTMc5/QtDUHueuSJz4n7wYl1/Wqcile1rj/FisE2rFgiVMzIpioIc6vtdsFzfr1EBgKHA0g9jEvkvR+EAJ86gWdHgx7YS8VcbHraxcz8oZc/nJGXtNdvAP1c+KuHOor0sAhs5uXF5JofT2ZCv7qK9b7Dsd0nFUqX16RB4zEWwdh1V4Sy0LHaaTXG1u1qEocFzwQV0Yq54fAdSAw+fo0klOvz9kP6csni+ll3/blOSH7wWljkjDLZWrx/AAjCinwoNT7maQsJIRJzNAkLz/8C1yZ04IjsgXUWoPgNt2I55WHG1AZt6W826p2F3k0q/i9SIK6Xi6Nclw+oL2PqKnPkXSA1/vQuJdO29CQJPC5euVP+UkmF3YUnKx2LHYJcFxhR3gVMUriKcB9B1Iv874cuV5MOemBzTLZKOa28ZgpO4n3PdmIPG2K0f90mN4pw9sMHBLkvGJxzDLpZm4kLWUfXxuQuatYXxXZb+VdjL0wrhrBTwN/xoIiFd0/dM3b4eA06BMxDRMJ/GsAQEibaLb1ZReHhMMmmy+csg8ydtAp7FXIpCuYpc3SqIoOOybjib6zcw1YK1vUaUbBjFr8OfbxtJVk7WerjtPIPIdSh5hpDlb4hFgkHQxIgCh5ijuDtRfr3gXcmGAKdl8H2RUSltMeMwFzD0J75BMxMu9fAdmpFx3dAj+cKQpmaGHaNWk7YWtDYKBGsHU5TmfBUIRck= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6042046)(6043046); SRVR:OS2PR01MB0916; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0916; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 4:WASRWb63YnzxE0vTLdh+FkhDjIouIv6Q5eCeEIw2U/2Y857GnCIq/MpL3cVK9b5u2qVR+gLyXd+7W7/iCDx1Lc2z98x1OD3yLcyXS17kUdo6GX1GNf7biWsrNQVoxWIsg7qzuBurhlQgW7V6Cr3WgtIhY6uz5HvaehjcMQYD0T2uehLisJ8TaXE9glFV1AjDcY5T0tjkplUBbUtrWPqTgVfWPZCYQBEYCduCK837Ts+yHlziiwQnvgy7mKdUJmqB0VJUVzRMB0iE+mSFZDnUSeqCDdNPufL0eiO/QpKZ9Um7iIlMUlBkb9fpjeZg1aZ8jqoOZ17fZA4GM04ZNLvfOQDVul/bgf/bBwHir4i8L5rI862foDJiwQnKpjJyjLR+f6oWTPY2XFsH9sBr2lRscE/lXQqfBsjKq3tKDMgFDz2Chjgoy0USm2BsjULkSC72oBRqrKLxdAVJ1ZP30A9JrA== X-Forefront-PRVS: 0929F1BAED X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(2870700001)(50466002)(86362001)(83506001)(81166005)(42186005)(92566002)(107886002)(5008740100001)(189998001)(117156001)(2906002)(64126003)(74482002)(33646002)(50986999)(31696002)(47776003)(65806001)(66066001)(65956001)(76176999)(3846002)(6116002)(586003)(5004730100002)(1096002)(4001350100001)(77096005)(2501003)(23676002)(2950100001)(54356999)(5001770100001)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0916; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwOTE2OzIzOkt0d1N6VWFzclhzVUVkV1NRdS9ITEpJd21V?= =?utf-8?B?OTZvYmk3aVZIbmQwcEJTV2g2djk4cnhyZVAzVmZ0akJIU2hFRW12UjVWU0ZK?= =?utf-8?B?ZkRDMkFqWFViUDVtcGR0amdlUHNGTStkRnAvNU1WOVdSYXBKMTA3RFMwdjdN?= =?utf-8?B?bkxCVzNEcU5JNld0eWNCRzgyWVVxNVNWRU94djJKTzRKdjJXOGkxTXA5ejJV?= =?utf-8?B?Y1VVVU9vU0xZZFJrNzZueFpjSnFGWUVFWHUrcys4MXM2ZHJQWDZtdHpZMTBj?= =?utf-8?B?SGY1SkdESGowVXhDeU9tZGpMRXYwaEdxM01rdzZlLzNVQWxYVFk5MGVHa2gv?= =?utf-8?B?cVFtb2hXVUxHeWp4c0NIZGNodWkwTWxVSThuYkpIN1RpaEV1a1lybGhma21m?= =?utf-8?B?NmxwclN4UWNyZFRQMzg4bGt0Q3JhOWpCViswZVg3WVlDVEdTNFk5TFBzSWFk?= =?utf-8?B?dUlRQmV5QWF2NWkwMnBKazR1bWVNMllGSjZ6UzZaNnc3ZjREcVJKNCtldlRU?= =?utf-8?B?SVN3V0JjVUp6QzNYRHoyOEl6Yi9yWGZPTkVLcGlyZzB1Z1FZRTlzakt2Q0tz?= =?utf-8?B?Y1ZwOTJCOTFrMEVvMjltRHV0SkwrVXByUThaVlBVTmJ6QVFXUGYrbmNtdnFS?= =?utf-8?B?WEV3MmtpQzM1VEpzNE8wcUVXbWVxd2ROMzhEMFB5WTM3bUdJblR6cXd2TEtK?= =?utf-8?B?c1I0ZjlqdTM1WlVLbVpxNHZFYVRqTkNDbVpmUTdsVFZjQ0t5TVdDSkNsQ2l1?= =?utf-8?B?bDJDUk5vVEZHblRFYXpkWFJJTkVodGJtNkxLMDFIa3hhQVErTUljenlaTnNF?= =?utf-8?B?cEpUdUdRejBqbGVaczNuS0NjYlU4c3dENEdUNzkwRi9PVnNuU2htVm9ZSG9p?= =?utf-8?B?Rktvcnk4ZFhMczdBeldhUlNuc2hiWkY3WHJUOTJFcmlKNmFLVTVza3ZXL1Vz?= =?utf-8?B?c1ZiZWd2d3lIMTBhN3pieER5L001RDZ2cFJTN0ZZcnVUazJodHBJcUV3YjND?= =?utf-8?B?L0FTVWEyVVlZTEhubWVqQXF1d1hUK1NtNmxnNzhPMGNxSEJ6Wm1RK1JYM1l3?= =?utf-8?B?YlJ5bkZ2MXJ2TkVFRFk5bW9DQUM5YS9LVjdySEQ5a2IxN1VQaGZtQStoejQv?= =?utf-8?B?QThGV043S2tkOWlTTC9BRGZNa1JyOWlMeUcyZlhTeU5pcEIxUmdUUmt4REZQ?= =?utf-8?B?TnorZTNOK1lIc2lpRzB2c1NPSlhFZFJpTFRuWEUxajBhelNPMUJqQ05RL2pi?= =?utf-8?B?UnNhVTRNV3h0Y01Oc3Q4c1VVdmtzQzVjVkM4d2tNM1NTSEVoeGJqWnRVWWZl?= =?utf-8?B?ajZsUTlteGx2cVZ5RGZRcTQzZzhlemRrS29ZWVRJMVh1U2FpenRBZ3hNdkdX?= =?utf-8?B?YkZRWWxSNUxhSEVLaHFGekpSSjlxYW1MZ1Q3bTlBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 5:kBrOUh3SnUTylqo9Fs/3JKT1TmrvUKLRZsNuwnjL/sXcvupP8h0FPrlUu2wH9czyHxXZxQFt+3Sa4Y6VZt80+gtrl9fZ2eTsMPnbtkiaeZPnz2FqsVoks0nczMMrvCxg32TZ/JuZ4hI0rDTjONYD2Q==; 24:vJtWoioRvbYgV+aYkRylWGXt/8Cn3eK8ZDcLy17e9uYMlKxLQzeW+p5Zz6Gq4OTMnx5XeMDGcSskT5IavA3anDVs7iXBukdXVIxYbwwZsS8=; 7:ZxUryjFkYsEwuP6ErGjKXfEYWTyAjSqL//Gd6E2VmfcFrEKRBv/e8kuB+qy9PTHDqEFaghgDtyhDRbeHS96O4a6DkC+slZRy3BHBMd7gRFKP4A8b4BsZRwgH89OKvKBWM7BcLAga0kGt7QYaM146dEuJ1VRphnTZgd9QjDsSIF4/wsF0T2VCQLUxuGRWeZNc SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2016 23:30:27.4993 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0916 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:30:34 -0000 Hello Tim, On 2016/05/02 05:55, Tim Bray wrote: > I find myself tasked with specifying a JSON-based DSL and preparing it for > public release, with a validator and so on. > > I had never really concerned myself much with options for JSON language > definition, but have discovered they’re not very good. The JSON Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. > > Is there good conventional wisdom about formally specifying a JSON dialect? Sorry for playing the devil's advocate, but asking the same for XML would give a lot of different opinions. I wouldn't expect the schema landscape (if it developed) to be much different, because there's a large span between simplicity and expressiveness that can be covered, and a lot of notational choices. In addition to that, many people use JSON because they don't want to use XML (if they don't have any actual experience, they at least heard that it's somehow "problematic", and that often extends to schemata). So the JSON's users tendency seems to be to try and avoid schemata. Regards, Martin. From nobody Sun May 1 16:41:05 2016 Return-Path: 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 F0BB212B037 for ; Sun, 1 May 2016 16:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DVy27XiClrUD for ; Sun, 1 May 2016 16:41:02 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 D876C12D10E for ; Sun, 1 May 2016 16:41:01 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id bi2so71007209igb.0 for ; Sun, 01 May 2016 16:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Fu+huXaA8iyUd6IoXURp2mPSU8clz/j3/hFs2hFeFyk=; b=Db+9NdKfsCwRifxIojeWWV0v/vm2i+R3frIdQIVDIpYlwUcj28bwF3O80mA62qOHYO nQSOWbPGdt6SwEwTdw+qUZv7xudxKPFcVQML1Omc/G/vU0Ax+hhtE+ToMJ9Ik0jg8Jei vtk35QOCX4sQnFSNUFAnr41d66/gfvSjm7hzn2Vc1iepxa7sNPaFjAgZ1WmLd0rzPPLf K0w7dz8flouogfIgKTVHX7nmA8frvqEx1WhazUAKoL8GaZ0aO8eIsJpP4Q0bOGhDl1Dc xrLouGU+QEAjK8eWYzUmcPbpcVAxgKd7Wgp42vx/en2BevuTR530pV1w6FzSBeJ0biAH X7fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Fu+huXaA8iyUd6IoXURp2mPSU8clz/j3/hFs2hFeFyk=; b=Ss5/kqozMM3fcYwkia5bWipxNkDTbRE+4ts9ofKb3u4gX69GYZguFcZKqpN4x92DKI 0C/M5I1CqiDVFRLi3iik/h0+62MbFKgrrScJBCfiyBdASEql8f+V3lfTQTQ1K2E0gHMP Xs3aJh4rCxa+glxMNZbY+/B/Kpp5q5TzNCppvaXXdy1N//1/wG4SWPYrpsctAocO7bXe pqtxR94pAzW/uBn5zICGKHkY7j8wzxwRfto9yaPuyMxYr+rZwa7Yzi/C82Pulp/m5fyC +Po02/ot/3XkV8W5Zho7Fx8IJWZWJJO2skyAq6Vquz0EQpU4Vn/J2aaeRKaDLiZCWtT9 JJKw== X-Gm-Message-State: AOPr4FVcLrrQka+DFTh/biCbLYqPdsWOK+cqzt5EplaGU7HP0gcmzZI7OVIhC7xmP3JPCSuM1PpbbVM9ypMdTg== MIME-Version: 1.0 X-Received: by 10.50.180.202 with SMTP id dq10mr17219756igc.37.1462146061199; Sun, 01 May 2016 16:41:01 -0700 (PDT) Received: by 10.107.52.1 with HTTP; Sun, 1 May 2016 16:41:01 -0700 (PDT) In-Reply-To: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> References: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> Date: Sun, 1 May 2016 16:41:01 -0700 Message-ID: From: Rob Sayre To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=14dae93406679687eb0531d068d5 Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:41:04 -0000 --14dae93406679687eb0531d068d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's rough terrain because anything that requires a schema could also avoid parsing and use Protobufs, Thrift, Avro, etc. I've had good luck with Thrift and Protobufs/gRPC. ymmv. - Rob On Sun, May 1, 2016 at 4:30 PM, Martin J. D=C3=BCrst wrote: > Hello Tim, > > On 2016/05/02 05:55, Tim Bray wrote: > >> I find myself tasked with specifying a JSON-based DSL and preparing it f= or >> public release, with a validator and so on. >> >> I had never really concerned myself much with options for JSON language >> definition, but have discovered they=E2=80=99re not very good. The JSON= Schema >> project is not terribly appealing - opaque spec, poor documentation and >> tools - and smells of neglect (last I-D expired in 2013). It's been >> suggested that a good approach would be just to write a jq program that >> emits true or false. >> >> Is there good conventional wisdom about formally specifying a JSON >> dialect? >> > > Sorry for playing the devil's advocate, but asking the same for XML would > give a lot of different opinions. I wouldn't expect the schema landscape > (if it developed) to be much different, because there's a large span > between simplicity and expressiveness that can be covered, and a lot of > notational choices. > > In addition to that, many people use JSON because they don't want to use > XML (if they don't have any actual experience, they at least heard that > it's somehow "problematic", and that often extends to schemata). So the > JSON's users tendency seems to be to try and avoid schemata. > > Regards, Martin. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --14dae93406679687eb0531d068d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's rough terrain because anything that requires a sc= hema could also avoid parsing and use Protobufs, Thrift, Avro, etc. I'v= e had good luck with Thrift and Protobufs/gRPC. ymmv.

- = Rob

On= Sun, May 1, 2016 at 4:30 PM, Martin J. D=C3=BCrst <duerst@it.aoyama.= ac.jp> wrote:
Hello Tim,

On 2016/05/02 05:55, Tim Bray wrote:
I find myself tasked with specifying a JSON-based DSL and preparing it for<= br> public release, with a validator and so on.

I had never really concerned myself much with options for JSON language
definition, but have discovered they=E2=80=99re not very good.=C2=A0 The JS= ON Schema
project is not terribly appealing - opaque spec, poor documentation and
tools - and smells of neglect (last I-D expired in 2013).=C2=A0 It's be= en
suggested that a good approach would be just to write a jq program that
emits true or false.

Is there good conventional wisdom about formally specifying a JSON dialect?=

Sorry for playing the devil's advocate, but asking the same for XML wou= ld give a lot of different opinions. I wouldn't expect the schema lands= cape (if it developed) to be much different, because there's a large sp= an between simplicity and expressiveness that can be covered, and a lot of = notational choices.

In addition to that, many people use JSON because they don't want to us= e XML (if they don't have any actual experience, they at least heard th= at it's somehow "problematic", and that often extends to sche= mata). So the JSON's users tendency seems to be to try and avoid schema= ta.

Regards,=C2=A0 =C2=A0Martin.

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

--14dae93406679687eb0531d068d5-- From nobody Sun May 1 16:41:09 2016 Return-Path: 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 9CF9D12B037 for ; Sun, 1 May 2016 16:41:04 -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 rDzyaMsNa_p5 for ; Sun, 1 May 2016 16:41:03 -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 31AB512D532 for ; Sun, 1 May 2016 16:41:02 -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; bh=y9nrAs6DRMcFvn35mKUqm2iMQMH12YS/spkorr3U0Hg=; b=nHKGfx+KjpBVa8Tm3C3ipT7kof BX1JSIOJxxhmM/ws5yFVsqTmiFcpzwzgCxOTDY3aqCB+HbX6ZgLVb7ZzZi2EiQWwRpttFxtZ/nPUJ qTYxJZln5eN65OisGIrlQffGyqYcU1aT4tYHlSDx7DuX2oxv3ayqwpdnv3f9ClBgcTsQuAXDlIvQT RMqimf2DHczMzDhgkmEwBagZP8p/b76KEz/YIUbY6qaJwr2932LzFEfAPjwlW2Eq6tV3RHRKCVolv +pvgpl++9ZUEiklqZo430G7/vO9tJGsqHAQEp/rEG6Eb0CUB1Es8sbnZ2wf97trXXofPCB6RBb9xv 5l8C5aKQ==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:60599 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1ax0yy-0007ih-OV; Sun, 01 May 2016 19:41:01 -0400 To: "json@ietf.org" References: From: Erik Wilde Message-ID: Date: Sun, 1 May 2016 16:40:55 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Cc: Tim Bray 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:41:04 -0000 On 2016-05-01 13:55, Tim Bray wrote: > I had never really concerned myself much with options for JSON language > definition, but have discovered theyre not very good. The JSON Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. FYI, at the WWW2016 conference three weeks ago there was a paper looking at JSON schema which came away with the same conclusions: implementations behave differently, but sadly that can (at least in part) be blamed on the spec itself, which simply is not completely specifying what a JSON schema really means: http://www2016.net/proceedings/proceedings/p263.pdf personally, i think that a better schema language might have some chances in the wild, something that's similar to what RELAX NG is in XML land: focused, clean, and simple. JSON schema is a rather odd grab bag of features, and as long as the semantics are not completely defined, i wouldn't even really call it a language. so currently, there really isn't a language that's stable and popular enough so that some subset of readers/developers/tools would be happy to see and use a schema. which i think is not great. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sun May 1 16:47:31 2016 Return-Path: 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 1F10012D54A for ; Sun, 1 May 2016 16:47:30 -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 Ob2FGxZX_-N9 for ; Sun, 1 May 2016 16:47:29 -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 1C1E412D545 for ; Sun, 1 May 2016 16:47:29 -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:References:To:Subject; bh=2RURdpBB6F1j98rZ85brDS/yDQVzjmWsgyNyMx7pWr0=; b=pSHQnwB8kJZaKlIQ9bW+CU0XJf LEPkjfOcx9BCcJXX0zbviZk6l9ra6msjvMTtMA57j+hkIfHohDKqCWEZYcc075C3Oyu0XccAhbbVq I2kXau7+vPmhpzcNk6oNC/ZK/44a6W5uIJvIiCP4mXmPsAGhr5QbC+vpIHeZ0vxJvw56H5i0ORYzb G8NQwbcv2aHnsHxz1NkBTmUeHTEz9IBtnaw4YJ2cpi3ec166kz9Dv+ea2RFamcx/iQrapO7Hkg7Dh GVR0XU1zWM/ubaWWhgMaDB9cZAevlqd12uFzkAGN3pKdVmaPYljV3Tlzsnubs2Xt9G8N6O32Z4wrP dPuL+Lrw==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:60614 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1ax15E-0008D8-4s; Sun, 01 May 2016 19:47:28 -0400 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Tim Bray , "json@ietf.org" References: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> From: Erik Wilde Message-ID: <0bd9bc8b-d3d8-4a5a-215a-cb8821846da8@dret.net> Date: Sun, 1 May 2016 16:47:26 -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: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:47:30 -0000 hello martin. On 2016-05-01 16:30, Martin J. Dürst wrote: > Sorry for playing the devil's advocate, but asking the same for XML > would give a lot of different opinions. I wouldn't expect the schema > landscape (if it developed) to be much different, because there's a > large span between simplicity and expressiveness that can be covered, > and a lot of notational choices. yes. and XML land was/is different because often, the document models are complex enough that some schema really is needed, and DTDs are just too primitive to be useful. but seeing the popularity of JSON in APIs and how often these also specify non-trivial and non-rigid "schemas", part of me thinks that given a language that allows to better "document" the grammar part of an API, some not-so-small subset of API devs/users might find that useful. > In addition to that, many people use JSON because they don't want to use > XML (if they don't have any actual experience, they at least heard that > it's somehow "problematic", and that often extends to schemata). So the > JSON's users tendency seems to be to try and avoid schemata. to some extent, that's certainly what's happening. but part of that may just be that so far, there simply isn't a good language to use. so they add a bunch of examples. which of course are not painting the full picture. and consumers have to look at all of them and have to figure out the white spots. i think there is some sweet spot to make that a bit less tedious, without making it so complicated/complex that people will get XSD shock syndrome. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sun May 1 18:13:37 2016 Return-Path: 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 C51F912B02F for ; Sun, 1 May 2016 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 99e2bIS_EJQ8 for ; Sun, 1 May 2016 18:13:33 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 B12B512B015 for ; Sun, 1 May 2016 18:13:33 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x7so68048920qkd.3 for ; Sun, 01 May 2016 18:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hwwF8LZvl5OkkxGLcojGS5+j1p5ChIk7ETWZLRqmMnc=; b=k6TJifuYjnyC+faFnZDxbT1M9ooNJW1tzRrzyhuv2heOe1Yxl01ukAsoow4HrdvNLK nc6FNjcsMrAnUEJypOpkljPTQLI20hVbqfD8XmzoTZvrjQgVjcg7MxDyIOI6nwxW2BHI OFrtDIBQFCyzw8HytvtofFD/u1O1kSmX10Zo/qDN1ZGH4QWOMa4skybxmUMNiZ/jZM/o pV9C3jetk2DG9lgk4skjkwPPXAujN4zXkpZxtclG1XFwn7ywcccR0wXkw8fkmJPvnKeM rKIfot2VXMh23USnEErZZ5Dxh6nnNnytGGn2urim6Bhz4e3vmN/4/Kkl7XnTNprSOnkk Vd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hwwF8LZvl5OkkxGLcojGS5+j1p5ChIk7ETWZLRqmMnc=; b=HBNrH0PnWfPZtcGETLkA+4AGmdhfMIu/JPQLuNddOIfvv7IjMJdq4RgqXQdV44Ux1X 6KuAJgx7y+jkw4pIyPRRndUYtEvCFzDBcpc4446ChOphFTasxva4EIkbZbdp7YXLcD3X mtbjO6a+t9Ij+cjswWNyFTb/yR5sbjv4bzrvut5qs+gYfy+SR9VnHfl6rHbp/9eelWqp U+abYLVgcI88LBOPeyamL0eZTjilvlORFXA3TsQAA051WGm/bqcn+e2f1qno5kV+IK+J jGb+QMmLxCeaJi2Fz2+7hvs4OZDNizvEt4kbjn2dMZBDyIlUwjwWfZIlM5UMAg5DEPnY RS7A== X-Gm-Message-State: AOPr4FWOvt2LpHIbxiQiRswdhfLsD30uG276eqL51CUDzb9O78sSfHwJC1r6Dfmrs/0kAhsKpLfxDOYCrrHlkQ== X-Received: by 10.55.174.68 with SMTP id x65mr31338180qke.184.1462151612823; Sun, 01 May 2016 18:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Sun, 1 May 2016 18:13:13 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> References: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> From: Tim Bray Date: Sun, 1 May 2016 18:13:13 -0700 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=94eb2c060f0c7dae520531d1b31d Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:13:36 -0000 --94eb2c060f0c7dae520531d1b31d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 1, 2016 at 4:30 PM, Martin J. D=C3=BCrst wrote: > Hello Tim, > > Sorry for playing the devil's advocate, but asking the same for XML would > give a lot of different opinions. I wouldn't expect the schema landscape > (if it developed) to be much different, because there's a large span > between simplicity and expressiveness that can be covered, and a lot of > notational choices. > =E2=80=8BHey Martin, I think the evidence is against you on this. Everyone= I know working in XML uses RelaxNG when they think they need a formal specification - it=E2=80=99s very polished, and the fact that there=E2=80= =99s an excellent free validator written by James Clark is another really good argument. On the other hand, if you want to run a bunch of different tests ad-hoc tests against some XML and get useful error messages, Schematron is super handy. I don=E2=80=99t know anyone who seriously uses XSD for any new work. =E2= =80=8B =E2=80=8B > =E2=80=8B=E2=80=8B > In addition to that, many people use JSON because they don't want to use > XML (if they don't have any actual experience, they at least heard that > it's somehow "problematic", and that often extends to schemata). So the > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > JSON's users tendency seems to be to try and avoid schemata. > =E2=80=8B I agree. =E2=80=8BI also think you probably should=E2=80=99t use XML unles= s you are doing something really document-flavored, and most people aren=E2=80=99t. =E2=80= =8BI also find that a lot of apps, perhaps most, don=E2=80=99t benefit that much from sche= mas. I=E2=80=99m currently trying to specify a DSL rather than an API, and I thi= nk having a good schema language/toolset would make my life easier :( =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B > > Regards, Martin. > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --94eb2c060f0c7dae520531d1b31d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Sun, May 1, 2016 at 4:30 PM, Martin J. D=C3=BCrst <duerst@it.aoyama.a= c.jp> wrote:
Hello Tim,=

Sorry for playing the devil's advocate, but asking the same for XML wou= ld give a lot of different opinions. I wouldn't expect the schema lands= cape (if it developed) to be much different, because there's a large sp= an between simplicity and expressiveness that can be covered, and a lot of = notational choices.

=E2=80=8BHey Martin, I think the eviden= ce is against you on this.=C2=A0 Everyone I know working in XML uses RelaxN= G when they think they need a formal specification - it=E2=80=99s very poli= shed, and the fact that there=E2=80=99s an excellent free validator written= by James Clark is another really good argument. =C2=A0 On the other hand, = if you want to run a bunch of different tests ad-hoc tests against some XML= and get useful error messages, Schematron is super handy.=C2=A0 I don=E2= =80=99t know anyone who seriously uses XSD for any new work. =C2=A0=E2=80= =8B
=E2=80=8B
=E2= =80=8B=E2=80=8B
In addition to that, many people use JSON because they= don't want to use XML (if they don't have any actual experience, t= hey at least heard that it's somehow "problematic", and that = often extends to schemata). So the
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
JS= ON's users tendency seems to be to try and avoid schemata.
=E2=80=8B
I agree. =C2= =A0=E2=80=8BI also think you probably should=E2=80=99t use XML unless you a= re doing something really document-flavored, and most people aren=E2=80=99t= . =C2=A0=E2=80=8BI also find that a lot of apps, perhaps most, don=E2=80=99= t benefit that much from schemas. =C2=A0

I=E2=80=99m currently trying to specify a DSL rather = than an API, and I think having a good schema language/toolset would make m= y life easier :(

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B<= /div>=C2=A0

Regards,=C2=A0 =C2=A0Martin.



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--94eb2c060f0c7dae520531d1b31d-- From nobody Sun May 1 18:58:32 2016 Return-Path: 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 2C37512B05B for ; Sun, 1 May 2016 18:58:31 -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 gIMEp9WIP-pQ for ; Sun, 1 May 2016 18:58:29 -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 A59C012B042 for ; Sun, 1 May 2016 18:58:29 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1ax37x-0003Fo-4q; Sun, 01 May 2016 21:58:25 -0400 Date: Sun, 1 May 2016 21:58:25 -0400 From: John Cowan To: Tim Bray Message-ID: <20160502015824.GA12309@mercury.ccil.org> References: <7a6edf91-30d1-383b-4548-e12b988f9467@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:58:31 -0000 Tim Bray scripsit: > I don’t know anyone who seriously uses XSD for any new work. ​ It was definitely being used for new work inside my then employer as of 2014, although we were generating the XSDs by conversion from RELAX NG, because it was the only schema language that was suitable for object binding to Java. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org May the hair on your toes never fall out! --Thorin Oakenshield (to Bilbo) From nobody Sun May 1 20:54:52 2016 Return-Path: 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 C3D6112D1B8 for ; Sun, 1 May 2016 20:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aG0g8ekPikZk for ; Sun, 1 May 2016 20:54:48 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 6DE1912D137 for ; Sun, 1 May 2016 20:54:48 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id w36so10709938qge.3 for ; Sun, 01 May 2016 20:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=81U/LrloFSGXIqTPSu3B05pyUd50BXCXtwynKwWC5zA=; b=J0eIk9KyEZhcnC7Aof7HUNv98aG9SnhdEUA9Xckl4VBtFXHZEve5ioE6XWEuOmxarl hwj+A0HibkQWoV1AAG417KIjqw6SqkU2MiDXDOtuP1duwLiuyTeon9SSmWwYZC8tla20 EfWBAsHGX8SycKAQqvxD83l6f41SIEhBQNI3JyTaSEY6xNiG4p9aLrw8kBkf3UGyqaJq BGqR0XnkS5m0NJ0TdhpJywuz7dKJztZ2IWuXd5h14iR88/kS9i6bmSkZIIG8ozPVBN4r yi0ba1bS4fP1ArR2Rme3VMf3gVBh2Z5EgZj7mKjPrqpOzP6iVRtqVkulKz6xEVEz+Kt1 2FkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=81U/LrloFSGXIqTPSu3B05pyUd50BXCXtwynKwWC5zA=; b=D+8rZD6by0mSlb6lKNsg239la1fRhFTa6ykWRRQ/wnAE+Qy6uI1jH7NJu85SuFzaOl ejg2kvbgirITpJm3jK4iM3hurno33ImsJNEai1riHZAJ2yv9FqOWCNoIzGctVWdqxXrU Q/l1I+ILhQ3xwQXYpfhobOUqHkjBwptMAqImlS3/ZUis4ylKiaderq9K4322vxU9yRbl ZC6IYqorYSQ263zvFSy3myyzRD1voAWVtv4k9ewKUxoT/vTmlkqLGj60Z+SMtwo32jn7 4FBHrbf8+XpTQZ6mY4WgEa0qhjY4pHTqEsE9jZKpKEpDImeRwHogK5Z/wQNRvE78B/5f s04g== X-Gm-Message-State: AOPr4FWyL8l0rBKy94/6O+foGHhU8m1EnMuT02vDy+HpjI2h02XLfyFvawtIfqi0iPs3ULJJ5aSJvQwdoXw86g== MIME-Version: 1.0 X-Received: by 10.140.91.194 with SMTP id z60mr29700895qgd.70.1462161287547; Sun, 01 May 2016 20:54:47 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Sun, 1 May 2016 20:54:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 May 2016 23:54:47 -0400 X-Google-Sender-Auth: B8OSjisjV1MG62fr6_1hI9Peiw0 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=001a113a7e2e2617f70531d3f469 Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 03:54:51 -0000 --001a113a7e2e2617f70531d3f469 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://github.com/hallambaker/PHB-Build-Tools Protogen may do what you want. It isn't anything like XML Schema but starting from an abstract definition of the protocol, it will generate implementation code in C or C# and Internet Draft suitable documentation in Markdown, XML2RFC or HTML. I used it to develop this spec from start to finish in three days including a reference implementation: https://tools.ietf.org/html/draft-hallambaker-lurk-02 The big problem with XML schema is that it is trying to provide all the functionality of DTDs and in a data description language you need none of that functionality. At this point the only distinction made in the schema is between lists of zero, one and many items. The schema language could be cleaned up. But if I was going to do that, I would want to develop one input language that works for my ASN.1, RFC822 header, TLS Schema and JSON backends. TLS schema requires things like integer sizes to be specified. JSON obviously does not. Except of course for cryptographic bignums where we tend to use base64 strings. On Sun, May 1, 2016 at 4:55 PM, Tim Bray wrote: > > I find myself tasked with specifying a JSON-based DSL and preparing it fo= r > public release, with a validator and so on. > > I had never really concerned myself much with options for JSON language > definition, but have discovered they=E2=80=99re not very good. The JSON = Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. > > Is there good conventional wisdom about formally specifying a JSON dialec= t? > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a113a7e2e2617f70531d3f469 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://github.com/hallambaker/PHB-Build-Tools

= Protogen may do what you want. It isn't anything like XML Schema but st= arting from an abstract definition of the protocol, it will generate implem= entation code in C or C# and Internet Draft suitable documentation in Markd= own, XML2RFC or HTML.


I used it to = develop this spec from start to finish in three days including a reference = implementation:



The big problem = with XML schema is that it is trying to provide all the functionality of DT= Ds and in a data description language you need none of that functionality.<= /div>

At this point the only distinction made in the sch= ema is between lists of zero, one and many items.

= The schema language could be cleaned up. But if I was going to do that, I w= ould want to develop one input language that works for my ASN.1, RFC822 hea= der, TLS Schema and JSON backends.

TLS schema requ= ires things like integer sizes to be specified. JSON obviously does not. Ex= cept of course for cryptographic bignums where we tend to use base64 string= s.



=
On Sun, May 1, 2016 at 4:55 PM, Tim Bray <tb= ray@textuality.com> wrote:
=
I find myself= tasked with specifying a JSON-based DSL and preparing it for public releas= e, with a validator and so on. =C2=A0

I had never really concerned myself much with options for JSON= language definition, but have discovered they=E2=80=99re not very good.=C2= =A0 The JSON Schema project is not terribly appealing - opaque spec, poor d= ocumentation and tools - and smells of neglect (last I-D expired in 2013).= =C2=A0 It's been suggested that a good approach would be just to write = a jq program that emits true or false.

Is there good conventional wisdom about formally specifying a= JSON dialect?
--
- Tim Bray (If you=E2=80=99d like = to send me a private message, see https://keybase.io/timbray)

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json


--001a113a7e2e2617f70531d3f469-- From nobody Sun May 1 22:58:13 2016 Return-Path: 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 2254E12D0F5 for ; Sun, 1 May 2016 22:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C1Q55qTAYw8N for ; Sun, 1 May 2016 22:58:10 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 C5DD212B062 for ; Sun, 1 May 2016 22:58:09 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id g17so125233322wme.1 for ; Sun, 01 May 2016 22:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=XPaC1sHiy3PTj4gwd9p5X+fgSxYWWC9bGYBPDRyg7OE=; b=xLTdfCOlh6Wq480R9li5BJzVmOQeMOdXG+ly/A6893f6PrT04VS0yHhxYWqGSTCHh1 VunfK4cnt0b36X8orexlhKlAZKqQYbWAAVlrZs0JwecYTlGakCcxvxrzmfEUy2g2O5XY ABDpsavc6FXuNBNepxZoqrzV+OJUBSKiMUKNZvpiA54nV5zRa+Q1lQ6sN0JAzp40swvM 6E+kMFSRNu8ORt48i+wg6PLT2aj2LI8pKTbPeRq56oMLQ8+FQmkqFIyyIvUSaNpitcuk CuamaSWqSvXbnTYacU7K4qyMxJ3jE/PCFxGmobWN7vgMnjFUeKLMz8Yd/7QPHrd+Ed0m 4CUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=XPaC1sHiy3PTj4gwd9p5X+fgSxYWWC9bGYBPDRyg7OE=; b=S7f8XbQAwrLjEVLNVpxgHRcNLMrRx/3w+1K9mrQWe4zt9aznF0YcLFmhUnhf/I+ryx YbBf3W21B0/AyQ4MsyGvKWe1SSFgsByobA90HnZl4nwH9gL1OrflUFgixHVMyJ+QoxzY dwmPs0VvTT7fq99Y9vhbsxcsglEP3t8eAe41qKPWlQepZFna5RC53CzQfJE0ITdbzgFr 2EwJC2YjAFlM/HB1U5LetdXfq2J4H8g+7ZpRneWQOtqKqKpTjq6yi5jR45TuS1TxyiDc 6EF+gzL5AyCZ/WGYVfT0Eo2QViUooZiE5m0ZEj3K84hzHTOOnErDPnOeoJII2ImK8jyQ OHCg== X-Gm-Message-State: AOPr4FW8lVoU7V7LaVPXkzUiDfjLtfTAOohKGOMt5TGVGfW4qKJNsFj/w6xEFY9gAxZMTQ== X-Received: by 10.194.221.37 with SMTP id qb5mr33615343wjc.171.1462168688166; Sun, 01 May 2016 22:58:08 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id vu4sm28412695wjc.27.2016.05.01.22.58.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 22:58:07 -0700 (PDT) To: Tim Bray , "json@ietf.org" References: From: Anders Rundgren Message-ID: <1d5080ea-f89a-fbdf-7de2-94443da02472@gmail.com> Date: Mon, 2 May 2016 07:57:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------160C499AE62A551E8E7DD5CC" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 05:58:12 -0000 This is a multi-part message in MIME format. --------------160C499AE62A551E8E7DD5CC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2016-05-01 22:55, Tim Bray wrote: > > I find myself tasked with specifying a JSON-based DSL and preparing it for public release, with a validator and so on. > > I had never really concerned myself much with options for JSON language definition, but have discovered theyre not very good. The JSON Schema project is not terribly appealing - opaque spec, poor documentation and tools - and smells of neglect (last I-D expired in 2013). It's been suggested that a good approach would be just to write a jq program that emits true or false. > > Is there good conventional wisdom about formally specifying a JSON dialect? I had used XML Schema for 10Y+ before I became a JSON "convert". I addressed the problem you mentioned in another and less formal way: 1. Creating a strongly typed JSON parser with access methods like getString(), getInt() etc. This also supports some derived types that you most likely need such as dateTime, BigInteger and BigDecimal (for the financial industry). 2. The I added a method for verifying that all elements have been read. This works quite well but of course do not address the documentation issue or the ability creating JSON from static object declaration. https://github.com/cyberphone/saturn/blob/master/resources/common/org/webpki/saturn/common/PayerAuthorization.java Anders > > -- > - Tim Bray (If youd like to send me a private message, see https://keybase.io/timbray) > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --------------160C499AE62A551E8E7DD5CC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 2016-05-01 22:55, Tim Bray wrote:

I find myself tasked with specifying a JSON-based DSL and preparing it for public release, with a validator and so on.

I had never really concerned myself much with options for JSON language definition, but have discovered theyre not very good. The JSON Schema project is not terribly appealing - opaque spec, poor documentation and tools - and smells of neglect (last I-D expired in 2013). It's been suggested that a good approach would be just to write a jq program that emits true or false.

Is there good conventional wisdom about formally specifying a JSON dialect?

I had used XML Schema for 10Y+ before I became a JSON "convert".

I addressed the problem you mentioned in another and less formal way:

1. Creating a strongly typed JSON parser with access methods like getString(), getInt() etc. This also supports some derived types that you most likely need such as dateTime, BigInteger and BigDecimal (for the financial industry).

2. The I added a method for verifying that all elements have been read.

This works quite well but of course do not address the documentation issue or the ability creating JSON from static object declaration.

https://github.com/cyberphone/saturn/blob/master/resources/common/org/webpki/saturn/common/PayerAuthorization.java

Anders


--
- Tim Bray (If youd like to send me a private message, see https://keybase.io/timbray)


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json


--------------160C499AE62A551E8E7DD5CC-- From nobody Mon May 2 03:51:25 2016 Return-Path: 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 726E112D1D1 for ; Mon, 2 May 2016 03:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 SiKop2sytjnj for ; Mon, 2 May 2016 03:51:21 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D4912B056 for ; Mon, 2 May 2016 03:51:21 -0700 (PDT) Received: (qmail 15891 invoked from network); 2 May 2016 11:46:42 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 2 May 2016 11:46:42 +0100 To: Tim Bray , "json@ietf.org" References: From: Peter Cordell Message-ID: <802c1540-c5b8-e487-05bb-5c54b03bd0e5@codalogic.com> Date: Mon, 2 May 2016 11:51:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:51:24 -0000 On 01/05/2016 21:55, Tim Bray wrote: > > I find myself tasked with specifying a JSON-based DSL and preparing it > for public release, with a validator and so on. > > I had never really concerned myself much with options for JSON language > definition, but have discovered theyre not very good. The JSON Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. > > Is there good conventional wisdom about formally specifying a JSON dialect? Andy Newton and I are working on JSON Content Rules (JCR) [1] which is a basic JSON grammar schema language that mirrors the functionality of Relax NG and XSD. We also have put together some thoughts on JSON Content Rules Co-Constraints (JCRCC) [2] which adds Schematron like functionality to JCR. There's some links to pilot implementations at [3]. Our goal has been to make it as simple as we can without losing expressiveness with a view to not requiring users to be experts in the technology before they can make use of it. We're also hoping that a simple solution will also readily enable multiple implementations. We'd obviously be delighted to hear from anybody who's interested in the work. Thanks, Pete. [1] https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ [2] https://datatracker.ietf.org/doc/draft-cordell-jcr-co-constraints/ [3] http://codalogic.github.io/jcr/ -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Mon May 2 09:17:49 2016 Return-Path: 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 CCDBC12B069 for ; Mon, 2 May 2016 09:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dNY_fJOMMgZI for ; Mon, 2 May 2016 09:17:46 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF14212B006 for ; Mon, 2 May 2016 09:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4862; q=dns/txt; s=iport; t=1462205865; x=1463415465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O36p11os3M2H5eJ2TbOTfPG9Xdgc7/7IQ0BBTi6elQk=; b=G1wBkE3mvaXEGerqLV4Vm7/1Or3tKV7Z6iMpniVJMoegkyCcditpgfD8 QwFX3PuEuLhxCMmzA7fK6BAkMqImx+KLC+KLheu197FyLgBv7yHNDh3MO v6J2AA0EO/BeWaMsXNzQRPi4nFBpmsaizf1fgRVnyCKKAI6qGDTi6+4ZD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAgChfCdX/5BdJa1dgzhTdwYGuXABD?= =?us-ascii?q?YF2FwuFbgIcgRQ4FAEBAQEBAQFlJ4RBAQEBBAEBASAROgsQAgEIEQQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBDQWIFQMSCQWqEIt8HYQ+AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFXyFJYF2glaERBAjgkYrgisFmBQBhXuCd4UlgWdOjFyGJIkMAR4BAUKCBRu?= =?us-ascii?q?BS2wBAYgGfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="scan'208";a="267959850" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 16:17:44 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u42GHiaS018536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 16:17:44 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 12:17:43 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 2 May 2016 12:17:43 -0400 From: "Joe Hildebrand (jhildebr)" To: "Manger, James" , Tim Bray Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AQHRlAaTE88EUYV2AkmALftkB7sIZp+flv6AgAVcVACAACd6AIAAt/GA Date: Mon, 2 May 2016 16:17:43 +0000 Message-ID: <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <7B1FA6514BAF8340B5039D41B569A700@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:17:48 -0000 SWYgd2UgZGlkIHRoaXMsIHRoZW4gd2Ugd291bGQgaGF2ZSB0byB0YWxrIHRoZSBJRVNHIGludG8g YXBwbHlpbmcgYW4gU1REIG51bWJlciB0byBSRkMgNzE1OSB3aXRoIGtub3duIGVycmF0YSwgb3Ig Z2l2ZSB1cCBvbiBKU09OIGJlY29taW5nIGEgZnVsbCBJbnRlcm5ldCBTdGFuZGFyZC4gIEluIG15 IG9waW5pb24sIGl0J3Mgd29ydGggY2hhbmdpbmcgdGhlIFJGQyBudW1iZXIgYWdhaW4uDQoNCi0t IA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg0KDQpPbiA1LzEvMTYsIDU6MTkgUE0sICJNYW5nZXIs IEphbWVzIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4gd3JvdGU6DQoNCj5Tb3Vu ZHMgbW9yZSBoYXJtZnVsIHRoYW4gaGVscGZ1bCB0byBhZ2FpbiBjaGFuZ2UgdGhlIFJGQyBudW1i ZXIgdGhhdCBkZWZpbmVzIEpTT04g4oCUIHJmYzQ2MjcsIHJmYzcxNTgsIHJmYzcxNTksIHJmY1hY WFgg4oCUIGZvciB3aGF0IGlzDQo+IHN1cHBvc2VkIHRvIGJlIGEgc2ltcGxlIGFuZCBzdGFibGUg Zm9ybWF0Lg0KPlN0aWNrIHRoZSB0ZXh0IGluIGFzIGFuIGVycmF0YSBtYXJrZWQg4oCcaGVsZCBm b3IgZG9jdW1lbnQgdXBkYXRl4oCdOyBvciBzdGljayBpdCBpbiBpdHMgb3duIFJGQyB0aGF0IHVw ZGF0ZXMgcmZjNzE1OSAoYml0IHdlaXJkPyk7IG9yDQo+IGluIGEgbGlhaXNvbiBub3RlIHRvIEVD TUEuDQo+IA0KPi0tDQo+SmFtZXMgTWFuZ2VyDQo+IA0KPkZyb206IGpzb24gW21haWx0bzpqc29u LWJvdW5jZXNAaWV0Zi5vcmddDQo+T24gQmVoYWxmIE9mIFRpbSBCcmF5DQo+U2VudDogTW9uZGF5 LCAyIE1heSAyMDE2IDY6NTggQU0NCj5UbzogSm9lIEhpbGRlYnJhbmQgKGpoaWxkZWJyKSA8amhp bGRlYnJAY2lzY28uY29tPg0KPkNjOiBqc29uQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtKc29u XSBOb3JtYXRpdmUgcmVmZXJlbmNlIHJlYXNvbmluZyBhbmQgbG9naXN0aWNzDQo+IA0KPk5ldmVy IHNlZW4gYW55dGhpbmcgcXVpdGUgbGlrZSB0aGlzIGluIGFuIFJGQywgYnV0IGl0IGRvZXNu4oCZ dCBmZWVsIGNyYXp5IG9yIGRhbWFnaW5nLiAgDQo+DQo+IA0KPg0KPkkgc2hhcmUgdGhlIG9waW5p b24gZXhwcmVzc2VkIGJ5IG90aGVycyBoZXJlIHRoYXQgRUNNQS00MDQgaXMgbGFyZ2VseSBpZ25v cmVkIGFuZCBvZiBtYXJnaW5hbCByZWxldmFuY2UsIGJ1dCBJIGdhdGhlciB0aGVyZeKAmXMgYSBw ZXJjZWl2ZWQgYmVuZWZpdCBpbiBlc3RhYmxpc2hpbmcgdGhhdCBFQ01BICYgSUVURiBhcmUgaW4g c3luYyBvbiB0aGlzIHN1YmplY3QuDQo+DQo+DQo+IA0KPk9uIFRodSwgQXByIDI4LCAyMDE2IGF0 IDEwOjA2IEFNLCBKb2UgSGlsZGVicmFuZCAoamhpbGRlYnIpIDxqaGlsZGVickBjaXNjby5jb20+ IHdyb3RlOg0KPg0KPkdvaW5nIGJhY2sgdG8gYW4gZWFybGllciBwb2ludCBpbiB0aGUgdGhyZWFk Og0KPg0KPk9uIDExLzE0LzE1LCAxMToxMCBBTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0 eS5jb20+IHdyb3RlOg0KPg0KPj5TbywgaXMgdGhlcmUgYSAqcmVhbCogcmVhc29uIHdoeSBhIG5v cm1hdGl2ZSByZWZlcmVuY2UgbWlnaHQgYmUgdXNlZnVsPyBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJl LCBhbmQgaXQncyBwdXJlbHkgcmhldG9yaWNhbCAoaW4gdGhlIGZvcm1hbCBzZW5zZSwgZGVzaWdu ZWQgdG8gc3VwcG9ydCBhbiBhcmd1bWVudCk6IFRvIG1ha2UgaXQgY2xlYXIgdG8gdGhlIHdvcmxk DQo+PiB0aGF0IGFsbCBKU09OIGlzIHRoZSBzYW1lIEpTT04gbm8gbWF0dGVyIHdoZXJlIGl0J3Mg c3BlY2lmaWVkLiAgU28gSSB0aGluayBpdCB3b3VsZCBiZSBwbGF1c2libGUgdG8gYWRkIHRoZSBm b2xsb3dpbmcgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxLjIgb2YgNzE1OSAo Zm9yIGNvbnZlbmllbmNlOg0KPj5odHRwOi8vcmZjNzE1OS5uZXQvcmZjNzE1OSNyZmMuc2VjdGlv bi4xLjIgKToNCj4+DQo+PuKAnFRoZSByZWZlcmVuY2UgdG8gRUNNQS00MDQgaW4gdGhlIHByZXZp b3VzIHNlbnRlbmNlIGlzIG5vcm1hdGl2ZSwgbm90IHdpdGggdGhlIHVzdWFsIG1lYW5pbmcgdGhh dCBpbXBsZW1lbnRvcnMgbmVlZCB0byBjb25zdWx0IGl0IGluIG9yZGVyIHRvIHVuZGVyc3RhbmQg dGhpcyBkb2N1bWVudCwgYnV0IHRvIGVtcGhhc2l6ZSB0aGF0IHRoZXJlIGFyZSBubyBpbmNvbnNp c3RlbmNpZXMgaW4gdGhlIGRlZmluaXRpb24gb2YgdGhlIHRlcm0g4oCcSlNPTiB0ZXh04oCdDQo+ IGluIGFueSBvZiBpdHMgc3BlY2lmaWNhdGlvbnMuIE5vdGUsIGhvd2V2ZXIsIHRoYXQgRUNNQS00 MDQgYWxsb3dzIHNldmVyYWwgcHJhY3RpY2VzIHdoaWNoIHRoaXMgc3BlY2lmaWNhdGlvbiByZWNv bW1lbmRzIGF2b2lkaW5nIGluIHRoZSBpbnRlcmVzdHMgb2YgbWF4aW1hbCBpbnRlcm9wZXJhYmls aXR5LuKAnQ0KPg0KPkkgbGlrZSB0aGlzIHRleHQgYSBsb3QuICBBZGRpbmcgYSBmZXcgbW9yZSBw b2ludHMgd291bGQgYmUgdXNlZnVsLCBJIGJlbGlldmU6DQo+DQo+LSBUaGUgaW50ZW50IGlzIHRo YXQgdGhlIGdyYW1tYXIgaXMgdGhlIHNhbWUgYmV0d2VlbiB0aGUgdHdvIGRvY3VtZW50cywgYWx0 aG91Z2ggZGlmZmVyZW50IGRlc2NyaXB0aW9ucyBhcmUgdXNlZC4gIElmIHRoZXJlIGEgZGlmZmVy ZW5jZSBpcyBmb3VuZCBiZXR3ZWVuIHRoZW0sIEVDTUEgYW5kIHRoZSBJRVRGIHdpbGwgd29yayB0 b2dldGhlciB0byB1cGRhdGUgYm90aCBkb2N1bWVudHMuDQo+DQo+LSBJZiBhbiBlcnJvciBpcyBm b3VuZCB3aXRoIGVpdGhlciBkb2N1bWVudCwgdGhlIG90aGVyIHNob3VsZCBiZSBleGFtaW5lZCB0 byBzZWUgaWYgaXQgaGFzIGEgc2ltaWxhciBlcnJvciwgYW5kIGZpeGVkIGlmIHBvc3NpYmxlLg0K Pg0KPi0gSWYgZWl0aGVyIGRvY3VtZW50IGlzIGNoYW5nZWQgaW4gdGhlIGZ1dHVyZSwgRUNNQSBh bmQgdGhlIElFVEYgd2lsbCB3b3JrIHRvZ2V0aGVyIHRvIGVuc3VyZSB0aGF0IHRoZSB0d28gZG9j dW1lbnRzIHN0YXkgYWxpZ25lZCB0aHJvdWdoIHRoZSBjaGFuZ2UuDQo+DQo+DQo+VGhlcmUgaXMg bGlhaXNvbiB3b3JrIHRvIGRvIHRvIGVuc3VyZSB0aGF0IEVDTUEtNDA0YmlzIGhhcyBzaW1pbGFy IGxhbmd1YWdlLCBidXQgSSB3b3VsZG4ndCBoYXZlIGFueSBwcm9ibGVtIHdpdGggdXMgcHVibGlz aGluZyBhIDcxNTliaXMgZHJhZnQgdGhhdCBpbmNsdWRlZCBsYW5ndWFnZSBsaWtlIHRoaXMgYmVm b3JlIEVDTUEgaXMgZnVsbHkgb25ib2FyZC4NCj4NCj4tLQ0KPkpvZSBIaWxkZWJyYW5kDQo+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5qc29u IG1haWxpbmcgbGlzdA0KPmpzb25AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pzb24NCj4NCj4NCj4NCj4NCj4NCj4NCj4gDQo+DQo+LS0gDQo+LSBUaW0g QnJheSAoSWYgeW914oCZZCBsaWtlIHRvIHNlbmQgbWUgYSBwcml2YXRlIG1lc3NhZ2UsIHNlZSAN Cj5odHRwczovL2tleWJhc2UuaW8vdGltYnJheSA8aHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXk+ KQ0KPg0KPg0KPg0KPg0KPg0K From nobody Mon May 2 09:28:04 2016 Return-Path: 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 5CEC612D58B for ; Mon, 2 May 2016 09:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=O8i51CKd; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=O8i51CKd 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 cL2B_JeUd9vp for ; Mon, 2 May 2016 09:28:01 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2268C12D588 for ; Mon, 2 May 2016 09:28:01 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 62F6C15A06BE; Mon, 2 May 2016 18:27:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1462206479; bh=LvgAHc3cflHUywDblMp9EUGZoE5Hh3NTF2gNuk2wLIU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=O8i51CKd5YuBmgIojHB+uzPlMB0a59bv794WFn72fpNvvcDaij05YPnw2pNi7IbQ+ aKqzu0emm9Goo+JZj//+2otFGvcupZDxeirwmAY9VTsbpB/Q2aoCNrd6Qtm4/JBp7Z zNF0zymrtVNPrQWk6OoNCzMd3xghk+3njPSDAwyQ= Received: from [192.168.178.20] (unknown [93.217.73.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id A7F4315A047D; Mon, 2 May 2016 18:27:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1462206479; bh=LvgAHc3cflHUywDblMp9EUGZoE5Hh3NTF2gNuk2wLIU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=O8i51CKd5YuBmgIojHB+uzPlMB0a59bv794WFn72fpNvvcDaij05YPnw2pNi7IbQ+ aKqzu0emm9Goo+JZj//+2otFGvcupZDxeirwmAY9VTsbpB/Q2aoCNrd6Qtm4/JBp7Z zNF0zymrtVNPrQWk6OoNCzMd3xghk+3njPSDAwyQ= To: "Joe Hildebrand (jhildebr)" , "Manger, James" , Tim Bray References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> From: Julian Reschke Message-ID: Date: Mon, 2 May 2016 18:28:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:28:03 -0000 On 2016-05-02 18:17, Joe Hildebrand (jhildebr) wrote: > If we did this, then we would have to talk the IESG into applying an STD number to RFC 7159 with known errata, or give up on JSON becoming a full Internet Standard. In my opinion, it's worth changing the RFC number again. ...we have errata to apply anyway, right? From nobody Mon May 2 09:40:11 2016 Return-Path: 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 4EEB612D594 for ; Mon, 2 May 2016 09:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KeW-cTT1PqVs for ; Mon, 2 May 2016 09:40:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E0B12D590 for ; Mon, 2 May 2016 09:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1678; q=dns/txt; s=iport; t=1462207207; x=1463416807; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gOmPN9nweRNyxt+FYvFdt9IPGPyQ4BdQceGgDiZQCSo=; b=RPpjmf/2AU9tVHaN0IXkkkFKak9Bdue/PjJFjs3M7yx+6s9ttIHjZaps VpYHRO7X4BTG7hujCIJdW6SUj6ea+cxnQPP9GYQUjbpWQjdtLI230HNtD 3tdJGIkk0HmgbwYbtuQ+sglbJMAE5gtjS7eIhSNYj4lW/wH0oeLv6pnWf o=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgBzgidX/4sNJK1DGoM4U30GuXAOg?= =?us-ascii?q?XYkhWwCgTE4FAEBAQEBAQFlJ4RBAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFAgOLLp?= =?us-ascii?q?KAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEiBcIgk6HaIIrBZgUAYMngWeJCYFRF?= =?us-ascii?q?o0qhiSJDAEeAUOCBRuBS2wBiAd/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="asc'?scan'208";a="268536342" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 16:40:06 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u42Ge6Lc028322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 16:40:06 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 11:40:06 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 2 May 2016 11:40:06 -0500 From: "Matt Miller (mamille2)" To: Julian Reschke Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AQHRoXBVlLbhRy7gw0mMULwD7976yZ+k6UIAgAAnegCAARyEgIAAAuIAgAADXQA= Date: Mon, 2 May 2016 16:40:06 +0000 Message-ID: <610D97F1-4884-46C0-A0B8-5DC1794F9B42@cisco.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.74] Content-Type: multipart/signed; boundary="Apple-Mail=_E9BAA3F2-20E8-479B-ADFE-C2B1158CB243"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , "Manger, James" , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:40:09 -0000 --Apple-Mail=_E9BAA3F2-20E8-479B-ADFE-C2B1158CB243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 2, 2016, at 10:28, Julian Reschke = wrote: >=20 > On 2016-05-02 18:17, Joe Hildebrand (jhildebr) wrote: >> If we did this, then we would have to talk the IESG into applying an = STD number to RFC 7159 with known errata, or give up on JSON becoming a = full Internet Standard. In my opinion, it's worth changing the RFC = number again. >=20 > ...we have errata to apply anyway, right? >=20 Yes, there are four errata that are either "Verified" or "Held for = Document Update": < = https://www.rfc-editor.org/errata_search.php?rfc=3D7159&rec_status=3D15&pr= esentation=3Dtable > -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_E9BAA3F2-20E8-479B-ADFE-C2B1158CB243 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXJ4LlAAoJEDWi+S0W7cO1VdkH/0z5YOBw+sFRrXt4K6OBJFkr YrN5N711ZPZx0ayPU+XXu5yytEdrvBVyhR2JpVURgdaic591sq46qgEdDGSigUpE CY6dY6rYHfA9faSpASAZvNw61pX1xKswxUOyBVYCh0T6hFMP3B5bhGjyk9S14HYr pCyNC9xT+OJ5MOYY6qRQivfoL3/T/TacLlLUrKpnFoNxCLGuOVCAYXXydK8U/IZQ YdlhOfL+qIZ71VszicenQ8x+b88hCoKJF9rnBJ1Y0NhovNh9tQKVJthIhnPjbxW/ o0inArTzRDWVdMRpkCpKCZAmgiLvav+BcMSWw1gasDR8Jah/ShJoQbzGRtgc+rc= =idFo -----END PGP SIGNATURE----- --Apple-Mail=_E9BAA3F2-20E8-479B-ADFE-C2B1158CB243-- From nobody Mon May 2 09:50:32 2016 Return-Path: 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 74A3A12D15F for ; Mon, 2 May 2016 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nnFWlNhQu5NS for ; Mon, 2 May 2016 09:50:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252DA12D596 for ; Mon, 2 May 2016 09:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1836; q=dns/txt; s=iport; t=1462207322; x=1463416922; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qN8CmjEQj1lC0DpguR8aLehNPsrjy/73fVMpeS5aiQk=; b=Rpfoht7IouX+CRFPPw8dnZcUN/Lw1sniRPHtvvr2VyloR5RLJT8Z6Fl1 dGk/t0BKDaki9AFEu/sSJonhr8HlXZ+kVt3S0/MaEi54q6qdvFKYMLYRs TbpX7dbPcX3PWJy2b+Nhqe+ByhJC5KxpzjcXyTsbZxs4lEonY1iugekoS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBQA8gidX/49dJa1dgzhTfQa5foF2I?= =?us-ascii?q?oVuAhyBFToSAQEBAQEBAWUnhEIBAQQjEVUCAQgODAImAgICMBUQAgQBEogqDqo?= =?us-ascii?q?ZkFsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJYF2CIJOhD2DACuCKwWHc4Vkg?= =?us-ascii?q?TKJCwGFe4gcjxGPMAEnCzCDa2yHSyUYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="scan'208";a="268730221" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 16:42:01 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u42Gg1qL026546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 16:42:01 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 12:42:00 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 2 May 2016 12:42:00 -0400 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "json@ietf.org" Thread-Topic: [Json] Schemas & so on Thread-Index: AQHRo/U855UvMn19j0KO3qh2throzZ+luaWA Date: Mon, 2 May 2016 16:42:00 +0000 Message-ID: <219BB6FA-F597-4235-AE53-6FE861CA28A5@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <0139D9708A6F914DA31711D661465457@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:50:31 -0000 SSd2ZSBiZWVuIHVzaW5nIENEREwgcmVjZW50bHk6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwtMDgNCg0KDQpFdmVuIHRo b3VnaCBpdCBzYXlzICJDQk9SIiBpbiB0aGUgbmFtZSwgaXQgd29ya3MgKnF1aXRlKiBuaWNlbHkg Zm9yIEpTT04uICBJbnN0YWxsIFJ1YnkgdG9vbGluZyB3aXRoIGBnZW0gaW5zdGFsbCBjZGRsYC4g IFBlcmhhcHMgQ2Fyc3RlbiBjYW4gc2VuZCB1cyBhbiB1cGRhdGVkIHBvaW50ZXIgdG8gdGhlIHNv dXJjZSBmb3IgdGhhdCB0b29sLg0KDQpFeGFtcGxlIENEREw6DQoNCnBlcnNvbiA9IHsNCiAgbmFt ZTogdGV4dCwNCiAgYWdlOiBpbnQNCn0NCg0KDQpBbmQgYSBjb25mb3JtaW5nIHBlcnNvbiBKU09O IHdvdWxkIGJlOiB7Im5hbWUiOiAiQWFyZHZhcmsiLCAiYWdlIjogMX0NCg0KLS0gDQpKb2UgSGls ZGVicmFuZA0KDQoNCg0KDQpPbiA1LzEvMTYsIDI6NTUgUE0sICJqc29uIG9uIGJlaGFsZiBvZiBU aW0gQnJheSIgPGpzb24tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdGJyYXlAdGV4dHVh bGl0eS5jb20+IHdyb3RlOg0KDQo+DQo+DQo+SSBmaW5kIG15c2VsZiB0YXNrZWQgd2l0aCBzcGVj aWZ5aW5nIGEgSlNPTi1iYXNlZCBEU0wgYW5kIHByZXBhcmluZyBpdCBmb3IgcHVibGljIHJlbGVh c2UsIHdpdGggYSB2YWxpZGF0b3IgYW5kIHNvIG9uLiAgDQo+DQo+DQo+SSBoYWQgbmV2ZXIgcmVh bGx5IGNvbmNlcm5lZCBteXNlbGYgbXVjaCB3aXRoIG9wdGlvbnMgZm9yIEpTT04gbGFuZ3VhZ2Ug ZGVmaW5pdGlvbiwgYnV0IGhhdmUgZGlzY292ZXJlZCB0aGV54oCZcmUgbm90IHZlcnkgZ29vZC4g IFRoZSBKU09OIFNjaGVtYSBwcm9qZWN0IGlzIG5vdCB0ZXJyaWJseSBhcHBlYWxpbmcgLSBvcGFx dWUgc3BlYywgcG9vciBkb2N1bWVudGF0aW9uDQo+IGFuZCB0b29scyAtIGFuZCBzbWVsbHMgb2Yg bmVnbGVjdCAobGFzdCBJLUQgZXhwaXJlZCBpbiAyMDEzKS4gIEl0J3MgYmVlbiBzdWdnZXN0ZWQg dGhhdCBhIGdvb2QgYXBwcm9hY2ggd291bGQgYmUganVzdCB0byB3cml0ZSBhIGpxIHByb2dyYW0g dGhhdCBlbWl0cyB0cnVlIG9yIGZhbHNlLg0KPg0KPg0KPklzIHRoZXJlIGdvb2QgY29udmVudGlv bmFsIHdpc2RvbSBhYm91dCBmb3JtYWxseSBzcGVjaWZ5aW5nIGEgSlNPTiBkaWFsZWN0Pw0KPg0K Pg0KPi0tIA0KPi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1lIGEgcHJpdmF0 ZSBtZXNzYWdlLCBzZWUgDQo+aHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkgPGh0dHBzOi8va2V5 YmFzZS5pby90aW1icmF5PikNCj4NCj4NCj4NCg== From nobody Mon May 2 11:11:45 2016 Return-Path: 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 0555212D5CF for ; Mon, 2 May 2016 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OBiv54-hNaLS for ; Mon, 2 May 2016 11:11:42 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 D2C8E12D5D6 for ; Mon, 2 May 2016 11:11:42 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id f74so72899883qge.2 for ; Mon, 02 May 2016 11:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EEmUzGOG8A6lWq0imstBn9Pnh11ME9y4YdrJ/owZI2A=; b=3+M8MY7ZQVFXdB5+m3hHO45k/gOwtxur6yfl7KtIcwqZ2xkvP++YR9ttwfdZQBiZFe omQ4wed+MhsakBT7U6vHyqPpxTvNmr0J0xnxvHgqet9m3y3HVgy4zeonQYpNz7vsAM6b CuBx+0YaqrohmalhTagxoOquzLyNb8GwUGy/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EEmUzGOG8A6lWq0imstBn9Pnh11ME9y4YdrJ/owZI2A=; b=OhUQvwXYFTD2PPmaf5U+41uGEI0DJf+A2sDNpqeYPwqrpXytqSBlJO8aSw/U6Gno93 ekvmEuFUyAoFFTiFMa2A7OQ2KLJQFoCMXDCtRkoyzgkQ4PmTHkvzEckF2ZFPNkbycA4l UoD8XoFM9vE26nV0dimnD2ECf3SOoygsL7DdPX9EpPuT/BhxkSn0rrdhLORiGo3dSmN7 oJIbVP20xz8O30nGuG1OnE5UQ/TyVZWB4/j/bnCvL7Ctd7oICa2AvnjHZea0sqvhib9x flUm/G5Ya/SP0YpueAvjSHY4zcW3IctKY/H53F0Rb1/9DwCe1It+Oipoy50O3KU9za1I vEIQ== X-Gm-Message-State: AOPr4FWmRGuqgoSXOuDJW4RGKwrZkkmrbx32J7Fce9urcR5W9j0X+RMeOC0L61Ded5gCjigy8Z8vqx1vMZ5NTw== X-Received: by 10.140.225.80 with SMTP id v77mr34891082qhb.53.1462212701825; Mon, 02 May 2016 11:11:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.85 with HTTP; Mon, 2 May 2016 11:11:27 -0700 (PDT) In-Reply-To: References: From: Austin William Wright Date: Mon, 2 May 2016 11:11:27 -0700 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=001a11373632adfd710531dfeca7 Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:11:45 -0000 --001a11373632adfd710531dfeca7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 1, 2016 at 1:55 PM, Tim Bray wrote: > > I find myself tasked with specifying a JSON-based DSL and preparing it fo= r > public release, with a validator and so on. > > I had never really concerned myself much with options for JSON language > definition, but have discovered they=E2=80=99re not very good. The JSON = Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. > > Is there good conventional wisdom about formally specifying a JSON dialec= t? > JSON Schema _is_ an active and ongoing effort. But as is usually the case with anything powerful and self-descriptive, there's a lot of problems that will crop up, a tiny few of which we've identified for the next release, but still certainly plenty more. This is compounded by the fact JSON Schema is hypermedia. We're actively soliciting feedback for a release at the GitHub repo: We'd like to hear what relative weaknesses you've encountered, and comparisons to other technologies. As far as tooling goes, there's a standard test suite, and as far as I'm aware JSON Schema has more implementations than anything else. Thanks, Austin Wright. --001a11373632adfd710531dfeca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, May 1, 2016 at 1:55 PM, Tim Bray <tbray@textuality.com><= /span> wrote:

I find myself tasked with s= pecifying a JSON-based DSL and preparing it for public release, with a vali= dator and so on. =C2=A0

I had never really concerned myself much with opt= ions for JSON language definition, but have discovered they=E2=80=99re not = very good.=C2=A0 The JSON Schema project is not terribly appealing - opaque= spec, poor documentation and tools - and smells of neglect (last I-D expir= ed in 2013).=C2=A0 It's been suggested that a good approach would be ju= st to write a jq program that emits true or false.

Is there good conventi= onal wisdom about formally specifying a JSON dialect?

JSON Schema _is_ an active and ongoing effort. But as is = usually the case with anything powerful and self-descriptive, there's a= lot of problems that will crop up, a tiny few of which we've identifie= d for the next release, but still certainly plenty more. This is compounded= by the fact JSON Schema is hypermedia.

We're active= ly soliciting feedback for a release at the GitHub repo:

We= 9;d like to hear what relative weaknesses you've encountered, and compa= risons to other technologies. As far as tooling goes, there's a standar= d test suite, and as far as I'm aware JSON Schema has more implementati= ons than anything else.

Thanks,

Austin Wright.

--001a11373632adfd710531dfeca7-- From nobody Mon May 2 17:10:09 2016 Return-Path: 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 0AC8012D6A6 for ; Mon, 2 May 2016 17:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 kmk76XujZ_aZ for ; Mon, 2 May 2016 17:10:06 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 6385012D53B for ; Mon, 2 May 2016 17:10:06 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6902322E25B; Mon, 2 May 2016 20:10:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Tue, 3 May 2016 10:10:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 00:10:09 -0000 FWIW - This general area of discussion came up in the IETF maybe two years ago; = can dig around in archives if people are interested, but IIRC it was = mostly hallway-based. I'd characterise the general feeling then as "run away screaming"; the = wounds of XSD / WS-* were too fresh. It came up again more recently (again, the hallway track), and the = feeling I got was that people were more amenable to it, but still = concerned about the numerous pitfalls. It strikes me that it might be worth writing down what we think is good = in such a beast, and what would be not-good. Getting agreement on that = might be... interesting, but if we had such a document (or maybe just a = wiki page), we'd be able to evaluate the current contenders, at least. Cheers, > On 2 May 2016, at 6:55 AM, Tim Bray wrote: >=20 >=20 > I find myself tasked with specifying a JSON-based DSL and preparing it = for public release, with a validator and so on. =20 >=20 > I had never really concerned myself much with options for JSON = language definition, but have discovered they=E2=80=99re not very good. = The JSON Schema project is not terribly appealing - opaque spec, poor = documentation and tools - and smells of neglect (last I-D expired in = 2013). It's been suggested that a good approach would be just to write = a jq program that emits true or false. >=20 > Is there good conventional wisdom about formally specifying a JSON = dialect? >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 2 18:01:18 2016 Return-Path: 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 A281B12D693 for ; Mon, 2 May 2016 18:01:16 -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 P5sOpPEe5khb for ; Mon, 2 May 2016 18:01:15 -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 E95F712B067 for ; Mon, 2 May 2016 18:01:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axOi7-0008EL-J5; Mon, 02 May 2016 21:01:11 -0400 Date: Mon, 2 May 2016 21:01:11 -0400 From: John Cowan To: Mark Nottingham Message-ID: <20160503010109.GA17482@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 01:01:16 -0000 Mark Nottingham scripsit: > It strikes me that it might be worth writing down what we think is good > in such a beast, and what would be not-good. Getting agreement on that > might be... interesting, but if we had such a document (or maybe just > a wiki page), we'd be able to evaluate the current contenders, at least. Here's what I think the bare necessities are for a schema language. This is loosely based on FtanGram, the schema language for FtanML, a markup language similar to XML and JSON. 1) A language for specifying the types of JSON items. A type is a set of JSON items. If the root item matches the root type and each sub-item recursively matches the subtype, then the JSON document is valid, otherwise not. 2) The following primitive types: 2a) The set containing only JSON null. 2b) The set containing both JSON booleans. 2c) The set containing only JSON true. 2d) The set containing only JSON false. 2e) The set containing all JSON numbers. 2f) The set containing all JSON integers. 2g) The set containing all JSON strings. 3) The type of JSON numbers with a specified upper and/or lower bound (inclusive or exclusive). 4) The type of JSON integers with a specified upper and/or lower bound (inclusive or exclusive). 5) The type of JSON strings that match a specified regular expression. 6) The type of all JSON arrays. 7) The type of JSON arrays that match a specified regular expression over types which match the elements of the array. The regular expression operators are sequence, choice, and bounded and unbounded repetition. 8) The type of all JSON objects. 9) The type of JSON objects with specified keys, with the types of the values corresponding to those keys. Keys may be required or optional. In addition, a way to specify whether other keys are allowed or forbidden. 10) The type of all JSON items. 11) The ability to name a type and refer to it by name. 12) The ability to define type libraries and import types from them. Comments? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner From nobody Mon May 2 18:13:54 2016 Return-Path: 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 86E7A12D6B1 for ; Mon, 2 May 2016 18:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 E66RLprN-Uho for ; Mon, 2 May 2016 18:13:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 5237512D1A1 for ; Mon, 2 May 2016 18:13:51 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7EF0122E1F3; Mon, 2 May 2016 21:13:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <20160503010109.GA17482@mercury.ccil.org> Date: Tue, 3 May 2016 11:13:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503010109.GA17482@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 01:13:53 -0000 > On 3 May 2016, at 11:01 AM, John Cowan wrote: >=20 > In addition, a way to specify whether other keys are allowed or = forbidden. Forbidding unrecognised keys isn't very JSONic, and arguably gets us = into the same quagmire that XSD became. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 2 19:17:35 2016 Return-Path: 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 CF82A12D540 for ; Mon, 2 May 2016 19:17:34 -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 vCWa2x3QPaTj for ; Mon, 2 May 2016 19:17:30 -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 C664512D53B for ; Mon, 2 May 2016 19:17:29 -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; bh=4h8M66mtY5XhMd4VOTTNXbKdmtkWQRu2jHe+3/0SxQc=; b=C8UQi99UEh6GHODzhTygMwnCi8 UhVyQyJFgn2VZkorxPl0Dw6qoPfc/p2zglDQxMSHLZ6wORyccv+VK3RHj5yOPIFeKk4Bqrgou7akV JeZ/zxI2nLgK4I2AOM+IkWJCHi60g6RYCAP1LjSoHtJwUZjWCXYSKA5w9X5G4xMu86vw0QTn7kaHC R16g6dBHZZoVXRD7+zVIRPOU4wCw3uL0R5CcGeVnYGLxHQkDk5pd9PKA9DHzuEL704moEaBY9L0lD nAjyUuBxtuR8Z/sGj7uEqwF7Fy7NQTggERbeHOCGlbkHP7hJlgZMCQOYAt8PHoEeuX4JtJWdn1ky+ /xFl2gSQ==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:59459 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1axPtw-0005px-E7; Mon, 02 May 2016 22:17:28 -0400 To: Mark Nottingham , Tim Bray References: From: Erik Wilde Message-ID: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> Date: Mon, 2 May 2016 19:17:27 -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: Content-Type: text/plain; charset=utf-8; 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: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:17:35 -0000 On 2016-05-02 17:10, Mark Nottingham wrote: > It strikes me that it might be worth writing down what we think is good in such a beast, and what would be not-good. Getting agreement on that might be... interesting, but if we had such a document (or maybe just a wiki page), we'd be able to evaluate the current contenders, at least. fwiw, after the discussion started on this list, it got me thinking because as mark noted, the discussion tends to start and then stop without a truly successful candidate emerging (so far). i think that there will be one, eventually, and over the weekend wrote down my thoughts about it here: http://dret.typepad.com/dretblog/2016/05/json-schema-why-and-how.html cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon May 2 19:46:05 2016 Return-Path: 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 6707F12B042 for ; Mon, 2 May 2016 19:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 zB2RPOXbHeJu for ; Mon, 2 May 2016 19:46:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 1705412B01C for ; Mon, 2 May 2016 19:46:01 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9D30622E1F3; Mon, 2 May 2016 22:45:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> Date: Tue, 3 May 2016 12:45:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> To: Joe Hildebrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Tim Bray , "Manger, James" , "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:46:03 -0000 > On 3 May 2016, at 2:17 AM, Joe Hildebrand (jhildebr) = wrote: >=20 > Sounds more harmful than helpful to again change the RFC number that = defines JSON =E2=80=94 rfc4627, rfc7158, rfc7159, rfcXXXX =E2=80=94 for = what is > supposed to be a simple and stable format. >=20 > Stick the text in as an errata marked =E2=80=9Cheld for document = update=E2=80=9D; or stick it in its own RFC that updates rfc7159 (bit = weird?); or > in a liaison note to ECMA. For better or worse, that's how things work. If we stop progressing = documents to get stable RFC numbers, something's really broken.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 2 19:54:19 2016 Return-Path: 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 8023F12B04F for ; Mon, 2 May 2016 19:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EIG9EkTDR0Nc for ; Mon, 2 May 2016 19:54:15 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 47FA312B01C for ; Mon, 2 May 2016 19:54:15 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id g17so14803594wme.1 for ; Mon, 02 May 2016 19:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5osVsnFcGJD4dLjBvNfuZOoz2ZLc7NJzK8FiMJF8bNQ=; b=vntw091QsGf5Ttgs2FXaoTFkg38l1xHrNM39Q7nU2QBH3rUjqKMOKB8iHRi5kvQGoV EiNAXl19PSs0l6SgA4AfwsxyLjdVcUVpNiiLNIy/Mffg7xvvDK/SwEAgggRxKKLPxzSE NR7s/WNjxy0bQD9xx/oMDAYw3CIS/VjG7TVa1nrP9OXVS54oM6mqdsLHHbso0KbNYW3o lmPksKB4QmEx9gB/l6rN1UVP2vEsTVkjwUHttV7F8INriXRdUUq61wHierXIAnjVdxrT 1HZp7ZGmLaeQjeTuUZb1vSO5KrBcwPGWhpTgYyWeRKC3tZMJdTZ/FURIQTrMx7Waj14a JhHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5osVsnFcGJD4dLjBvNfuZOoz2ZLc7NJzK8FiMJF8bNQ=; b=JWcfsR31OWI39uaI7+MjqqKKTk5p7mSxnpskohm3rWW1sQsx89/khjBrYTfoRkYIK9 O1Vvr4WJhfF7o5j89ua3d6iGV5hjBThl1L/++LSwcnElqS+Z/XGhdMsvDmnlZM1gCPEq DgWJpgOFigUqVPzQ0VvDPlBjoQoGzK+RZJouV7KZZbiKM2nnMk4DjNMMttBYRz24kJ4h Aw3qlX9NVXv0W1YLWZgsmFRx4fJvNk6Xp08cWNg1AAcfsEp8fm3eSscoGKfXkI3LNhHh w4l8lwlXepvoPAX6n/xFcgGewml3vNScVIJY7UhTZYRoqZ8wGgOVUuzRQiO1h1sp1Hn9 VysA== X-Gm-Message-State: AOPr4FUKWHEsImtpG++qsv+6uUDIRYZlXw1dpgtiWCA2qQSE0bou6gVZRrt4ohLfyLLrIg== X-Received: by 10.28.90.65 with SMTP id o62mr21402249wmb.16.1462244053739; Mon, 02 May 2016 19:54:13 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id e8sm1818953wma.2.2016.05.02.19.54.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 19:54:12 -0700 (PDT) To: Erik Wilde , Mark Nottingham , Tim Bray References: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> From: Anders Rundgren Message-ID: Date: Tue, 3 May 2016 04:53:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:54:17 -0000 On 2016-05-03 04:17, Erik Wilde wrote: > On 2016-05-02 17:10, Mark Nottingham wrote: >> It strikes me that it might be worth writing down what we think is good in such a beast, and what would be not-good. Getting agreement on that might be... interesting, but if we had such a document (or maybe just a wiki page), we'd be able to evaluate the current contenders, at least. > > fwiw, after the discussion started on this list, it got me thinking > because as mark noted, the discussion tends to start and then stop > without a truly successful candidate emerging (so far). i think that > there will be one, eventually, and over the weekend wrote down my > thoughts about it here: > > http://dret.typepad.com/dretblog/2016/05/json-schema-why-and-how.html Thanx! IMO, the #1 problem is that there are at least three potential consumers of a "schema": - Validators - Code generators - System documentation I don't think a static declarative system would be very useful. OTOH, scripting would work particularly well for documentation so I will personally stick to the programmatic approach. I'm mainly concerned about the external part (documentation). Here is an example: https://cyberphone.github.io/openkeystore/resources/docs/keygen2.html#InvocationRequest Anders > > cheers, > > dret. > From nobody Mon May 2 20:03:29 2016 Return-Path: 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 2C92D12D0C9 for ; Mon, 2 May 2016 20:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 vTemQQ2hHkLE for ; Mon, 2 May 2016 20:03:26 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 C7BE112B04F for ; Mon, 2 May 2016 20:03:25 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id f92so3211573qgf.0 for ; Mon, 02 May 2016 20:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C9GO+qGPrPXysfNy51QiEnHzhHFEmUWImI+BR4t5HBc=; b=vDl+9XZmSZlCfYwBpdDcnSfvR8/sQEcyozvgYM4OVUu4A73tfv7nVlAVjpQe9LmzZ6 5b+YCcG+lbY0MLxHyye1oNGRrxso+cCScGuyxL07XYP7kLc+hLvEKPBF9xTs0Zm/Vkx0 f0iGM+/9ezrfvGl6cjohct5xwuilc3bUDUTFYL1H609r5DukiXF/R7uotKgl76PR/9Fc 6QEhZFeVMLvMpWG8q8QYg+oulnTB5T8Bnzn38xACqvbmLbsd7SilJ79chPg//BxqpIip Y/9YGMyzC6A67zc0khRGmguquLxUgnscdh0xEesDi2dN0OITl/6PZ8ICWDJL6o0zQI3W m/Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C9GO+qGPrPXysfNy51QiEnHzhHFEmUWImI+BR4t5HBc=; b=A8ydYdO2PXgLfxqY2vid1GDmF9rUdVKp9JzHlml3Pk/dzEhYTwiwVchl3C/9AqjGKo 8k3T1z/KB/0SJqvglLpJBX0db1i0NYUYIZ9vpP0hfNmK4ZpdpzCa1iDjVzzcs4M6dV1L HiSl1WgdFYVYGFFjLKDxgf+qJvMYtZPkVlzAv0WYsJyKbzmKSghYCIaobemEbolm5dkE chihbSgelUPN35QYDKS6DmDeaV0RHs91hbjJwnneCXf57ICtx5cQxhB1LB7CwV9t7jtT hOJ8wnxyW/Lk45hVMzWAiWlutUJKmya978okCTCwJzJQbSDOiYWjjKwho1KJR3jLSSxC EIbQ== X-Gm-Message-State: AOPr4FWCxApG4EgxFVP3Di8Hpr33Z5miyiHth9UlcYOpEMxBs7KEDZyU1hsd6NubKc7T+KLWh6qB1fYUkypREQ== X-Received: by 10.140.161.4 with SMTP id h4mr5787qhh.99.1462244604956; Mon, 02 May 2016 20:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Mon, 2 May 2016 20:03:05 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: From: Tim Bray Date: Mon, 2 May 2016 20:03:05 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113a55de40ee100531e75a65 Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:03:28 -0000 --001a113a55de40ee100531e75a65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2016 at 5:10 PM, Mark Nottingham wrote: It strikes me that it might be worth writing down what we think is good in > such a beast, and what would be not-good. Getting agreement on that might > be... interesting, but if we had such a document (or maybe just a wiki > page), we'd be able to evaluate the current contenders, at least. > [Not facetiously] RelaxNG, only for JSON. 1. based on a carefully-worked-through formalism (hedge automata in the XML case) 2. Expressive and readable (didn't insist on schema & instance in same syntax) 3. Came with a really-silck validator that Just Worked and was easy to embed in other languages (who ya gonna call? James Clark!) Unfortunately, if my dim recollection of hedge automata is correct, they are not appropriate for JSON. =E2=80=8B=E2=80=8B > > Cheers, > > > > > On 2 May 2016, at 6:55 AM, Tim Bray wrote: > > > > > > I find myself tasked with specifying a JSON-based DSL and preparing it > for public release, with a validator and so on. > > > > I had never really concerned myself much with options for JSON language > definition, but have discovered they=E2=80=99re not very good. The JSON = Schema > project is not terribly appealing - opaque spec, poor documentation and > tools - and smells of neglect (last I-D expired in 2013). It's been > suggested that a good approach would be just to write a jq program that > emits true or false. > > > > Is there good conventional wisdom about formally specifying a JSON > dialect? > > > > -- > > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham https://www.mnot.net/ > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a113a55de40ee100531e75a65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Ma= y 2, 2016 at 5:10 PM, Mark Nottingham <mnot@mnot.net> wrote:

It strikes = me that it might be worth writing down what we think is good in such a beas= t, and what would be not-good. Getting agreement on that might be... intere= sting, but if we had such a document (or maybe just a wiki page), we'd = be able to evaluate the current contenders, at least.
=
[Not = facetiously] RelaxNG, only for JSON. =C2=A0

1. based on a carefully-worked-through formalism (hedg= e automata in the XML case)
2. Expressive and readable (didn't insist on schema & = instance in same syntax)
3. Came with a really-silck validator that Just Worked and was ea= sy to embed in other languages (who ya gonna call? James Clark!)

Unfortunately, if my dim recollecti= on of hedge automata is correct, they are not appropriate for JSON.
=E2=80=8B=E2=80=8B
=C2=A0

Cheers,



> On 2 May 2016, at 6:55 AM, Tim Bray <tbray@textuality.com> wrote:
>
>
> I find myself tasked with specifying a JSON-based DSL and preparing it= for public release, with a validator and so on.
>
> I had never really concerned myself much with options for JSON languag= e definition, but have discovered they=E2=80=99re not very good.=C2=A0 The = JSON Schema project is not terribly appealing - opaque spec, poor documenta= tion and tools - and smells of neglect (last I-D expired in 2013).=C2=A0 It= 's been suggested that a good approach would be just to write a jq prog= ram that emits true or false.
>
> Is there good conventional wisdom about formally specifying a JSON dia= lect?
>
> --
> - Tim Bray (If you=E2=80=99d like to send me a private message, see h= ttps://keybase.io/timbray)
> _________________________________________= ______
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a113a55de40ee100531e75a65-- From nobody Mon May 2 20:04:50 2016 Return-Path: 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 2035C12D0C9 for ; Mon, 2 May 2016 20:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 JUo7oUgfXztP for ; Mon, 2 May 2016 20:04:47 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 7800612B05B for ; Mon, 2 May 2016 20:04:47 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f74so3172723qge.2 for ; Mon, 02 May 2016 20:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QE3FjbyW9ekthYDAo/RDqjXvWKvvrOfFVxDtbibsiww=; b=sMgl/u7m+nXBYnHwNFn+tjri1fAPN1cLbvpOXWXW/ip5g9Kn1aizOGth8yiFOkUPUE aCMGwwDbjbSNHoS8N6FjRCdcGrBHakYHyxAnph8yoy1i3a+tkglUGkNHJ0wO57LQ/8Vq p+M52NXtvPQ5bWgKI+UHhygDRS3Ue8r+S8bmN85FnuIzWTBa6FSypk8L1X0iXwx1R9tH N2D+VlNE3+YJPnJQTWWCT5MGAT5/9ChiMm8FF+SOjpL5h82da8Iwcov8JUqq/pqfSTWy tWc78CxstIU6O3POvcb8ELmABfTxrMsYtRg0P6LpTxRhsyJRDIIUw0mMi8U+OLSOTnar YIQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QE3FjbyW9ekthYDAo/RDqjXvWKvvrOfFVxDtbibsiww=; b=PsX5EhWkeASFsBmWsRT50kRGxR8jUyUyFC2S9iSImM2crYtAQ1brXMo4oza4VqVG5x /P3tYOFGl4cSzxO3WDLFi2xP+zHjYHYsaaXvj35FXygeu7/V1NafDKvRC3fXJWOl1lH2 rX3CNU3hbQA3QUR5NxjdugoIAaVVANXpoeDR6daSerA+4nHgCWkQBNFmgHD4J500mVWi Q208MRIXXp1XBbfsS8iR1t67fwZ0/mPJURGa1KuK/bR1uyJk3s6uQqoHByvd8jNera3m TXN42AN5BW04SEpy6/zo7R3et/MnZCGMoZMyiadYLRbxrVHUcO0HV9tfBghNz+Xk4Xtc 7OTw== X-Gm-Message-State: AOPr4FUOBP/3kdg+xPj82uSGYKZagmsiCiLodkmlTW0MGbTUKJQu9Zhywcq4vymvFkmDa3VH8tB/tJThkazYNQ== X-Received: by 10.140.40.231 with SMTP id x94mr13670qgx.83.1462244686617; Mon, 02 May 2016 20:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Mon, 2 May 2016 20:04:27 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> From: Tim Bray Date: Mon, 2 May 2016 20:04:27 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c11de41ef7c10531e75fb0 Archived-At: Cc: John Cowan , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:04:49 -0000 --001a11c11de41ef7c10531e75fb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2016 at 6:13 PM, Mark Nottingham wrote: > > > On 3 May 2016, at 11:01 AM, John Cowan wrote: > > > > In addition, a way to specify whether other keys are allowed or > forbidden. > > Forbidding unrecognised keys isn't very JSONic, and arguably gets us into > the same quagmire that XSD became. > =E2=80=8BHaha, I like that, we=E2=80=99ll MUST-IGNORE-IFY ALL THE APIs! Si= mply make=E2=80=8B MUST-UNDERSTAND inexpressible. Effective if a bit Orwellian. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c11de41ef7c10531e75fb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 2,= 2016 at 6:13 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 3 May 2016, at 11:01 AM, John Cowan <cowan@mercury.ccil.org> wrote:
>
> In addition, a way to specify whether other keys are allowed or forbid= den.

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

=E2=80=8BHaha,= I like that, we=E2=80=99ll MUST-IGNORE-IFY ALL THE APIs!=C2=A0 Simply make= =E2=80=8B MUST-UNDERSTAND inexpressible.=C2=A0 Effective if a bit Orwellian= .


=C2=A0

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




--
=
- Tim Bray (If you=E2= =80=99d like to send me a private message, see https://keybase.io/timbray)
--001a11c11de41ef7c10531e75fb0-- From nobody Mon May 2 20:15:11 2016 Return-Path: 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 99F1F12D0F2 for ; Mon, 2 May 2016 20:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GBZCtMJg69CG for ; Mon, 2 May 2016 20:15:09 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 58FC112D0C9 for ; Mon, 2 May 2016 20:15:08 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id u10so103860410igr.1 for ; Mon, 02 May 2016 20:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=00PEWRFaIrj+JCXPF2hz+zHCJYZ2iefFaTEwAoHyZuM=; b=1KTKZssnvAK/14czvB/4q6pYOj9OOlZBbh8Or8nGr9Ugu7KjvH1D2vaiM6yswFuQL4 O5xj+W9mzu0CiSji+txceK0EV1llxoh9IeEFWu7wLdkpA5j6AJWopdlCaQLmJKMqpge1 shCnF2ApzJx9HPajM2Oh7ijKRG3iTRbmWjYeS4dNYOcWmUbY4yi3ZhDYF7u+UkFPPZWA HwX9JZDJCEnDLL1WjpWtArZjr5b+qCGA8uOdp+yk+u9wGBallxp7RJ9d4OIHxJCGzsHV cc4BUYZaN7KWgJE1mgWf9D96cRxXewooqQsB2E0/BzuzHzsTgK8Xw3S9qkOpx6xxbjgl B2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=00PEWRFaIrj+JCXPF2hz+zHCJYZ2iefFaTEwAoHyZuM=; b=SBS5aiEGwY6mwqp4BA/PXLkQPt7dotDYdWi/P7wLmNj58eE2RKN7jWsI+Od1rOWIDT SkXCogXNMZ+RHLoVxy8cgUL2h5fAiHxlF0wMB+kUgXPLt8kq4SEP5vgPn9uMmiFtzRWi Cu/Ec1x5aujdghO1POk/gihTswkIv5Mv9b1IL/XuxVjGr8U435ZEiyQpqgnQv7RRY4FR UzNk+9+FulcuMTHoRn32z6BJGwCUWHIasNjV+nwrDE9C+ZOBrW+CVw9UAT69IFLGU1Dg 3vtXvO7ERL7t+s31dNxHxQrkJrKYLC4hSEXtNUU8d1C4OTp+eSx20Q9b0dsSqShP61JE okvA== X-Gm-Message-State: AOPr4FVU3DjNcZE4CFbhZgLqs1XX9sl4mVt5Uf3CpY9TISYRqWa+kQ1VqqiClafmBHZL903J8wuaeGsHrBeIfQ== MIME-Version: 1.0 X-Received: by 10.50.18.166 with SMTP id x6mr24113473igd.12.1462245307608; Mon, 02 May 2016 20:15:07 -0700 (PDT) Received: by 10.107.52.1 with HTTP; Mon, 2 May 2016 20:15:07 -0700 (PDT) In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> Date: Mon, 2 May 2016 20:15:07 -0700 Message-ID: From: Rob Sayre To: Tim Bray Content-Type: multipart/alternative; boundary=14dae93a0cbd2275ec0531e78460 Archived-At: Cc: Mark Nottingham , John Cowan , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:15:10 -0000 --14dae93a0cbd2275ec0531e78460 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2016 at 8:04 PM, Tim Bray wrote: > > On Mon, May 2, 2016 at 6:13 PM, Mark Nottingham wrote: > >> >> > On 3 May 2016, at 11:01 AM, John Cowan wrote: >> > >> > In addition, a way to specify whether other keys are allowed or >> forbidden. >> >> Forbidding unrecognised keys isn't very JSONic, and arguably gets us int= o >> the same quagmire that XSD became. >> > > =E2=80=8BHaha, I like that, we=E2=80=99ll MUST-IGNORE-IFY ALL THE APIs! = Simply make=E2=80=8B > MUST-UNDERSTAND inexpressible. Effective if a bit Orwellian. > This discussion has not adequately addressed the fact that there are much more efficient ways to encode JSON data if you have a schema. It can be protobufs, thrift, cbor, avro, or whatever. They do must-ignorify everything, btw. The IETF is far behind the industry standard here. - Rob --14dae93a0cbd2275ec0531e78460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 2, 2016 at 8:04 PM, Tim Bray <tbray@textuality.com> wrote:

On Mon, May 2, 2016 at 6:13 PM, Mark Nottingham <mnot@m= not.net> wrote:

> On 3 May 2016, at 11:01 AM, John Cowan <cowan@mercury.ccil.org> wrote:
>
> In addition, a way to specify whether other keys are allowed or forbid= den.

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

=E2=80=8BHaha, I like that, we= =E2=80=99ll MUST-IGNORE-IFY ALL THE APIs!=C2=A0 Simply make=E2=80=8B MUST-U= NDERSTAND inexpressible.=C2=A0 Effective if a bit Orwellian.

This discussion has not ade= quately addressed the fact that there are much more efficient ways to encod= e JSON data if you have a schema. It can be protobufs, thrift, cbor, avro, = or whatever. They do must-ignorify everything, btw.

The IETF is far behind the industry standard here.

- Rob
--14dae93a0cbd2275ec0531e78460-- From nobody Mon May 2 20:28:20 2016 Return-Path: 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 13EC812D0A0 for ; Mon, 2 May 2016 20:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 B5Y4qjCpNiv1 for ; Mon, 2 May 2016 20:28:17 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 2151212B018 for ; Mon, 2 May 2016 20:28:17 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id f74so3319974qge.2 for ; Mon, 02 May 2016 20:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2WXq6Kaknfjs76+izpqh1RI/2MM8w+dFBt8xY6ljSkc=; b=1vTxelz8NWOdNXsChfudWAMMVJcVnmE1GD4m2vuBEBOqiIQWFUVe2kV7Xi4ydPbBJv TpYUDwv9nM98CmKi2ohNYNcka8KKX/o70RRxL2MEFzRHL00sCuzUN9HVxgbbBIkU3uuJ AIiP2nPMmOCOvCTXrmoxNmS5szeLo4RE+4sA5bQB/AOePr6QrPC12RAKTRMisNpjFiRA hydKwx9QkkwfX/LyFqrDeT98zt02vN1UuCS0503yExFFSm8LOq8/jY85HsoyY0dgmvHc Rb8BHO0YcknTU6E2UTpzxucfRnkOf2d4HQJ8z9ZtirVy8pW+wIcYUDpIU4JbeZldaYg0 C3yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2WXq6Kaknfjs76+izpqh1RI/2MM8w+dFBt8xY6ljSkc=; b=S1XvjkyyuwslnIco8BIPlPCSIKQWKFQM0MSPOlbH+nQJn7EaWDOpzBwbMrpwJVQC/l /zAkGRD8upkdIIp43LuS2m8AcbpXhsEVIJr1FZKFLnV/3oFnJrcfVtUntjIvu+qJYg6O VG1xUewJrOhis/Dqxme/ua0VUQxVDuR1LORzff1khTK29c7fwouAbH5/4m2ywgKwShFT DWVRWxB38bBVKQrOvEd3WEYztVfl6A5hNCgb0zsJLaRKs6GkMAaCosLpQlLBCCGkegio oTBTnnmpFBNXwZxviFjpBXQmdvpcWl7NW55OjOrlftMIyYAMTH3cwwukVIFKrP7K9Vbi E8nw== X-Gm-Message-State: AOPr4FXPGnwE6Q+8lG8sgSFhgSLEA6Qg/l+nMIuRrMSBADjY+kfSrdP0+DkZxJIAmBWjdkThGaMLyT2lpaboyA== X-Received: by 10.140.143.144 with SMTP id 138mr121048qhp.88.1462246096268; Mon, 02 May 2016 20:28:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Mon, 2 May 2016 20:27:56 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> From: Tim Bray Date: Mon, 2 May 2016 20:27:56 -0700 Message-ID: To: Rob Sayre Content-Type: multipart/alternative; boundary=001a11371e562487a40531e7b37c Archived-At: Cc: Mark Nottingham , John Cowan , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:28:19 -0000 --001a11371e562487a40531e7b37c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 2, 2016 at 8:15 PM, Rob Sayre wrote: > This discussion has not adequately addressed the fact that there are much > more efficient ways to encode JSON data if you have a schema. It can be > protobufs, thrift, cbor, avro, or whatever. They do must-ignorify > everything, btw. > > The IETF is far behind the industry standard here. > I suppose, but 1. It is rarely the case that markup serialization/deserialization efficiency is that significant to the performance of an application, and 2. being binary sucks. Anyhow, in my day job we want to have a JSON DSL and we want to have a validator for it, and we think a decent schema language would facilitate construction of the validator. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B > > - Rob > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11371e562487a40531e7b37c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Mon, May 2, 2016 at 8:15 PM, Rob Sayre <sayrer@gmail.com> wro= te:
This discussion has not adequately addressed the fa= ct that there are much more efficient ways to encode JSON data if you have = a schema. It can be protobufs, thrift, cbor, avro, or whatever. They do mus= t-ignorify everything, btw.

The IETF is far behind= the industry standard here.

<= /div>
I suppose,= but=C2=A0

=
1. It is rarel= y the case that markup serialization/deserialization efficiency is that sig= nificant to the performance of an application, and
2. being binary sucks.

Anyhow, in my day job we want to have a = JSON DSL and we want to have a validator for it, and we think a decent sche= ma language would facilitate construction of the validator.

=
=E2=80=8B=E2=80= =8B

=E2=80=8B=E2=80=8B
=C2=A0

-= Rob



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11371e562487a40531e7b37c-- From nobody Mon May 2 20:50:07 2016 Return-Path: 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 26F2112D166 for ; Mon, 2 May 2016 20:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 oUNxbhfs8lDC for ; Mon, 2 May 2016 20:50:04 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 675EF12D164 for ; Mon, 2 May 2016 20:50:04 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x7so3699869qkd.3 for ; Mon, 02 May 2016 20:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8WYpkZVcUXVcUZJqG0L/POoJRtSPCendE2//Oufn9Ng=; b=KUavrfcn6e3ADyGM0DZtv0O+1A8F0ngASODQKEPxB6TJUFxpPVqwj8bcP5PKqz6nbQ /PUFjIWz4LIGx0SuIkaipHqXUg3HtSc/rP8zsVj52cOWo6tsalCN1CL8EF+n4owrkHjF 1ljOKiZCJZxde/HX2ESH8R0UjsiV956vPCvAMSpn+c8brcVrbNPobLMzx6H9/AgZ/RsC j8RiXA8FQyGijyJo3eQbrnbRI25cQF5UjFH+b7WFvrsYYpjKpe10EhKSZJxqfVdRIc9M Fe18NqqEFQB27soC1Hf72FPIZlnIIr9ikXQzrj2S2M/FU/n+60LwMGBPF0bcTJUZg//c FMOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8WYpkZVcUXVcUZJqG0L/POoJRtSPCendE2//Oufn9Ng=; b=LmaybcMr6urezgJQfN+zR382suJAJ8Lj5A2+I/pAhJh1UDWVqxXScx2X4+BmZGAUeJ g9lD25ttpoIzGPF2NpYeOy2cZ/kjCQQpBwHhd8K9AE/uqcLBpnbpeheDPw+o6AImL6Da e3SsleBcBcM02LhCD9Znr1fR2kz/TF1DBAa/Vc+oaNClAUCsdUAa+pLO5gThvUgmxjfH SW7HtvSUZrdteSYuecQK03mo+n6LHPrs6GuN6YO7rDkm9agnwSthVdl7Eo3bRaKz3vqV OfdNcV6PT1GvemeRbEhabpBkjw9kmzx97g5inXEOU5Pfos1Bn8fb0GSzZrYi+lZwfG41 YwFg== X-Gm-Message-State: AOPr4FVdxMyD46aPo4OuBvSChHt3laYV8+rdQKjm+vbA2Ej6UAdfasl1a5456j3QQ1U/0KO4Te1itTXtz39pEw== X-Received: by 10.55.72.196 with SMTP id v187mr154690qka.97.1462247403518; Mon, 02 May 2016 20:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Mon, 2 May 2016 20:49:43 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> From: Tim Bray Date: Mon, 2 May 2016 20:49:43 -0700 Message-ID: To: Rob Sayre Content-Type: multipart/alternative; boundary=001a114a7f880f9eed0531e801e9 Archived-At: Cc: Mark Nottingham , John Cowan , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:50:06 -0000 --001a114a7f880f9eed0531e801e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Somone linked to this paper: http://www2016.net/proceedings/proceedings/p263.pdf [Foundations of JSON Schema]. It=E2=80=99s really quite encouraging. I don=E2=80=99t actually hate JSON schema, was just disappointed with the specification and the tooling. On Mon, May 2, 2016 at 8:27 PM, Tim Bray wrote: > On Mon, May 2, 2016 at 8:15 PM, Rob Sayre wrote: > >> This discussion has not adequately addressed the fact that there are muc= h >> more efficient ways to encode JSON data if you have a schema. It can be >> protobufs, thrift, cbor, avro, or whatever. They do must-ignorify >> everything, btw. >> >> The IETF is far behind the industry standard here. >> > > I suppose, but > > 1. It is rarely the case that markup serialization/deserialization > efficiency is that significant to the performance of an application, and > 2. being binary sucks. > > Anyhow, in my day job we want to have a JSON DSL and we want to have a > validator for it, and we think a decent schema language would facilitate > construction of the validator. > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > >> >> - Rob >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a114a7f880f9eed0531e801e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Som= one linked to this paper:=C2=A0http://www2016.net/proceedings/proceedings/p263.pdf= [Foundations of JSON Schema].=C2=A0 It=E2=80=99s really quite encouraging.=

I don=E2=80=99t actually= hate JSON schema, was just disappointed with the specification and the too= ling.

= On Mon, May 2, 2016 at 8:27 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
On Mon, May 2= , 2016 at 8:15 PM, Rob Sayre <sayrer@gmail.com> wrote:
This discussion has not adequately ad= dressed the fact that there are much more efficient ways to encode JSON dat= a if you have a schema. It can be protobufs, thrift, cbor, avro, or whateve= r. They do must-ignorify everything, btw.

The IETF= is far behind the industry standard here.

I suppose, but=C2=A0

1. It is rarely the case that markup serialization/deserialization e= fficiency is that significant to the performance of an application, and
2. being binary su= cks.

=
Anyhow, in my day jo= b we want to have a JSON DSL and we want to have a validator for it, and we= think a decent schema language would facilitate construction of the valida= tor.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0
=
=

- Rob



--=
- Tim Bray (If you=E2=80=99d like to send m= e a private message, see https://keybase.io/timbray)



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a114a7f880f9eed0531e801e9-- From nobody Mon May 2 20:58:39 2016 Return-Path: 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 DD66812D164 for ; Mon, 2 May 2016 20:58:37 -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 lO065-_bIhGF for ; Mon, 2 May 2016 20:58:36 -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 9C24A12D0E2 for ; Mon, 2 May 2016 20:58:36 -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; bh=ogfhTidR6QAhkpoyypgUwbp0B4NeMG8sOLRd9Sl6a3I=; b=n09ZmOni0nzySRcA4UXFDs9o11 KNafDoYXW7DltOtC0HfSGv8w7yA2d+h4g3vUhUmDa7vSdih8i2sdsRXHYJ3wY0f3onnjqmsucIWOK yEhHKV08SCsvpP2Hsto7jkc19xo2aRdW2rZ62RspiJCLIpTAVB0vBUBTnVOKj7QUliSGYU/2f6CdL 31wtmFJNQ/MWkixtb9bS+qgN6rwOamIP4EpG0vOMfikUdG/xAXOrfx8AwdgXuw/VAc1HoBm/+tBaX lqcEG/niPCMAvmiPMBpZ1srVS3gQtqNPcNXOlyRR1nK/PnxAr2Ray6JtdHITBROXzRvVfj3RfRphs do+N0vNg==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:60541 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1axRTn-0004Qg-HF; Mon, 02 May 2016 23:58:35 -0400 To: Tim Bray , Rob Sayre References: <20160503010109.GA17482@mercury.ccil.org> From: Erik Wilde Message-ID: <4d11b571-0f22-1ea2-c117-284b36409766@dret.net> Date: Mon, 2 May 2016 20:58:34 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Cc: Mark Nottingham , John Cowan , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:58:38 -0000 On 2016-05-02 20:49, Tim Bray wrote: > Somone linked to this > paper: http://www2016.net/proceedings/proceedings/p263.pdf [Foundations > of JSON Schema]. Its really quite encouraging. > I dont actually hate JSON schema, was just disappointed with the > specification and the tooling. the talk they gave was good. what's needed would be to make the spec more formally sound (that's their specific focus, and apparently that's feasible without major changes to the general mechanics), and then, as a separate issue, maybe moving the syntax to something more palatable. other possible improvements to the spec (personally, for example, i find the hypermedia aspect of it to be a bit strange at that level) then mostly depend on preference and perspective. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon May 2 21:17:47 2016 Return-Path: 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 9D2E512D6A6 for ; Mon, 2 May 2016 21:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 dJ3Enw-OXjLh for ; Mon, 2 May 2016 21:17:43 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 5621D12D1B4 for ; Mon, 2 May 2016 21:17:42 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id r184so3915012qkc.1 for ; Mon, 02 May 2016 21:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e3hnkBLjdSe3kkVQ1R/oRLdeVL1j7cg7nYms6R4DW54=; b=Zd7fJFbo1DyZyTvGfuThxOl7RB+y/5NWVe/U9XpKu+lG/vHMsPVEB8N1YM4LV+RtXJ q4qIwn7r/9nlEy9pbMz0rnDoIhiOLX6VvlmHXJDXKE/S008RW3A6mILsXHCgyM4Ll1bE E8VqrEpgP84P6HFr/P+FQuBpQyKvjcHegeHWpphU9eBVQGDJBtU7GR0aAPe+eYBvyV/g hN+7C3W+auOsGxYgT00OsnRUNIHcVAC2IrXmTf7wvlJmF0M+OYvGH+LvylTJmIjcO04G qUIRffiAOSjP8Gt9C0JCQJt5U7tFWZA5q+STkyzKXDThtQMkStVMBPkrLXV04C0FORnn fSwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e3hnkBLjdSe3kkVQ1R/oRLdeVL1j7cg7nYms6R4DW54=; b=i63qqNonLiyzrlrBuhmvi3atsaATNxaiACOUfXxnG2iIBcY+UTphMsPRLN+7ExvwbK 2ETXGXvo7UhcNy0JtlXlB7yxUuyOlwFMTaoP6PBVBZudWjStmRi5rnMf0ZUfrE7zJZOH Tt1je31M/WXSoQppAr5GhO+5MNsZUihUJm92VX1o46BNLjHJJiIAhtP8YQzk+z2O1exo Ntzahq5KlUrMR/RAXn2lt5ZVBYxRqCsnYwNpoHxw6cTpGrJVryLdKiqYAEXvoFHVBwGD nh6rcVcZUD7Lj0WBRLfZH8A24Iw2yXw3hVJ6lfzrix1SjyVHpBpcVsGmdlp/TE45ecDk 8Eww== X-Gm-Message-State: AOPr4FUZ2KKN1MRx82j9Oj1jsKg2kaj786s0+ZL+YYq3NUMsIutKFdZs494VH7IKBrzq3RVIxCTmX6ujqAipQA== X-Received: by 10.55.6.23 with SMTP id 23mr272068qkg.66.1462249061574; Mon, 02 May 2016 21:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Mon, 2 May 2016 21:17:22 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: <4d11b571-0f22-1ea2-c117-284b36409766@dret.net> References: <20160503010109.GA17482@mercury.ccil.org> <4d11b571-0f22-1ea2-c117-284b36409766@dret.net> From: Tim Bray Date: Mon, 2 May 2016 21:17:22 -0700 Message-ID: To: Erik Wilde Content-Type: multipart/alternative; boundary=001a114c5af6e3876b0531e863be Archived-At: Cc: Mark Nottingham , "json@ietf.org" , John Cowan , Rob Sayre 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 04:17:45 -0000 --001a114c5af6e3876b0531e863be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hrmf. I have a big moderately-complex day-job DSL in front of me that actually has a useful purpose and I expect tooling to be built around. So I need a validator and a schema would be helpful. It=E2=80=99d be fun to b= uild schemas in JSON Schema, its subset described in that paper, CDDL, JCR, and anything else that sounded plausible. Then I=E2=80=99d have a useful opini= on about the issues, which I don=E2=80=99t have now. Unfortunately our DSL isn=E2=80=99t decloaking till sometime in the second = half of the year. If the matter is still relevant, I promise to do that then. On Mon, May 2, 2016 at 8:58 PM, Erik Wilde wrote: > On 2016-05-02 20:49, Tim Bray wrote: > >> Somone linked to this >> paper: http://www2016.net/proceedings/proceedings/p263.pdf [Foundations >> of JSON Schema]. It=E2=80=99s really quite encouraging. >> I don=E2=80=99t actually hate JSON schema, was just disappointed with th= e >> specification and the tooling. >> > > the talk they gave was good. what's needed would be to make the spec more > formally sound (that's their specific focus, and apparently that's feasib= le > without major changes to the general mechanics), and then, as a separate > issue, maybe moving the syntax to something more palatable. > > other possible improvements to the spec (personally, for example, i find > the hypermedia aspect of it to be a bit strange at that level) then mostl= y > depend on preference and perspective. > > > cheers, > > dret. > > -- > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a114c5af6e3876b0531e863be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hrm= f.=C2=A0 I have a big moderately-complex day-job DSL in front of me that ac= tually has a useful purpose and I expect tooling to be built around.=C2=A0 = So I need a validator and a schema would be helpful.=C2=A0 It=E2=80=99d be = fun to build schemas in JSON Schema, its subset described in that paper, CD= DL, JCR, and anything else that sounded plausible.=C2=A0 Then I=E2=80=99d h= ave a useful opinion about the issues, which I don=E2=80=99t have now.

Unfortunately our DSL isn=E2= =80=99t decloaking till sometime in the second half of the year.=C2=A0 If t= he matter is still relevant, I promise to do that then.

On Mon, May 2, 2016 a= t 8:58 PM, Erik Wilde <erik.wilde@dret.net> wrote:
On 2016-05-02 20:49, Tim Bray w= rote:
Somone linked to this
paper: http://www2016.net/proceedings/proceeding= s/p263.pdf [Foundations
of JSON Schema].=C2=A0 It=E2=80=99s really quite encouraging.
I don=E2=80=99t actually hate JSON schema, was just disappointed with the specification and the tooling.

 the talk they gave was good. what's needed would be to make the spec mo= re formally sound (that's their specific focus, and apparently that'= ;s feasible without major changes to the general mechanics), and then, as a= separate issue, maybe moving the syntax to something more palatable.

other possible improvements to the spec (personally, for example, i find th= e hypermedia aspect of it to be a bit strange at that level) then mostly de= pend on preference and perspective.
=

cheers,

dret.

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



--
=
- Tim Bray (If you=E2= =80=99d like to send me a private message, see https://keybase.io/timbray)
--001a114c5af6e3876b0531e863be-- From nobody Tue May 3 06:12:56 2016 Return-Path: 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 1371012D505 for ; Tue, 3 May 2016 06:12:55 -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 xMg0MKKFigeL for ; Tue, 3 May 2016 06:12:53 -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 7EE6712D501 for ; Tue, 3 May 2016 06:12:53 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axa89-0002ou-Cy; Tue, 03 May 2016 09:12:49 -0400 Date: Tue, 3 May 2016 09:12:49 -0400 From: John Cowan To: Erik Wilde Message-ID: <20160503131248.GA22066@mercury.ccil.org> References: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:12:55 -0000 Erik Wilde scripsit: > http://dret.typepad.com/dretblog/2016/05/json-schema-why-and-how.html I'll respond here rather than as a blog comment. I agree with most of your points and recently mentioned your XSD compact syntax on xml-dev. (I regret that this remained stand-alone and was never incorporated into Jing and Trang, where it would have done the most good.) However, I think that there is a counterexample to the "no JSON syntax" claim, which is Examplotron. When describing a grammar using a fixed metaformat, using instance syntax is too much of a pain. But when using examples (which people have anyway) and annotating them to specify a few critical generalities, instance syntax is a clear win. I think that a JSON schema language of this form, without too many bells and whistles, might actually be usable. I had hoped, when I started to read the JCR document, that JCR was a language of this type. But while valid JSON instances are for the most part also valid JCR, an instance does not match other structurally similar instances: instead, it matches only itself, making it entirely useless. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) From nobody Tue May 3 06:17:50 2016 Return-Path: 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 ; 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 ; 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 ; Tue, 3 May 2016 06:17:47 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axaCv-0003AB-AK; Tue, 03 May 2016 09:17:45 -0400 Date: Tue, 3 May 2016 09:17:45 -0400 From: John Cowan To: Mark Nottingham Message-ID: <20160503131744.GB22066@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue May 3 06:38:28 2016 Return-Path: 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 E36F612B04B for ; Tue, 3 May 2016 06:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, 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 b7ImHpBqHxca for ; Tue, 3 May 2016 06:38:24 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (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 5AE8D12D501 for ; Tue, 3 May 2016 06:38:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9FBFE4088D14; Tue, 3 May 2016 09:38:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB3nATf1LizG; Tue, 3 May 2016 09:38:23 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 8C3A84088D09; Tue, 3 May 2016 09:38:22 -0400 (EDT) Date: Tue, 03 May 2016 09:38:20 -0400 From: Cyrus Daboo To: Mark Nottingham , Tim Bray Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1772 Archived-At: Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:38:27 -0000 Hi, --On May 3, 2016 at 10:10:00 AM +1000 Mark Nottingham wrote: > This general area of discussion came up in the IETF maybe two years ago; > can dig around in archives if people are interested, but IIRC it was > mostly hallway-based. > > I'd characterise the general feeling then as "run away screaming"; the > wounds of XSD / WS-* were too fresh. > > It came up again more recently (again, the hallway track), and the > feeling I got was that people were more amenable to it, but still > concerned about the numerous pitfalls. > > It strikes me that it might be worth writing down what we think is good > in such a beast, and what would be not-good. Getting agreement on that > might be... interesting, but if we had such a document (or maybe just a > wiki page), we'd be able to evaluate the current contenders, at least. > At the time my personal reason for wanting something like this was not so much to have a formal "schema" or "rules", but rather something that could be used in protocol specs to "describe" what JSON an implementor would expect to see in a request or response. That is a very real problem that we faced when developing RFC7808 - which is a JSON-based HTTP protocol. Initially I wrote that using an early version of draft-newton-json-content-rules, but since that did not progress to publication, we were asked to switch to using the format developed in RFC7071 (). So, rather than a formal "schema", I would rather see this group focus on a standard way to "describe" JSON structures in protocol specs, with the goal of having something easy to understand or base implementations off. Perhaps a purely informational document is all that is needed. -- Cyrus Daboo From nobody Tue May 3 06:58:30 2016 Return-Path: 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 4223E12D82B for ; Tue, 3 May 2016 06:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 as1iDCAEi2yK for ; Tue, 3 May 2016 06:58:26 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 BB55612D1E9 for ; Tue, 3 May 2016 06:57:52 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id u185so26456009iod.3 for ; Tue, 03 May 2016 06:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qgVOC6DlNcQ5mnYNt4+27tri7e9fYaiS0iS2uYIrs5g=; b=Vjcbf3x+3zX+JwmzI0Ji7cFBLQ2QkP48VAcgX5ICFwQXRg6SuSHKNj3RdpQPy+7Zla VzuN3FGtX69i86NSmQVNxeiHjKbatGu3DPV4+QqE3YJXS1rur8D4p8Ji+YHgnp9MZvaL FiSUJYSJgvFsvKRO8wBnAys/LZo8YFX3SuTXBdgpmP9vOLjWJKnCKilN2AAcU0UM4Go5 AEaZNefBg3P4UkDFedVsVwyOVHdn2FDNVAOY7PDDJ48NnU60RNuZry0TSKhut6btrm/i TvmmidsIfsVy04so9T1QQoCeU4oQneZ7UJtXY+3c2TnegcTl2GzCla2up0iisnZl6oGt 19og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qgVOC6DlNcQ5mnYNt4+27tri7e9fYaiS0iS2uYIrs5g=; b=LbqJTFLYw1HPp8nvSAq3dZizjPkp+/1HQg4ni6FNsRnXaoyZzhS4mEYlx8ahnHXO1L lI85tL9WqRPyttvb9vmxlsdrnXulOjM0SNA84/UMkemCpohF4sutApYmwZclLzYNjZyl Z+rWHxA9qH56gjdQY9R/ErvfkzJR6HevZVKvdEFqLRLtjK1Svq+RX+ncsqQ4a6t6pSDu pJqrF4F2s5kIhE2KgM5oRwexjOjXEHBll7udoKalhmdgHKixaS3NfZYubT2L/kLcCv7k iytYvuOgGEDBuGKv/ZKf57hlgCc1gECUnvJZUO7c41KgVTveXYfwpuBNmjsiUHRFgvdx YsMw== X-Gm-Message-State: AOPr4FV5BddgO/ZQbtzNOrD6+FkdbimrCdepQFL7QHqnNcjIGaG/+DpkAWqHkwzaH0f/zw== X-Received: by 10.107.0.7 with SMTP id 7mr3604910ioa.35.1462283872082; Tue, 03 May 2016 06:57:52 -0700 (PDT) Received: from [172.22.5.100] ([12.231.104.138]) by smtp.gmail.com with ESMTPSA id k2sm12531923igx.7.2016.05.03.06.57.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 06:57:51 -0700 (PDT) To: Cyrus Daboo References: From: Victor Kareh Message-ID: Date: Tue, 3 May 2016 09:57:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:58:29 -0000 Hello, What you're describing sounds similar enough to the node.js Mongoose ORM schema definition [http://mongoosejs.com/docs/guide.html]. We actually use that style at my day job for our API documentation (not actually using mongoose, just the schema spec) and it works really well to communicate across teams providing/consuming the API. It supports a high-level description (no validation, just expected types and structure) or a more thorough version with validation rules and property constraints. -- Victor Kareh On 2016-05-03 9:38 AM, Cyrus Daboo wrote: > Hi, > > --On May 3, 2016 at 10:10:00 AM +1000 Mark Nottingham > wrote: > >> This general area of discussion came up in the IETF maybe two years ago; >> can dig around in archives if people are interested, but IIRC it was >> mostly hallway-based. >> >> I'd characterise the general feeling then as "run away screaming"; the >> wounds of XSD / WS-* were too fresh. >> >> It came up again more recently (again, the hallway track), and the >> feeling I got was that people were more amenable to it, but still >> concerned about the numerous pitfalls. >> >> It strikes me that it might be worth writing down what we think is good >> in such a beast, and what would be not-good. Getting agreement on that >> might be... interesting, but if we had such a document (or maybe just a >> wiki page), we'd be able to evaluate the current contenders, at least. >> > > At the time my personal reason for wanting something like this was not > so much to have a formal "schema" or "rules", but rather something > that could be used in protocol specs to "describe" what JSON an > implementor would expect to see in a request or response. That is a > very real problem that we faced when developing RFC7808 - which is a > JSON-based HTTP protocol. Initially I wrote that using an early > version of draft-newton-json-content-rules, but since that did not > progress to publication, we were asked to switch to using the format > developed in RFC7071 (). > > So, rather than a formal "schema", I would rather see this group focus > on a standard way to "describe" JSON structures in protocol specs, > with the goal of having something easy to understand or base > implementations off. Perhaps a purely informational document is all > that is needed. > > From nobody Tue May 3 07:26:54 2016 Return-Path: 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 3A8921200A0 for ; Tue, 3 May 2016 07:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 hzPbjMF6GY-R for ; Tue, 3 May 2016 07:26:51 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35BC12D0A4 for ; Tue, 3 May 2016 07:26:47 -0700 (PDT) Received: (qmail 25245 invoked from network); 3 May 2016 15:22:08 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 3 May 2016 15:22:08 +0100 To: John Cowan , Erik Wilde References: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> <20160503131248.GA22066@mercury.ccil.org> From: Peter Cordell Message-ID: <60c96d28-70a5-f3a3-30b3-b6f7232b60ab@codalogic.com> Date: Tue, 3 May 2016 15:26:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160503131248.GA22066@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:26:53 -0000 On 03/05/2016 14:12, John Cowan wrote: > However, I think that there is a counterexample to the "no JSON syntax" > claim, which is Examplotron. ... > > I had hoped, when I started to read the JCR document, that JCR was a > language of this type. But while valid JSON instances are for the most > part also valid JCR, an instance does not match other structurally similar > instances: instead, it matches only itself, making it entirely useless. > I disagree that JCR is "entirely useless". I think it's a great strength that you can start with an actual JSON example, but then generalise it via annotation to be more embracing. I think Examplotron is neat, but it makes lots of assumptions about what you're trying to express. It essentially guesses what you mean by a construct. This may work for a little while, but soon runs out of steam. There's a reason why people say you should be explicit about what you want. Plus, there is the issue of practical syntax. XML offers namespaces so you can do things like to differentiate between one or more and zero or more (or optional etc). Lacking even comments it's hard to see how a JSON based syntax could do this is an elegant way. (I can imagine some ugly hacks involving unlikely member names, but I'd really rather not.) And the ability to explicitly state that you want a particular string (for example), rather than having that being inferred as any string, opens up the use of JCR as part of a test vector suite, which could be very useful as part of implementation validation. So, very useful indeed IMO. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 3 08:08:53 2016 Return-Path: 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 4032212D51B for ; Tue, 3 May 2016 08:08:52 -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 QPIHflVljvYb for ; Tue, 3 May 2016 08:08:50 -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 66CAD12D512 for ; Tue, 3 May 2016 08:08:50 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axbwK-0002kn-U5; Tue, 03 May 2016 11:08:44 -0400 Date: Tue, 3 May 2016 11:08:44 -0400 From: John Cowan To: Peter Cordell Message-ID: <20160503150844.GI29513@mercury.ccil.org> References: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> <20160503131248.GA22066@mercury.ccil.org> <60c96d28-70a5-f3a3-30b3-b6f7232b60ab@codalogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60c96d28-70a5-f3a3-30b3-b6f7232b60ab@codalogic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , "json@ietf.org" , Tim Bray , Erik Wilde 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:08:52 -0000 Peter Cordell scripsit: > I disagree that JCR is "entirely useless". Sorry, I meant that using a plain JSON document as a JCR document is entirely useless, not that JCR as a whole is useless. > Examplotron is neat, but it makes lots of assumptions about what > you're trying to express. It essentially guesses what you mean by a > construct. Well, I'd rather say that it has some well-documented conventions about instance values. > This may work for a little while, but soon runs out of > steam. There's a reason why people say you should be explicit about > what you want. >From the language designer's (and implenter's) viewpoint, yes. From the user's view, where the non-iconic features may be unnecessary for many applications, not so much. Examplotron has a gentler learning curve than any explicit grammar-based system. > Plus, there is the issue of practical syntax. XML offers namespaces > so you can do things like to differentiate > between one or more and zero or more (or optional etc). Lacking > even comments it's hard to see how a JSON based syntax could do this > is an elegant way. (I can imagine some ugly hacks involving > unlikely member names, but I'd really rather not.) And name quotation, yes. I agree it's a problem. Still, even if JSON syntax should be or must be extended, I still think structural iconicity where possible is an important principle. > And the ability to explicitly state that you want a particular > string (for example), rather than having that being inferred as any > string, opens up the use of JCR as part of a test vector suite, > which could be very useful as part of implementation validation. Good point. > So, very useful indeed IMO. I have a lot of specific comments on JCR. What's the best forum for them? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org At times of peril or dubitation, Perform swift circular ambulation, With loud and high-pitched ululation. From nobody Tue May 3 08:33:05 2016 Return-Path: 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 CA7FA12D529 for ; Tue, 3 May 2016 08:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 ctPeKR64yzzG for ; Tue, 3 May 2016 08:33:02 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D5712D0EC for ; Tue, 3 May 2016 08:33:02 -0700 (PDT) Received: (qmail 28159 invoked from network); 3 May 2016 16:28:22 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 3 May 2016 16:28:22 +0100 To: John Cowan References: <4bb21809-bb40-7a3e-b7c7-f37da0976ea2@dret.net> <20160503131248.GA22066@mercury.ccil.org> <60c96d28-70a5-f3a3-30b3-b6f7232b60ab@codalogic.com> <20160503150844.GI29513@mercury.ccil.org> From: Peter Cordell Message-ID: <4273095f-0590-07df-bb22-fe09f9c4157d@codalogic.com> Date: Tue, 3 May 2016 16:32:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160503150844.GI29513@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:33:04 -0000 On 03/05/2016 16:08, John Cowan wrote: > Peter Cordell scripsit: > > I have a lot of specific comments on JCR. What's the best forum for them? > I'd be very interested to get your feedback. Now would be a good time as we've been quite fluid up until now, but are starting to feel things are firming up. For the time being discuss@json-content-rules.org is the best option. It's not a mailing as such but will fan out to Andy and I. Longer term, I believe that the IETF can set up (or used to be able to setup) a mailing list for topics even if they are not associated with a working group. If that's still an option, and there's enough interest, that might be something worth pursuing. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 3 10:13:11 2016 Return-Path: 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 9058912DD12 for ; Tue, 3 May 2016 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F_lGa_A2TDaq for ; Tue, 3 May 2016 10:13:07 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 CF32612DCB8 for ; Tue, 3 May 2016 10:08:48 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id 90so11270534qgz.1 for ; Tue, 03 May 2016 10:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2UjjQX9HjpcPJL9Xg/foaQJVG5SOG9bxEncTyN9KUsc=; b=0HT7HUn0gSXk7+T8G44UdnqCVae07+JnoCRDYwZDdcsjnVWsrTI807yf+5TL4JKo0T HFf3DDJvY8N+VJEpO2LY09FElLlDqQUQEGayAOagyIDtObRkDNuQ766O6iUjutcEAvU8 Ar2xm743NPawUGKQtdKVcVJ5GzNOp/KOROtvOO2Z6k2gQuU1Fp7TZIfF+1wlOdsGrQAK ZsYNHpH2Nk+1LvW4GmJIa2mCjIlkSoaN2UNkJUe5A5Y0McQ0d84Zz9Oa0yi+0kEsihdv cc7WJM5e4aDaPbR/BVmFUiiLyAVGlwZnwKe5qpFoW+RdYwy5sai1u/S9BnaWTx1NeUOr lRtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2UjjQX9HjpcPJL9Xg/foaQJVG5SOG9bxEncTyN9KUsc=; b=Zx7t9ohdxDNSMcdR7RIizPoEY3UZryX9YrH4Mc1NiMV9tFA8ZayA8q6vxpUc/7hZHK 7xtVqDNLKdsn2Lnf/rtuadZSzSueO00SV6Ge/tLuAUf1u/obPwNTTJ7E4I3JKdrETL8C 0F/itWwDZ7DBZ0+z7Dtt/OvhqiPpKpmcURA+hmS4SvsitQZjtKb7QH0jD1IYG9yptmvi M9i/xQPmFu/rO5u3LZmAHV/fTf3Mp7X+3PU8zXVdzyz4dfiCXQZbvQNLkAN3GJiir/QB MPa/DD0yjIQOz2Ron5zDzGpoJp2N0fG6kEFtONpZyMO2X8/ooCsfYFN/Go3q3OQQOPAa 2VfQ== X-Gm-Message-State: AOPr4FVi4U6DdEkRjvIEI2jwuHVkeLFDoVQhGPMSVMNNiWsSqlfEoh5cydDRRiXLe70JCkV28Y77pcghDDxt4w== MIME-Version: 1.0 X-Received: by 10.141.44.135 with SMTP id v129mr3950195qhe.46.1462295327988; Tue, 03 May 2016 10:08:47 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 10:08:47 -0700 (PDT) In-Reply-To: <20160503010109.GA17482@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> Date: Tue, 3 May 2016 13:08:47 -0400 X-Google-Sender-Auth: R-omOazzxETA0cXxwAzazDc_Bxs Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=94eb2c0bdc2494e3760531f32940 Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:13:09 -0000 --94eb2c0bdc2494e3760531f32940 Content-Type: text/plain; charset=UTF-8 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. It isn't something we need in JSON serialization. What we do need is a model for how to extend JSON based protocols. When is it allowed to add in new elements to structures? what structures are backwards compatible with the old? My answers to those being 'always' and 'when the tag is the same'. On Mon, May 2, 2016 at 9:01 PM, John Cowan wrote: > Mark Nottingham scripsit: > > > It strikes me that it might be worth writing down what we think is good > > in such a beast, and what would be not-good. Getting agreement on that > > might be... interesting, but if we had such a document (or maybe just > > a wiki page), we'd be able to evaluate the current contenders, at least. > > Here's what I think the bare necessities are for a schema language. > This is loosely based on FtanGram, the schema language for FtanML, > a markup language similar to XML and JSON. > > 1) A language for specifying the types of JSON items. A type is a set of > JSON items. If the root item matches the root type and each sub-item > recursively matches the subtype, then the JSON document is valid, > otherwise not. > > 2) The following primitive types: > 2a) The set containing only JSON null. > 2b) The set containing both JSON booleans. > 2c) The set containing only JSON true. > 2d) The set containing only JSON false. > 2e) The set containing all JSON numbers. > 2f) The set containing all JSON integers. > 2g) The set containing all JSON strings. > > 3) The type of JSON numbers with a specified upper and/or lower bound > (inclusive or exclusive). > > 4) The type of JSON integers with a specified upper and/or lower bound > (inclusive or exclusive). > > 5) The type of JSON strings that match a specified regular expression. > > 6) The type of all JSON arrays. > > 7) The type of JSON arrays that match a specified regular expression > over types which match the elements of the array. The regular expression > operators are sequence, choice, and bounded and unbounded repetition. > > 8) The type of all JSON objects. > > 9) The type of JSON objects with specified keys, with the types of the > values corresponding to those keys. Keys may be required or optional. > In addition, a way to specify whether other keys are allowed or forbidden. > > 10) The type of all JSON items. > > 11) The ability to name a type and refer to it by name. > > 12) The ability to define type libraries and import types from them. > > Comments? > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash > him with a Cshell! Vi didn't I mount it on a troff?" --Francis Turner > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --94eb2c0bdc2494e3760531f32940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 languag= e.

We do specify bounds on representation, int32, uint32= etc. But that is more a matter of convenience and space management. It isn= 't something we need in JSON serialization.

Wh= at we do need is a model for how to extend JSON based protocols. When is it= allowed to add in new elements to structures? what structures are backward= s compatible with the old? My answers to those being 'always' and &= #39;when the tag is the same'.



On Mon, May 2, 2= 016 at 9:01 PM, John Cowan <cowan@mercury.ccil.org> wro= te:
Mark Nottingham scripsit:

> It strikes me that it might be worth writing down what we think is goo= d
> in such a beast, and what would be not-good. Getting agreement on that=
> might be... interesting, but if we had such a document (or maybe just<= br> > a wiki page), we'd be able to evaluate the current contenders, at = least.

Here's what I think the bare necessities are for a schema langua= ge.
This is loosely based on FtanGram, the schema language for FtanML,
a markup language similar to XML and JSON.

1) A language for specifying the types of JSON items.=C2=A0 A type is a set= of
JSON items.=C2=A0 If the root item matches the root type and each sub-item<= br> recursively matches the subtype, then the JSON document is valid,
otherwise not.

2) The following primitive types:
2a) The set containing only JSON null.
2b) The set containing both JSON booleans.
2c) The set containing only JSON true.
2d) The set containing only JSON false.
2e) The set containing all JSON numbers.
2f) The set containing all JSON integers.
2g) The set containing all JSON strings.

3) The type of JSON numbers with a specified upper and/or lower bound
(inclusive or exclusive).

4) The type of JSON integers with a specified upper and/or lower bound
(inclusive or exclusive).

5) The type of JSON strings that match a specified regular expression.

6) The type of all JSON arrays.

7) The type of JSON arrays that match a specified regular expression
over types which match the elements of the array.=C2=A0 The regular express= ion
operators are sequence, choice, and bounded and unbounded repetition.

8) The type of all JSON objects.

9) The type of JSON objects with specified keys, with the types of the
values corresponding to those keys.=C2=A0 Keys may be required or optional.=
In addition, a way to specify whether other keys are allowed or forbidden.<= br>
10) The type of all JSON items.

11) The ability to name a type and refer to it by name.

12) The ability to define type libraries and import types from them.

Comments?

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.o= rg
Awk!" sed Grep. "A fscking python is perloining my Ruby; l= et me bash
=C2=A0 =C2=A0 him with a Cshell!=C2=A0 Vi didn't I mount it on a troff?= " --Francis Turner

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

--94eb2c0bdc2494e3760531f32940-- From nobody Tue May 3 10:19:53 2016 Return-Path: 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 C598512DCB8 for ; Tue, 3 May 2016 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zFOb3ytHipil for ; Tue, 3 May 2016 10:19:49 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 B4D3412DA0D for ; Tue, 3 May 2016 10:16:55 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x7so12027523qkd.3 for ; Tue, 03 May 2016 10:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=V5nc5BBEmfUtrK/FI4upMHJnOAfAd3rtB+HbCSDcZ+E=; b=bh+iSy3iPutisTDvhuwGBM6QnJffIuSYfd+YSlGDV5uGqWTVH3IRBdq3y41cV0AlrU g2i/3Vp6DwlJLiNe0ZtsBwgkatQZTuVVbWYnWvkHmqep3wODSo+bKNNTM6rtcjNtY8/y 9IBJ+pL8K9njmOO9POFtpVPSC5/986b+yLuAZrUMc1eqdPSPPIMdQL0ZtRo1aVRd+hzv Pw0lOR/gCqP1kuLWvvAqAV/lH1jwkaVVv/4jXUfSLEUE/ob7cR2iIdM9jOURF2zm2HZo /7MABFXWN4u0LxRhPqFn+KwG/YnC4lp1OpNH0tBqMIrjP48DpO2kJoozsth0A7L1WX0E 3KOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V5nc5BBEmfUtrK/FI4upMHJnOAfAd3rtB+HbCSDcZ+E=; b=N03dLRTABDPYiZeJPLIr+EmDPsZTVlA8Bj8J/GpTBL+1dlRs0wljoomwJMo54SXW9o Evc0MHgAN+ExWaGBB/DGHXy7RtDNfeNSS/Blv2tjaA/PyUAhP7J9t5Cniu/QJNcd8xfP Hcx8reywiMJQ1FinszddMWYABjrSnJblVdw4OcFCuAWHn9pRIYLfXvSVZm2lImnL892W ACjzp0n/2mFy8Z+RSN/YXng+ZWToTsIV5KOZQaO8wAO7OzsOtapveCmYcKpuIMHqZMgW vQ5TY6UZAzGoe1PzWs5fX1vEeWDDb0qUATzl2FK+39qy/WEUL7vM6iUKyQK2eiJMEpFF ES1A== X-Gm-Message-State: AOPr4FVQ3Vkz1EHYDToc0tdnQSLQp3MEYqxv1ojwjsM+d2fyjJfAH8WJnfbJ5KBCQXPqHFwfFYj2zRintybeyw== MIME-Version: 1.0 X-Received: by 10.55.209.18 with SMTP id s18mr4075285qki.196.1462295814707; Tue, 03 May 2016 10:16:54 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 10:16:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 May 2016 13:16:54 -0400 X-Google-Sender-Auth: 0fmV12_poFWMg6Y3LQwM1sR8JIo Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=001a1147992a97a5ed0531f3465b Archived-At: Cc: Mark Nottingham , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:19:52 -0000 --001a1147992a97a5ed0531f3465b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't see any value to 'validation' for data exchange. The reason that it is useful in XML is that XML is a document format and it is useful to tell the user if the document is well formed or not as they type. We have the following questions: 1) Is the input stream well formed JSON syntax? 2) Does the parsed JSON data contain all the necessary data fields required for the message? 3) Are the fields of the correct type? 4) Can we extend messages and preserve backwards compatibility? 5) Can we define new messages that will be rejected by legacy systems that are unable to process them? If we go beyond that, we are into programming. Yes, it is occasionally useful to state that the number of flanges to be delivered is less than 12. But very very rarely in an IETF application protocol. The type of constraints that are required in our types of protocol tend to be of the sort, 'if there is a reference to an item named X, there must be a corresponding definition elsewhere in the message'. And even those tend to be rather complex as the widget being deleted or modified might have been defined in a different message. On Mon, May 2, 2016 at 11:03 PM, Tim Bray wrote: > > > On Mon, May 2, 2016 at 5:10 PM, Mark Nottingham wrote: > > It strikes me that it might be worth writing down what we think is good i= n >> such a beast, and what would be not-good. Getting agreement on that migh= t >> be... interesting, but if we had such a document (or maybe just a wiki >> page), we'd be able to evaluate the current contenders, at least. >> > > [Not facetiously] RelaxNG, only for JSON. > > 1. based on a carefully-worked-through formalism (hedge automata in the > XML case) > 2. Expressive and readable (didn't insist on schema & instance in same > syntax) > 3. Came with a really-silck validator that Just Worked and was easy to > embed in other languages (who ya gonna call? James Clark!) > > Unfortunately, if my dim recollection of hedge automata is correct, they > are not appropriate for JSON. > =E2=80=8B=E2=80=8B > > >> >> Cheers, >> >> >> >> > On 2 May 2016, at 6:55 AM, Tim Bray wrote: >> > >> > >> > I find myself tasked with specifying a JSON-based DSL and preparing it >> for public release, with a validator and so on. >> > >> > I had never really concerned myself much with options for JSON languag= e >> definition, but have discovered they=E2=80=99re not very good. The JSON= Schema >> project is not terribly appealing - opaque spec, poor documentation and >> tools - and smells of neglect (last I-D expired in 2013). It's been >> suggested that a good approach would be just to write a jq program that >> emits true or false. >> > >> > Is there good conventional wisdom about formally specifying a JSON >> dialect? >> > >> > -- >> > - Tim Bray (If you=E2=80=99d like to send me a private message, see >> https://keybase.io/timbray) >> > _______________________________________________ >> > json mailing list >> > json@ietf.org >> > https://www.ietf.org/mailman/listinfo/json >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a1147992a97a5ed0531f3465b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't see any value to 'validation' for data= exchange.

The reason that it is useful in XML is that X= ML is a document format and it is useful to tell the user if the document i= s well formed or not as they type.=C2=A0

We have t= he following questions:

1) Is the input stream wel= l formed JSON syntax?
2) Does the parsed JSON data contain all th= e necessary data fields required for the message?
3) Are the fiel= ds of the correct type?
4) Can we extend messages and preserve ba= ckwards compatibility?
5) Can we define new messages that will be= rejected by legacy systems that are unable to process them?

=
If we go beyond that, we are into programming. Yes, it is occasi= onally useful to state that the number of flanges to be delivered is less t= han 12. But very very rarely in an IETF application protocol.
The type of constraints that are required in our types of proto= col tend to be of the sort, 'if there is a reference to an item named X= , there must be a corresponding definition elsewhere in the message'. A= nd even those tend to be rather complex as the widget being deleted or modi= fied might have been defined in a different message.



On Mon, May 2, 2016 at 11:03 PM, Tim Bray <tbray@textuality.com= > wrote:


On Mon, May 2, = 2016 at 5:10 PM, Mark Nottingham <mnot@mnot.net> wrote:

It strikes me that it might be worth writing down what we think is = good in such a beast, and what would be not-good. Getting agreement on that= might be... interesting, but if we had such a document (or maybe just a wi= ki page), we'd be able to evaluate the current contenders, at least.

[Not facetiously] RelaxNG, only for JSON. =C2=A0
=

1. based on a carefully-worked= -through formalism (hedge automata in the XML case)
2. Expressive and readable (didn't= insist on schema & instance in same syntax)
3. Came with a really-silck validator tha= t Just Worked and was easy to embed in other languages (who ya gonna call? = James Clark!)
<= br>
Unfortunate= ly, if my dim recollection of hedge automata is correct, they are not appro= priate for JSON.
=E2=80=8B=E2=80=8B
=C2=A0

Cheers,



> On 2 May 2016, at 6:55 AM, Tim Bray <tbray@textuality.com> wrote:
>
>
> I find myself tasked with specifying a JSON-based DSL and preparing it= for public release, with a validator and so on.
>
> I had never really concerned myself much with options for JSON languag= e definition, but have discovered they=E2=80=99re not very good.=C2=A0 The = JSON Schema project is not terribly appealing - opaque spec, poor documenta= tion and tools - and smells of neglect (last I-D expired in 2013).=C2=A0 It= 's been suggested that a good approach would be just to write a jq prog= ram that emits true or false.
>
> Is there good conventional wisdom about formally specifying a JSON dia= lect?
>
> --
> - Tim Bray (If you=E2=80=99d like to send me a private message, see h= ttps://keybase.io/timbray)
> _______________________________________________
> json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




<= /div>--
- Tim Bray (If you=E2=80=99d like to= send me a private message, see https://keybase.io/timbray)

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json


--001a1147992a97a5ed0531f3465b-- From nobody Tue May 3 10:27:23 2016 Return-Path: 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 39F4D12D690 for ; Tue, 3 May 2016 10:27:22 -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 f0eObD1A_NTy for ; Tue, 3 May 2016 10:27:20 -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 5484712D1B6 for ; Tue, 3 May 2016 10:25:41 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axe4o-0003jg-2a; Tue, 03 May 2016 13:25:38 -0400 Date: Tue, 3 May 2016 13:25:38 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160503172537.GM29513@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:27:22 -0000 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. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Your worships will perhaps be thinking that it is an easy thing to blow up a dog? [Or] to write a book? --Don Quixote, Introduction From nobody Tue May 3 10:40:38 2016 Return-Path: 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 ; 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 ; 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 ; 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 ) id 1axeJF-0006NX-Gl; Tue, 03 May 2016 13:40:33 -0400 To: John Cowan , Phillip Hallam-Baker References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> From: Erik Wilde Message-ID: <77fdbae1-98cd-96cc-64e3-7ad321433684@dret.net> Date: Tue, 3 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: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 | From nobody Tue May 3 11:11:27 2016 Return-Path: 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 DF32B12DD61 for ; Tue, 3 May 2016 11:11:25 -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 B-eEaWqj2VUt for ; Tue, 3 May 2016 11:11:19 -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 A15A412D8BE for ; Tue, 3 May 2016 11:10:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axelp-0006qE-Eq; Tue, 03 May 2016 14:10:05 -0400 Date: Tue, 3 May 2016 14:10:05 -0400 From: John Cowan To: Erik Wilde Message-ID: <20160503181004.GA20065@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <77fdbae1-98cd-96cc-64e3-7ad321433684@dret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77fdbae1-98cd-96cc-64e3-7ad321433684@dret.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Phillip Hallam-Baker , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:11:26 -0000 Erik Wilde scripsit: > 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? Of course it would be permissible. 42 is 00000000042 is 42.00000. > this is the part where XSD took a deep dive (making it complex but > powerful) and separated the lexical space and the value space: I agree that this has to be done, but I think that JSON is simple enough that the mapping is self-evident. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org It's the old, old story. Droid meets droid. Droid becomes chameleon. Droid loses chameleon, chameleon becomes blob, droid gets blob back again. It's a classic tale. --Kryten, Red Dwarf From nobody Tue May 3 11:13:46 2016 Return-Path: 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 87F2012D8C8 for ; Tue, 3 May 2016 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kW6_dMqrQuia for ; Tue, 3 May 2016 11:13:42 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 4F95212D874 for ; Tue, 3 May 2016 11:12:08 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id 90so12131526qgz.1 for ; Tue, 03 May 2016 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=nNqD0V/rrMSGE839EuR5k3L496+PT0h8m8I18AHf3QQ=; b=uKqKRBgxLDr6F0nYu9GFBSL2fTwDvN/YBKnq/av7lDAL5kvTlnuNXgWva+Nks7KQwn 3+gJIeGrAlxI+TyikJAXys23evdr4u/2qfAX2HvMrWVSqcpskBjMzx5S8gAzq8cdZn+m VNxV9SOrKe1VacT0cj7O5sExRJIsDocMGXE3b+hDyc0dE72/YQfiqzI9Y99h/AZrhPbg YG6KPUm+PBI1zv2rgRoQREMMcBNFNPx9jqIVZgJgmj8HNej8gdzbLv6eBU9otUAZW8bc VKDPNjaqR8PPIeUJU3/9ovkTUl/HxM5J9VDWIxCdKqYVyD2Jjh0zudsOlK/CDJlE9JcY wJhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nNqD0V/rrMSGE839EuR5k3L496+PT0h8m8I18AHf3QQ=; b=UkjfsWzG2PAWBweOce150+ZeCGhqI3MWjdOTlQEc2QABpsFpHm0fwkznrFdRcp7cyd YxcGYYLvaGpPm1yATvAN/rCp1CgAZQ7G6vctls7FleD2GkTgB4XY454/UyKhZKuYIWoU Xy4+r3Z8sItQitNbeQTEF6DyNr4XyLvm0+go2CqAis05a6QNIPCmYq1wjJxkxzmo3Aw5 7XOC7TT3oDsYuSnZkFOTsjPSKSzEfZ3FH+imjmePjgy4BXA7FBwfBo/riEZ6UpbI55pl UqgsHkq92Y9OZAgaZWRpuDD+V+uMLq/ZEBCnUVuDxuK7tLkSLbyXDQC1Z1fWxia9m7jt 6gqA== X-Gm-Message-State: AOPr4FV7yDYrQmWlQfODoJLou/fmzAqoICfLU3XcSHVlJ1c5ie03oKhaNkP5T7MIt76YuxpOs27Oo10b3d4rFQ== MIME-Version: 1.0 X-Received: by 10.141.44.135 with SMTP id v129mr4379496qhe.46.1462299127471; Tue, 03 May 2016 11:12:07 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 11:12:07 -0700 (PDT) In-Reply-To: <20160503172537.GM29513@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> Date: Tue, 3 May 2016 14:12:07 -0400 X-Google-Sender-Auth: JIejOhoBdjfzsyPlhohSt5U4Gpg Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=94eb2c0bdc240c668a0531f40c09 Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:13:44 -0000 --94eb2c0bdc240c668a0531f40c09 Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 1:25 PM, 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. > Right now, my tool allows those hints to be specified when it is used to generate TLS schema serializers/deserializers but I haven't seen the need to use them for a JSON protocol so far. I think syntactic sugar does actually matter. That is I see a big difference between something like int MyField; and something like this {"MyField" : { "type" : "Integer", "max" : 42, "min" : -32 } } I think the chances of spotting a blooper in the second is a lot better. If I ever did another revision to my tools to put all of the parsers into one system, it would probably have an input language that was something like the following: MyStruct Class MyIntField Integer MyStringField String If I then wanted to specify representation it would probably be by subtyping 'Integer' to allow int8, uint8, ... int64, uint64 like you suggest. Right now, the only case where I see a need to call something out as a special case is for handling BigNums. We use those a lot in Crypto but it is a real pain to use a generator where every Integer is a bignum by default. It is also inefficient as you have to convert your bignum to decimal and back. The reason for having the 'label before declaration' rule is that it provides consistency. Every definition has the label first. C has a nasty habit of doing this differently for classes and fields/variables. Doing it the same way throughout is much cleaner. The label should go first because it is always one token while the definition may be a structure. --94eb2c0bdc240c668a0531f40c09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 3, 2016 at 1:25 PM, John Cowan <cowan@mercury.ccil.org>= ; wrote:
Phillip Hallam-Baker scri= psit:

> 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.=C2=A0 We = need to
specify the bounds on specific JSON numbers so that we know that we can
safely deserialize them to language-specific types.=C2=A0 I agree that we d= on't
need arbitrary bounds like -1..52 very much, but 0..255 is another matter.<= br> It would probably be enough to allow a fixed set of bounds like u8, s8, ...=
u64, s64, f32, f64.

Right now, my tool = allows those hints to be specified when it is used to generate TLS schema s= erializers/deserializers but I haven't seen the need to use them for a = JSON protocol so far.

I think syntactic sugar does= actually matter. That is I see a big difference between something like

int MyField;

and something l= ike this

{"MyField" : { "type"= : "Integer", "max" : 42, "min" : -32 } }

I think the chances of spotting a blooper in the seco= nd is a lot better.


If I ever did a= nother revision to my tools to put all of the parsers into one system, it w= ould probably have an input language that was something like the following:=

MyStruct Class
=C2=A0 =C2=A0 MyIntField= Integer
=C2=A0 =C2=A0 MyStringField String

<= div>If I then wanted to specify representation it would probably be by subt= yping 'Integer' to allow int8, uint8, ... int64, uint64 like you su= ggest.

Right now, the only case where I see a need= to call something out as a special case is for handling BigNums. We use th= ose a lot in Crypto but it is a real pain to use a generator where every In= teger is a bignum by default. It is also inefficient as you have to convert= your bignum to decimal and back.

The reason for h= aving the 'label before declaration' rule is that it provides consi= stency. Every definition has the label first. C has a nasty habit of doing = this differently for classes and fields/variables. Doing it the same way th= roughout is much cleaner. The label should go first because it is always on= e token while the definition may be a structure.

<= br>

--94eb2c0bdc240c668a0531f40c09-- From nobody Tue May 3 11:15:15 2016 Return-Path: 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 9DB1712D86F for ; Tue, 3 May 2016 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Qs9gVZHdBK9j for ; Tue, 3 May 2016 11:15:08 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 48A8212D874 for ; Tue, 3 May 2016 11:13:45 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n63so12910845qkf.0 for ; Tue, 03 May 2016 11:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=5b2y69sVOIi4ucpMcLmpr8LOh7SaSY/7j7O2xLZ2ZXU=; b=i11WG83VcfoKPQ5oEsXseooM9XAzWi7s8u6tNZ1l9SQohPajeeNm5ty9S6aFipef8T paJJ+Vuwtic3B9HCt36MxJ96hJxIPDsPpo1mgy2ztokA1ot0QXJ7NHUvE5R/Y8h03aIU 0KPEDtsank6HCdrInPiYmoCNGNoY3oFiOhUGNRZNpLUS38hfNTmwnVqBJLJyqrsca7py JxLxVxNcs9CE1eZFIpm4MvksRbbQImx8PF/X6DevArRac14/ZYoxn8WeY6eH+tEaz6A2 6YJrSI0TebJtOqKmLcdXQo9RXJKAIcEG3a1Sc6s6f+BerVOMqq8N06YJd8EShhJVwJBO JQkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5b2y69sVOIi4ucpMcLmpr8LOh7SaSY/7j7O2xLZ2ZXU=; b=TTWhPwjrefrQgNgFQeS4gI1CB21eyZRPYVZIWWNPktSMOguoogP7x9GQUwMHLC725c y/YD4hhBa52Yqe/86U+mmfnRono1vMrsSPwMtu0GqnLV9MoMxrS/pxvXm6BRGtoJafyf BLVX8xnOb67tcaGr44ntF8IZYDxx9ZDBP4R+9JwAKKO31Luz2A6M3CpzvWyTAbugvO60 okiN4MQLun6jtoe87ZIZfezsICqI3t0yN7jZ6lrlFifp9iow+y8dpKm/2TwfrAUYdbEr alxgWdw9G2lR0uKg72UQhGft2c6VBKJKceNdV8IEiIWj1kjCs+Wcwh8TC+GQjT57sEwd xeWA== X-Gm-Message-State: AOPr4FWrRyHXjOvJM0SMzTrWzzvRcU+tWOkRpgDZiswBlN6eT7DYiOt8vqUFDhRpyy+ygUFvuEbLZFlcEHDf+w== MIME-Version: 1.0 X-Received: by 10.55.114.71 with SMTP id n68mr4408793qkc.37.1462299224386; Tue, 03 May 2016 11:13:44 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 11:13:44 -0700 (PDT) In-Reply-To: <20160503181004.GA20065@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <77fdbae1-98cd-96cc-64e3-7ad321433684@dret.net> <20160503181004.GA20065@mercury.ccil.org> Date: Tue, 3 May 2016 14:13:44 -0400 X-Google-Sender-Auth: VX4xL-sOTLB5IBXjdgTlORr57dE Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a114fef8ad3306e0531f411bf Archived-At: Cc: Mark Nottingham , "json@ietf.org" , Tim Bray , Erik Wilde 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:15:13 -0000 --001a114fef8ad3306e0531f411bf Content-Type: text/plain; charset=UTF-8 Not in JSON. No leading zeros. The only integer that starts with a zero is zero. (unless json.org has it wrong). On Tue, May 3, 2016 at 2:10 PM, John Cowan wrote: > Erik Wilde scripsit: > > > 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? > > Of course it would be permissible. 42 is 00000000042 is 42.00000. > > > this is the part where XSD took a deep dive (making it complex but > > powerful) and separated the lexical space and the value space: > > I agree that this has to be done, but I think that JSON is simple enough > that the mapping is self-evident. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > It's the old, old story. Droid meets droid. Droid becomes chameleon. > Droid loses chameleon, chameleon becomes blob, droid gets blob back > again. It's a classic tale. --Kryten, Red Dwarf > --001a114fef8ad3306e0531f411bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not in JSON. No leading zeros. The only integer that start= s with a zero is zero.

(unless json.org has it wrong).

On Tue, May 3, 2016 at 2:10 PM, John Cowan <= cowan@mercury.ccil.org> wrote:
Erik Wilde scripsit:

> 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?
Of course it would be permissible.=C2=A0 42 is 00000000042 is 42.000= 00.

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

I agree that this has to be done, but I think that JSON is simple en= ough
that the mapping is self-evident.

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.o= rg
It's the old, old story.=C2=A0 Droid meets droid.=C2=A0 Droid be= comes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.=C2=A0 It's a classic tale.=C2=A0 --Kryten, Red Dwarf

--001a114fef8ad3306e0531f411bf-- From nobody Tue May 3 12:09:15 2016 Return-Path: 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 9509712D0C0 for ; Tue, 3 May 2016 12:09:13 -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 u50B8NjbVlxD for ; Tue, 3 May 2016 12:09:12 -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 454F312D0C3 for ; Tue, 3 May 2016 12:09:12 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axfgy-0002dn-B3; Tue, 03 May 2016 15:09:08 -0400 Date: Tue, 3 May 2016 15:09:08 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160503190908.GA6756@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:09:13 -0000 Phillip Hallam-Baker scripsit: > I think syntactic sugar does actually matter. That is I see a big > difference between something like > > int MyField; > > and something like this > > {"MyField" : { "type" : "Integer", "max" : 42, "min" : -32 } } I agree, but {"MyField": -254} (under a convention by which negative numbers express signed values, if you need to distinguish signed from unsigned) is not too bad. > I think the chances of spotting a blooper in the second is a lot better. The first, I suppose you mean. > The reason for having the 'label before declaration' rule is that it > provides consistency. Every definition has the label first. C has a nasty > habit of doing this differently for classes and fields/variables. Doing it > the same way throughout is much cleaner. The label should go first because > it is always one token while the definition may be a structure. Every language not heavily under the thumb of C has always used name before type. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org We want more school houses and less jails; more books and less arsenals; more learning and less vice; more constant work and less crime; more leisure and less greed; more justice and less revenge; in fact, more of the opportunities to cultivate our better natures. --Samuel Gompers From nobody Tue May 3 12:10:03 2016 Return-Path: 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 B882512D123 for ; Tue, 3 May 2016 12:10:01 -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 0AF242q5Y0cU for ; Tue, 3 May 2016 12:10:00 -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 56FA112D0C0 for ; Tue, 3 May 2016 12:10:00 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axfhl-0002fu-Ms; Tue, 03 May 2016 15:09:57 -0400 Date: Tue, 3 May 2016 15:09:57 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160503190957.GB6756@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:10:02 -0000 Phillip Hallam-Baker scripsit: > 2) Does the parsed JSON data contain all the necessary data fields required > for the message? > 3) Are the fields of the correct type? These points are just the kind of validation I am talking about. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org He made the Legislature meet at one-horse tank-towns out in the alfalfa belt, so that hardly nobody could get there and most of the leaders would stay home and let him go to work and do things as he pleased. --H.L. Mencken's translation of the Declaration of Independence From nobody Tue May 3 12:35:01 2016 Return-Path: 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 0970412D5C0 for ; Tue, 3 May 2016 12:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lpUr6OTNGnBw for ; Tue, 3 May 2016 12:34:59 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 23D8312D5D6 for ; Tue, 3 May 2016 12:34:59 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id f92so13244118qgf.0 for ; Tue, 03 May 2016 12:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Gj3KLStlRu0KFJo8+zR7g2NI9cHTR+u31fW7YVg4WUk=; b=rNUZ2UPvBVZTR3RxT4teYiWJkOA//BauA+lcwdpZu1QcZWGVDW5WbpB5SjXeIoqFvG KptNu8bQeHK8c6nvG8q9JCB4V9HbTupMQzBCRSbF3q2Qo1/R/xVLtBuGBmmF+fikAgdt AIoQYZJb+HORPxAEM6ndLHOEdzByrQ6Wh4dFLsV2lnXWk2hcA9/iBjDU5DrT1ME0eyzP n5E0jIbMLHkQDUhXkftuT653J/N7XQ0ruUJY2Ktk1U6v+a5CQte8ahAhmTZD5+YgSkFN 35+WWvn8ldIhPOMYjf7yZkvNq1fUmhi5UqEYMa4AqCB34hsKusAOxchsfmpVy1Am8z7w LTdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Gj3KLStlRu0KFJo8+zR7g2NI9cHTR+u31fW7YVg4WUk=; b=l2lp6IVigipswngaKD8kEaB4ZvjajO/pI3W4jTyH+doPPEOrqoRHNYjBGPlqqQDQrF ABcJXXtgjDzwjxkVj7lGecLfnS+8S4t0p2raiiS78Eqbsw5ewV65Fog2MQ931lZ5mdV/ 7gpdO8xt02uYU7cq7zREEaYD7VEpb3J0+tk+2AumlHFRHXXkqxHo0P8gpU/jIVooCk2x wPh6jaVHKNF15vd8cw+4Nipbbl1jGJNz2IWksYKnvzbEbz+P9Rp+yFj9ALNeeolZFONq qqx0epu++EmgK2jo9kipze4o7RIoIIhcpWZx6V1XUgnYE4WjNy/0Rgim+/yUtp9Hxb2q YoHQ== X-Gm-Message-State: AOPr4FWZmpf4zeuNnDjctu35NjmEVdQWQIxpdY0g6DpcKZKpbV5CjlJcVCT3LZETSf+ht6ia5rqBAwQjevcv5Q== MIME-Version: 1.0 X-Received: by 10.141.44.135 with SMTP id v129mr4899044qhe.46.1462304098187; Tue, 03 May 2016 12:34:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 12:34:57 -0700 (PDT) In-Reply-To: <20160503190957.GB6756@mercury.ccil.org> References: <20160503190957.GB6756@mercury.ccil.org> Date: Tue, 3 May 2016 15:34:57 -0400 X-Google-Sender-Auth: eUjYcb-M_dQrYgL_m9Xschp25zw Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=94eb2c0bdc24537f3a0531f534be Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:35:01 -0000 --94eb2c0bdc24537f3a0531f534be Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 3:09 PM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > 2) Does the parsed JSON data contain all the necessary data fields > required > > for the message? > > 3) Are the fields of the correct type? > > These points are just the kind of validation I am talking about. > > Agreed. What we do not need is the type of validation XSD gives us: 1) Order in which the elements appear. 2) alternatives 3) model groups 4) the bizaro dual type system in which elments type data and types type elements. 5) Distinguishing attributes and elements 6) etc. --94eb2c0bdc24537f3a0531f534be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 3, 2016 at 3:09 PM, John Cowan <cowan@mercury.ccil.or= g> wrote:
Phillip Hallam-Ba= ker scripsit:

> 2) Does the parsed JSON data contain all the necessary data fields req= uired
> for the message?
> 3) Are the fields of the correct type?

These points are just the kind of validation I am talking about.
=
Agreed. What we do not need is the type of validation= XSD gives us:

1) Order in which the elements appe= ar.
2) alternatives
3) model groups
4) the bi= zaro dual type system in which elments type data and types type elements.
5) Distinguishing attributes and elements
6) etc.=C2=A0<= /div>

--94eb2c0bdc24537f3a0531f534be-- From nobody Tue May 3 12:50:43 2016 Return-Path: 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 6C9C912D0DC for ; Tue, 3 May 2016 12:50:42 -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 Bfr1V6LDNLAp for ; Tue, 3 May 2016 12:50:41 -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 182E412B03A for ; Tue, 3 May 2016 12:50:41 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axgL7-0005E9-9B; Tue, 03 May 2016 15:50:37 -0400 Date: Tue, 3 May 2016 15:50:37 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160503195037.GC6756@mercury.ccil.org> References: <20160503190957.GB6756@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:50:42 -0000 Phillip Hallam-Baker scripsit: > 1) Order in which the elements appear. My understanding is that people do use JSON arrays this way: the first element means X, the second means Y. If arrays are always or almost always used in a uniform way, then we don't have to worry about order, just specify a single type type for all the individual elements. > 2) alternatives No cases of number-or-string, or object-or-null? > 3) model groups > 4) the bizaro dual type system in which elments type data and types type > elements. > 5) Distinguishing attributes and elements Agreed on those. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "But I am the real Strider, fortunately," he said, looking down at them with his face softened by a sudden smile. "I am Aragorn son of Arathorn, and if by life or death I can save you, I will." From nobody Tue May 3 13:03:14 2016 Return-Path: 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 63DCF12D838 for ; Tue, 3 May 2016 13:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZCdY64KWMiRJ for ; Tue, 3 May 2016 13:03:10 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 4DA8912B03A for ; Tue, 3 May 2016 13:03:10 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 90so13589555qgz.1 for ; Tue, 03 May 2016 13:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dtv9kd8ku5/4sEOaeQpd4kq/65II17m0j4nHxhPZ0aA=; b=SyMFUaZ1aBaP1n70V2DXE2FTRyMXjBPc4tmPKZD2lNvhju/opU0yI4PKmMgYNBJ4zB DcIfbnwJIThtjVqlPltOH+GjEZOs4a0wZaem3OR07i91FOvybMbST5YlAPOeqQsBK7ov Qru8d7PvCmWfZJL9DV8uLfv2hbuNRxFeWj36PbihBk/89Mz+zTBZx6AHVAyZ+7TI6eBQ yFahLRBevA8s8wnJch5IknM/FbTNF29C9edbdeRoFo+/bcgiQLzly8M8vBKz7PWQ3Aoj U7Wo+6tDn/8nwP+iPugWAwC8hqlhFG7l65dSOESSXXv6iCS4Ypn+DpR43HGYdG08aHjD CoXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dtv9kd8ku5/4sEOaeQpd4kq/65II17m0j4nHxhPZ0aA=; b=L/Txy+eVUbefJmK+fsJo4wizDveh0AJ1q88KRc3eUYBGdNXvIfD/dyReIPTa93e1Xk TQLmkGYMGxxNwMsabJirMN0pgfw+yX27CKbxnvko0md9PrQLDMojMBJf4ph81KY9iU1E 0LzfngwvxcqyAIzaAkU3pO8JdY33ED4V7D80MpIChPxbO6dzizx7kYBkUtSJq7YsHB4J Z0tU0c5wFS1Zs7Xf+HSGYNV7NYG8tWqjiWOj/Ppah1C7qCAk6hp9I5KzC1+J+EJ+GuT1 zXDzX4PLsbMNMOh0cebliEDSy9GGHYaSWPVDqYOYk/HcAxkhPU2Tve8eHX+Fnt7vgvjO QPDA== X-Gm-Message-State: AOPr4FV875F/b64XWBlTy7VsT6e5oEE5yIE648nSf9OgGQuyGwV9oWrMKpGp3rIBERAfZhCy5CVV+GtV4SMafA== MIME-Version: 1.0 X-Received: by 10.140.18.114 with SMTP id 105mr4678485qge.41.1462305782107; Tue, 03 May 2016 13:03:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 13:03:00 -0700 (PDT) In-Reply-To: <20160503195037.GC6756@mercury.ccil.org> References: <20160503190957.GB6756@mercury.ccil.org> <20160503195037.GC6756@mercury.ccil.org> Date: Tue, 3 May 2016 16:03:00 -0400 X-Google-Sender-Auth: dZ48tbUKRIbfKWJ9YWkyHF1STbw Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c03f7ebb793c0531f598b9 Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:03:13 -0000 --001a11c03f7ebb793c0531f598b9 Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 3:50 PM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > 1) Order in which the elements appear. > > My understanding is that people do use JSON arrays this way: the first > element means X, the second means Y. If arrays are always or almost > always used in a uniform way, then we don't have to worry about order, > just specify a single type type for all the individual elements. > > > 2) alternatives > > No cases of number-or-string, or object-or-null? > I don't allow number or string or see the need. For all fields I allow the following Minimum Occurrences = 0 or 1 Maximum Occurrences = 1 or unlimited. Null is only allowed if the Minimum Occurrences is 0. If Max is unlimited then the field maps to a list rather than a simple variable and the corresponding serialization is an array. That is possibly too strict as right now going from max occurs 1 to unlimited breaks backwards compatibility as the serialization changes from item to array[item]. I could probably be loser there. There might be an argument to be made for any 'Any' field type which can contain anything. I don't support that right now. But I might have to rejigger my parser if I am supporting ACME and they don't go to the nested approach. ACME has the following type system, lets say you are sending a Delete request, an acceptable message serialization would be: { "field1" : "data", "field2" : "data", "field3" : "data", "type" : "Delete", "field4" : "data", "field5" : "data"} The only way this can be supported is to parse the entire JSON tree to an intermediate format and then perform schema processing on the tree. Which is fine if that is the way you want to do things and you are not writing a transaction where field1 might be several Gb and so you want to check if you understand the transaction before accepting the data or otherwise concerned about being practical. If I have to support the above, I will probably do so by pre-parsing the tree and so it would be fairly straight forward to support a variant type. But there would have to be a good reason because it is going to have to be mapped to a C / C# / Java type sometime. > > > 3) model groups > > 4) the bizaro dual type system in which elments type data and types type > > elements. > > 5) Distinguishing attributes and elements > > Agreed on those. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > "But I am the real Strider, fortunately," he said, looking down at them > with his face softened by a sudden smile. "I am Aragorn son of Arathorn, > and if by life or death I can save you, I will." > --001a11c03f7ebb793c0531f598b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 3, 2016 at 3:50 PM, John Cowan <cowan@mercury.ccil.or= g> wrote:
Phillip Hallam-Baker scripsit:<= br>
> 1) Order in which the elements appear.

My understanding is that people do use JSON arrays this way: the fir= st
element means X, the second means Y.=C2=A0 If arrays are always or almost always used in a uniform way, then we don't have to worry about order,<= br> just specify a single type type for all the individual elements.

> 2) alternatives

No cases of number-or-string, or object-or-null?

<= /div>
I don't allow number or string or see the need.
For all fields I allow the following

M= inimum Occurrences =3D 0 or 1
Maximum Occurrences =3D 1 or unlimi= ted.

Null is only allowed if the Minimum Occurrenc= es is 0. If Max is unlimited then the field maps to a list rather than a si= mple variable and the corresponding serialization is an array.
That is possibly too strict as right now going from max occurs= 1 to unlimited breaks backwards compatibility as the serialization changes= from item to array[item]. I could probably be loser there.

<= /div>

There might be an argument to be made for any '= ;Any' field type which can contain anything. I don't support that r= ight now. But I might have to rejigger my parser if I am supporting ACME an= d they don't go to the nested approach.

ACME h= as the following type system, lets say you are sending a Delete request, an= acceptable message serialization would be:

{ &quo= t;field1" : "data",
=C2=A0"field2" : &qu= ot;data",
=C2=A0"field3" : "data",
=C2=A0"type" : "Delete",
=C2=A0&= quot;field4" : "data",
=C2=A0"field5"= ; : "data"}

The only way this can be= supported is to parse the entire JSON tree to an intermediate format and t= hen perform schema processing on the tree. Which is fine if that is the way= you want to do things and you are not writing a transaction where field1 m= ight be several Gb and so you want to check if you understand the transacti= on before accepting the data or otherwise concerned about being practical.<= /div>


If I have to support the above, I w= ill probably do so by pre-parsing the tree and so it would be fairly straig= ht forward to support a variant type.

But there wo= uld have to be a good reason because it is going to have to be mapped to a = C / C# / Java type sometime.

=C2=A0

> 3) model groups
> 4) the bizaro dual type system in which elments type data and types ty= pe
> elements.
> 5) Distinguishing attributes and elements

Agreed on those.

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.o= rg
"But I am the real Strider, fortunately," he said, looking= down at them
with his face softened by a sudden smile.=C2=A0 "I am Aragorn son of A= rathorn,
and if by life or death I can save you, I will."

--001a11c03f7ebb793c0531f598b9-- From nobody Tue May 3 13:14:49 2016 Return-Path: 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 7C22712D87A for ; Tue, 3 May 2016 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 MH1kxvjjjqpy for ; Tue, 3 May 2016 13:14:44 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E48D12D87D for ; Tue, 3 May 2016 13:14:43 -0700 (PDT) Received: (qmail 30993 invoked from network); 3 May 2016 21:10:04 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 3 May 2016 21:10:03 +0100 To: Phillip Hallam-Baker , John Cowan References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> From: Peter Cordell Message-ID: Date: Tue, 3 May 2016 21:14:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:14:47 -0000 On 03/05/2016 19:12, Phillip Hallam-Baker wrote: > On Tue, May 3, 2016 at 1:25 PM, John Cowan > wrote: > 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. > > > ... > > I think syntactic sugar does actually matter. That is I see a big > difference between something like > > int MyField; > > and something like this > > {"MyField" : { "type" : "Integer", "max" : 42, "min" : -32 } } > > I think the chances of spotting a blooper in the second is a lot better. > JCR allows: { "MyField" : -32..42 } That's easy and very clear IMO. While I agree that such constraints are rare, there is a big difference between "rare" and "never". Parsing the above is no biggy and if it conveys important information to a developer I'd gladly pay the price for a slightly more complex bit of parsing code than having to do something like: int MyField; // Really it's restricted to -32 to 42 I think HTTP (and similar) response codes are effectively 100..999 for example. Currently for numbers JCR just has integer and float. I don't think there would be any resistance to adding types such as int8, uint8, int16, uint16, int32, uint32, int64, uint64, int128, uint128, bigint, float, double and decimal (or similar names). Tedious to document, but if it makes a user's life easier to express what they want that's the correct balance IMO. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 3 13:34:47 2016 Return-Path: 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 843F612D631 for ; Tue, 3 May 2016 13:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 OSzbwiZtGXzt for ; Tue, 3 May 2016 13:34:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D4C12D620 for ; Tue, 3 May 2016 13:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=892; q=dns/txt; s=iport; t=1462307682; x=1463517282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bmtPgf4FX3mbVdgcSO1Xf8AX6+ujO1Zksc/QyOjC1f8=; b=S+AkI+YOFV6VYgyXIoBlMbJxlSaR/zUhYxY+dkTT45tosqP/y0m0dbY8 p4Kc9jeDqH4/UqxBEMYD96cFvbpqJn2Tm4kMV/S7V5vO1xLYGAA7ffFXp +Syye1EoXbOWgKyorcYWbDb48g512FEfKerJ+FiLaK/rbQvGAwTZZz3HN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgANCylX/40NJK1egziBUAa6GwENg?= =?us-ascii?q?XWGEAIcgSY4FAEBAQEBAQFlJ4RCAQEEDhURMRQQAgEIDgwCJgICAjAVEAIEAQ0?= =?us-ascii?q?FGYgRrAOQbwEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSSBdoJXhD+DACuCLgEEm?= =?us-ascii?q?BYBjheBUo1AjzEBHgEBQoNrbIc9fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,574,1454976000"; d="scan'208";a="269151628" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 20:34:42 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u43KYfr1018318 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 20:34:41 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 16:34:40 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 3 May 2016 16:34:40 -0400 From: "Joe Hildebrand (jhildebr)" To: Peter Cordell , Phillip Hallam-Baker , John Cowan Thread-Topic: [Json] Schemas & so on Thread-Index: AQHRo/U855UvMn19j0KO3qh2throzZ+mm2cAgAAOTYCAAQ5YgIAABLUAgAAM/YCAACI+AP//oQEA Date: Tue, 3 May 2016 20:34:40 +0000 Message-ID: References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:34:45 -0000 T24gNS8zLzE2LCAyOjE0IFBNLCAianNvbiBvbiBiZWhhbGYgb2YgUGV0ZXIgQ29yZGVsbCIgPGpz b24tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcGV0ZWpzb25AY29kYWxvZ2ljLmNvbT4g d3JvdGU6DQoNCg0KDQo+Q3VycmVudGx5IGZvciBudW1iZXJzIEpDUiBqdXN0IGhhcyBpbnRlZ2Vy IGFuZCBmbG9hdC4gIEkgZG9uJ3QgdGhpbmsgDQo+dGhlcmUgd291bGQgYmUgYW55IHJlc2lzdGFu Y2UgdG8gYWRkaW5nIHR5cGVzIHN1Y2ggYXMgaW50OCwgdWludDgsIA0KPmludDE2LCB1aW50MTYs IGludDMyLCB1aW50MzIsIGludDY0LCB1aW50NjQsIGludDEyOCwgdWludDEyOCwgYmlnaW50LCAN Cj5mbG9hdCwgZG91YmxlIGFuZCBkZWNpbWFsIChvciBzaW1pbGFyIG5hbWVzKS4gIFRlZGlvdXMg dG8gZG9jdW1lbnQsIGJ1dCANCj5pZiBpdCBtYWtlcyBhIHVzZXIncyBsaWZlIGVhc2llciB0byBl eHByZXNzIHdoYXQgdGhleSB3YW50IHRoYXQncyB0aGUgDQo+Y29ycmVjdCBiYWxhbmNlIElNTy4N Cg0KTm90ZTogaW50NTMgYW5kIHVpbnQ1MyBhcmUgcHJvYmFibHkgbW9yZSBpbXBvcnRhbnQgdGhh biA2NCBhbmQgMTI4LCB3aGljaCB3aWxsIG5lZWQgc3BlY2lhbCBlbmNvZGluZyBhbnl3YXkuDQoN Ci0tIA0KSm9lIEhpbGRlYnJhbmQNCg== From nobody Tue May 3 13:44:16 2016 Return-Path: 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 9846312D8AC for ; Tue, 3 May 2016 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kKyN8JzU7iSc for ; Tue, 3 May 2016 13:44:12 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 4FAE412D896 for ; Tue, 3 May 2016 13:44:10 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id f92so14121200qgf.0 for ; Tue, 03 May 2016 13:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9HcRmkTmV/vrylXFWdCH69RYzZ1WWr3yvg+Nrea7Xiw=; b=HtJuE48Qtbdohe4R4C7qJmpsnKXauRkQmfge+24HljgDUjDW5F62i2q67dLYxIL0qQ RDYSvT9TFtxo4JL8zDnsrY1pKLpUVnRHaGG9ucwmvkL61c5sKGDUpfXuMvx7XoSEVr/Z +LUIvjqj1EEc6MJnxdy4e0Sf5pufJ6oGDYSt++4qkupJRQaDaCT/HV0hrUjZbhf84y0m m6opxsfg6XEx9V+IeYfYBonCC18Sx5aPEh0rL0g9KmzcUF614muhqHh6/MSQuC58TipO f65G6J+qea6oEmGPN+t6ZJTtTX0OYo976xOitLak0U8WIOOUyK3z6LT72vrSv1G2m74S JGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9HcRmkTmV/vrylXFWdCH69RYzZ1WWr3yvg+Nrea7Xiw=; b=e/VBPcYvYLLt8SarJCpu/u3ePdXtrbU/EUzBLVVL2jDVj9I0B68orpRM2RmY3J46fR P9WfhYQ4kJcEJt2W7k4Ru+DQgZYYcAtu8eZx9r8nlGlLi/U8d94rYR2ouHjliVJAKtrJ Vul55aGooI0sy3oVT3mH9AjDgtirXEzw3GHaBt346R9ML+BRcQCAYHJ87ide1F6/aj1c fjmfehFkz7hVYYbcevw+8zAEfijNz05l+BQdfE4wTlC6HijpSW/mwWTB/D0X21FdrOcn T9IPWVFBHkM88eT4DWKHR23RXIlyCzA7fgf0Xggupi1Hx6Rj4MSIepCMxRZafPX6MSt3 W4Lg== X-Gm-Message-State: AOPr4FXdniUY7EID8ot61kcd6EmQ/XGS8i9BvD3BWmckjf9i4i2UQdPoXwSOD+jO+rVdMRqkSlIXvngtPwZPTA== MIME-Version: 1.0 X-Received: by 10.140.84.145 with SMTP id l17mr4846446qgd.12.1462308249480; Tue, 03 May 2016 13:44:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Tue, 3 May 2016 13:44:09 -0700 (PDT) In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> Date: Tue, 3 May 2016 16:44:09 -0400 X-Google-Sender-Auth: 9ZCGppEfXEmOs5GAlZp5Lv8CD5w Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a11c14d10c34e4f0531f62b1d Archived-At: Cc: Tim Bray , John Cowan , Peter Cordell , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:44:15 -0000 --001a11c14d10c34e4f0531f62b1d Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 4:34 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 5/3/16, 2:14 PM, "json on behalf of Peter Cordell" < > json-bounces@ietf.org on behalf of petejson@codalogic.com> wrote: > > > > >Currently for numbers JCR just has integer and float. I don't think > >there would be any resistance to adding types such as int8, uint8, > >int16, uint16, int32, uint32, int64, uint64, int128, uint128, bigint, > >float, double and decimal (or similar names). Tedious to document, but > >if it makes a user's life easier to express what they want that's the > >correct balance IMO. > > Note: int53 and uint53 are probably more important than 64 and 128, which > will need special encoding anyway. > Why? JSON does not specify limits on integer sizes. 128 would require special handling but I do INT64s all the time. --001a11c14d10c34e4f0531f62b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 3, 2016 at 4:34 PM, Joe Hildebrand (jhildebr) <jhildebr@c= isco.com> wrote:
On 5/3/16, 2:14 PM, "json on behalf of Peter Cordell" &l= t;json-bounces@ietf.org on beh= alf of petejson@codalogic.com= > wrote:



>Currently for numbers JCR just has integer and float.=C2=A0 I don't= think
>there would be any resistance to adding types such as int8, uint8,
>int16, uint16, int32, uint32, int64, uint64, int128, uint128, bigint, >float, double and decimal (or similar names).=C2=A0 Tedious to document= , but
>if it makes a user's life easier to express what they want that'= ;s the
>correct balance IMO.

Note: int53 and uint53 are probably more important than 64 and 128, = which will need special encoding anyway.

Why?

JSON does not specify limits on integer siz= es. 128 would require special handling but I do INT64s all the time.
<= div>
=C2=A0
--001a11c14d10c34e4f0531f62b1d-- From nobody Tue May 3 14:03:38 2016 Return-Path: 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 83D0612D8EA for ; Tue, 3 May 2016 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 zyyyAZy--2S9 for ; Tue, 3 May 2016 14:03:35 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC83712D8E9 for ; Tue, 3 May 2016 14:03:34 -0700 (PDT) Received: (qmail 32756 invoked from network); 3 May 2016 21:58:55 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 3 May 2016 21:58:55 +0100 To: "Joe Hildebrand (jhildebr)" , Phillip Hallam-Baker , John Cowan References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> From: Peter Cordell Message-ID: <8d5d2daf-7b69-5f07-1440-33fba9d92ae3@codalogic.com> Date: Tue, 3 May 2016 22:03:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:03:36 -0000 On 03/05/2016 21:34, Joe Hildebrand (jhildebr) wrote: > On 5/3/16, 2:14 PM, "json on behalf of Peter Cordell" wrote: > > > >> Currently for numbers JCR just has integer and float. I don't think >> there would be any resistance to adding types such as int8, uint8, >> int16, uint16, int32, uint32, int64, uint64, int128, uint128, bigint, >> float, double and decimal (or similar names). Tedious to document, but >> if it makes a user's life easier to express what they want that's the >> correct balance IMO. > > Note: int53 and uint53 are probably more important than 64 and 128, which will need special encoding anyway. Thanks. I hadn't heard about Int53, so that's great feedback. Uncertainty and wanting community feedback about which values to include (are 128 bit values useful?) and what to call them (should they by byte, short, int, long for example) is the main reason why we haven't included such types already. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 3 14:24:56 2016 Return-Path: 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 0540E12D92A for ; Tue, 3 May 2016 14:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bTdnxws1_tC4 for ; Tue, 3 May 2016 14:24:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EFB12D92C for ; Tue, 3 May 2016 14:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1024; q=dns/txt; s=iport; t=1462310690; x=1463520290; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=g2qjyqY+s9/x8C0wGF9Oj/MFO51kVM02DHeL6VAhI/8=; b=YmUgUk3FKoAPEC4sKiEmKJLA/uP0H+DW3cQSJ8EE1l9JBtCv8sAXb//F JAy3knfLri/7gFQi8SHcJFVMMedMvQG/xrLCZkamx+xOYaKkrtyCBwOD8 7UecECLZdQ1FB8X1IafmjiSX7r4FT0D+civh/vzGwZC9QMKH1ENqpdlwG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgAXFilX/40NJK1egziBUAauOYtiA?= =?us-ascii?q?Q2BdYJegzICHIEoOBQBAQEBAQEBZSeEQgEBBCMRRRACAQgaAiYCAgIfERUQAgQ?= =?us-ascii?q?OBYgVAxKraIwdDYQ7AQEBAQEBAQEBAQEBAQEBAQEBAQEWfIUkgXaCV4JDgXyDA?= =?us-ascii?q?CuCLgEEl2UxAYwggXePEodRh2ABHgEBQoNrbIc9fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,574,1454976000"; d="scan'208";a="100498755" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 21:24:49 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u43LOnEu023710 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 21:24:49 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 17:24:48 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 3 May 2016 17:24:48 -0400 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker Thread-Topic: [Json] Schemas & so on Thread-Index: AQHRo/U855UvMn19j0KO3qh2throzZ+mm2cAgAAOTYCAAQ5YgIAABLUAgAAM/YCAACI+AP//oQEAgABnO4D//6bFgA== Date: Tue, 3 May 2016 21:24:48 +0000 Message-ID: <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.19] Content-Type: text/plain; charset="utf-8" Content-ID: <7A3372DEE11E0A4A8C031C4646C0B9E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , John Cowan , Peter Cordell , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:24:56 -0000 T24gNS8zLzE2LCAyOjQ0IFBNLCAiaGFsbGFtQGdtYWlsLmNvbSBvbiBiZWhhbGYgb2YgUGhpbGxp cCBIYWxsYW0tQmFrZXIiIDxoYWxsYW1AZ21haWwuY29tIG9uIGJlaGFsZiBvZiBpZXRmQGhhbGxh bWJha2VyLmNvbT4gd3JvdGU6DQoNCg0KDQo+SlNPTiBkb2VzIG5vdCBzcGVjaWZ5IGxpbWl0cyBv biBpbnRlZ2VyIHNpemVzLiAxMjggd291bGQgcmVxdWlyZSBzcGVjaWFsIGhhbmRsaW5nIGJ1dCBJ IGRvIElOVDY0cyBhbGwgdGhlIHRpbWUuDQoNCllvdSBuZWVkIHRvIHRlc3QgaW50ZWdlcnMgbGFy Z2VyIHRoYW4gMl41MyB3aXRoIHRoZSBKU09OIGltcGxlbWVudGF0aW9uIGluIEVDTUFzY3JpcHQg dGhlbi4gIFJGQyA3MTU5LCBzZWN0aW9uIDYgc2F5cyANCg0KIiIiDQpOb3RlIHRoYXQgd2hlbiBz dWNoIHNvZnR3YXJlIGlzIHVzZWQsIG51bWJlcnMgdGhhdCBhcmUgaW50ZWdlcnMgYW5kDQogICBh cmUgaW4gdGhlIHJhbmdlIFstKDIqKjUzKSsxLCAoMioqNTMpLTFdIGFyZSBpbnRlcm9wZXJhYmxl IGluIHRoZQ0KICAgc2Vuc2UgdGhhdCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBhZ3JlZSBleGFjdGx5 IG9uIHRoZWlyIG51bWVyaWMNCiAgIHZhbHVlcy4NCiIiIg0KDQpJbiBwYXJ0aWN1bGFyLCBFQ01B c2NyaXB0IHdpbGwgY29ycnVwdCB5b3VyIGludGVnZXJzIHNpbGVudGx5LCB1bmxlc3MgdGhleSBh cmUgZW5jb2RlZCBhcyAoZm9yIGV4YW1wbGUpIHN0cmluZ3MuIA0KDQotLSANCkpvZSBIaWxkZWJy YW5kDQo= From nobody Tue May 3 14:45:37 2016 Return-Path: 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 94BAA12D62D for ; Tue, 3 May 2016 14:45:35 -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 1Oj_7WOxti4o for ; Tue, 3 May 2016 14:45:34 -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 9145E12D19F for ; Tue, 3 May 2016 14:45:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axi8H-0005YC-3m; Tue, 03 May 2016 17:45:29 -0400 Date: Tue, 3 May 2016 17:45:29 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20160503214528.GF6756@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Phillip Hallam-Baker , Tim Bray , Peter Cordell , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:45:36 -0000 Joe Hildebrand (jhildebr) scripsit: > You need to test integers larger than 2^53 with the JSON implementation > in ECMAscript then. RFC 7159, section 6 says Indeed, and browsers are surely not the only JSON implementations to treat all numbers as IEEE 64-bit binary floats. If we are going to have a type for integers representable as floats, then it should be called int54 according to the usual conventions, with the caveat that -(2**53) cannot be represented, because floats are not two's-complement. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org On the Semantic Web, it's too hard to prove you're not a dog. --Bill de hOra From nobody Wed May 4 03:43:32 2016 Return-Path: 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 4E5AE12D193 for ; Wed, 4 May 2016 03:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 HSyHSiW9OGOP for ; Wed, 4 May 2016 03:43:29 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C750212D18E for ; Wed, 4 May 2016 03:43:28 -0700 (PDT) Received: (qmail 9994 invoked from network); 4 May 2016 11:38:48 +0100 Received: from host31-54-178-133.range31-54.btcentralplus.com (HELO ?192.168.1.72?) (31.54.178.133) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 4 May 2016 11:38:48 +0100 To: John Cowan , "Joe Hildebrand (jhildebr)" References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> <20160503214528.GF6756@mercury.ccil.org> From: Peter Cordell Message-ID: <61b459a9-c77a-c8e2-d22d-d89e91ed9ad3@codalogic.com> Date: Wed, 4 May 2016 11:43:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160503214528.GF6756@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Schemas & so on - int54 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:43:31 -0000 On 03/05/2016 22:45, John Cowan wrote: > > If we are going to have a type for integers representable as floats, > then it should be called int54 according to the usual conventions, > with the caveat that -(2**53) cannot be represented, because floats > are not two's-complement. If your protocol needed an unsigned value bigger than 32 bits, but not as big as 64-bits, to mirror int54, would it be appropriate to define a uint53 type (i.e. the unsigned version of int(N) stored in a floating point value is uint(N-1))? Or would you do something else? Thanks, Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Wed May 4 05:48:33 2016 Return-Path: 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 D698912D1D1 for ; Wed, 4 May 2016 05:48:31 -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 PI2k1dqVRvhE for ; Wed, 4 May 2016 05:48:30 -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 3ACDF12B03D for ; Wed, 4 May 2016 05:48:30 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axvxB-0000UR-2d; Wed, 04 May 2016 08:31:12 -0400 Date: Wed, 4 May 2016 08:30:56 -0400 From: John Cowan To: Peter Cordell Message-ID: <20160504123054.GC22066@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> <20160503214528.GF6756@mercury.ccil.org> <61b459a9-c77a-c8e2-d22d-d89e91ed9ad3@codalogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61b459a9-c77a-c8e2-d22d-d89e91ed9ad3@codalogic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Schemas & so on - int54 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:48:32 -0000 Peter Cordell scripsit: > If your protocol needed an unsigned value bigger than 32 bits, but > not as big as 64-bits, to mirror int54, would it be appropriate to > define a uint53 type (i.e. the unsigned version of int(N) stored in > a floating point value is uint(N-1))? Or would you do something > else? I suppose so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ From nobody Wed May 4 07:02:46 2016 Return-Path: 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 6D0D712D1EC for ; Wed, 4 May 2016 07:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lg6qGbJcec0k for ; Wed, 4 May 2016 07:02:42 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 8C7C812D1EB for ; Wed, 4 May 2016 07:02:42 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f74so23510206qge.2 for ; Wed, 04 May 2016 07:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=6uqMB1fFDFr4Mz0dnb9KZK/DOWD7M3tbdxf32u7lecY=; b=xrEHH8X+DheiNYmaqW+QsLFSty8t6081Msv1btHbAV5XSEB84IttSVbc7vsolREWvl qXzvjQdlra7WulQoAdPuJ+zCbNNQvFOjeRNG8Q4JZXes7fdpL9rQFpfH98Q+2UMgyp89 /KN9DlhqJ3F7bG+qQfpu3pggZllxTS5nLCfWBaWIfBtgGhvHAJyNWmrtffC6txh/p4Vi HImHtXLNBko4ta9AGBbdYEBzQ/AqTLofoVS+/94x2wYQ9Liifz+g5H/tfm9mPMhpvFrV BYyV4mS1HZ7LvXLIJmktJjrcmUAlJsmKTG8TVfCh7w9Q9JHQdbzEPe1aopd006xVZQIZ h70w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6uqMB1fFDFr4Mz0dnb9KZK/DOWD7M3tbdxf32u7lecY=; b=GjPL76XitSPh47d7/CBHoFrOrojNvmQQQ4HV7PraPkxa/wJGrXi6K6ITnGoAUVai5f hGARNu52rmGojsj8hT1BW5kXma1aLgUnWmH2cR2k9JYpZIWRYtYaWszurzh/ZNbuk84P hBi1Vhg1XSmFvg/NwYyY387JqUqj0i0ETAoFg6UEAYhW8Miv9o80uBJlfb+Ya2rkHzcr h/5OEkBxgelKtkpwGrvtLe/kyvm5WnFfJaLu/yQKSncHua7/kkHjlW2Lv1PY/+TfcR8O eSVydEhmqxNZ+yd8AGpft7CklAFSrOvzrFGcI7SykE/P3XhMnNVsTxxtXwRy/XC0sXda gs0w== X-Gm-Message-State: AOPr4FVqtxQXXBrtOR4GDo2xZDqizPe/uNoHIrT0gE6EI0rkLBdjDKxg+9Vr+8BE6VUOCzFV7L50kabjiibmfQ== MIME-Version: 1.0 X-Received: by 10.141.44.135 with SMTP id v129mr8927965qhe.46.1462370561706; Wed, 04 May 2016 07:02:41 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Wed, 4 May 2016 07:02:41 -0700 (PDT) In-Reply-To: <20160503214528.GF6756@mercury.ccil.org> References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> <20160503214528.GF6756@mercury.ccil.org> Date: Wed, 4 May 2016 10:02:41 -0400 X-Google-Sender-Auth: D-nys0SmhF5rzc7mR9J2n8I1UxY Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=94eb2c0bdc24dc5231053204adf8 Archived-At: Cc: Tim Bray , Peter Cordell , "Joe Hildebrand \(jhildebr\)" , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:02:45 -0000 --94eb2c0bdc24dc5231053204adf8 Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 5:45 PM, John Cowan wrote: > Joe Hildebrand (jhildebr) scripsit: > > > You need to test integers larger than 2^53 with the JSON implementation > > in ECMAscript then. RFC 7159, section 6 says > > Indeed, and browsers are surely not the only JSON implementations to > treat all numbers as IEEE 64-bit binary floats. > > If we are going to have a type for integers representable as floats, > then it should be called int54 according to the usual conventions, > with the caveat that -(2**53) cannot be represented, because floats > are not two's-complement. > I agree. I use -MaxInt as a Not a Number value in my code anyway... Right now however, JSON isn't really suited to use as a data exchange format for scientific use. Which is one of the things I tried to address in JSON-B (Binary) and JSON-D (Data). The JSON has unallocated code points that can be used to useful extend the serialization to add additional encodings. For length delimited strings, binary data etc. CBOR introduced a completely different data model with the result that the JOSE working group had to be followed by a CBOR specific one. Binary encoding of floats is the simplest and most reliable method of ensuring that they round trip. And that is essential if an encoding is going to be viable for data exchange. JSON-B has binary encodings for the IEEE 32 and 64 bit floats for that reason and JSON-D adds in the higher precision Intel formats that use the whole 64 bits for the mantissa. That said, binary encoding means losing the 'text file' property of JSON. If I was going to use JSON for scientific purposes, I might well add in a base16 or base64 encoding for floats. Using the unused code points for extension has the advantage that even though each serialization option requires a different encoder, a single decoder can recognize all four variations (JSON, JSON-B, JSON-C, JSON-D). That simplifies protocol implementation as it is only necessary for a service to say what it will accept, it is not necessary for a client to tag what it actually sends. It also allows encapsulation to work as you would expect. --94eb2c0bdc24dc5231053204adf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 3, 2016 at 5:45 PM, John Cowan <cowan@mercury.ccil.or= g> wrote:
Joe Hildebrand (j= hildebr) scripsit:

> You need to test integers larger than 2^53 with the JSON implementatio= n
> in ECMAscript then.=C2=A0 RFC 7159, section 6 says

Indeed, and browsers are surely not the only JSON implementations to=
treat all numbers as IEEE 64-bit binary floats.

If we are going to have a type for integers representable as floats,
then it should be called int54 according to the usual conventions,
with the caveat that -(2**53) cannot be represented, because floats
are not two's-complement.

I agree. = I use -MaxInt as a Not a Number value in my code anyway...

Right now however, JSON isn't really suited to use as a data e= xchange format for scientific use. Which is one of the things I tried to ad= dress in JSON-B (Binary) and JSON-D (Data).

The JS= ON has unallocated code points that can be used to useful extend the serial= ization to add additional encodings. For length delimited strings, binary d= ata etc. CBOR introduced a completely different data model with the result = that the JOSE working group had to be followed by a CBOR specific one.

Binary encoding of floats is the simplest and most rel= iable method of ensuring that they round trip. And that is essential if an = encoding is going to be viable for data exchange. JSON-B has binary encodin= gs for the IEEE 32 and 64 bit floats for that reason and JSON-D adds in the= higher precision Intel formats that use the whole 64 bits for the mantissa= .

That said, binary encoding means losing the '= ;text file' property of JSON. If I was going to use JSON for scientific= purposes, I might well add in a base16 or base64 encoding for floats.
=C2=A0

Using the unus= ed code points for extension has the advantage that even though each serial= ization option requires a different encoder, a single decoder can recognize= all four variations (JSON, JSON-B, JSON-C, JSON-D). That simplifies protoc= ol implementation as it is only necessary for a service to say what it will= accept, it is not necessary for a client to tag what it actually sends. It= also allows encapsulation to work as you would expect.
--94eb2c0bdc24dc5231053204adf8-- From nobody Wed May 4 07:35:33 2016 Return-Path: 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 C149D12D1E2 for ; Wed, 4 May 2016 07:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QxWezlQu1zTj for ; Wed, 4 May 2016 07:35:30 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 6D33412D0B6 for ; Wed, 4 May 2016 07:29:58 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id x7so25495019qkd.3 for ; Wed, 04 May 2016 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=zxWgYCpr9z3dlT+Agu8qe0ixfrgLKeRWY7Oc/O4sNJk=; b=f9giJx5klis6zlw29kQf4ZW7FGndwVxHFzAQhKQXVFNA3ECOElRjEJIZtIHwOdH466 gGYtDUIJIGTvRV/Owydlat7olbajxgqNXznvxkgRCBcyAh6/BumqvfUSlKzBydMxHdGr JpKdq53Lu39z+lwSp6C63WeAtf9OnWfBInQ9oa8XwJ0tSgCRi/EplnQHbtkf6TErhOgy k2uy4v80IfeashDfu7pHg9arIAeweYOabYdUV/C7tJZZZd2fnuiGH8mOBNBNnnuXG3cL Wf9j+tZqwQuf7BjF7lJBjsYeTfDWl6v6vrkLBmd/2NVfI3w+Lgmg24xmMcdV8baeV/xi 3aOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zxWgYCpr9z3dlT+Agu8qe0ixfrgLKeRWY7Oc/O4sNJk=; b=Cuxv/Jp+lFbxKNrgtN0lwaTfrdNfO+QuTf0wpWGQzIy0e71nicHs/VJNEECkwQNMkp Q6HFg9MWvOvujUUapJYflx4x+Kw0gycg1iYJclqqJc5KAj/7edxNs0lrEMrClLSDf55T hQu1q7btZcVBP+8SQtlZUSNDyBaAKiTGVD248WQBbV4fURWPTDv4r7irT1aMHeN3oOkA ytLKH9Ryq2GxOcTx1BnM/0UXbAoKpFU8Mtit0Csh2iloeIkxeIxCqw7hLelHcO+r4EQo sQYJK5cNlk7G/GqBLthM9LCpjEQe2A2qCpi3kfffb+EgylQDMu2nN/moLaTCDHMUsoL6 W0Ug== X-Gm-Message-State: AOPr4FVBSZ8Tx1Otj8iif+Fyi4kNd49DgvkVLtnMP5SWKmvXsa2gngy3Jat0IEqllMo1LG52rWEb9p1Wg1tGlQ== MIME-Version: 1.0 X-Received: by 10.55.217.9 with SMTP id u9mr8824891qki.27.1462372197502; Wed, 04 May 2016 07:29:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Wed, 4 May 2016 07:29:57 -0700 (PDT) In-Reply-To: References: <20160503010109.GA17482@mercury.ccil.org> <20160503172537.GM29513@mercury.ccil.org> <46FCFC42-3FF1-4CD5-A397-A0553B43AC39@cisco.com> <20160503214528.GF6756@mercury.ccil.org> Date: Wed, 4 May 2016 10:29:57 -0400 X-Google-Sender-Auth: h5Y1WfSAbVElH1IQ3FRJu3y3uxg Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a1149aa685c999a0532050f67 Archived-At: Cc: Tim Bray , Peter Cordell , "Joe Hildebrand \(jhildebr\)" , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:35:32 -0000 --001a1149aa685c999a0532050f67 Content-Type: text/plain; charset=UTF-8 If we did get into extended schema discussions, one of my main issues that I don't see well supported in existing schema systems is support for encryption and signature. These are features that I really would like to be able to have supported in the 'validation' layer. In the Mesh I have nested structures where portions of the inner structure are signed. A user profile contains a set of application profiles, both of which are signed. One side effect is that every profile structure ends up having two flavors - signed and unsigned. And that is messy. So for example, say this is my schema without signatures UserProfile Class Applications List Devices List ApplicationProfile Class ... fields And a JSON encoded object would be: "UserProfile" : { "Applications" : [ {"MailApplicationProfile" : {...} } ] } Since Application Profile is an abstract class, the deserializer needs to know which particular subtype is being decoded. So the instances of the class need to be tagged. Easy enough, right? Well if we add signatures (or encryption) they are in effect just wrappers round a class. But they have the effect of burying that tag I need to decode the object. So I would like to have something like: ApplicationProfile Class "UserProfile" : { "Applications" : [ ["Jose-Header" , $$ {"MailApplicationProfile" : {...} } ] } $$, "Jose-trailer" ] ] ...] } Where $$...$$ is the base 64 signed data blob as a string. Same for encrypted data. This type of approach would let me move all the signature validation parts into code. I would still need to hand code the path math for validation of the signing keys. When rendered in C#, I would get a class like this: class UserProfile : JSON.Object { List Applications; List Devices; } abstract class ApplicationProfile : JSON.SignedObject { ... fields } class MailApplicationProfile : ApplicationProfile { ... } The JSON.SignedObject class would inherit from JSON.Object and provide mechanisms for verifying signatures, etc. Using the array allows the order of the JOSE data items to be forced which helps a lot in writing verification code into the deserializer which is of course essential if you want to do a one pass deserialization on a constrained device. Encryption would be handled in a similar way by JSON.EncryptedObject. --001a1149aa685c999a0532050f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we did get into extended sch= ema discussions, one of my main issues that I don't see well supported = in existing schema systems is support for encryption and signature. These a= re features that I really would like to be able to have supported in the &#= 39;validation' layer.

In the Mesh I have nested structures where portions of = the inner structure are signed. A user profile contains a set of applicatio= n profiles, both of which are signed. One side effect is that every profile= structure ends up having two flavors - signed and unsigned. And that is me= ssy.

S= o for example, say this is my schema without signatures

UserProfile Class
=C2=A0 =C2=A0 Applications =C2=A0 =C2=A0 List <= ApplicationProfile>
=C2=A0 =C2=A0 Device= s =C2=A0 =C2=A0 =C2=A0List <DeviceProfile>

ApplicationProfile Class <Abs= tract>
=C2=A0 =C2=A0 ... fields

And a JSON enc= oded object would be:

"UserProfile" : { "Applications" : [ {= "MailApplicationProfile" : {...} } ] }

Since Application Profile is an = abstract class, the deserializer needs to know which particular subtype is = being decoded. So the instances of the class need to be tagged.


Easy enough, right? Well if we add signatures (or encry= ption) they are in effect just wrappers round a class. But they have the ef= fect of burying that tag I need to decode the object.

So I would like to have som= ething like:

ApplicationProfile Class <Signed Abstract>

"UserProfile&quo= t; : { "Applications" : [=C2=A0
= =C2=A0 =C2=A0 =C2=A0["Jose-Header" , =C2=A0$$ {"MailApplicat= ionProfile" : {...} } ] } $$, "Jose-trailer" ]
=C2=A0 =C2=A0 =C2=A0 ] ...] }

Where $$...$$ is the base 64 sig= ned data blob as a string. Same for encrypted data.


This type of approach would let me move all the signature validatio= n parts into code. I would still need to hand code the path math for valida= tion of the signing keys. When rendered in C#, I would get a class like thi= s:

cla= ss UserProfile : JSON.Object {
=C2=A0 =C2=A0List <ApplicationProfile> Applications;=
=C2=A0 =C2=A0List <DeviceProfile> De= vices;
=C2=A0 =C2=A0}

abstract class Applic= ationProfile : JSON.SignedObject {
=C2=A0 = =C2=A0... fields
=C2=A0 =C2=A0}

class MailApplica= tionProfile : ApplicationProfile {
=C2=A0 = =C2=A0...
=C2=A0 =C2=A0}

The JSON.SignedObject cl= ass would inherit from JSON.Object and provide mechanisms for verifying sig= natures, etc. Using the array allows the order of the JOSE data items to be= forced which helps a lot in writing verification code into the deserialize= r which is of course essential if you want to do a one pass deserialization= on a constrained device.

Encryption would be handled in a similar way by JSON.En= cryptedObject.=C2=A0

--001a1149aa685c999a0532050f67-- From nobody Wed May 4 08:01:07 2016 Return-Path: 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 2E3A012D515 for ; Wed, 4 May 2016 08:01:06 -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 HjgAvGXQOvG7 for ; Wed, 4 May 2016 08:01:04 -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 DB79112D15C for ; Wed, 4 May 2016 08:00:55 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1axyIE-0002k2-Qw; Wed, 04 May 2016 11:00:51 -0400 Date: Wed, 4 May 2016 11:00:50 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160504150050.GG6756@mercury.ccil.org> References: <20160503190957.GB6756@mercury.ccil.org> <20160503195037.GC6756@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:01:06 -0000 Phillip Hallam-Baker scripsit: > I don't allow number or string or see the need. It comes up precisely when you have a bignum and want to send it out as a JSON number if you can, a JSON string if you must. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org First known example of political correctness: After Nurhachi had united all the other Jurchen tribes under the leadership of the Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should be banned, and from then on, they were all to be called Manchus. --S. Robert Ramsey, The Languages of China From nobody Wed May 4 08:11:14 2016 Return-Path: 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 6D53512D71E for ; Wed, 4 May 2016 08:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qxXt4uxgBYAf for ; Wed, 4 May 2016 08:11:06 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 94FEB12D6D7 for ; Wed, 4 May 2016 08:10:05 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f74so24748704qge.2 for ; Wed, 04 May 2016 08:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+HPOIDiX+MySRQKbWvLHmDLUZFH6/2daF8oKZJfMvsI=; b=dirUDHDauceNfCaZnMvieULGpZfVj3oPNesjE9Ix+yECh15utlSSBLAyQ6B9A+QW2J WFncsupXocLoK8jqCQXxRcLXkPco9Xyw6tEMKnQu41Xws+Jh1To3nBc8EiK8N6W9HDcI P/wRn0TxJIDLF8EysI4gBXxPnsQyA6HgU4+l+a0ZkoSYO+oFJg0H13538p5YXE/RNuh7 F1bQPyQeoqrNpF2EdVKJP16GCPnhAsvp7kWZ6TnZBOb49TmKgsrROnGoapvYGIjEtOq/ pSPHa2ynwfpp/5wIX0tNV9lac8IK4Z4DnJs8Kkrrb836WuPrd9Q8F8Zmvn6RTzDtdq1P /nSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+HPOIDiX+MySRQKbWvLHmDLUZFH6/2daF8oKZJfMvsI=; b=iX2Q7TL1azESBh0abkcGzFl6PMIKj62nJtFR8onJ4xC5CETkMQzXKktSrS9KgEvgYe E0BwMriBtpLOUdCKG2BCI/WnltI4UbN4G8j4g2wwADh+dWv9Y5Gg2W3ObNIK8Sa+G++7 lvppIIe9S1K3Rjjgr5UjhPHuzKxZ2ToPf1ClFXAj5HaZ3ryq/IkRaNZRFHq5MXRYuRVq pfh/lAFgcDWcnTFwWnDGXtRVX61cPSxquZV4gQ0nKTynNOqkwJolJ+H4h6RDdpR8V0rI 8gjrFHC45d3KUXwF2XipxzmjglfB2nlM43L48H/HpT+NfzSFmz/K83cOqIWWarYOJP8s Mxbw== X-Gm-Message-State: AOPr4FUqWZdcs67rqyTKrr0B92FuPehnMr/BjWVe/JpeAqzZyj7js4Y8pmSMt42Jnr7IzJL5a+dMBADoULHrLA== MIME-Version: 1.0 X-Received: by 10.140.41.200 with SMTP id z66mr8753659qgz.20.1462374604745; Wed, 04 May 2016 08:10:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Wed, 4 May 2016 08:10:04 -0700 (PDT) In-Reply-To: <20160504150050.GG6756@mercury.ccil.org> References: <20160503190957.GB6756@mercury.ccil.org> <20160503195037.GC6756@mercury.ccil.org> <20160504150050.GG6756@mercury.ccil.org> Date: Wed, 4 May 2016 11:10:04 -0400 X-Google-Sender-Auth: XUgWDFS5P66MTislUuB0G3Mq6ns Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c13b84d83de80532059e19 Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:11:13 -0000 --001a11c13b84d83de80532059e19 Content-Type: text/plain; charset=UTF-8 On Wed, May 4, 2016 at 11:00 AM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > I don't allow number or string or see the need. > > It comes up precisely when you have a bignum and want to send it out > as a JSON number if you can, a JSON string if you must. > As I said before, I would add BigNum to the schema as a separate type, just like binary and DateTime. Could do the same for real32 and real64 of course. What I think we are converging on is the idea of a schema that extends the type system of the data model but not the JSON encoding. --001a11c13b84d83de80532059e19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 4, 2016 at 11:00 AM, John Cowan <cowan@mercury.ccil.org&g= t; wrote:
Phillip Hallam-Baker scr= ipsit:

> I don't allow number or string or see the need.

It comes up precisely when you have a bignum and want to send it out=
as a JSON number if you can, a JSON string if you must.

As I said before, I would add BigNum to the schema as a se= parate type, just like binary and DateTime.

Could = do the same for real32 and real64 of course.


<= /div>
What I think we are converging on is the idea of a schema that ex= tends the type system of the data model but not the JSON encoding.
--001a11c13b84d83de80532059e19-- From nobody Wed May 4 12:59:08 2016 Return-Path: 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 D9E5A12D5D1 for ; Wed, 4 May 2016 12:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E1EU_qBoj444 for ; Wed, 4 May 2016 12:58:59 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 72AF312D52A for ; Wed, 4 May 2016 12:58:55 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 90so29567115qgz.1 for ; Wed, 04 May 2016 12:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=JCXk6Nf+RPHcEV69mwRn/3XxEa12bbyCyiC5SIJPlwQ=; b=kOWuqqxNfgTGj/nhkfY6NIHNKCTRc5cUxs8eLvonZnGf7cZE6Jc49TDJmPnV1hoy6a SvULrRAnoQ9b50oA6jBWncS4W09P7dlkHw/FDcOLb6Rm8ulZ5pyblaOJIpov3sbDHH9I Q2jAhqwd9Kk1bn6Tuv2oKJafg3+CuOhkUIO7OUtOV6mm/s5nLcgn8hJrI7buigTOqUaj 8MBYV0pryHI9qu7XT5d1DcfjCeMCgrRdHRwTrdJbUgomTbm8KC1AW9SZ/Y2Ia/mMRc9s YsPlR8Z+lSby0OYFEuWeOJ9H7t7zbotYd9Czhw41jytH28tkN7j89S8RYvNDShuBPiAk WjKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JCXk6Nf+RPHcEV69mwRn/3XxEa12bbyCyiC5SIJPlwQ=; b=flD1ag0Lyepgd8DtQZNXa9YWGBA8bwdPW0TLyGTgRxFr/kAQUU8BbVivOIY/8B+hIm bidHMiVgbn+vddPWge5YD6nkR2cP02EmixeFgQqJUQuhXZq7iyfwjTVVEXaJxPbi/r3Q TVIwy+53dv4fb68OiK3nHx1qHt2HRRVCcyBEGuoJyD48QL+wUO/6zH18Lp+qqn150U8s wSlyHdXQNJ/5xrU2vJVg9hbbX9we/BQRUcBVKitLf30qSTWdjeVxWPZOtBj1C7ZMUsJ1 j64xEuE2ZBtgCfuCG29kza8NF0g+NSs/46qpZLmJfpUjJwOpt2JwZaotR0mSn+nzosla d3Ww== X-Gm-Message-State: AOPr4FXlIXsAe9+AwJG2fK6tVOPCHpMV6uBgEPm6eUXPyK5WwEhn8weGLTxSjGh28AvkXVN5OigK3MaCu6xBGg== MIME-Version: 1.0 X-Received: by 10.140.84.145 with SMTP id l17mr10328462qgd.12.1462391934550; Wed, 04 May 2016 12:58:54 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.24.38 with HTTP; Wed, 4 May 2016 12:58:54 -0700 (PDT) In-Reply-To: References: <20160503190957.GB6756@mercury.ccil.org> <20160503195037.GC6756@mercury.ccil.org> <20160504150050.GG6756@mercury.ccil.org> Date: Wed, 4 May 2016 15:58:54 -0400 X-Google-Sender-Auth: m1UoF3L5AHAHFjTRFRwlS4k0B9s Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c14d10c824a8053209a787 Archived-At: Cc: Mark Nottingham , Tim Bray , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:59:04 -0000 --001a11c14d10c824a8053209a787 Content-Type: text/plain; charset=UTF-8 While we are at it. Thinking of encoding a signed object as an array gives me an idea. If we take the approach of [ , , ] And also we are allowing a Bignum to be encoded as either a number or a string that contains a Base63 encoded value: MyStruct Class one BigNum two BigNum {"one" : 1, "two" : "AAAAAAAA2" } The one thing I feel missing from XSD that is incredibly useful is the ability to put in links between objects as Identifiers. Now I use this to a vast extent in Goedel, my code synthesis system. So right now in my JSON structures I have strings that are identifiers for the enclosing object and I have other strings that are references to those identifiers. But there is no information in the JSON schema to say which is which or to impose type constraints, etc. So lets say we have a definition as follows MyStruct1 Class Inner MyStruct2 MyStruct2 Class Identifier ID I can then encode in my current system as follows: { Inner : { ID : "Fred"} } But now lets say I want to refer to the same structure in another part of the same document and I know it is already serialized. This could be written as: { Inner : "Fred" } Now lets say that we have a child class defined MyStruct3 Class Encoding this requires us to tag the structure so we know what the correct subtype is. We could use the nested approach I showed earlier. Or we could use an array: { Inner : ["MyStruct3 ", { ID : "Fred"}] } This does seem very natural and flexible. And adding identifiers is sufficient to make the encoding capable of being usefully self describing. --001a11c14d10c824a8053209a787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While we are at it. Thinking of= encoding a signed object as an array gives me an idea.

If we take the approach o= f
=C2=A0 [ <signature header>, <si= gned Data>, <signature value>]
And also we are allowing a Bignum to be e= ncoded as either a number or a string that contains a Base63 encoded value:=

MyStr= uct Class
=C2=A0 =C2=A0one BigNum
=C2=A0 =C2=A0two BigNum

=C2=A0 {"one" : 1, "= ;two" : "AAAAAAAA2" }

The one thing I feel missing from XSD that i= s incredibly useful is the ability to put in links between objects as Ident= ifiers. Now I use this to a vast extent in Goedel, my code synthesis system= .

So r= ight now in my JSON structures I have strings that are identifiers for the = enclosing object and I have other strings that are references to those iden= tifiers. But there is no information in the JSON schema to say which is whi= ch or to impose type constraints, etc.

=
So lets say we have a definition as follow= s

MySt= ruct1 Class
=C2=A0 =C2=A0Inner MyStruct2

MyStruct= 2 Class
=C2=A0 =C2=A0Identifier ID

I can then enc= ode in my current system as follows:

{ Inner : =C2=A0{ ID : "Fred"} }= =C2=A0

But now lets say I want to refer to the same structure in another part of = the same document and I know it is already serialized. This could be writte= n as:

= { Inner : =C2=A0"Fred" }=C2=A0

Now lets say that we have a child cl= ass defined

MyStruct3 Class <Inherit MyStruct2><= /div>

=
Encoding this requires us to tag the s= tructure so we know what the correct subtype is. We could use the nested ap= proach I showed earlier. Or we could use an array:

{ Inner : =C2=A0["MyStruc= t3=C2=A0", { ID : "Fred"}] }=C2=A0


This does seem very natural and flexible. And adding identifiers is s= ufficient to make the encoding capable of being usefully self describing.
--001a11c14d10c824a8053209a787-- From nobody Mon May 9 08:55:46 2016 Return-Path: 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 013E912B04D for ; Mon, 9 May 2016 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0b2BU4XHW4R6 for ; Mon, 9 May 2016 08:55:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BCF12D530 for ; Mon, 9 May 2016 08:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2405; q=dns/txt; s=iport; t=1462809341; x=1464018941; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=89RlI+XpH/aEmF7S3Y2v82bDyM60i0PKxH4/IhNL8x8=; b=bAS7coqnWiHofYir5GU7I99rxHezn1hGISw/SVvEb59d6Rb8VTMA0Qf0 86HcjVMboyDnZ8O2ZIm0CFw3CKRfqfomGuM78wnzmsa+Gn6N70ryXJr4n uXtMQuL39uoMt55Ho5P/HG/dtqJX0dJKlC6ZwH1KTMRwET8qkT7zg1/CW s=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgAgsjBX/4cNJK1dgziBWLh/DoF2h?= =?us-ascii?q?hACgTE4FAEBAQEBAQFlHAuEQgEBBCNWEAIBCEICAjIlAgQOE4gdryiQWQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQ0IiBYIgk6HPyuCLgWYIgGDJ4Fog2SFKIFpjS6GK?= =?us-ascii?q?YkRAR4BQ4NriHUBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="asc'?scan'208";a="105240107" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 15:55:41 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u49Fte1M027285 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 15:55:41 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 10:55:40 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 9 May 2016 10:55:40 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org" Thread-Topic: [Json] Normative reference reasoning and logistics Thread-Index: AQHRoXBVlLbhRy7gw0mMULwD7976yZ+k6UIAgAAnegCAARyEgIAAr4SAgApKpwA= Date: Mon, 9 May 2016 15:55:40 +0000 Message-ID: <4BA8C03B-C38F-4322-96F4-DD39C6ED6E68@cisco.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.101.72.31] Content-Type: multipart/signed; boundary="Apple-Mail=_6B010BCB-1325-4E5D-8803-51DCBB21A6B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:55:45 -0000 --Apple-Mail=_6B010BCB-1325-4E5D-8803-51DCBB21A6B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, It appears we have rough consensus to include a combination of the = following text suggested by Tim Bray: The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term =E2=80=9CJSON = text=E2=80=9D in any of its specifications. Note, however, that ECMA-404 allows several practices which this specification recommends avoiding in the interests of maximal interoperability. With these additional points suggested by Joe Hildebrand: - The intent is that the grammar is the same between the two documents, although different descriptions are used. If there a difference is found between them, ECMA and the IETF will work together to update both documents. - If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible. - If either document is changed in the future, ECMA and the IETF = will work together to ensure that the two documents stay aligned = through the change. If there are no objections, then Tim and Joe can finalize the text and = include it with the next revision to draft-ietf-jsonbis-rfc7159bis. Thank you, - JSON Chair --Apple-Mail=_6B010BCB-1325-4E5D-8803-51DCBB21A6B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXMLL/AAoJEDWi+S0W7cO1t04H+wW0b86WD7WvxiGJKrQ5DJqc miiAW3NjaHtbVqzXgBENs3tZ98e+L7zaTiwp7wXQvXwYwAe83M4jLFeDp83uV8nK BEsLBoq4cynSMGYLtO19rWdlUm5DKtkqGAEcuc0ccw5CpjCzMmNP17vxtgjKV7YI Vc6+XyN9mkuGL+7fqdCLW5Nda5upiCJjvQz9c1C/IFkQJS2UJ2J92KR4d4S4UJeF PXZ9/PANgf1zkGAz5EfzYyZH8V45iMdRBLFSQeSFiUdWhKLM3iHkvxd/D9NhuAxa 4NxiedqTrdVgMUrXL1gaLQibWYRqC0zmjaKhjffdwoOv0svYCTLlHLqp09sZFUU= =95so -----END PGP SIGNATURE----- --Apple-Mail=_6B010BCB-1325-4E5D-8803-51DCBB21A6B3-- From nobody Thu May 12 22:12:18 2016 Return-Path: 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 B723412B017 for ; Thu, 12 May 2016 22:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 doMHRq2yizBL for ; Thu, 12 May 2016 22:12:15 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 2217812D09A for ; Thu, 12 May 2016 22:12:15 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id f92so52553506qgf.0 for ; Thu, 12 May 2016 22:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2V6uq0b9kit6L35zNKeK0wZ8d0rIrF0XKel1K1OTpZs=; b=OA6tyJX1zbe37wret1AqaC4SytLtkL0sj/uwDHqioXBT/rHSxjoh1/Zr2LrZxjri0z sDFIoVodYZvYWOkW5i64qX3Sc/ccnG9IVZPUZxGKRU6no3Hua/sZ9IyjxuG4q4qSw/9o DaI5OOXqUn4z9VkJwbzzUI8NQS3DagpoPJYKpSGd/3Tn1yxXKcXRGQZqFLT6Bdop1OJR TvMOcIO7LefYZKA6IgdIEEQMsfzZutu47tmEtvx+9gmNfKuZEKnIYNaN9X9Fzscmy1H0 a/tTMOWPdjrvotHKvI1SvjnYuTqUSiUDOQP232bC7XFUE/sJan+LuUvTrv2NZGE9qW7E Kvgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2V6uq0b9kit6L35zNKeK0wZ8d0rIrF0XKel1K1OTpZs=; b=Rzx2LVM5RpXq20QDxYmmy3zCzlfqyFC2HLE6kJ/5RwMELjyOCHsYOO/fARKdG3tVdc 28WfAciaPBZEgFqdSzSNSmAQDwsOeuI7HqO7KMU5SVJgLdgZAaN7rbcB1h4A4axe8FT2 oY0t0tSuSyr9Ef5eBzE0H7mh9YadcEvj8i6sRWY0cOoxlhJbCpKBLJD4+gtQ7tl9a9lK bEg9Slwj8p7UuDwQGsTewYl+WiXX/70dwOwoEC0vIQpBfQHHe2oUMd0vEwco5nhMZqTu 3+VXKRxGfwUWxHLdaV/LUZym6jRbJ6/pPywhyMBv+Xqs7tR+r0sPx4OC3cv9SzCnLSjH bvrg== X-Gm-Message-State: AOPr4FU19MnLAkBw37HmufRGDsIvFrn/aBvnPbQl+lzTGxq+f7ExwgQ5PKuQvQGDpBmQB6VJmhCByEe+4B0AZw== X-Received: by 10.140.194.138 with SMTP id p132mr14089111qha.78.1463116334260; Thu, 12 May 2016 22:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.201 with HTTP; Thu, 12 May 2016 22:11:54 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: <4BA8C03B-C38F-4322-96F4-DD39C6ED6E68@cisco.com> References: <978CE59C-19EA-44E0-8AA9-620B854ACB6F@cisco.com> <255B9BB34FB7D647A506DC292726F6E13BD0AFB47F@WSMSG3153V.srv.dir.telstra.com> <896CAFF7-A29E-48F1-B2DA-F4A09CD9B313@cisco.com> <4BA8C03B-C38F-4322-96F4-DD39C6ED6E68@cisco.com> From: Tim Bray Date: Thu, 12 May 2016 22:11:54 -0700 Message-ID: To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=001a114338b25e7cd10532b25144 Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Normative reference reasoning and logistics X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 05:12:18 -0000 --001a114338b25e7cd10532b25144 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Will do. On Mon, May 9, 2016 at 8:55 AM, Matt Miller (mamille2) wrote: > Hello all, > > It appears we have rough consensus to include a combination of the > following text suggested by Tim Bray: > > The reference to ECMA-404 in the previous sentence is normative, > not with the usual meaning that implementors need to consult it > in order to understand this document, but to emphasize that there > are no inconsistencies in the definition of the term =E2=80=9CJSON te= xt=E2=80=9D > in any of its specifications. Note, however, that ECMA-404 allows > several practices which this specification recommends avoiding in > the interests of maximal interoperability. > > With these additional points suggested by Joe Hildebrand: > > - The intent is that the grammar is the same between the two > documents, although different descriptions are used. If there a > difference is found between them, ECMA and the IETF will work > together to update both documents. > > - If an error is found with either document, the other should be > examined to see if it has a similar error, and fixed if possible. > > - If either document is changed in the future, ECMA and the IETF will > work together to ensure that the two documents stay aligned through > the change. > > If there are no objections, then Tim and Joe can finalize the text and > include it with the next revision to draft-ietf-jsonbis-rfc7159bis. > > > Thank you, > > - JSON Chair > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a114338b25e7cd10532b25144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wil= l do.

= On Mon, May 9, 2016 at 8:55 AM, Matt Miller (mamille2) &l= t;mamille2@cisco.co= m> wrote:
Hello all,

It appears we have rough consensus to include a combination of the followin= g text suggested by Tim Bray:

=C2=A0 =C2=A0 The reference to ECMA-404 in the previous sentence is normati= ve,
=C2=A0 =C2=A0 not with the usual meaning that implementors need to consult = it
=C2=A0 =C2=A0 in order to understand this document, but to emphasize that t= here
=C2=A0 =C2=A0 are no inconsistencies in the definition of the term =E2=80= =9CJSON text=E2=80=9D
=C2=A0 =C2=A0 in any of its specifications. Note, however, that ECMA-404 al= lows
=C2=A0 =C2=A0 several practices which this specification recommends avoidin= g in
=C2=A0 =C2=A0 the interests of maximal interoperability.

With these additional points suggested by Joe Hildebrand:

=C2=A0 =C2=A0 - The intent is that the grammar is the same between the two<= br> =C2=A0 =C2=A0 =C2=A0 documents, although different descriptions are used.= =C2=A0 If there a
=C2=A0 =C2=A0 =C2=A0 difference is found between them, ECMA and the IETF wi= ll work
=C2=A0 =C2=A0 =C2=A0 together to update both documents.

=C2=A0 =C2=A0 - If an error is found with either document, the other should= be
=C2=A0 =C2=A0 =C2=A0 examined to see if it has a similar error, and fixed i= f possible.

=C2=A0 =C2=A0 - If either document is changed in the future, ECMA and the I= ETF will
=C2=A0 =C2=A0 =C2=A0 work together to ensure that the two documents stay al= igned through
=C2=A0 =C2=A0 =C2=A0 the change.

If there are no objections, then Tim and Joe can finalize the text a= nd include it with the next revision to draft-ietf-jsonbis-rfc7159bis.


Thank you,

- JSON Chair



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a114338b25e7cd10532b25144-- From nobody Sun May 22 11:15:35 2016 Return-Path: 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 95F2E12D1B5 for ; Sun, 22 May 2016 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 hoKPxeN-gxN0 for ; Sun, 22 May 2016 11:15:33 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 0C81512D1AC for ; Sun, 22 May 2016 11:15:33 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x7so95296868qkd.3 for ; Sun, 22 May 2016 11:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2Co/SJ0iotdY4foBdqiddr9AlE/5h/CAxJ/oQR5bkYw=; b=HODFmWDe2nhoNAE5gZzKXBuyJT6FZFAH3+bKvt7/7PDTlP6yIs19KVwVr7JLYAzpPr RKOXPbI5/FEtrqNiHxJ2bs5ifglZLl1pRRkk7yjiah2i5zh3DE9K+83wOqWfwDZbnQNT TR5D5vw5+T7rQ0TvARiKP7ijZdCua3D1BpceHNQGWspvHzWEeqV0Kh9UDDPAJ0E8ceQE gZaDYC6BrvfcOn45+E5UeIENUE7JxBCI27erD1zeGIJPlhsbBr2yd+0ATSb/mzDjWcpW xDRM8wJ0/GVhjhyfXJp+I8klv+is3GKAmcRZ/6UOTEFLciB4+F4yytIT1ZSptpQt3CCd ZJug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2Co/SJ0iotdY4foBdqiddr9AlE/5h/CAxJ/oQR5bkYw=; b=MWwYJNnWzx7zCZMi+Z4hb/LRjihrs62mlF05URwxP+QphTPFAPzzZ2FuYtD0C9qraZ 2K1LBGR1XYwKkmjaR8tleaxhor3/gxos5z4rAtZnUBg5zeoKkUWO4VljuOf+tzhgtM5E ZhJ35l938KF6JtRx1zuJ8h6XZGSGTTErPW3gSCvlA4T5J0JZ12poL+Kntg5ZNHgaNcqs nZ1woTA3rImAbuepems5NjkCDTrDVQeo+N092Q6qtg5iroQSk1QQNVi4B9ABCpvcqnE8 rFFMOud1eQWRKeCIVmsNVfZHkB9CE/8l789GxGnawypabIycsxSw8sgSUzeAj/0dySEg Hm1g== X-Gm-Message-State: AOPr4FVJg7u7J+cjmm8DJUTL1ljE0t5zCICnkbSki+gH1AYzJfCG1bQveoW4JSrD1IixWbSIRFn1pCIujb476w== X-Received: by 10.233.222.4 with SMTP id s4mr12654652qkf.19.1463940932104; Sun, 22 May 2016 11:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.100.215 with HTTP; Sun, 22 May 2016 11:15:12 -0700 (PDT) X-Originating-IP: [209.52.88.172] From: Tim Bray Date: Sun, 22 May 2016 11:15:12 -0700 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0437703b17d40533724f21 Archived-At: Subject: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 18:15:34 -0000 --94eb2c0437703b17d40533724f21 Content-Type: text/plain; charset=UTF-8 See https://www.tbray.org/ongoing/When/201x/2016/05/22/Json-Schema-Gripe --94eb2c0437703b17d40533724f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c0437703b17d40533724f21-- From nobody Mon May 23 08:41:32 2016 Return-Path: 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 D636A12D99C for ; Mon, 23 May 2016 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Zgj5PC6hKy5w for ; Mon, 23 May 2016 08:41:29 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9DE12D993 for ; Mon, 23 May 2016 08:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1464018089; x=1465227689; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=64Tjk9eUQiYYYaeFxdXk1b+2QbEbwu10tVEbPBM65/c=; b=RZnc6qsLuWp4UNyd5mZnL3PRhDMKBOBoajn6SkxW0/DXYlY7JWSyka40 ZbR7f9kMaZ0l4YmScBU7apjePpPhE+VyrpHs+5y5SBgsXAfUWwY3weKKJ Cllvjtj/V+dH2ohOfYiIAJcmQRCLylhIpiicJouOKjQ31mKMwJigZqYag o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcBQBoI0NX/4QNJK1bgzdWfQa3bIQUI?= =?us-ascii?q?oVvAhyBEzsRAQEBAQEBAWUnhEMBAQQjEVUCAQgODAImAgICMBUQAgQBEogvDrM?= =?us-ascii?q?9kT8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSaBdgiCT4Q/gwErgi4FmDcBj?= =?us-ascii?q?h+BaY0zhjOJGAE2LIIGBBiBS26IFSUYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="scan'208";a="276804439" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 15:41:28 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4NFfRVi023628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 15:41:28 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 11:41:27 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 23 May 2016 11:41:27 -0400 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "json@ietf.org" Thread-Topic: [Json] Another problematic JSON Schema use-case Thread-Index: AQHRtFXy/R2imDBXvkmlE5Z/zz9P2p/GeCsA Date: Mon, 23 May 2016 15:41:26 +0000 Message-ID: <812B862C-4D8F-4173-9BDC-479A1A31C72A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:41:31 -0000 T24gNS8yMi8xNiwgMTI6MTUgUE0sICJqc29uIG9uIGJlaGFsZiBvZiBUaW0gQnJheSIgPGpzb24t Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdGJyYXlAdGV4dHVhbGl0eS5jb20+IHdyb3Rl Og0KDQo+U2VlIGh0dHBzOi8vd3d3LnRicmF5Lm9yZy9vbmdvaW5nL1doZW4vMjAxeC8yMDE2LzA1 LzIyL0pzb24tU2NoZW1hLUdyaXBlDQoNCg0KVGhlIENEREwgSeKAmW0gY3VycmVudGx5IHVzaW5n IGZvciBvbmUgcGFydCBvZiBkcmFmdC1oaWxkZWJyYW5kLWRldGggaXM6DQoNCmBgYA0KdXBkYXRl ID0gQV91cGRhdGUgLyBBQUFBX3VwZGF0ZSAvIC4uLg0KDQpBX3VwZGF0ZSA9IHsNCiAgcnR5cGU6 ICJBIiwNCiAgdjRhZGRyZXNzOiB0c3RyLA0KICBjb21tb24NCn0NCg0KQUFBQV91cGRhdGUgPSB7 DQogIHJ0eXBlOiAiQUFBQSIsDQogIHY2YWRkcmVzczogdHN0ciwNCiAgY29tbW9uDQp9DQoNCmNv bW1vbiA9ICgNCiAgPyB0dGw6IHVpbnQsDQogID8gY29tbWVudDogdHN0ciwNCiAgPyB1aWQ6IHRz dHINCikNCg0KYGBgDQoNClRoZSBkaXNjcmltaW5hbnQgaXMgdGhlIOKAnHJ0eXBl4oCdIGZpZWxk LCBhbmQgdGhlbiBlYWNoIHJ0eXBlIGhhcyBhIHNldCBvZiBjb21tb24gb3B0aW9uYWwgZmllbGRz LCBhbmQgYSBzZXQgb2YgcmVxdWlyZWQgcnR5cGUtc3BlY2lmaWMgZmllbGRzLg0KDQpXaGVuIHlv dSBwYXNzIGluIHRoaXMgSlNPTjogYHsicnR5cGUiOiAiQUFBQSJ9YA0KDQpUaGUgQ0RETCB0b29s aW5nIGdpdmVzIHRoaXMgZXJyb3I6DQoNCmBgYA0KQ0RETCB2YWxpZGF0aW9uIGZhaWx1cmUgKG5p bCBmb3IgeyJydHlwZSI9PiJBQUFBIn0pOg0KWyJBQUFBIiwgWzpwcmltLCAzXSwgbmlsXQ0KYGBg DQoNCldoaWNoIGlzIGEgbGl0dGxlIGVzb3RlcmljLCBncmFudGVkLCBidXQgd2hlbiBkZWNpcGhl cmVkIHNheXMgdGhhdCB0aGUg4oCcQUFBQeKAnSBrZXkgaXMgcmVxdWlyZWQsIGJ1dCB3YXNu4oCZ dCB0aGVyZS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg== From nobody Mon May 23 18:30:34 2016 Return-Path: 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 0A13812DBB4 for ; Mon, 23 May 2016 18:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 88vyfBSyZ1Ie for ; Mon, 23 May 2016 18:30:31 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 DE25212DC17 for ; Mon, 23 May 2016 18:30:30 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id f92so1144012qgf.0 for ; Mon, 23 May 2016 18:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5hoHYNEUI8RfKTcJET11XI7dNVFiHhR1vlxh9+E1uDY=; b=oezSIFp0WcqgKxG6HdNkYGXAEEYfVwPEy97aldRpdp/10y7EQHzz5D/eI8IEtuJui6 DFlX9ArmZqgLK/QsQAU8pyj0q4rsSICIDFC0GNaZiaurkAoXqYGlorfJOE/ll6zdhqaL 2beh1fvnzoCYtLBXP+ztHSfQ3lfrpMqPd7n/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5hoHYNEUI8RfKTcJET11XI7dNVFiHhR1vlxh9+E1uDY=; b=MV3lC83J2pzy1tHzlm/ElM8l1D/4CLGu4SHIkxPwTyNMDLsz2ugCvW3lfXZfzv4He6 pWVwR7p/TArYKgRt+SDhDfoTLstEhcOjwuxA2wF2qMBwzFlZElnqW9Wg1jVJUultAqTX 95oVH719X6pPuo47yQcIPFvm75wd+qQ2imxltqyZbQW5la2caa7cAqA9Klosd7MbcOGY wiRZbMdCU0q2WLAMQWrHUW/bFclFkZlV/pzdRmhUZSsJVRVvzC3A6Ew27QawfzhZeQH9 vZQmsz53xVPQkuhfvHS3I11EszeRmpZE8JHOi/6NJKJfVPjT4vEURrMdWWhSaoJCFljW vUog== X-Gm-Message-State: ALyK8tIwkDxHm4rw0K8lHCnndxeAwj4Y/87fH22ZFMEdgpPW5Q6fH/3TsaCM3ZbXkjkHiTamd9qt9n9oc0W4bA== X-Received: by 10.140.92.37 with SMTP id a34mr987126qge.88.1464053429858; Mon, 23 May 2016 18:30:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.85 with HTTP; Mon, 23 May 2016 18:30:15 -0700 (PDT) In-Reply-To: References: From: Austin William Wright Date: Mon, 23 May 2016 18:30:15 -0700 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=001a1139baf29e8d1a05338c80a8 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 01:30:33 -0000 --001a1139baf29e8d1a05338c80a8 Content-Type: text/plain; charset=UTF-8 This is a problem that I tried working on a year or two ago, but couldn't find any good resolution to. Let's create a JSON Schema for the described problem (slightly modified/expanded for illustration below): { "type": "object", "additionalProperties": { "type": "object", "properties": {"Type":{"enum":["Animal", "Vegetable", "Mineral"]}}, "required": ["Type"], "oneOf": [ { "properties": { "Type":{"enum":["Animal"]}, "Thermoregulation":{"enum":["Endotherm", "Ectotherm"]} }, "required": ["Thermoregulation"] }, { "properties": { "Type":{"enum":["Vegetable"]}, "Organic":{"type":"number"} }, "required": ["Organic"] }, { "properties": { "Type":{"enum":["Mineral"]}, "Organic":{"type":"boolean"} }, "required": ["Organic"] } ] } } Here's a valid instance for illustration: { "o1": { "Type": "Animal", "Thermoregulation": "Endotherm", "Species": "Felis catus", "Label": "cat" }, "o2": { "Type": "Mineral", "Organic": false, "Label": "Quartz" } } This, however, is an invalid instance: { "o3": { "Type": "Vegetable", "Endotherm": true, "Label": "Silver" } } What sort of error would be appropriate here? (E.g. Is this a typo for the "Type" property? Or is this just missing a required "Organic" property?) When I run it through my validator, I get this error: (1 of 1) instance.o3 is not exactly one from ,< http://example.org/Vegetable>, And within all three schemas, exactly one constraint fails. So which one do we suggest errors for? Changing 'Vegetable' to 'Animal', and changing 'Endotherm' to 'Organic' are all equally reasonable (to a computer) one-word fixes. In general, JSON Schema and many other schemas are designed to ensure things are valid. They're not well engineered to help people fix things when they're invalid. A similar problem is that localizing error strings. There's a few suggestions to add custom error strings to JSON Schema, but then we have the problem that they're not localized. If we allow multiple strings (one per localization), then we have to update the schema every time we add a locale, which means changing the file even though nothing about the schema has changed. I just created < https://github.com/json-schema-org/json-schema-spec/issues/31> to look at this problem as it relates to JSON Schema. Cheers, Austin Wright. On Sun, May 22, 2016 at 11:15 AM, Tim Bray wrote: > See https://www.tbray.org/ongoing/When/201x/2016/05/22/Json-Schema-Gripe > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a1139baf29e8d1a05338c80a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a problem that I tried working on a year or two ag= o, but couldn't find any good resolution to.

Let'= ;s create a JSON Schema for the described problem (slightly modified/expand= ed for illustration below):

{
"type": "objec= t",
"= ;additionalProperties": {
"type": "object",
"properties": {"T= ype":{"enum":["Animal", "Vegetable", &qu= ot;Mineral"]}},
= "required": ["Type"],
"oneOf": [
{
"properties": {
"Type":{&quo= t;enum":["Animal"]},
"Thermoregulation":{"enum":[&= quot;Endotherm", "Ectotherm"]}
},
"required": ["Thermoregulation&qu= ot;]
},
{
"properties": {=
"Typ= e":{"enum":["Vegetable"]},
"Organic":{"type= ":"number"}
},
= "required": ["Organic"]
},
{
"properties": {
"Type":{"enum":= ["Mineral"]},
"Organic":{"type":"boolean"}
},
= "required":= ["Organic"]
}
= ]
}
= }

Here's a valid instance for illustration:

{
"o1": {
"Type": "Animal",
"Thermoregulation": &quo= t;Endotherm",
<= /span>"Species": "Felis catus",
"Label": "cat"=
},
= "o2": {
<= div> "Type": &= quot;Mineral",
= "Organic": false,
"Label": "Quartz"
}
}

<= /div>
This, however, is an invalid instance:

{=
"o3"= ;: {
"Ty= pe": "Vegetable",
"Endotherm": true,
"Label": "Silver"
}
}

What sort of error would be appropriate here?= (E.g. Is this a typo for the "Type" property? Or is this just mi= ssing a required "Organic" property?)

Wh= en I run it through my validator, I get this error:

(1 of 1)=C2=A0instance.o3 is not exactly one from <http://example.org/Animal>,<<= a href=3D"http://example.org/Vegetable">http://example.org/Vegetable>= ;,<http://example.org/Mineral= >

And within all= three schemas, exactly one constraint fails. So which one do we suggest er= rors for? Changing 'Vegetable' to 'Animal', and changing &#= 39;Endotherm' to 'Organic' are all equally reasonable (to a com= puter) one-word fixes.

In general, JSON Schema and= many other schemas are designed to ensure things are valid. They're no= t well engineered to help people fix things when they're invalid.
=

A similar problem is that localizing error strings. The= re's a few suggestions to add custom error strings to JSON Schema, but = then we have the problem that they're not localized. If we allow multip= le strings (one per localization), then we have to update the schema every = time we add a locale, which means changing the file even though nothing abo= ut the schema has changed.

I just created <https://github.com/json-schema-org/js= on-schema-spec/issues/31> to look at this problem as it relates to J= SON Schema.

Cheers,

Austi= n Wright.


On Sun, May 22, 2016 at 11:15 AM, Tim Bray <tbray@textuality.com> wrote:



_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json


--001a1139baf29e8d1a05338c80a8-- From nobody Mon May 23 20:54:56 2016 Return-Path: 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 27E8312D0A0 for ; Mon, 23 May 2016 20:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 mkPwwkqRqzIN for ; Mon, 23 May 2016 20:54:53 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 9E5E112D5DA for ; Mon, 23 May 2016 20:54:53 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y126so3302881qke.1 for ; Mon, 23 May 2016 20:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+6OdpaC2nlxl2BE8Mq7OepOqGxuz5e+4YOZwNFtx9s=; b=k/9J+Yk2m8LnvOtCJ+GyDba3r27Eit2HGozNsTujShqzk9sEQgniLVVXh4BhuVcJbo eoYK5HC2kWe5+V10h9EpO42fTSyDTXU/yuHy5iBaJB77cdkpyu/3/ofYQRi+lc4fEzcX 4JUpgRZ7srrEEcA1s/mwKBthUN0F2WkzewulLCBNxGDF3M/6pHbLHIqceOQeaag6MoAX xuaLw+Dv1vpU6ftP8A9OZj3J6EoCCxiN7kZnqo/thXINRXB7tHksMcV4qGZU1m6D2UPW +vEBDmafOVcLwdhsfr/l1pWroBkn3cpkpS14p3V3JKqqIqh0EGprnA8vDoHZ92gz6ROW KCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u+6OdpaC2nlxl2BE8Mq7OepOqGxuz5e+4YOZwNFtx9s=; b=HWjWDxhywtaTp1cl9hofckTiUedstywF0wp4CnBnTyhxeYV8rREcIvxDFWOt1sLzxG 5LjsbovhNXEXU24OYeSJ5cAZu+zBhgaOu3AGAv/15VlRm3awf4Tht32TiKO2csZl4sK/ tQK+M4IAmkHAUESfhCF6dToy0YLG49+s3AyHBldUvJ4wj4CgvWzACKJyabooPLxR4JGE vggQ5pVVEpqVDdg+Rnx1+nNCWRnLzby52fonvDar73dCkRBzcbwxSIS8A3WU3736iG0l mFzbu581y6c+VQ8zbygm5nzw+LFpezbTYPvm796Ug3tDRARoYHA7188lyNnYbxk2Brab FeIA== X-Gm-Message-State: ALyK8tJongxBeZr+lWLVDFTLIRBZ55quNKoGfaEErWrcCqp8JEDrnL8/yoqJPM9W/RZYEU7pAuNDK1Cf1qPIog== X-Received: by 10.55.215.132 with SMTP id t4mr1418680qkt.66.1464062092628; Mon, 23 May 2016 20:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.100.215 with HTTP; Mon, 23 May 2016 20:54:33 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: From: Tim Bray Date: Mon, 23 May 2016 20:54:33 -0700 Message-ID: To: Austin William Wright Content-Type: multipart/alternative; boundary=001a1149dd5ef5f1d205338e8439 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 03:54:55 -0000 --001a1149dd5ef5f1d205338e8439 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm, I have to excerpt one line here: On Mon, May 23, 2016 at 6:30 PM, Austin William Wright wrote= : > > In general, JSON Schema and many other schemas are designed to ensure > things are valid. They're not well engineered to help people fix things > when they're invalid. > =E2=80=8BI find this troubling. I expect modern compilers to give me highl= y actionable errors, with line numbers. Is the nature of JSON DSL=E2=80=99s a= nd programming languages so deeply different that this is not a reasonable thing to ask a schema processor to do? If so, then what are schemas for? I=E2=80=99ve seen them as having two use= s: 1. Specification aids 2. Debugging aids For #1, I see schemas as a poor second-best to clear human-readable description. For #2, Schemas are appealingly declarative and presumably much more compact than the equivalent declarative code. But if they can=E2=80=99t te= ll me what the problem is, why bother? And furthermore, I=E2=80=99ve never thoug= ht validators could rely on schemas alone, because schemas can=E2=80=99t check semantic constraints (=E2=80=9Cis that a valid part number?=E2=80=9D) --001a1149dd5ef5f1d205338e8439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm= , I have to excerpt one line here:

On Mon, May 23, 2016 at 6:30 PM, Austin William Wrig= ht <= aaa@bzfx.net> wrote:

In general, JSON Schema and many other schem= as are designed to ensure things are valid. They're not well engineered= to help people fix things when they're invalid.

=E2=80=8BI find this troubling.=C2=A0 I expect modern compilers to give m= e highly actionable errors, with line numbers. Is the nature of JSON DSL=E2= =80=99s and programming languages so deeply different that this is not a re= asonable thing to ask a schema processor to do?

If so, then what are schemas for?=C2=A0 I=E2=80=99ve= seen them as having two uses:

1. Specification aids
2. Debugging aids

For #1, I see schemas as a poor second-best to clear human-readable d= escription.
For= #2, Schemas are appealingly declarative and presumably much more compact t= han the equivalent declarative code.=C2=A0 But if they can=E2=80=99t tell m= e what the problem is, why bother?=C2=A0 And furthermore, I=E2=80=99ve neve= r thought validators could rely on schemas alone, because schemas can=E2=80= =99t check semantic constraints (=E2=80=9Cis that a valid part number?=E2= =80=9D)



--001a1149dd5ef5f1d205338e8439-- From nobody Tue May 24 14:36:43 2016 Return-Path: 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 9124212D557 for ; Tue, 24 May 2016 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OHyHgT8aaSIN for ; Tue, 24 May 2016 14:36:40 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 C2CFD12B056 for ; Tue, 24 May 2016 14:36:39 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so151461756wmn.1 for ; Tue, 24 May 2016 14:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Uefxf3x7K1ZbuavW1Tre/EWmsZFY/lRhSI2rE1mGJXQ=; b=kiKnDO6yauu3cgZ4O4DM333ErdCr1VNNR/58mmIq9Xsv3yWMh5GRNar8K+q5p8J5Pj TtCkNHavfg6AA8rfDuP3HDyYIir39rdgfB1xYfXYBU2KgD0/gWQIzy//GZdkZ7Fs4mvL end7Fwsw9TI0QHToEg1MWd1K2P+MeXVWBC6flx0RpsXvvw2oY89djN9kHkyvn5vX109j hmvBjIFfTHOvhhUJGVKYoVzalaBgAsulXyT1Krw5VWLvWuZiD+yNobmMmT42UkFyCB2G S+tKVumaRp4QW7RCBcrIhW/INSyAunQND9e5kBfepjSzmocH3EAweR42HnR7bDk4T5q5 Cogw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Uefxf3x7K1ZbuavW1Tre/EWmsZFY/lRhSI2rE1mGJXQ=; b=SDKhFHtlH03E8yGkQMTbV0cBWcBfkMZf/G4CzIYNIURiUNAMqYr8/ddACpLoO5nBHO Vx55xtL589C7KdrUlr2I+KFnaqcqF5YsKoQb7FuEZVVo19q11bD5fZrpSZ3ApQgJURG3 xnFJKQ1x2q88w94s5df0HqTvSpvPvTcf9ox2rBhAQgpoddFTe/s7C05bpSveu/ptE7/A vIgmMP6PmetHty0dtoLGgNXEWunqWEsg5oQu14aaYTp1F0l81/EnFLGUxsw7fZTKe2Up fTUMt9Uatb1YH1JnyQdsdR7tUU4TPROTw6rdjw0K+f/gWWSlxbfmGc63om2ODIUZv7aF /i5g== X-Gm-Message-State: ALyK8tLLV2SDGUbY7pZWHfdCZfZQJdNTDgdWfSN+TocT5uiqvejYFPrr7y1QhMS6Et6xdw== X-Received: by 10.28.48.196 with SMTP id w187mr826785wmw.71.1464125798290; Tue, 24 May 2016 14:36:38 -0700 (PDT) Received: from [192.168.1.181] (178.113.53.64.wireless.dyn.drei.com. [178.113.53.64]) by smtp.googlemail.com with ESMTPSA id c185sm20759161wme.9.2016.05.24.14.36.37 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 14:36:37 -0700 (PDT) To: json@ietf.org From: Christian Zangl Message-ID: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> Date: Tue, 24 May 2016 23:36:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:36:41 -0000 JSON is used in a lot of places and has helped improve things like data exchange and data storage. It is also used in areas it's less suited for, like configuration files. People seem to prefer JSON for configuration over YAML and other config formats. I started Human JSON (Hjson) because I found the experience frustrating (for example missing/trailing comma problems, no comments). With Hjson you get a superset of JSON that allows you to - add #, // or /**/ comments, - omit quotes for keys, - omit quotes for strings (terminated by LF, no escapes), - omit braces for the root object, - omit the comma at the end of a line - add trailing commas and - use multiline strings with proper whitespace handling. These changes should make it easer to read and write configs while still preserving the power of JSON. Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You can find the draft here: http://hjson.org/rfc.html There are also syntax diagrams and more at http://hjson.org/syntax.html Thoughts? From nobody Tue May 24 16:52:21 2016 Return-Path: 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 3E69F12D5D3 for ; Tue, 24 May 2016 16:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 lzbgc5BVCasJ for ; Tue, 24 May 2016 16:52:17 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CEE12D5D5 for ; Tue, 24 May 2016 16:52:17 -0700 (PDT) Received: from mfilter33-d.gandi.net (mfilter33-d.gandi.net [217.70.178.164]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id F3B2FC5A4F; Wed, 25 May 2016 01:52:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter33-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter33-d.gandi.net (mfilter33-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id hZCRz8WrkHkf; Wed, 25 May 2016 01:52:14 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D6C1CC5A46; Wed, 25 May 2016 01:52:13 +0200 (CEST) Message-ID: <5744E92B.3010704@tzi.org> Date: Wed, 25 May 2016 01:52:11 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> In-Reply-To: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 23:52:19 -0000 First, the name. If something calls itself X, it should be an X. HJSON is not JSON. It is a Hacked JSON. Second, > People seem to prefer JSON for > configuration over YAML and other config formats. Can't be. YAML *contains* JSON. If you like JSON, you already like YAML, because every JSON file is a YAML file. (You may not like what else YAML brings to the table, but that would be a mistake.) (If you like JSON mostly because everything is JSON, well: HJSON isn't.) Third, YAML also isn't stuck with the limitations of the JSON data model. Binary data, maps with keys that aren't strings, etc. I'm not opposed to writing a spec for a Hacked JSON. However, I think the time spent for doing that would be much better invested in an updated spec for YAML. Grüße, Carsten From nobody Tue May 24 18:07:34 2016 Return-Path: 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 6BAE212B028 for ; Tue, 24 May 2016 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KEznvHhB7jOi for ; Tue, 24 May 2016 18:07:31 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 A5F0312D100 for ; Tue, 24 May 2016 18:07:31 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t145so21905139qke.2 for ; Tue, 24 May 2016 18:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sxaondNbmMkv6mLKe00eudHOaaM728OYJevDxHWoY+A=; b=4gzm89uVxNcPbvjdYXDUpqgopRzwg3zVW1CTiaGsMpQaGI6WZsP2t2X+GSyrLub1fp 0apOJdxUBKUeNezba5OQnqbl+GLhafL1oWVuCe+jr1EXByZ+05UN7gTJeSwgzZCf6T1B lMtXdpoCrwL6eobCiF+KGPDKhEmokCdfO+ouU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sxaondNbmMkv6mLKe00eudHOaaM728OYJevDxHWoY+A=; b=f0zRljWQx/KuduAusI9gDo3RDBYMpqp+UkLNfZ4HjOr08QemSjk/FYlZ7Wj0KUjnbO 43b7EbGdl+C+quBDGafm8LpjZw5rz41awPnLfqNBwHjYv/W8SbJmJwWDziqElNTRssFT KzcrdqXkkOBnmsjJFzh6RHoMcq8BwvyOnz4PHjHrbnTCSfqFjHZl+v+6TlQmJYFJ8kXZ SkwOOpq4N6L2g4BH64SAlK0j2ESjewIPTJfdFZPMQlwPocuJsrUI3cW2m4/4yOp6hb+t m8UMmDsEgM1OTIqdXa8RN5t/KJFdlpuzlJyR/dI1Y+VI5YOC5tpWr1OIsU3SIP2d3KdL zfTw== X-Gm-Message-State: ALyK8tKHceRlHL5VOIEvJ/tN8lxe2r3MMFiWZ0nzPKL9TrqfDKRF+QALubwgsVfxXPgSrCSuIimRG2fTBdJ89g== X-Received: by 10.55.215.132 with SMTP id t4mr1136347qkt.66.1464138450704; Tue, 24 May 2016 18:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.85 with HTTP; Tue, 24 May 2016 18:07:16 -0700 (PDT) In-Reply-To: References: From: Austin William Wright Date: Tue, 24 May 2016 18:07:16 -0700 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=001a1149dd5e41b6c20533a04c20 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 01:07:33 -0000 --001a1149dd5e41b6c20533a04c20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also use them as specification aids, I think JSON Hyperschema is a great tool to make JSON APIs become RESTful (because it's self-documenting). I also use them for validation and sanity checking, like an assert() call: It's not something that should ever trip, but it's there in case the impossible happens (but that would never happen, right?). I agree with your opinion it's troubling, though. Unfortunately it's hard to strike a balance between making something that's easy to compose and easy to read, versus something that's expressive and gives you exactly the right error message. I'd love to talk how to fix this problem, though! It seems like this problem is closely tied with automatic UI generation. How would I design a form to enter data of the kind that you're expecting? Three separate forms? A master drop-down that automatically changes the remaining fields and automatically populates the "Type" one? Move the "Type" drop-down first, and change all the other fields if it changes? What if I want to change the type of an entity from Vegetable to Plant? It seems if we can answer these questions, we would also tackle your validation errors problem for free. Austin. On Mon, May 23, 2016 at 8:54 PM, Tim Bray wrote: > Hmm, I have to excerpt one line here: > > On Mon, May 23, 2016 at 6:30 PM, Austin William Wright > wrote: > >> >> In general, JSON Schema and many other schemas are designed to ensure >> things are valid. They're not well engineered to help people fix things >> when they're invalid. >> > > =E2=80=8BI find this troubling. I expect modern compilers to give me hig= hly > actionable errors, with line numbers. Is the nature of JSON DSL=E2=80=99s= and > programming languages so deeply different that this is not a reasonable > thing to ask a schema processor to do? > > If so, then what are schemas for? I=E2=80=99ve seen them as having two u= ses: > > 1. Specification aids > 2. Debugging aids > > For #1, I see schemas as a poor second-best to clear human-readable > description. > For #2, Schemas are appealingly declarative and presumably much more > compact than the equivalent declarative code. But if they can=E2=80=99t = tell me > what the problem is, why bother? And furthermore, I=E2=80=99ve never tho= ught > validators could rely on schemas alone, because schemas can=E2=80=99t che= ck > semantic constraints (=E2=80=9Cis that a valid part number?=E2=80=9D) > > > > --001a1149dd5e41b6c20533a04c20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also use them as specification aids, I think JSON Hypers= chema is a great tool to make JSON APIs become RESTful (because it's se= lf-documenting).

I also use them for validation and sanity checking, like an assert() c= all: It's not something that should ever trip, but it's there in ca= se the impossible happens (but that would never happen, right?).

I agree with you= r opinion it's troubling, though. Unfortunately it's hard to strike= a balance between making something that's easy to compose and easy to = read, versus something that's expressive and gives you exactly the righ= t error message.

I'd love to talk how to fix this problem, though!
<= div class=3D"gmail_extra">
It seems lik= e this problem is closely tied with automatic UI generation. How would I de= sign a form to enter data of the kind that you're expecting? Three sepa= rate forms? A master drop-down that automatically changes the remaining fie= lds and automatically populates the "Type" one? Move the "Ty= pe" drop-down first, and change all the other fields if it changes? Wh= at if I want to change the type of an entity from Vegetable to Plant? It se= ems if we can answer these questions, we would also tackle your validation = errors problem for free.

Austin.

On Mon, May 23, 2016 at 8:54 PM, Tim Bray <tbray@tex= tuality.com> wrote:
Hmm, I have to excerpt one line here:

On Mo= n, May 23, 2016 at 6:30 PM, Austin William Wright <aaa@bzfx.net> = wrote:

In general,= JSON Schema and many other schemas are designed to ensure things are valid= . They're not well engineered to help people fix things when they'r= e invalid.

=E2=80=8BI find this troubling.=C2=A0 I expect modern com= pilers to give me highly actionable errors, with line numbers. Is the natur= e of JSON DSL=E2=80=99s and programming languages so deeply different that = this is not a reasonable thing to ask a schema processor to do?

If so, th= en what are schemas for?=C2=A0 I=E2=80=99ve seen them as having two uses:

1. Specification aids
2. Debugging aid= s

For #1, I see schemas as a poor second-best to clear human-readable des= cription.
For #2, Schemas are appealing= ly declarative and presumably much more compact than the equivalent declara= tive code.=C2=A0 But if they can=E2=80=99t tell me what the problem is, why= bother?=C2=A0 And furthermore, I=E2=80=99ve never thought validators could= rely on schemas alone, because schemas can=E2=80=99t check semantic constr= aints (=E2=80=9Cis that a valid part number?=E2=80=9D)




--001a1149dd5e41b6c20533a04c20-- From nobody Tue May 24 18:26:11 2016 Return-Path: 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 C2C4A12D6AE for ; Tue, 24 May 2016 18:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QCy3xAZ5vWzc for ; Tue, 24 May 2016 18:26:08 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 2037812D521 for ; Tue, 24 May 2016 18:26:08 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id y126so24705916qke.1 for ; Tue, 24 May 2016 18:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=AGy3NbeTt5lyUSgBZfIH2n9O/nP6e3VI347bYLQ1MDM=; b=orPK76VR43p30L5j/gFHrFv9VVw1dMnb0kOKXGk/eaYoRFP95Bjg3eQnWDaLSM8qH7 nl9cKjoF/vxIpk2xjTKwdaRtPEhYF3OHwZbw3f46c3fyEVKPtE2RE0uqA5i52jRUYtc6 qk9KWjGB2v/+a/lrCyoV8tnASUlNnX3H9p/BRGdynt3Gp18E49tJ39z8tTwiJdvtNwzF pUw0CiQ5lcpZQ7NoJRLpYRimiLov1sKJGD9iObD90jkxRBsj3ImQJ926a2r4DmgX1mRb DLMMapVBq+cC3eMr5qQQIJywRKpUpyHtUSYfGSLENtKap8fl0cZENE5Xo/57G8GVYF+A i9sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AGy3NbeTt5lyUSgBZfIH2n9O/nP6e3VI347bYLQ1MDM=; b=MbJBPIY5JdGdFmAW61XpKRj0y2fiX9UaHLuixAAh23dEzwv+/bZBArTQdo2ltMUETf lBUPXzjPkJL+BP/jEKkv/Z0eRpsWaBqcUZIhPoJHEuND3eJwsDkqRMlDuZp7ny5eiGnF ayZqIl6vrlzlGcPTGgjZizVSBHyB9rMrHLXskD0KoCuQiQelGuZ3vnVTnFti2X8yzUI0 79ibCOPMre3wcrG7JlYwICiViuBkonIqKxjqIijEEWv9sbIc8MPi6A9LVSSxFYayjIbN Hi3jULd3kembEKhLy7JSSavH/KjMYJpEN8t1gArwDgVDyA974iHbZknAAc3UN32wjRjV f8RQ== X-Gm-Message-State: ALyK8tIFN5owi+oLDrAwN3MCAh9imcC73VvJM4hvrVSY/HS2oROcLBcMj34ZbX6qy94E2HqpyeznOZ7/XPs8RA== MIME-Version: 1.0 X-Received: by 10.55.114.71 with SMTP id n68mr1181242qkc.37.1464139567168; Tue, 24 May 2016 18:26:07 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.105 with HTTP; Tue, 24 May 2016 18:26:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 21:26:06 -0400 X-Google-Sender-Auth: Q-Nyzsng4z1ntaPPSqxirGwZKVg Message-ID: From: Phillip Hallam-Baker To: Austin William Wright Content-Type: multipart/alternative; boundary=001a114fef8acd80b80533a08eb7 Archived-At: Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 01:26:10 -0000 --001a114fef8acd80b80533a08eb7 Content-Type: text/plain; charset=UTF-8 On Tue, May 24, 2016 at 9:07 PM, Austin William Wright wrote: > I also use them as specification aids, I think JSON Hyperschema is a great > tool to make JSON APIs become RESTful (because it's self-documenting). > > I also use them for validation and sanity checking, like an assert() call: > It's not something that should ever trip, but it's there in case the > impossible happens (but that would never happen, right?). > > I agree with your opinion it's troubling, though. Unfortunately it's hard > to strike a balance between making something that's easy to compose and > easy to read, versus something that's expressive and gives you exactly the > right error message. > > I'd love to talk how to fix this problem, though! > > It seems like this problem is closely tied with automatic UI generation. > How would I design a form to enter data of the kind that you're expecting? > Three separate forms? A master drop-down that automatically changes the > remaining fields and automatically populates the "Type" one? Move the > "Type" drop-down first, and change all the other fields if it changes? What > if I want to change the type of an entity from Vegetable to Plant? It seems > if we can answer these questions, we would also tackle your validation > errors problem for free. > Funny you should say that. This past couple of weeks I have resurrected the GUI generator I built for X-Windows before working on the Web. [The new version targets GTK as primary and will probably do Windows Forms and HTML in due course] Yes, there are similarities between the problems. In both cases you have an abstract model and a presentation of that model, a View for the UI and a serialization for JSON. Yes, if one had the problem of producing both, you could share a lot of code. But not so much as you might expect. A GUI is a Model-View-Controller app and unlike the problem of serializing/deserializing JSON, you have to do a lot of validation on the inputs. In particular you need to be able to validate a dialog box when the user hits 'Accept' and tell them where they went wrong. You also need to be able to support 'cancel'. In short, it ends up as a very much more involved problem if you are going to do it right. XML is as complex as it is because it supports features that allow text editors to validate input as people type. And JSON is simpler because it does not support those features. And if you try to turn JSON into XML you will probably end up with something almost as complex. --001a114fef8acd80b80533a08eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2016 at 9:07 PM, Austin William Wright <aaa@bzfx.net>= ; wrote:
I also u= se them as specification aids, I think JSON Hyperschema is a great tool to = make JSON APIs become RESTful (because it's self-documenting).

I also use them for = validation and sanity checking, like an assert() call: It's not somethi= ng that should ever trip, but it's there in case the impossible happens= (but that would never happen, right?).
I agree with your opinion it's troubl= ing, though. Unfortunately it's hard to strike a balance between making= something that's easy to compose and easy to read, versus something th= at's expressive and gives you exactly the right error message.

I'd love t= o talk how to fix this problem, though!

It seems like this problem is closely= tied with automatic UI generation. How would I design a form to enter data= of the kind that you're expecting? Three separate forms? A master drop= -down that automatically changes the remaining fields and automatically pop= ulates the "Type" one? Move the "Type" drop-down first,= and change all the other fields if it changes? What if I want to change th= e type of an entity from Vegetable to Plant? It seems if we can answer thes= e questions, we would also tackle your validation errors problem for free.<= /div>


Funny you should= say that. This past couple of weeks I have resurrected the GUI generator I= built for X-Windows before working on the Web. [The new version targets GT= K as primary and will probably do Windows Forms and HTML in due course]

Yes, there are similarities between the problems. In = both cases you have an abstract model and a presentation of that model, a V= iew for the UI and a serialization for JSON. Yes, if one had the problem of= producing both, you could share a lot of code. But not so much as you migh= t expect.

A GUI is a Model-View-Controller app and= unlike the problem of serializing/deserializing JSON, you have to do a lot= of validation on the inputs. In particular you need to be able to validate= a dialog box when the user hits 'Accept' and tell them where they = went wrong. You also need to be able to support 'cancel'.

In short, it ends up as a very much more involved problem i= f you are going to do it right. XML is as complex as it is because it suppo= rts features that allow text editors to validate input as people type. And = JSON is simpler because it does not support those features. And if you try = to turn JSON into XML you will probably end up with something almost as com= plex.

=C2=A0
--001a114fef8acd80b80533a08eb7-- From nobody Tue May 24 22:33:14 2016 Return-Path: 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 4EDF112DA3C for ; Tue, 24 May 2016 22:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 asfoi-qh_zJg for ; Tue, 24 May 2016 22:33:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 0292212DA3E for ; Tue, 24 May 2016 22:33:10 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D23F0509B5 for ; Wed, 25 May 2016 01:33:09 -0400 (EDT) To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> From: Sean Leonard Message-ID: Date: Tue, 24 May 2016 22:31:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5744E92B.3010704@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 05:33:12 -0000 On 5/24/2016 4:52 PM, Carsten Bormann wrote: > First, the name. If something calls itself X, it should be an X. > > HJSON is not JSON. It is a Hacked JSON. > > Second, > >> People seem to prefer JSON for >> configuration over YAML and other config formats. > Can't be. YAML *contains* JSON. > If you like JSON, you already like YAML, because every JSON file is a > YAML file. > (You may not like what else YAML brings to the table, but that would be= > a mistake.) > > (If you like JSON mostly because everything is JSON, well: HJSON isn't.= ) > > Third, YAML also isn't stuck with the limitations of the JSON data mode= l. > Binary data, maps with keys that aren't strings, etc. > > I'm not opposed to writing a spec for a Hacked JSON. However, I think > the time spent for doing that would be much better invested in an > updated spec for YAML. Yeah I pretty much agree with Carsten. A nice effort, but I do not=20 support moving forward with this as-is. More thoughts in a separate=20 e-mail (eventually). Regards, Sean From nobody Tue May 24 23:49:26 2016 Return-Path: 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 E64CB12D5BF for ; Tue, 24 May 2016 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 JRLrPwQE0jKA for ; Tue, 24 May 2016 23:49:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 9B8B812DA5C for ; Tue, 24 May 2016 23:49:18 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5D8FA509B5; Wed, 25 May 2016 02:49:17 -0400 (EDT) To: json@ietf.org, Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> From: Sean Leonard Message-ID: <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> Date: Tue, 24 May 2016 23:48:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 06:49:25 -0000 On 5/24/2016 2:36 PM, Christian Zangl wrote: > JSON is used in a lot of places and has helped improve things like=20 > data exchange and data storage. It is also used in areas it's less=20 > suited for, like configuration files. People seem to prefer JSON for=20 > configuration over YAML and other config formats. > > I started Human JSON (Hjson) because I found the experience=20 > frustrating (for example missing/trailing comma problems, no=20 > comments). With Hjson you get a superset of JSON that allows you to > > - add #, // or /**/ comments, > - omit quotes for keys, > - omit quotes for strings (terminated by LF, no escapes), > - omit braces for the root object, > - omit the comma at the end of a line > - add trailing commas and > - use multiline strings with proper whitespace handling. > > These changes should make it easer to read and write configs while=20 > still preserving the power of JSON. > Thoughts? I read through the document with interest. It's a nice idea. I don't=20 discourage it in general. But... It seems that what you want is a configuration file format. There are=20 already many config file formats, as well as many textual data formats.=20 YAML comes to mind. This looks like YAML (certainly, a subset of it) a=20 lot more than JSON or even JavaScript. Why not just embed completely valid JSON items in the configuration file = format of your choice? That seems a lot more practical. Configuration=20 files usually say "name=3Dvalue" anyway, not "name: value". # is not comment syntax in JSON, or JavaScript. It's from config files=20 and scripts. Hence demonstrating that this is not really JSON-related. You say "omit braces for the root object", but then it's not JSON. If=20 you include the braces, then it's JSON, and it's annoying for humans to=20 write. Humans are lazy and don't like to balance < > tags or { } braces. = They like line breaks by hitting Enter to separate things. But line=20 breaks are not separators in JSON/JavaScript. JSON/JS are designed to=20 let the author put in line breaks wherever he/she/it wants, to aesthetic = taste. And vice-versa for commas. It's easy to balance { } braces when=20 you just have a couple of them, i.e., a simple JSON object that is the=20 single value of a single config element on a single line. Your format should not get a media type. If it is for "humans", it needs = to be text/*, such as text/plain. Humans edit things with editors, that=20 work on text. As text, you cannot assume UTF-8 encoding. It's just a=20 stream of text. If a user chooses to author this format in Shift-JIS (or = if that's the locale/code page in effect on the local machine), that's=20 the user's choice. You cannot ignore the implications of the charset=20 parameter. Finally, since the draft explicitly disavows use in transfer protocols=20 and so forth, it's not appropriate for Standards Track. I'd suggest=20 Experimental. Regards, Sean From nobody Tue May 24 23:52:15 2016 Return-Path: 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 91DC012DA5B for ; Tue, 24 May 2016 23:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.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 W6UQb4u3YdyL for ; Tue, 24 May 2016 23:52:11 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 9328B12D644 for ; Tue, 24 May 2016 23:52:11 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a136so108346277wme.0 for ; Tue, 24 May 2016 23:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=OVcrt/ZkKk41h02uJq9lAqJKKAphx49rCWQNMfa+YEo=; b=bL/NRde3W92TWtYCL4JZxI01WNVonkTzkjPpgCiAl9fGJ9Cjq8uNDncNyimb9zf9XA uNfyaAxqnU6Gwlv/IqobgqfhdP15gMcaGzDh6TEd5JQ9LgT77nsGAJQsYIA9N7K2d+Jk c6EGhL9SwFPAeJIuAtGDTASpUFzSM36QP8jfimmCGzrOrcvzlFzh0r9hneN2MR5ir36f LVfwU0O0x0KKhg1G5YxMBAJXd6coGN1taXy5b79ig2iGvy6sAO3KlttlW+ktF8ZZv9+l kS0RKECQSVmGp7ctqT/RwBui0EuUVBpr1R8+N8J4i6hMDLLQLsYuqRzARjQ0Ss0avw/2 Litw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=OVcrt/ZkKk41h02uJq9lAqJKKAphx49rCWQNMfa+YEo=; b=DwfYekaLDpZF6uewa4qeMGpxsq9kAQ9RG9IvGcQewNIHxoYuuFae27E82y/QjE6G7s nZHUAZqWc9VrITM2yLDLWWL6Nc/FdN6uDqCpf9JTZzaAgrgUoOteC4F3hkcxi66RGqZv 0GkaDQ/eY8S0/6X9KdMH4Ja+kH/b9DqZzNHMbYO++j4Vn55D9noz3nQMQnr8x0QtqcSF MSapFvYzarujuCQuJ7Bpf9QizZ1CgKj+1NveuENm+kJp4oA4KSeVRwiy98ha/O1hk0ta guSOSn2QV02KM44fFEdnpDIa/AJ/GQ5bWQl8iUwIef6Gp1n9dH+6ONzfCIitVCYTnmmI WKkw== X-Gm-Message-State: ALyK8tJoDBjD7wkqI/DcTytKG65WCVlr2UhvdA5IHtL5Z0RE5VknK2OOzHmrxzrZ1aA5Q3UVI8PSsgN3/ugGsA== MIME-Version: 1.0 X-Received: by 10.28.212.8 with SMTP id l8mr1516559wmg.11.1464159129955; Tue, 24 May 2016 23:52:09 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Tue, 24 May 2016 23:52:09 -0700 (PDT) X-Originating-IP: [94.127.55.205] In-Reply-To: References: Date: Wed, 25 May 2016 02:52:09 -0400 Message-ID: From: Andrew Newton To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Austin William Wright , "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 06:52:13 -0000 On Mon, May 23, 2016 at 11:54 PM, Tim Bray wrote: > Hmm, I have to excerpt one line here: > > On Mon, May 23, 2016 at 6:30 PM, Austin William Wright wro= te: >> >> >> In general, JSON Schema and many other schemas are designed to ensure >> things are valid. They're not well engineered to help people fix things = when >> they're invalid. > > > I find this troubling. I expect modern compilers to give me highly > actionable errors, with line numbers. Is the nature of JSON DSL=E2=80=99s= and > programming languages so deeply different that this is not a reasonable > thing to ask a schema processor to do? It's not too much to ask, but the problem may be with the JSON parser. Many parsers ingest JSON and give back native data structures, which is what makes JSON simple for most people. But a validator needs context that a typical JSON parser does not provide. > > If so, then what are schemas for? I=E2=80=99ve seen them as having two u= ses: > > 1. Specification aids > 2. Debugging aids While not typical, being malleable enough to aid the creation of testing harnesses is a great third use. > > For #1, I see schemas as a poor second-best to clear human-readable > description. In my experience, many non-English readers greatly benefit from a formal syntax. And depending on the complexity of the problem, prose cannot strike the right balance between precision and TLDR. > For #2, Schemas are appealingly declarative and presumably much more comp= act > than the equivalent declarative code. But if they can=E2=80=99t tell me = what the > problem is, why bother? And furthermore, I=E2=80=99ve never thought vali= dators > could rely on schemas alone, because schemas can=E2=80=99t check semantic > constraints (=E2=80=9Cis that a valid part number?=E2=80=9D) Certainly they are no replacement for application logic, but I don't think anybody ever made that claim. -andy From nobody Wed May 25 00:22:22 2016 Return-Path: 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 02A4A12D60C for ; Wed, 25 May 2016 00:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lHN6Qp77w0nI for ; Wed, 25 May 2016 00:22:18 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 762A012D5F7 for ; Wed, 25 May 2016 00:22:18 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a136so109537748wme.0 for ; Wed, 25 May 2016 00:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BTnRr8pKisjAFmVlpKUXgyHB+uIN1fJthljTttjLJmE=; b=VKpZkCBokiqy3M96UP1l8sHXALoievgpqPLDl9rclWjlHaojH3g7WaXVlc2PAsAZ/b vEHorwAVLrrtl3u4UFn6+6OX/JqC1NW/V1Yhh8gN3+1kGrF8MgbJXqNgR4AHPLnrPgqq p3jHXWPfKks4Zvc1jBT1e8jMhmAB9rPLxTpHCUeLfTFn8RP6sbVzDTVuTiY7TMiD6jIA yskbknbDSTfWP2Q4CsKt2tVonKZtf0asgYfD8sQxk9t7elYTtWTViY/7RbxoNIjCWXIL FR9krYjVfxcFKmybgLcZuvXV9gSivb9BG8ZBfwVvshYY0t9+uAmsDfX/kPfyuK0S+iQf B4PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BTnRr8pKisjAFmVlpKUXgyHB+uIN1fJthljTttjLJmE=; b=GYtpKXaYcrnbwt7s3cfRb67F4acobVtoJHCXcihndFvDPiCbyJ8gZm6Q9WpbvAN05q b1KmJtN7BIMdtnH+kHjlCNn8WFZGxzpEO8OXQdbSt44YIZAilZB3JZSxe91jCeaSp5n7 45M4eQOhLw0Nv5jssiBd9o+qjNbZb8lETnxQ9fHp66VLAZWWbj4KfUVgg3d/pZ1XOtUo tiGFIeu9yVsQaYrOd9xqEnXtWikJ9cpd2tH8nLImhXYO7oQ4UmPBXvK5qzEsgRZL/ucR DMTu44Gd6UjyA5/3YvmYQWJO3IdueiIJ6B7hSOT0M1OSJ/AqbO3fBitZqQ5cAtlNSVBI n9fQ== X-Gm-Message-State: ALyK8tJuuIceCQt5yHha5gJ6EleJWM9nHKo0oBu30U+pLCwgr0nRoc11MSEw3OWq81FcXA== X-Received: by 10.28.137.210 with SMTP id l201mr1637335wmd.31.1464160936946; Wed, 25 May 2016 00:22:16 -0700 (PDT) Received: from [192.168.1.181] (178.113.72.111.wireless.dyn.drei.com. [178.113.72.111]) by smtp.googlemail.com with ESMTPSA id hm7sm7079062wjb.41.2016.05.25.00.22.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 00:22:16 -0700 (PDT) To: Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> From: Christian Zangl Message-ID: Date: Wed, 25 May 2016 09:22:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5744E92B.3010704@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:22:20 -0000 > Can't be. YAML *contains* JSON. > If you like JSON, you already like YAML, because every JSON file is a > YAML file. Hjson *contains* JSON, every JSON file is also a Hjson file, so you must like Hjson? From nobody Wed May 25 01:16:12 2016 Return-Path: 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 B9AA412B047 for ; Wed, 25 May 2016 01:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Js5qPi8USJHU for ; Wed, 25 May 2016 01:16:09 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17F912B010 for ; Wed, 25 May 2016 01:16:09 -0700 (PDT) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5171C17214F; Wed, 25 May 2016 10:16:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id WXvZ-1bD-Wo7; Wed, 25 May 2016 10:16:06 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id BFDC317210A; Wed, 25 May 2016 10:16:05 +0200 (CEST) Message-ID: <57455F43.6010506@tzi.org> Date: Wed, 25 May 2016 10:16:03 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 08:16:11 -0000 Christian Zangl wrote: >> Can't be. YAML *contains* JSON. >> If you like JSON, you already like YAML, because every JSON file is a >> YAML file. > > Hjson *contains* JSON, every JSON file is also a Hjson file, so you must > like Hjson? Since you ask what I like: HUMANS SHOULD NOT BE WRITING JSON *), so, no, I don't like JSON as a configuration file format. The people I have met who didn't know about YAML usually liked .ini-style **) configuration file formats, as exemplified by TOML ***). Since my experience is that every configuration file format turns more and more complex over time, I prefer to base them on a powerful generic format such as YAML. YAML is also pretty good in noise reduction. (And, as I noted, if you are really itching to write JSON, or have some JSON data that you just want to paste in, you can do so in YAML.) As another data point, CBOR diagnostic notation is based on JSON. Ouch; this is actually meant to be written and read by humans. The CDDL draft then goes ahead and defines an extended diagnostic notation to reduce some of the hurt (not needed for CDDL itself, but it helps for notating CBOR examples, e.g., in the COSE draft). Grüße, Carsten *) https://mumble.org.uk/blog/2014/09/23/json-and-the-arguments/ and a million other people have found that out... **) https://en.wikipedia.org/wiki/INI_file ***) https://github.com/toml-lang/toml From nobody Wed May 25 01:36:59 2016 Return-Path: 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 6B3A712D12C for ; Wed, 25 May 2016 01:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DP99AHxf2kvs for ; Wed, 25 May 2016 01:36:56 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 21A1412D10C for ; Wed, 25 May 2016 01:36:55 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n129so168965377wmn.1 for ; Wed, 25 May 2016 01:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ooBHtbh9f3TExa0YCE6x6gasI62y7v0ZQP+ObngA3ak=; b=SGUyKsJC9q+0BngUUFcNlpafHg9GsYftjx2goSyyyTbMn3gA6+xTr99v+sU0mEl79D U2dkXfA5SXZbHudsZ0kb8CxZj/8Px7VUCcj1Vccx1Lwwg1Fu90o1DEJmfX9pTRkw2pME pACRQDF4j8M9OWIrsaJamcqwzHOVBxC/7fvAx8OmLOdeXr4GAINP9v/3z/SwBqvTai7p /4utoHTFxPHDK2YrLjQrXVpOaNCQPs5HgW9NQivRnoMmamiBN1shkkcugvwGqYl8JHA9 2PR3KN8vyTiZhw2iBgVZXoK13G+xJJDuK6qvsdy/29UBtxuTHEr+BTl1ybcb/4+8WY/d LitQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ooBHtbh9f3TExa0YCE6x6gasI62y7v0ZQP+ObngA3ak=; b=dtztvXg1O+ixeKMnRiQw6Euk2I9VZExPHYkfj16IQ700wzJRLLl2Xqp669mVJCac+J smSpmjd3NZb2D460eyDzM28q1EXoObx24Tq7w20yxx24zIuro1c+ZFWhQgCEOkwkMVSY Y0qTpdjRFApq2IbIO8jxrGN8NrdjoHO65cL5y2q9VY1w1mN/udjSY+Xcdc2zWOOemHBd rRfOYecB1aR3Rp8RRIhGqgkaAsAzruNKzxS8H+NUU+cSLeL0u/EW0lA0xjXjzWxOnM9q Tp20wGdFfC8ieJek8zgRWxm+Cui8FhkRiHFTQ5adtFgdeI7kx4J3uA3XUdGS0E+0S8pq AKWA== X-Gm-Message-State: ALyK8tImSCLcn+VvZsxJHDtb+QkQfJAg39VDyvTP1tuQrexnnYA2zUlVvYL98Ts6O7mVXQ== X-Received: by 10.28.137.14 with SMTP id l14mr2016962wmd.64.1464165414180; Wed, 25 May 2016 01:36:54 -0700 (PDT) Received: from [192.168.1.181] (178.113.72.111.wireless.dyn.drei.com. [178.113.72.111]) by smtp.googlemail.com with ESMTPSA id f11sm23595609wmf.22.2016.05.25.01.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 01:36:53 -0700 (PDT) To: Sean Leonard , json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> From: Christian Zangl Message-ID: <21160816-48c7-169e-5a83-19b7601420a0@gmail.com> Date: Wed, 25 May 2016 10:36:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 08:36:58 -0000 On 2016-05-25 08:48, Sean Leonard wrote: > It seems that what you want is a configuration file format. There are > already many config file formats, as well as many textual data formats. > YAML comes to mind. This looks like YAML (certainly, a subset of it) a > lot more than JSON or even JavaScript. Yes this is another config file format. Why? Because I think that using JSON for configs is an antipattern. Since YAML&others are not a good option (to some people) Hjson is positioned as a reasonable alternative. > Why not just embed completely valid JSON items in the configuration file > format of your choice? That seems a lot more practical. Configuration > files usually say "name=value" anyway, not "name: value". I'm not sure what you mean here. If I embed JSON in the config I have the same problems as using JSON for configs in the first place. > # is not comment syntax in JSON, or JavaScript. It's from config files > and scripts. Hence demonstrating that this is not really JSON-related. JSON was 'discovered' in JavaScript, hence it's name, but has since been ported to 50+ languages. While JavaScript is evolving, JSON is fixed at v1 (not a bad thing). So to me, apart from the name, JSON isn't JavaScript anymore. JSON doesn't allow comments so selecting # seemed practical (IMO it's nicer to read than //). // and /**/ comments were added because it was a popular request. > You say "omit braces for the root object", but then it's not JSON. If > you include the braces, then it's JSON, and it's annoying for humans to > write. Humans are lazy and don't like to balance < > tags or { } braces. > They like line breaks by hitting Enter to separate things. But line > breaks are not separators in JSON/JavaScript. JSON/JS are designed to > let the author put in line breaks wherever he/she/it wants, to aesthetic > taste. And vice-versa for commas. It's easy to balance { } braces when > you just have a couple of them, i.e., a simple JSON object that is the > single value of a single config element on a single line. Hjson is a superset of JSON. You don't have to omit them but they are optional for the root. You need something to define the structure. Braces are there because JSON has them and because the alternatives (like indentation) seem worse. Hjson allows line breaks to be separators instead of commas. > Your format should not get a media type. If it is for "humans", it needs > to be text/*, such as text/plain. Humans edit things with editors, that > work on text. As text, you cannot assume UTF-8 encoding. It's just a > stream of text. If a user chooses to author this format in Shift-JIS (or > if that's the locale/code page in effect on the local machine), that's > the user's choice. You cannot ignore the implications of the charset > parameter. I can remove the media type but wouldn't it help with file associations/editor syntax? Joe suggested to require UTF-8, it made sense to me. https://github.com/laktak/hjson/issues/43 > Finally, since the draft explicitly disavows use in transfer protocols > and so forth, it's not appropriate for Standards Track. I'd suggest > Experimental. OK. Thanks for the feedback! From nobody Wed May 25 09:27:37 2016 Return-Path: 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 4A77212D84C for ; Wed, 25 May 2016 09:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 6IgEN6TooM0K for ; Wed, 25 May 2016 09:27:33 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 2B07D12D855 for ; Wed, 25 May 2016 09:27:33 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id t40so35602051ioi.0 for ; Wed, 25 May 2016 09:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=/7523epmJ82kDtK58Dy6y7BVhxAcMEjEVnl5WJfg4Pg=; b=EuuTUveThsmPmIZVtr6bh3pzbgVdCeREwyvayun+1rw9w945UfVS2emEekr2nW5rSB JVl2OALaRVYcWxSdPVMMhZYfLb8DD/Gzjy3C7buLuL1u0+oL+B4JECVXikLZi6BtWnNN H0rJmg9rWbLGvBiIffGZrjPY/oV1n1E5mKGU0z7bbGoeR4I8y3vLUpmEkI79NZP3og3y 7UwCWdXMCV0eqiMOY21lL8alUN9jJODBdd+9nlFBA6B6zKB4ZxAS2C1oG4rWB9J8hgln tCiAFc5mLyti6Z6XVO16VCUIR9BTxZ/ZI024X0v8MbDb2jFEGHL+j0qDHou3UctmUf6S aykg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=/7523epmJ82kDtK58Dy6y7BVhxAcMEjEVnl5WJfg4Pg=; b=iA0K9T8FEKPAWERTmW8mdLNHjDQ0P6MLa6U18MRVDNDZGtY4gRSC2YM8/Nc8XE8M5y 6sb46qopAO/AJLSBdPHbV80vcLi5ULftEEJDXVOIrMtQls0JH9CQPb24fa0RKk4NYoG0 kBuFs7V3sJ9x7pyRVrEBnXTPZvJ35BCTKUZnSzpomXqNvnATRhNP9Hms3vAfchgcWBru rnCfS7/WyMfzPoWZm3Aat/k++4vy0YBctUBi6U8TZ5+OKTThhvD1n7oBYd4J7lpY7Zcu s/ancExMaFUX6D7Y2Jk1gNJe7xG7vRiEkNnbAr125HG3nrIA8U34zl873067OwLPOhTh /QUw== X-Gm-Message-State: ALyK8tLoPuxahLLxYWD6wuRKVVSVjf203J7XoCdJwPfflyDX6jtTUUeDNeaw3QSgjzX4A7WjDCdUfO5xuL6lrA== MIME-Version: 1.0 X-Received: by 10.107.62.196 with SMTP id l187mr4411808ioa.185.1464193652447; Wed, 25 May 2016 09:27:32 -0700 (PDT) Received: by 10.64.77.233 with HTTP; Wed, 25 May 2016 09:27:32 -0700 (PDT) Received: by 10.64.77.233 with HTTP; Wed, 25 May 2016 09:27:32 -0700 (PDT) In-Reply-To: References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> Date: Wed, 25 May 2016 18:27:32 +0200 Message-ID: From: Stefan Reich To: json@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0610628967980533ad26fe Archived-At: Subject: [Json] Fwd: Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 16:27:35 -0000 --94eb2c0610628967980533ad26fe Content-Type: text/plain; charset=UTF-8 ---------- Weitergeleitete Nachricht ---------- Von: "Stefan Reich" Datum: 25.05.2016 18:27 Betreff: Re: [Json] Human JSON (Hjson) An: "Christian Zangl" Cc: I did a similar thing called JSON+C (JSON with comments). Stefan Am 24.05.2016 23:36 schrieb "Christian Zangl" : > JSON is used in a lot of places and has helped improve things like data > exchange and data storage. It is also used in areas it's less suited for, > like configuration files. People seem to prefer JSON for configuration over > YAML and other config formats. > > I started Human JSON (Hjson) because I found the experience frustrating > (for example missing/trailing comma problems, no comments). With Hjson you > get a superset of JSON that allows you to > > - add #, // or /**/ comments, > - omit quotes for keys, > - omit quotes for strings (terminated by LF, no escapes), > - omit braces for the root object, > - omit the comma at the end of a line > - add trailing commas and > - use multiline strings with proper whitespace handling. > > These changes should make it easer to read and write configs while still > preserving the power of JSON. > > Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You > can find the draft here: http://hjson.org/rfc.html There are also syntax > diagrams and more at http://hjson.org/syntax.html > > Thoughts? > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --94eb2c0610628967980533ad26fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
---------- Weitergeleitete Nachricht ----------<= br>Von: "Stefan Reich" <stefan.reich.maker.of.eye@googlemail.com>
D= atum: 25.05.2016 18:27
Betreff: Re: [Json] Human JSON (Hjson)
An: &qu= ot;Christian Zangl" <corall= lama@gmail.com>
Cc:

I= did a similar thing called JSON+C (JSON with comments).

Stefan

Am 24.05.2016 23:36 schrieb "Christian Zang= l" <coral= llama@gmail.com>:
JSON is used in a lot of places and has helped improve things like dat= a exchange and data storage. It is also used in areas it's less suited = for, like configuration files. People seem to prefer JSON for configuration= over YAML and other config formats.

I started Human JSON (Hjson) because I found the experience frustrating (fo= r example missing/trailing comma problems, no comments). With Hjson you get= a superset of JSON that allows you to

- add #, // or /**/ comments,
- omit quotes for keys,
- omit quotes for strings (terminated by LF, no escapes),
- omit braces for the root object,
- omit the comma at the end of a line
- add trailing commas and
- use multiline strings with proper whitespace handling.

These changes should make it easer to read and write configs while still pr= eserving the power of JSON.

Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You ca= n find the draft here: http://hjson.org/rfc.html There are also syntax = diagrams and more at http://hjson.org/syntax.html

Thoughts?

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--94eb2c0610628967980533ad26fe-- From nobody Wed May 25 11:19:20 2016 Return-Path: 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 69A5212D8B2 for ; Wed, 25 May 2016 11:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d45VtvVNe8dL for ; Wed, 25 May 2016 11:19:17 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 D0C0312D8A9 for ; Wed, 25 May 2016 11:19:16 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id 190so6066889iow.2 for ; Wed, 25 May 2016 11:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=UD461lFzVgYSMoZvzYJe9RzHcVVhQ855ZIcNXCKAMe8=; b=DTD6JQCNrtHzg1IlEOUnEn3ItWXSTIdOIvfYVXB/GpDYhSgFIPr5sGr6rZGf8/2R+P 3tda6xbLP9tfNtIuFI0B7srZZFyaXLXXV14/B+SzbFGquTYTe8B0hDTUDbsN6kpVH43c hn3gJURZK+XnEQcQE1915fqUIOWYjj0Eu1vUWxHI5RNakqBUupyV3cgxA1cp8xiUPzIY jyqYkNDL3Lf347Dg244IrOEdBxivulsPpEDyef/RayZ9/RdNhsnE1uUkis1DApKhiiXr 5H2uwH/eQCFD6tuCawel3/zw/ItVLaO9rbcVxCQxmXZpEevgJObDRB9avP7DZXlJ85l0 CUCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UD461lFzVgYSMoZvzYJe9RzHcVVhQ855ZIcNXCKAMe8=; b=eiJI1XBLkpeedtataOGKIb3R1IIuxr1sCT4LZE3MQUUa9wkYlzFldbUfC5fUu+ll5W q5WGwINCdY3SIrss0eWrtDsKW1OEcQkOZIq+7E2ujRIuw1w6iLiDscZlbd+V1hoyI9su Pg+T9tJMMfm9x1KVYwJFwmpoiOdTXMrKHPC9lZXv615mTZnKkgv/UD1cQ5LxE5Uyth4q 8SFQlNMVtTciF/HD+6iuMLahaqDpm3x4qZr843Ad0zIp3lOJvfT243gXhmsA+w47L1g5 r4M+GwKqIK1WoLrs2jyb0AIH3Jwsd9J4o6A5Asn9MZX2OreWjSmWsYqYDuafjDl0f8VT EtjA== X-Gm-Message-State: ALyK8tJaFPLSoRPIGouZ6CTeyZG3FA3bOMLaRreOBQPAuSKi2K1qpPgNHU/O3XBtjxyc9G8X540VuYtsDlMbeQ== MIME-Version: 1.0 X-Received: by 10.200.54.170 with SMTP id a39mr4876894qtc.104.1464200353989; Wed, 25 May 2016 11:19:13 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.105 with HTTP; Wed, 25 May 2016 11:19:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2016 14:19:13 -0400 X-Google-Sender-Auth: zhhUVPveMC6ZdW1DA9Sg7doINZI Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=001a1141a612facca50533aeb5ec Archived-At: Cc: Austin William Wright , Tim Bray , "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:19:18 -0000 --001a1141a612facca50533aeb5ec Content-Type: text/plain; charset=UTF-8 The core problem with 'JSON Schema' is that either you like strongly typed languages or you don't. I have some very strong opinions on the advantages of strong typing. My college tutor was Tony Hoare. But a lot of people don't see the point just as a lot of folk in the nuclear physics lab used to turn off compiler warnings to 'get rid of' their errors. If you don't like strong typing then you probably won't see the value of a schema language because you will be using languages that allow you to write something like this var DOM = JSON.Parse (Textfile); Where JSON.Parse is a completely generic function that dumps out a tree that you can then access through dynamic binding. Dynamic binding certainly has advantages but it has what people from my camp consider to be the serious disadvantage that you can't do static type checking at compile time. It also has the disadvantage that you end up with code that looks like this: struct Furniture { string: Name; string: Type; } Which serializes as "Furniture" : { "Name" : "Aeron", "Type" : "Chair" } Which is fine, if you don't want to use an object oriented language where you would write something like: class Furniture { string: Name; } class Chair : Furniture { } Which would typically serialize as : "Chair" : {Name: "Aeron"} If you design a protocol with strong typing in mind it is highly unlikely that you are going to have problems using dynamic binding as a result. But the reverse is not the case. Since I do security, I insist on static type checking. Perl is fine for writing a Web site mashup. It isn't something I would want to see used on a CA. --001a1141a612facca50533aeb5ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The core problem with 'JSON= Schema' is that either you like strongly typed languages or you don= 9;t.

I= have some very strong opinions on the advantages of strong typing. My coll= ege tutor was Tony Hoare. But a lot of people don't see the point just = as a lot of folk in the nuclear physics lab used to turn off compiler warni= ngs to 'get rid of' their errors.
<= br>
If you don't like strong typing the= n you probably won't see the value of a schema language because you wil= l be using languages that allow you to write something like this

var DOM =3D JSON= .Parse (Textfile);

Where JSON.Parse is a completely generic function that dumps o= ut a tree that you can then access through dynamic binding.

Dynamic binding certa= inly has advantages but it has what people from my camp consider to be the = serious disadvantage that you can't do static type checking at compile = time.

= It also has the disadvantage that you end up with code that looks like this= :

stru= ct Furniture {
=C2=A0 =C2=A0 string: Name;<= /div>
=C2=A0 =C2=A0 string: Type;
=C2=A0 =C2=A0 }

=
Which serializes as

"Furniture" : { "Na= me" : "Aeron", "Type" : "Chair" }
<= div class=3D"gmail_extra">
Which is fin= e, if you don't want to use an object oriented language where you would= write something like:

class Furniture {
=C2=A0 = =C2=A0 string: Name;
=C2=A0 =C2=A0 }
<= div class=3D"gmail_extra">
class Chair = : Furniture {
=C2=A0 =C2=A0 }

Which would typical= ly serialize as :

"Chair" : {Name: "Aeron"}


If you design a protocol with strong typing in mind it is = highly unlikely that you are going to have problems using dynamic binding a= s a result. But the reverse is not the case.

Since I do security, I insist on sta= tic type checking. Perl is fine for writing a Web site mashup. It isn't= something I would want to see used on a CA.

--001a1141a612facca50533aeb5ec-- From nobody Wed May 25 11:26:48 2016 Return-Path: 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 56B1312D8BC for ; Wed, 25 May 2016 11:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Fhc0dr_Eu7e3 for ; Wed, 25 May 2016 11:26:44 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9709212D8B2 for ; Wed, 25 May 2016 11:26:44 -0700 (PDT) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B3FBF41C08E; Wed, 25 May 2016 20:26:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 19p5Ulz1Fakg; Wed, 25 May 2016 20:26:41 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 80AA241C08D; Wed, 25 May 2016 20:26:40 +0200 (CEST) Message-ID: <5745EE5E.5050801@tzi.org> Date: Wed, 25 May 2016 20:26:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:26:46 -0000 Andrew Newton wrote: > It's not too much to ask, but the problem may be with the JSON parser. > Many parsers ingest JSON and give back native data structures, which > is what makes JSON simple for most people. But a validator needs > context that a typical JSON parser does not provide. Can you give an example for that? (I'm familiar with a problem like this from CBOR, where CDDL maybe sometimes wants to make serialization choices*), which are no longer visible at the data model level; I just haven't seen the need with JSON.) Grüße, Carsten *) such as float16 vs. float32 vs. float64. From nobody Wed May 25 14:42:59 2016 Return-Path: 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 1635512DD84 for ; Wed, 25 May 2016 14:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 y0MqECV6qhPW for ; Wed, 25 May 2016 14:42:56 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 979C912D1E2 for ; Wed, 25 May 2016 14:42:56 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n129so77625291wmn.1 for ; Wed, 25 May 2016 14:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dVqyh/IddqfgOwE6QoscyNdyjisfcEPTL/OcM9surks=; b=toEGyXzhJWbCNNMFhdBlUZXqIDUMfhT8z3UHdDm5IL7wbR1eS9uDrkQO74bESC+stN Rnqr+cS1kUAnt2cMUgLeXJZVispwlgEMavdngk2Gp0smMqhxlep3xtOX1DSTPwXPOm/6 /4bJAEMqihl1qyGYO2IUuMK2FzoIxou/IQkSFcVErbCDAH5novXK1wnInDDehfSVLXNZ n4JiEKvoVeWPq13VCFhDtZ2AI4LSfxYNgADcrGDtnRTIluZR93v4IUelwS3px34A0kdm 7FPD4gfw+EFvcCQ2KTXAkYOND1abwl4CambyUsoRbzzv51K3oEgkwNtwKVWIXmu+54hJ udmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dVqyh/IddqfgOwE6QoscyNdyjisfcEPTL/OcM9surks=; b=nEGkbjjVhPsvrwXYVRglrPc96PK0yFwfwgBH3o110Rkk53xLTsBOoEaKOJiVm8ScXs 9REgK10IBIwY/JMH3kv9nbGK6rqQyCTOd9us0OCj6LjT8NTv2d6Rq/0n7hR7K6AxhPvv eGYFMScHuiwpmB+zjZLu0PNi2aTiajj+afCilNS2wJobqOjPqOBf36ijA3P2DkTjO3Gx HVqHhcg+KVymSiPaeujEkGfJEhaWj1Jl3dfB1zi1D353PpOYUWmueprDd7hOgoGICHnm 6/bRBRUWf7x3T1yzUw0fpJFTuLidMr555UKVQTQpmLGfJbJVInbczBwrunbiC0RV7AYL j3VQ== X-Gm-Message-State: ALyK8tK26d6y+5iIapOMj6IZtsvxkZ+Ea5ATvzzKvpzYBGcm5vaI/7o68Mjo718VVmJesQ== X-Received: by 10.194.104.102 with SMTP id gd6mr736367wjb.170.1464212575005; Wed, 25 May 2016 14:42:55 -0700 (PDT) Received: from [192.168.1.181] (178.113.72.111.wireless.dyn.drei.com. [178.113.72.111]) by smtp.googlemail.com with ESMTPSA id m7sm113415wma.10.2016.05.25.14.42.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 14:42:54 -0700 (PDT) To: Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> <57455F43.6010506@tzi.org> From: Christian Zangl Message-ID: <2eec2464-3315-9cd6-f850-ab83d98a94a8@gmail.com> Date: Wed, 25 May 2016 23:42:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57455F43.6010506@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:42:58 -0000 On 2016-05-25 10:16, Carsten Bormann wrote: > HUMANS SHOULD NOT BE WRITING JSON *), so, no, I don't like JSON as a > configuration file format. Couldn't agree more! > The people I have met who didn't know about YAML usually liked > .ini-style **) configuration file formats, as exemplified by TOML ***). While those are certainly better options it's not uncommon to see JSON configs. I'd like to get people to switch. If they switch to YAML/INI/TOML that's fine too. Even if you don't like the name, "Human JSON" signals that it's a format they already know. You can in fact just replace the parser and everything keeps working. > Since my experience is that every configuration file format turns more > and more complex over time, I prefer to base them on a powerful generic > format such as YAML. YAML is also pretty good in noise reduction. JSON is such a nice format because it's easy and requires almost no explanation. When you look at YAML it's not easy to guess what it does and yaml.org only makes it worse. -chris From nobody Wed May 25 14:59:03 2016 Return-Path: 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 3B4C712DD92 for ; Wed, 25 May 2016 14:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 NchqkXmd4yMT for ; Wed, 25 May 2016 14:59:01 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604EB12DD0E for ; Wed, 25 May 2016 14:59:01 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id E167B41C08A; Wed, 25 May 2016 23:58:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id iZDx6XozHkV3; Wed, 25 May 2016 23:58:58 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BC7FF41C080; Wed, 25 May 2016 23:58:57 +0200 (CEST) Message-ID: <5746201F.7080707@tzi.org> Date: Wed, 25 May 2016 23:58:55 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> <57455F43.6010506@tzi.org> <2eec2464-3315-9cd6-f850-ab83d98a94a8@gmail.com> In-Reply-To: <2eec2464-3315-9cd6-f850-ab83d98a94a8@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:59:03 -0000 Christian Zangl wrote: > When you look at YAML it's not easy to guess what it does Not so sure about that -- kramdown-rfc is using YAML as its structured part and people seem to be picking it up from the examples nicely. (I probably still have to improve those examples some more.) > and yaml.org > only makes it worse. Now, there we have strong agreement. (But that would be true for any format that tries to offer its spec as its only documentation, or worse, its documentation as its spec :-) This could be fixed without even changing the format at all. Curious question: What part of HJSON is actually a subset of YAML? What did you do that YAML doesn't have? Grüße, Carsten From nobody Wed May 25 21:54:14 2016 Return-Path: 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 332A412D5E5 for ; Wed, 25 May 2016 21:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RaWZxNeVY-Ki for ; Wed, 25 May 2016 21:54:11 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 7577712D1B5 for ; Wed, 25 May 2016 21:54:11 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a136so8093075wme.0 for ; Wed, 25 May 2016 21:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=wJSGDatbJfGw5zMPva/FjtO+cMs+USNmxfBDcTVsw4w=; b=rzQeQr2+0LrzqgK00TPfDuJNSNe1/XS7eZGqDrg+Wrny7scCH5jh7EXc51tK+Nk3tJ myhf4AR0UOD5gjOoa2rHh+gMdisxxh1Ue+03bF4UTR1yLe1o3Tr6bmE3JsZsxpFT1sA9 aAOk9aUiHWy6oVAsxTYHu70jo2yapv3nvRPw0R+kmpBu1fJojM1DbGzJW03hatSdcY7+ IKFrqlzEI+nyTg4pJRjD0Nf4aoA4NfRj1pnAR1DEYPRzd0IU3QKrWzt97zCKq6dF4u4a P/Mkr7Zazdoadgr++Ul15QEqau8aKEJngdy/+RNhXyBoG3b1BETp3Ej5mxRxKFiZyyIb /B6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wJSGDatbJfGw5zMPva/FjtO+cMs+USNmxfBDcTVsw4w=; b=b2lNcAZ2udTfzT73QP7APtpaeMc+wf+ZfrD9RCSBOcE7mw9Rcl3/pi4W+fPaM4+Zah 3xXOPX78JAjwcpJ1iLPimPoQpqu0QSvjploDti3KkSaUNM/ItRgOfzBWUabYhg4QEOW3 Medk41YJIVvcHjxgul9ekcsP68J2zsgV/z4tQKi/lp3kBmodjaq2sOkLP5T1RhidOmXz VMUnjksfdeZRXrYswUiIlBAzTrPPMtnU0oOarSWtIcOD2ll4zTeUfSsl01TEattvw/0Y 7cDJ0fAVg0c6xcB0yt0gTmu9tqZI8faakqXrmpZwwUAdccMc7ei/fbPyI9a/KpOW6LCT XsFQ== X-Gm-Message-State: ALyK8tKPrTXev7bzycNsnXC+unY5bCc02wtu30MQUVVAqldwJnDOe4q1qZp7ClwBlU8mbg== X-Received: by 10.194.216.33 with SMTP id on1mr7192605wjc.120.1464238449910; Wed, 25 May 2016 21:54:09 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id q125sm1385506wmd.19.2016.05.25.21.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 21:54:09 -0700 (PDT) To: Christian Zangl , json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> <21160816-48c7-169e-5a83-19b7601420a0@gmail.com> From: Anders Rundgren Message-ID: <45878809-7718-fc38-a8ec-d8c5654c66cd@gmail.com> Date: Thu, 26 May 2016 06:53:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <21160816-48c7-169e-5a83-19b7601420a0@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Comments in JSON = De facto standard. Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:54:13 -0000 Adding comments to JSON would IMO solve the "human" part. It is already used in Chrome config files since ages back. Anders From nobody Thu May 26 00:00:32 2016 Return-Path: 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 05B0212D883 for ; Thu, 26 May 2016 00:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.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 Wg4tDNlS-768 for ; Thu, 26 May 2016 00:00:29 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 E392D12D89A for ; Thu, 26 May 2016 00:00:28 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n129so87176020wmn.1 for ; Thu, 26 May 2016 00:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=U69KfIZoydGy6n16t10rktQam6TOKBDtB2lWTOOQQ4Y=; b=LBbbhhC48zYelRUvLXNXqnInjKHe1ElMjhxvUjIdqPn1Kt9oYVRmDa8+FX4YrLZ/j5 ht+7fYlTgH0in2lU5ec8xKdVcLnpTEaf5Rn87m9qndlUNy3wGbFS7gEFOaepVmAQTwqE hXZM4lgdZr0cCRmTkf0G5um1FtMJAphxHL8nBu9hzTLfkzjE4T+PZ1EjCaldvCh/CTy/ omq3DO7ypPKLFt9vfUeSX30VBgj4Z+feDHUZsRAy2awgBoNubgo6vwSD5LQ3g/dmnsvE cpNSIDPCBqFC3d9eDKjRXF6f3EsTMvYsFsQ6O9/rHYUp0TKUVxOfGiK7lfGin/hh/w0o 1H+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=U69KfIZoydGy6n16t10rktQam6TOKBDtB2lWTOOQQ4Y=; b=CxChU36vGUX7VEn7rjvlVgNvEFoWdra+gekUjNeYxWp3u1IZea49Qc1TZvOLAYQrbF uzTNm6cI0NMRilTSnOFuLnnjZnBnHDpKUQFREz7+/Qr02IdTiUZdEmENsEqVCujL5xvk 1XQFqsmYIyCfYzFUJ5Ag1ZdduuSPd3rNu3qzdHnoqrt7OwURNffXAZBQgbLz459f+rpN bs4hYjT1ohViDDxZJm1edhnLCF++blrU3oQrc/PYn5i7FA1767z6lUOyBu+oWO13joqU 7I2LoZvlKg0aKhx/B03WufbQHMAAU+Zn9U4iXY1NbMyPUzzKsUs6FuLA6cztYx3wc8xs 3ISg== X-Gm-Message-State: ALyK8tLaLhXF60nDvhs73hh28FF2A9kJo429pLOOcSJxNSVomiFPbIBsxjU3gdqc1/uae8U4jmOohnZkBsQgYA== MIME-Version: 1.0 X-Received: by 10.28.92.20 with SMTP id q20mr1948531wmb.76.1464246027298; Thu, 26 May 2016 00:00:27 -0700 (PDT) Received: by 10.194.153.39 with HTTP; Thu, 26 May 2016 00:00:27 -0700 (PDT) X-Originating-IP: [94.127.55.205] In-Reply-To: <5745EE5E.5050801@tzi.org> References: <5745EE5E.5050801@tzi.org> Date: Thu, 26 May 2016 09:00:27 +0200 Message-ID: From: Andrew Newton To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 07:00:31 -0000 On Wed, May 25, 2016 at 8:26 PM, Carsten Bormann wrote: > Andrew Newton wrote: >> It's not too much to ask, but the problem may be with the JSON parser. >> Many parsers ingest JSON and give back native data structures, which >> is what makes JSON simple for most people. But a validator needs >> context that a typical JSON parser does not provide. > > Can you give an example for that? > Given the following: [ { "foo" : "bar" } ] Here is what happens if I use the built-in Ruby parser: irb(main):017:0> s => "\n[\n { \"foo\":\"bar\"}\n]\n" irb(main):018:0> JSON.parse s => [{"foo"=>"bar"}] If a validator wants to ensure that "foo" is "baz" and not "bar", its lost the information to tell the user to look at line 2. By contrast, if a validator were to use Jackson as a stream parser, it would have access to JsonLocation: http://fasterxml.github.io/jackson-core/javadoc/2.1.0/com/fasterxml/jackson/core/JsonLocation.html > (I'm familiar with a problem like this from CBOR, where CDDL maybe > sometimes wants to make serialization choices*), which are no longer > visible at the data model level; I just haven't seen the need with JSON.) I'm not sure we are talking about the same thing. -andy From nobody Thu May 26 04:00:26 2016 Return-Path: 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 127DF12D64A for ; Thu, 26 May 2016 04:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dilettant.eu 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 vbQczKTmAEPB for ; Thu, 26 May 2016 04:00:22 -0700 (PDT) Received: from mailrelay4.public.one.com (mailrelay4.public.one.com [195.47.247.71]) (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 4123D12D782 for ; Thu, 26 May 2016 04:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dilettant.eu; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=WTCOcv3rLmgEqPwJSsUd6teM26dQU2iz6vlQHC2kjkc=; b=RjjJEeo5gNcgTSi4UDpS5XgXZ5TLiPh06k7l10Ozn0R0Eo5VlnvSE1Ai0ca3oK1yVMV6GsJytub0I nL+w2nPyLlWqk9duDXuO9Aa7UsPGu9OYMko+SV5d739Jsj7Pfm6rEzhznVsCBKGHYubDrjGoXZZWWB /x66ddGots+Z89nQ= X-HalOne-Cookie: 56a71fad1abce7180d67b41e4c1d5e0efa32c034 X-HalOne-ID: 08d3851f-2331-11e6-a8e4-b8ca3afa9d73 Received: from [192.168.0.17] (unknown [37.201.170.50]) by smtpfilter1.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 26 May 2016 11:00:18 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-70643EF2-75B4-48DA-A977-71D572C6CCF2 Mime-Version: 1.0 (1.0) From: Stefan Hagen X-Mailer: iPhone Mail (13F69) In-Reply-To: <45878809-7718-fc38-a8ec-d8c5654c66cd@gmail.com> Date: Thu, 26 May 2016 13:00:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> <21160816-48c7-169e-5a83-19b7601420a0@gmail.com> <45878809-7718-fc38-a8ec-d8c5654c66cd@gmail.com> To: Anders Rundgren Archived-At: Cc: Christian Zangl , json@ietf.org Subject: Re: [Json] Comments in JSON = De facto standard. Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:00:24 -0000 --Apple-Mail-70643EF2-75B4-48DA-A977-71D572C6CCF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 2016-05-26 at 06:53 Anders Rundgren wro= te: >=20 > Adding comments to JSON would IMO solve the "human" part. > It is already used in Chrome config files since ages back. I second that. Nearly always switcted to using python dicts for edited confi= g / foxtite files from JSON for the good readabiloty of commented entries an= d editor support. "Stefan" # Like so ;-) --Apple-Mail-70643EF2-75B4-48DA-A977-71D572C6CCF2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 2016-05-26 at 06:53 Anders Rundgren &l= t;anders.rundgren.net@gmail.com> wrote:

Adding comments to JSON would IMO solve th= e "human" part.

I s= econd that. Nearly always switcted to using python dicts for edited config /= foxtite files from JSON for the good readabiloty of commented entries and e= ditor support.

"Stefan" # Like so ;-)

= --Apple-Mail-70643EF2-75B4-48DA-A977-71D572C6CCF2-- From nobody Thu May 26 04:03:12 2016 Return-Path: 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 B906012DD3C for ; Thu, 26 May 2016 04:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Yo214TsmXgiF for ; Thu, 26 May 2016 04:03:08 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C336812DD33 for ; Thu, 26 May 2016 04:03:07 -0700 (PDT) Received: (qmail 11106 invoked from network); 26 May 2016 11:58:15 +0100 Received: from host86-178-51-202.range86-178.btcentralplus.com (HELO ?192.168.1.72?) (86.178.51.202) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 May 2016 11:58:15 +0100 To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> From: Peter Cordell Message-ID: <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> Date: Thu, 26 May 2016 12:03:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Christian Zangl Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:03:11 -0000 For me JSON is too simple, and YAML is too complex. I've tried to get into YAML a couple of times, but it seems to have multiple ways to do the same things, so I end up getting confused. It clearly fails at at least one level to be human friendly. Why JSON doesn't have comments eludes me. JavaScript does, so missing that bit in the subsetting was a big drop off IMO. I'd love something that is more flexible than JSON, but less complicated than YAML. While I might quibble about some of the choices in this proposal, the fact that it can be described as JSON with 7 lines of variations is a big win. What I find frustrating in this space is that protocols and specifications are the bread and butter of IETF. And yet the IETF has put very little effort into developing 'tools' for this area (*). And the really sad thing is that the reason is not because this is a difficult problem, but more that it is such a simple problem that everyone comes up with their own pet solution and they'd rather have no solution instead of someone else's solution. As a result we end up with other groups second hand goods like XML and JSON. So I'd welcome it going forward in a form that would allow experience with working with the format and would be simple for a working group to adopt and put on standards track if they felt it was useful. Perhaps as an AD shepherded individual RFC that can just be 're-badged' to put it on standards track if the desire arose. (* OK, we have ABNF, but that's the assembly language of protocol design and we should really be aspiring to higher levels of abstraction in this day and age.) Pete Cordell Read & write XML in C++, http://www.xml2cpp.com On 24/05/2016 22:36, Christian Zangl wrote: > JSON is used in a lot of places and has helped improve things like data > exchange and data storage. It is also used in areas it's less suited > for, like configuration files. People seem to prefer JSON for > configuration over YAML and other config formats. > > I started Human JSON (Hjson) because I found the experience frustrating > (for example missing/trailing comma problems, no comments). With Hjson > you get a superset of JSON that allows you to > > - add #, // or /**/ comments, > - omit quotes for keys, > - omit quotes for strings (terminated by LF, no escapes), > - omit braces for the root object, > - omit the comma at the end of a line > - add trailing commas and > - use multiline strings with proper whitespace handling. > > These changes should make it easer to read and write configs while still > preserving the power of JSON. > > Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You > can find the draft here: http://hjson.org/rfc.html There are also syntax > diagrams and more at http://hjson.org/syntax.html > > Thoughts? > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > . > From nobody Thu May 26 07:01:58 2016 Return-Path: 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 B316712D8D3 for ; Thu, 26 May 2016 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EZgDwxvQbkjr for ; Thu, 26 May 2016 07:01:54 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 EE80012DB0C for ; Thu, 26 May 2016 07:01:52 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y126so58433692qke.1 for ; Thu, 26 May 2016 07:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=InWajPpzOOfv5+45fPhdq8MUdROG5EN3P/iMHutOCH4=; b=MNWNFFy+oTGNqm+n20NXuRgIp2mvErwq0hU+0QLF5hQv5QgqCotC4AuBPIRYkwghsQ Pgn1bDLrbG9ERQkIj3LhP26GtXnRF1rDIdben4oHsSidiclXkkVihjQge55iKjtODiF7 8XS8SUsa1eADPy9h4QXkREurnz9y92pUwgan4OkWHb+rFq0KoajMDc13eulacDNi52uy sf86ZCRtNk9FbQs1wFqsaZ0fjpj+GIxaR7IuAC4MKqgnSS9+j25+hkTCyD+g305Jxgf5 FN5sI8mJisjmHMtIwez3cGVXVCtYr+aNd4zZkF0B1PawxI+Yv17Ac8wv8WD+Zm+5CENw 1jUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=InWajPpzOOfv5+45fPhdq8MUdROG5EN3P/iMHutOCH4=; b=e2Kc12h/lQRC4pTfU1v6y7sHzJu1i45620xGQ+tJAZV46ZizRzaYKNioZgetMGJ4xy lrA23pPsqmwD5M+QnbVL4rI8aJFvXr77PPDGsoewqnX0/GUBiFp6ymGjPPieRv4Z8dff bE+9lzFFAeE7gn3FISU/YDZbk6i7mVTnBHXNLalkLs3WJ90eqrhPylSMYazzR8z2oDw0 1e4DF25P+cgTYQwxGaehnYmUP24DWATifQhcqETe5P2xM2iV/BO15SIwK0yzPTh3cAr5 9/+Wshc+Ywp0ssgY+Kr+t4qEURvOPE+d1z6pmjMEwz8bqXqbsTGNEH4ZzWac5gZ7HuEs LlSw== X-Gm-Message-State: ALyK8tK1f53jz1Ak+sxxq+liEnhgrpOoGmzhxkSMbIRwd4NkWGCkWbIWeBDMPb9Sg/8pNp5BSkq0YTJeOvj5Mg== MIME-Version: 1.0 X-Received: by 10.200.51.165 with SMTP id c34mr8937938qtb.48.1464271312029; Thu, 26 May 2016 07:01:52 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 07:01:51 -0700 (PDT) In-Reply-To: <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> Date: Thu, 26 May 2016 10:01:51 -0400 X-Google-Sender-Auth: Vr4otL5B09YUd_guiRCiWLmuVzE Message-ID: From: Phillip Hallam-Baker To: Peter Cordell Content-Type: multipart/alternative; boundary=001a1141bfc4688e020533bf3bf0 Archived-At: Cc: Christian Zangl , JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 14:01:57 -0000 --001a1141bfc4688e020533bf3bf0 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 7:03 AM, Peter Cordell wrote: > For me JSON is too simple, and YAML is too complex. I've tried to get > into YAML a couple of times, but it seems to have multiple ways to do the > same things, so I end up getting confused. It clearly fails at at least > one level to be human friendly. Why JSON doesn't have comments eludes me. > JavaScript does, so missing that bit in the subsetting was a big drop off > IMO. > > I'd love something that is more flexible than JSON, but less complicated > than YAML. While I might quibble about some of the choices in this > proposal, the fact that it can be described as JSON with 7 lines of > variations is a big win. > > What I find frustrating in this space is that protocols and specifications > are the bread and butter of IETF. And yet the IETF has put very little > effort into developing 'tools' for this area (*). And the really sad thing > is that the reason is not because this is a difficult problem, but more > that it is such a simple problem that everyone comes up with their own pet > solution and they'd rather have no solution instead of someone else's > solution. As a result we end up with other groups second hand goods like > XML and JSON. > > So I'd welcome it going forward in a form that would allow experience with > working with the format and would be simple for a working group to adopt > and put on standards track if they felt it was useful. Perhaps as an AD > shepherded individual RFC that can just be 're-badged' to put it on > standards track if the desire arose. > > (* OK, we have ABNF, but that's the assembly language of protocol design > and we should really be aspiring to higher levels of abstraction in this > day and age.) > > Pete Cordell > Read & write XML in C++, http://www.xml2cpp.com This seems to be the 'stop people using JSON' working group. Every single time someone suggests a variant of JSON, the response is 'NO'. Which wouldn't be bad only then the same people get go off and design something entirely different that doesn't match JSON at all. So instead of adding binary extensions to JSON, we get CBOR, a completely different specification that requires completely different tooling. CBOR was not developed in an open fashion and now the same people who got to benefit from that end run around the IETF rules want to block this work in favor of their pet ponies again. I suggest that we form a separate WG for encodings that are supersets of JSON encoding but map back to the JSON data model. And if we can't form it here, we take the work somewhere that is actually open and the insiders club doesn't get to veto reasonable proposals so they can clear the track for their own proposals. A superset of JSON encoding optimized for human input makes a lot of sense. In particular it should be possible for a single parser to read data in either strict JSON or JSON-x. Which is what I did with JSON-B, JSON-C and JSON-D. I suggest the following additions: 1) Comments 2) Use of quotes on labels is optional if the label conforms to C-like rules (does not start with a digit or contain white space, control or punctuation marks. 3) Allow trailing comas 4) Punctuation optional in situations it is not ambiguous. --001a1141bfc4688e020533bf3bf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 7:03 AM, Peter Cordell <petejson@codalogi= c.com> wrote:
For me JSON is too simple, = and YAML is too complex.=C2=A0 I've tried to get into YAML a couple of = times, but it seems to have multiple ways to do the same things, so I end u= p getting confused.=C2=A0 It clearly fails at at least one level to be huma= n friendly.=C2=A0 Why JSON doesn't have comments eludes me.=C2=A0 JavaS= cript does, so missing that bit in the subsetting was a big drop off IMO.
I'd love something that is more flexible than JSON, but less complicate= d than YAML.=C2=A0 While I might quibble about some of the choices in this = proposal, the fact that it can be described as JSON with 7 lines of variati= ons is a big win.

What I find frustrating in this space is that protocols and specifications = are the bread and butter of IETF.=C2=A0 And yet the IETF has put very littl= e effort into developing 'tools' for this area (*).=C2=A0 And the r= eally sad thing is that the reason is not because this is a difficult probl= em, but more that it is such a simple problem that everyone comes up with t= heir own pet solution and they'd rather have no solution instead of som= eone else's solution.=C2=A0 As a result we end up with other groups sec= ond hand goods like XML and JSON.

So I'd welcome it going forward in a form that would allow experience w= ith working with the format and would be simple for a working group to adop= t and put on standards track if they felt it was useful.=C2=A0 Perhaps as a= n AD shepherded individual RFC that can just be 're-badged' to put = it on standards track if the desire arose.

(* OK, we have ABNF, but that's the assembly language of protocol desig= n and we should really be aspiring to higher levels of abstraction in this = day and age.)

Pete Cordell
Read & write XML in C++, http://www.xml2cpp.com

<= /div>
This seems to be the 'stop people using JSON' working gro= up.

Every single time someone suggests a variant o= f JSON, the response is 'NO'. Which wouldn't be bad only then t= he same people get go off and design something entirely different that does= n't match JSON at all.=C2=A0

So instead of add= ing binary extensions to JSON, we get CBOR, a completely different specific= ation that requires completely different tooling.

= CBOR was not developed in an open fashion and now the same people who got t= o benefit from that end run around the IETF rules want to block this work i= n favor of their pet ponies again.

I suggest t= hat we form a separate WG for encodings that are supersets of JSON encoding= but map back to the JSON data model. And if we can't form it here, we = take the work somewhere that is actually open and the insiders club doesn&#= 39;t get to veto reasonable proposals so they can clear the track for their= own proposals.


A superset of JSON = encoding optimized for human input makes a lot of sense. In particular it s= hould be possible for a single parser to read data in either strict JSON or= JSON-x. Which is what I did with JSON-B, JSON-C and JSON-D.

=
I suggest the following additions:

1) C= omments

2) Use of quotes on labels is optional if = the label conforms to C-like rules (does not start with a digit or contain = white space, control or punctuation marks.

3) Allo= w trailing comas

4) Punctuation optional in situat= ions it is not ambiguous.


--001a1141bfc4688e020533bf3bf0-- From nobody Thu May 26 07:32:04 2016 Return-Path: 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 15BAF12DB46 for ; Thu, 26 May 2016 07:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dilettant.eu 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 j-miJ0dSxDD1 for ; Thu, 26 May 2016 07:31:52 -0700 (PDT) Received: from mailrelay12.public.one.com (mailrelay12.public.one.com [195.47.247.212]) (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 8C7A912D746 for ; Thu, 26 May 2016 07:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dilettant.eu; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=78GkYmmaPir1CqFGbrE0HxeL/zP9FRZOsl/mzLMnxfY=; b=DORI1PrZM92c/zkQ0K3kTMQv5bfQWMOCzkrTPh0OHV6uhCo/i8fsIJehWv54rOXsHp3c/ScCgkn70 5VGy1u+t5iI1IkXqdsVPNnelwjWgTzcG/UpRVkdkOPIC7SuR/h8HzEGYeYJFx6RKmytrhsWdtDqKS5 OzQNOn5fFabLL9ZE= X-HalOne-Cookie: a164f558c82bbb502644986ec15b9c80618d1520 X-HalOne-ID: 8e176dc1-234e-11e6-bb5b-b82a72cffc46 Received: from [192.168.0.17] (unknown [37.201.169.98]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 26 May 2016 14:31:37 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-0A0F6EC4-9CF7-4B17-912C-5D70E1A7F124 Mime-Version: 1.0 (1.0) From: Stefan Hagen X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Thu, 26 May 2016 16:31:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2E41CD46-8289-4E2D-B68A-EC213BEEA7E8@dilettant.eu> References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> To: Phillip Hallam-Baker Archived-At: Cc: Christian Zangl , Peter Cordell , JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 14:32:03 -0000 --Apple-Mail-0A0F6EC4-9CF7-4B17-912C-5D70E1A7F124 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Am 26.05.2016 um 16:01 schrieb Phillip Hallam-Baker = : >=20 >=20 >=20 >> On Thu, May 26, 2016 at 7:03 AM, Peter Cordell w= rote: >> For me JSON is too simple, and YAML is too complex. I've tried to get in= to YAML a couple of times, but it seems to have multiple ways to do the same= things, so I end up getting confused. It clearly fails at at least one lev= el to be human friendly. Why JSON doesn't have comments eludes me. JavaScr= ipt does, so missing that bit in the subsetting was a big drop off IMO. >>=20 >> I'd love something that is more flexible than JSON, but less complicated t= han YAML. While I might quibble about some of the choices in this proposal,= the fact that it can be described as JSON with 7 lines of variations is a b= ig win. >>=20 >> What I find frustrating in this space is that protocols and specification= s are the bread and butter of IETF. And yet the IETF has put very little ef= fort into developing 'tools' for this area (*). And the really sad thing is= that the reason is not because this is a difficult problem, but more that i= t is such a simple problem that everyone comes up with their own pet solutio= n and they'd rather have no solution instead of someone else's solution. As= a result we end up with other groups second hand goods like XML and JSON. >>=20 >> So I'd welcome it going forward in a form that would allow experience wit= h working with the format and would be simple for a working group to adopt a= nd put on standards track if they felt it was useful. Perhaps as an AD shep= herded individual RFC that can just be 're-badged' to put it on standards tr= ack if the desire arose. >>=20 >> (* OK, we have ABNF, but that's the assembly language of protocol design a= nd we should really be aspiring to higher levels of abstraction in this day a= nd age.) >>=20 >> Pete Cordell >> Read & write XML in C++, http://www.xml2cpp.com >=20 > This seems to be the 'stop people using JSON' working group. >=20 > Every single time someone suggests a variant of JSON, the response is 'NO'= . Which wouldn't be bad only then the same people get go off and design some= thing entirely different that doesn't match JSON at all.=20 >=20 > So instead of adding binary extensions to JSON, we get CBOR, a completely d= ifferent specification that requires completely different tooling. >=20 > CBOR was not developed in an open fashion and now the same people who got t= o benefit from that end run around the IETF rules want to block this work in= favor of their pet ponies again. >=20 > I suggest that we form a separate WG for encodings that are supersets of J= SON encoding but map back to the JSON data model. And if we can't form it he= re, we take the work somewhere that is actually open and the insiders club d= oesn't get to veto reasonable proposals so they can clear the track for thei= r own proposals. >=20 >=20 > A superset of JSON encoding optimized for human input makes a lot of sense= . In particular it should be possible for a single parser to read data in ei= ther strict JSON or JSON-x. Which is what I did with JSON-B, JSON-C and JSON= -D. >=20 > I suggest the following additions: >=20 > 1) Comments >=20 > 2) Use of quotes on labels is optional if the label conforms to C-like rul= es (does not start with a digit or contain white space, control or punctuati= on marks. >=20 > 3) Allow trailing comas >=20 > 4) Punctuation optional in situations it is not ambiguous. I support all 4 selected additions proposed. 1 I already suggested 2) is nice albeit eg in dot language I never know if it irritates me more to= have to add quotes for those labels needing them or that then the quoted an= d unqupted ones look somehow like from different classes ... Ad 3) It is not cool IMO to state the end of a sequence by absence of an element s= eparator when there is in any case a terminating "embedding" token following= . Ad 4) Iff we find a way to compactly describe these situations ;-) Best, Stefan # a valid array to the right?= --Apple-Mail-0A0F6EC4-9CF7-4B17-912C-5D70E1A7F124 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Am 26.05.2016 um 16:01 schrieb Phillip= Hallam-Baker <ietf@hallambaker.c= om>:


On Thu, May 26, 2= 016 at 7:03 AM, Peter Cordell <petejson@codalogic.com> wr= ote:
For me JSON is too simple, and YAML is too complex.&n= bsp; I've tried to get into YAML a couple of times, but it seems to have mul= tiple ways to do the same things, so I end up getting confused.  It cle= arly fails at at least one level to be human friendly.  Why JSON doesn'= t have comments eludes me.  JavaScript does, so missing that bit in the= subsetting was a big drop off IMO.

I'd love something that is more flexible than JSON, but less complicated tha= n YAML.  While I might quibble about some of the choices in this propos= al, the fact that it can be described as JSON with 7 lines of variations is a= big win.

What I find frustrating in this space is that protocols and specifications a= re the bread and butter of IETF.  And yet the IETF has put very little e= ffort into developing 'tools' for this area (*).  And the really sad th= ing is that the reason is not because this is a difficult problem, but more t= hat it is such a simple problem that everyone comes up with their own pet so= lution and they'd rather have no solution instead of someone else's solution= .  As a result we end up with other groups second hand goods like XML a= nd JSON.

So I'd welcome it going forward in a form that would allow experience with w= orking with the format and would be simple for a working group to adopt and p= ut on standards track if they felt it was useful.  Perhaps as an AD she= pherded individual RFC that can just be 're-badged' to put it on standards t= rack if the desire arose.

(* OK, we have ABNF, but that's the assembly language of protocol design and= we should really be aspiring to higher levels of abstraction in this day an= d age.)

Pete Cordell
Read & write XML in C++, http://www.xml2cpp.com

This seems to be the 'stop people using JSON' working group.

Every single time someone suggests a variant of JSON, the r= esponse is 'NO'. Which wouldn't be bad only then the same people get go off a= nd design something entirely different that doesn't match JSON at all. =

So instead of adding binary extensions to JSON, we= get CBOR, a completely different specification that requires completely dif= ferent tooling.

CBOR was not developed in an open f= ashion and now the same people who got to benefit from that end run around t= he IETF rules want to block this work in favor of their pet ponies again.

I suggest that we form a separate WG for encoding= s that are supersets of JSON encoding but map back to the JSON data model. A= nd if we can't form it here, we take the work somewhere that is actually ope= n and the insiders club doesn't get to veto reasonable proposals so they can= clear the track for their own proposals.


A superset of JSON encoding optimized for human input makes a lot of s= ense. In particular it should be possible for a single parser to read data i= n either strict JSON or JSON-x. Which is what I did with JSON-B, JSON-C and J= SON-D.

I suggest the following additions:

1) Comments

2) Use of quotes on lab= els is optional if the label conforms to C-like rules (does not start with a= digit or contain white space, control or punctuation marks.

<= /div>
3) Allow trailing comas

4) Punctuation op= tional in situations it is not ambiguous.

I support all 4 selected additions proposed.

=
1 I already suggested

2) is nice albeit e= g in dot language I never know if it irritates me more to have to add quotes= for those labels needing them or that then the quoted and unqupted ones loo= k somehow like from different classes ...

Ad 3)
It is not cool IMO to state the end of a sequence by absence of an el= ement separator when there is in any case a terminating "embedding" token fo= llowing.

Ad 4)
Iff we find a way to compa= ctly describe these situations ;-)

Best, Stefan &nb= sp;# a valid array to the right?
= --Apple-Mail-0A0F6EC4-9CF7-4B17-912C-5D70E1A7F124-- From nobody Thu May 26 08:08:15 2016 Return-Path: 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 EC7E512D6ED for ; Thu, 26 May 2016 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KK3f5eH0wq16 for ; Thu, 26 May 2016 08:08:10 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A41312D6EB for ; Thu, 26 May 2016 08:08:10 -0700 (PDT) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id C0A75FB8CB; Thu, 26 May 2016 17:08:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YbdFMaa5-wjP; Thu, 26 May 2016 17:08:07 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id C4243FB8D3; Thu, 26 May 2016 17:08:06 +0200 (CEST) Message-ID: <57471154.1050107@tzi.org> Date: Thu, 26 May 2016 17:08:04 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:08:13 -0000 I don't normally reply to messages of this kind. But since there are probably some new people around here who are not used to these antics: Phillip Hallam-Baker wrote: > CBOR was not developed in an open fashion Nope, you don't get to perpetuate that myth here. (And, no, I'm also not interested in long messages redefining "open" long enough that this statement turns into a form of true.) > and now the same people who > got to benefit from that end run around the IETF rules You also don't get to bolster your arguments by personal attacks. > want to block > this work in favor of their pet ponies again. And it also doesn't help if you frame the discussion in a destructive way. Legitimate questions have been asked, facts have been stated, and opinions (some more, some less well-founded) have been made known. Enabling that kind of discussion is an important part of openness. Grüße, Carsten From nobody Thu May 26 08:11:19 2016 Return-Path: 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 E9CC912D5A9 for ; Thu, 26 May 2016 08:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 3NjiTAxPYhtz for ; Thu, 26 May 2016 08:11:17 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFBF12D10A for ; Thu, 26 May 2016 08:11:17 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 1E68E47E824; Thu, 26 May 2016 17:10:41 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C6CE0A80D5; Thu, 26 May 2016 17:10:40 +0200 (CEST) Message-ID: <574711EE.2010405@tzi.org> Date: Thu, 26 May 2016 17:10:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: JSON WG References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471154.1050107@tzi.org> In-Reply-To: <57471154.1050107@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:11:19 -0000 Carsten Bormann wrote: (Things that I don't like to write.) And back to something productive: I think there is consensus that something would need to be added to JSON to make it more amenable to configurations and other data entered and edited by humans. We all have different experience with the various, well-tried approaches here (e.g., some found YAML too complex, some have good experience with it; various other extensions to and variations of JSON are embodied in various open source projects, and there are even other approaches like TOML where it would be nice to understand the reasons for their existence). Based on these different experience backgrounds we also have different opinions. But that doesn't mean we can't converge on something. The nature of a a JSON working group is that it would tend to converge on "fixing" JSON. Since this natural tendency (hammer/nail) always needs a bit of a counteraction, I've been stressing that there are other approaches, such as formalizing existing standards in this space. Grüße, Carsten From nobody Thu May 26 08:23:33 2016 Return-Path: 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 70E7E12D704 for ; Thu, 26 May 2016 08:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3X1WIjzFbf4n for ; Thu, 26 May 2016 08:23:31 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 C7C4A12D163 for ; Thu, 26 May 2016 08:23:30 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y126so60224635qke.1 for ; Thu, 26 May 2016 08:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=g0WExuc8Sl6hHtDjySA8SCR7bzvJyD12qPrItm9gLog=; b=m5VKsCAZ0M+hMne08p3wHturVEALmig5+9fAieNKCoqWZ7h+8P1ooRcRjGyxMcatLO 9kOzkqT4wG2MMN4PAvsF6gHQ7JYNShPIdw7zE9ar7MQVdkp5nKErrNBprE6/UoJT5Dxu b1Hiuyo1Zi04lRbosRxUOdEmj94D+30MdWLq9l6YP/im7/moSaN4aYvH22dpnLuIPUrv T8tuSbaOVafdxgSi3qhOpPAXMklrM9odJl/rgLJX/6kMgVyeeeceE3Bn6qoo70cKJQJC bOCEtQc8whDoSyJ+89phcg3TcT1nEGLgdLgNM8uT2+yteiAuY2e3LrfP3Hl0MvbEDZkS SMPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=g0WExuc8Sl6hHtDjySA8SCR7bzvJyD12qPrItm9gLog=; b=f//CWHwuKt3Si1482wdfaIzrR1OARrpaBlt7OtajOlCdeDmA//pzxPH1clR+Jtovoa iL2A3DPJPT3a6TYUltNGBBQKPJbs5sd00fX94nMSPYLuycuo4K9tOr3cCbbk6YwCtibr DplE3hctB8jQSx3IYnocdVGRi0i6DPrDDIFUwzu90owe9axdZpYNK6SXV8Ey3SGDkd1f AwTFERpd4npTw/jnrXGiKoFm60TTjU0HI6zMG5mqcWfaLxvIWEKRofVvAYXn3KiAf0CI qc+cycxbqomexy9/+GqY0+YH5W8mrLRXjuzgWo/9u0QQX1f3spT3pcvgSbJ88Ll4+8y0 Vaxw== X-Gm-Message-State: ALyK8tLdKJi6hKX2+aOhfXJVB/xysUEDkyYnCSY5wrq8MTjVt1HikRUGKkfwHCg+IDB851bKA7GeZKi/a9Q24g== MIME-Version: 1.0 X-Received: by 10.55.114.71 with SMTP id n68mr9736517qkc.37.1464276209866; Thu, 26 May 2016 08:23:29 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 08:23:29 -0700 (PDT) In-Reply-To: <57471154.1050107@tzi.org> References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471154.1050107@tzi.org> Date: Thu, 26 May 2016 11:23:29 -0400 X-Google-Sender-Auth: OVdrxPS68UR3JYL5j4-yrDa2ZzI Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a114fef8a579d170533c05fd6 Archived-At: Cc: JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:23:32 -0000 --001a114fef8a579d170533c05fd6 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 11:08 AM, Carsten Bormann wrote: > I don't normally reply to messages of this kind. > But since there are probably some new people around here who are not > used to these antics: > > Phillip Hallam-Baker wrote: > > CBOR was not developed in an open fashion > > Nope, you don't get to perpetuate that myth here. > > (And, no, I'm also not interested in long messages redefining "open" > long enough that this statement turns into a form of true.) I was specifically told that my contributions were not wanted and unwelcome because the work was being done by a private group that was not required to be open or consider any external requirements. That is a fact. It may not be a fact you want to hear but it is what happened. That was the basis on which I made an appeal which also didn't actually get heard because the AD didn't act on it until he decided it was too late to do so. > > and now the same people who > > got to benefit from that end run around the IETF rules > > You also don't get to bolster your arguments by personal attacks. I am simply stating what happened. If you are upset that the facts put the behavior of some of the people supporting your proposal in a bad light, that is not my fault. Perhaps instead of attacking me for daring to raise the complaint you would want to say 'I am sorry if your proposals were ignored unfairly'. There is a reason I am angry about that behavior and I think I have every right to be in the circumstances. And yes, I will continue to raise it each and every time it appears something similar is happening. --001a114fef8a579d170533c05fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 11:08 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
I don't normally reply to = messages of this kind.
But since there are probably some new people around here who are not
used to these antics:

Phillip Hallam-Baker wrote:
> CBOR was not developed in an open fashion

Nope, you don't get to perpetuate that myth here.

(And, no, I'm also not interested in long messages redefining "ope= n"
long enough that this statement turns into a form of true.)

I was specifically told that my contributions were not wan= ted and unwelcome because the work was being done by a private group that w= as not required to be open or consider any external requirements.

That is a fact. It may not be a fact you want to hear but i= t is what happened. That was the basis on which I made an appeal which also= didn't actually get heard because the AD didn't act on it until he= decided it was too late to do so.

=C2=A0
> and now the same people w= ho
> got to benefit from that end run around the IETF rules

You also don't get to bolster your arguments by personal attacks= .

I am simply stating what happened. If you= are upset that the facts put the behavior of some of the people supporting= your proposal in a bad light, that is not my fault.

Perhaps instead of attacking me for daring to raise the complaint you wo= uld want to say 'I am sorry if your proposals were ignored unfairly'= ;.


There is a reason I am angry abo= ut that behavior and I think I have every right to be in the circumstances.= And yes, I will continue to raise it each and every time it appears someth= ing similar is happening.
--001a114fef8a579d170533c05fd6-- From nobody Thu May 26 08:24:37 2016 Return-Path: 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 D896912D710 for ; Thu, 26 May 2016 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 9yKmEnTvXtHg for ; Thu, 26 May 2016 08:24:35 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF84312D702 for ; Thu, 26 May 2016 08:15:27 -0700 (PDT) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 78BE8A811C; Thu, 26 May 2016 17:15:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id D6ssZB9sFX-R; Thu, 26 May 2016 17:15:24 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id F102EA80C2; Thu, 26 May 2016 17:15:23 +0200 (CEST) Message-ID: <57471309.8040102@tzi.org> Date: Thu, 26 May 2016 17:15:21 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Peter Cordell References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> In-Reply-To: <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Christian Zangl , json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:24:36 -0000 Peter Cordell wrote: > For me JSON is too simple, and YAML is too complex. I've tried to get > into YAML a couple of times, but it seems to have multiple ways to do > the same things, so I end up getting confused. I think it would be a great academic subject to study *where* people stumble that try to pick up something like YAML. Can you relate your experience in some more detail (off-list if that helps)? > It clearly fails at at > least one level to be human friendly. Why JSON doesn't have comments > eludes me. JavaScript does, so missing that bit in the subsetting was a > big drop off IMO. JSON was meant as an interchange format between programs, which don't need comments to talk to each other. (Also, if you do need to include commentary material, you way want to process this together with the other data, so you just add it as fields to your structure, keeping your data model simple.) [Just trying to relate the rationale as I have heard it expressed many times. Doesn't apply that much to config files, of course.] Grüße, Carsten From nobody Thu May 26 08:36:17 2016 Return-Path: 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 803CD12D71E for ; Thu, 26 May 2016 08:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Dz-DmxmSEGkO for ; Thu, 26 May 2016 08:36:14 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 487B812D6FA for ; Thu, 26 May 2016 08:36:10 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id 90so38741848qgz.1 for ; Thu, 26 May 2016 08:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=kahHuOyfj0dFMt+miVWIk0XBLtpMOQ7/buOSKFdBc/w=; b=B3cYV2CSjYB6fdHotgDlmMEgzHWq35jp5gRg1t/3D1Mi9rSZC45J0LexNx2oczdwY8 2vB2GWM78kXhwrCKyNO90vmb6J2l2HP+tJD++BeetoDa9c25fYQ4GAx1fB/awwEXCrBr qE4Nk6SOsRVBDQnxQU2zmeUpIbB7HpwjziNnjJhTNisOM3PclajxzIaMf5R3XOEcY4fb NY+vtm4ZMAsFTgzfGRHtnLC6chr2WP8DS+lso/g1LDUCPDm7AMNmtg1k6KOvor1maXna byPtVRA2t5di31uxCtIuqmpVmI+5xOH2fVS8TAyamiUBXc9ABJyUvPXTLxAmB8+II/XF 6UdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kahHuOyfj0dFMt+miVWIk0XBLtpMOQ7/buOSKFdBc/w=; b=mOUUlEui6fvj7LLRi/Wy3NpNPsDzczNaHN9ySFgOcD5G+nFfHxTOjGmSFUalDdzJXG T/8IYTg6EQ4YisWG+/Esnm1GM9Fec3xGnKOmlm9ZwY4iFO6v29RcCB6U3sj4Tuoplr2U KM1+KMpf6V97gsCYuEE1QzTd2RmYxh8huHkHBA/zgcTC+MggUYUFWo+dCuTmvg0J/khn ek9E171m39CgJ31QD95nDX65kUXyYwbPJyPdWe7OW2/JN03C4LEc8nslBNtBOXCzWsAh oaleGWzcFiMJyNulgIReWV9hpwNLW3WdYaqUcKmyOzI9Q8zGSoMQoofL9YQ3thCDILMZ bg9g== X-Gm-Message-State: ALyK8tKrTje9jp1J4NsEOmcshH7npogPRzrVdk1HzYMT+7k8e2RpKZQXyrhXnPOthWjHdxuCr7DwtmEsRbAT4g== MIME-Version: 1.0 X-Received: by 10.141.3.213 with SMTP id f204mr184930qhd.104.1464276969439; Thu, 26 May 2016 08:36:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 08:36:09 -0700 (PDT) In-Reply-To: <574711EE.2010405@tzi.org> References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471154.1050107@tzi.org> <574711EE.2010405@tzi.org> Date: Thu, 26 May 2016 11:36:09 -0400 X-Google-Sender-Auth: LYumDBsiWIkuo6IxpEFeVC83Mxg Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113a9e7a9dc9ca0533c08cf1 Archived-At: Cc: JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:36:15 -0000 --001a113a9e7a9dc9ca0533c08cf1 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 11:10 AM, Carsten Bormann wrote: > Carsten Bormann wrote: > (Things that I don't like to write.) > > And back to something productive: > > I think there is consensus that something would need to be added to JSON > to make it more amenable to configurations and other data entered and > edited by humans. We all have different experience with the various, > well-tried approaches here (e.g., some found YAML too complex, some have > good experience with it; various other extensions to and variations of > JSON are embodied in various open source projects, and there are even > other approaches like TOML where it would be nice to understand the > reasons for their existence). Based on these different experience > backgrounds we also have different opinions. > > But that doesn't mean we can't converge on something. The nature of a a > JSON working group is that it would tend to converge on "fixing" JSON. > Since this natural tendency (hammer/nail) always needs a bit of a > counteraction, I've been stressing that there are other approaches, such > as formalizing existing standards in this space. > YAML is not a markup language, it is called "YAML Ain't Markup Language". It is actually a schema format. While it might be useful to look at how they solved the issues, 'use YAML' isn't actually very helpful. What I do very much like about YAML is that it is indentation delimited like Python, occam and most of my languages I have developed using Goedel. However making that work with JSON which is brace delimited may be hard. The way I avoided this issue in Goedel is that the language is indentation delimited by default but it switches to brace delimited as soon as it hits a brace and continues to be brace delimited until it hits the matching close brace. So the following would all be equivalent: { "Tag1" : { "Tag2" : { "Tag3" : "Data" } } } Tag1 Tag2 Tag3 "Data" Tag1 { "Tag2" : { "Tag3" : "Data" } } } The second version is pretty much the Goedel syntax. I can show that is unambiguous as I define it as a FSM and then produce the grammar from the FSM. --001a113a9e7a9dc9ca0533c08cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 11:10 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
Carsten Bormann wrote:
(Things that I don't like to write.)

And back to something productive:

I think there is consensus that something would need to be added to JSON to make it more amenable to configurations and other data entered and
edited by humans.=C2=A0 We all have different experience with the various,<= br> well-tried approaches here (e.g., some found YAML too complex, some have good experience with it; various other extensions to and variations of
JSON are embodied in various open source projects, and there are even
other approaches like TOML where it would be nice to understand the
reasons for their existence).=C2=A0 Based on these different experience
backgrounds we also have different opinions.

But that doesn't mean we can't converge on something.=C2=A0 The nat= ure of a a
JSON working group is that it would tend to converge on "fixing" = JSON.
Since this natural tendency (hammer/nail) always needs a bit of a
counteraction, I've been stressing that there are other approaches, suc= h
as formalizing existing standards in this space.

<= /div>
YAML is not a markup language, it is called=C2=A0=C2=A0"YAML= Ain't Markup Language".

It is actually a= schema format. While it might be useful to look at how they solved the iss= ues, 'use YAML' isn't actually very helpful.

What I do very much like about YAML is that it is indentation delimi= ted like Python, occam and most of my languages I have developed using Goed= el. However making that work with JSON which is brace delimited may be hard= .

The way I avoided this issue in Goedel is that t= he language is indentation delimited by default but it switches to brace de= limited as soon as it hits a brace and continues to be brace delimited unti= l it hits the matching close brace.

So the followi= ng would all be equivalent:

{ "Tag1" : {= "Tag2" : { "Tag3" : "Data" } } }
<= br>
Tag1
=C2=A0 =C2=A0 Tag2
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Tag3 "Data"

Tag1 { "Tag2= " : { "Tag3" : "Data" } } }


The second version is pretty much the Goedel syntax. I ca= n show that is unambiguous as I define it as a FSM and then produce the gra= mmar from the FSM.=C2=A0

=C2=A0
--001a113a9e7a9dc9ca0533c08cf1-- From nobody Thu May 26 08:56:10 2016 Return-Path: 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 F01DC12D74C for ; Thu, 26 May 2016 08:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 NxKLs-PPbiJF for ; Thu, 26 May 2016 08:56:08 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 EDCC712D73C for ; Thu, 26 May 2016 08:56:07 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y126so60921943qke.1 for ; Thu, 26 May 2016 08:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yOXs5fLHxg/pFSlho+r4fCTaJCOBLSuOGxlHo3O8Isk=; b=pQrxg7WNElNrfBMvKpl0eQil57+spxZnU+rVkfM2ct6l1DqUD4XyjryZb4mkvdikVO ZBrg8qvfU5ZN9VVstJ7qYJFflzGhK1zfjjpmZ73vObZI0qKkIX+K1koZEngCVcGrkoZq ZL8nCY0w1FU3kGZYbSVoC4GFPGFnzLB7wKm5Xbs21TwdOcPAxrjcMwvQRg14beU845qj AfRzi+Pkb4Zb7aCvkMmAxnMZfZfj4ETdzRrkkYYMDjMpuruuNgWcuBOQkf85QWozuZzH XuIhP2MyH9l5muOLjtY8lsYT2nhr24mPh2XWMfmkjE7isZWsJ0Hm9tl5RQk2EduPviRJ 2cew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yOXs5fLHxg/pFSlho+r4fCTaJCOBLSuOGxlHo3O8Isk=; b=Kgqz28E2NynlX1hzMKDG2C6RP+3aNwW/OmLwp73r9TSBO3LSvHBINPxMGs5jz/BZGy 80cJKmbUbONNO4L7ZEEhSCROkkiXLNT6MbSezIujc2aaH0lwRxrEMrxeG2sOi3HA0Mvx HSi2pR72M+2+O1hrS1+qiPxfTNb3t7u2Ywa6D3XvpMHDIVDwCe/QN2hvj7EeQcHZLbfe StJH+dW4K9uSRIyxW9WZd1hiD1n5tiLtEAh8dsmJEqlnHzgWLVAC6lR81q1Icg6ck4ND yJwDldFIQ8YdpsiJr8zgecTE6uf1JTIhjiLR01ZwL3ohWTy75/PuuJEfPjiOD/RoSZRS eZYA== X-Gm-Message-State: ALyK8tL8xyMKi/xodTtmW/ovDT75A3cChCBO2KrsCkId1YZn0X2YkxoyKMcyS2jlN5CiBu6Dm5wS6X+s2zHYpQ== MIME-Version: 1.0 X-Received: by 10.200.50.162 with SMTP id z31mr9287453qta.7.1464278167060; Thu, 26 May 2016 08:56:07 -0700 (PDT) Received: by 10.140.100.215 with HTTP; Thu, 26 May 2016 08:56:06 -0700 (PDT) X-Originating-IP: [64.141.86.146] Received: by 10.140.100.215 with HTTP; Thu, 26 May 2016 08:56:06 -0700 (PDT) In-Reply-To: References: <5745EE5E.5050801@tzi.org> Date: Thu, 26 May 2016 08:56:06 -0700 Message-ID: From: Tim Bray To: Andrew Newton Content-Type: multipart/alternative; boundary=001a11403d540029f80533c0d47b Archived-At: Cc: Carsten Bormann , json@ietf.org Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 15:56:10 -0000 --001a11403d540029f80533c0d47b Content-Type: text/plain; charset=UTF-8 So, to close the loop, here's how I worked around the problem. I auto-processed my large schema with a Ruby script to generate a small schema for each of the "Type":"Animal/Vegetable/Mineral" variations, then if the large schema reports any errors, I run through the objects validating each with the appropriate micro-schema. This way, I almost always get a human-comprehensible error message. Not optimal, but better than writing a fully procedural validator by hand. On May 26, 2016 12:00 AM, "Andrew Newton" wrote: > On Wed, May 25, 2016 at 8:26 PM, Carsten Bormann wrote: > > Andrew Newton wrote: > >> It's not too much to ask, but the problem may be with the JSON parser. > >> Many parsers ingest JSON and give back native data structures, which > >> is what makes JSON simple for most people. But a validator needs > >> context that a typical JSON parser does not provide. > > > > Can you give an example for that? > > > > Given the following: > > [ > { "foo" : "bar" } > ] > > Here is what happens if I use the built-in Ruby parser: > > irb(main):017:0> s > => "\n[\n { \"foo\":\"bar\"}\n]\n" > irb(main):018:0> JSON.parse s > => [{"foo"=>"bar"}] > > If a validator wants to ensure that "foo" is "baz" and not "bar", its > lost the information to tell the user to look at line 2. > > By contrast, if a validator were to use Jackson as a stream parser, it > would have access to JsonLocation: > > http://fasterxml.github.io/jackson-core/javadoc/2.1.0/com/fasterxml/jackson/core/JsonLocation.html > > > (I'm familiar with a problem like this from CBOR, where CDDL maybe > > sometimes wants to make serialization choices*), which are no longer > > visible at the data model level; I just haven't seen the need with JSON.) > > I'm not sure we are talking about the same thing. > > -andy > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11403d540029f80533c0d47b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, to close the loop, here's how I worked around the pr= oblem. I auto-processed my large schema with a Ruby script to generate a sm= all schema for each of the "Type":"Animal/Vegetable/Mineral&= quot; variations, then if the large schema reports any errors, I run throug= h the objects validating each with the appropriate micro-schema.=C2=A0 This= way, I almost always get a human-comprehensible error message.

Not optimal, but better than writing a fully procedural vali= dator by hand.

On May 26, 2016 12:00 AM, "Andrew Newton&qu= ot; <andy@hxr.us> wrote:
On Wed, May 25, 2016 at 8:2= 6 PM, Carsten Bormann <cabo@tzi.org&= gt; wrote:
> Andrew Newton wrote:
>> It's not too much to ask, but the problem may be with the JSON= parser.
>> Many parsers ingest JSON and give back native data structures, whi= ch
>> is what makes JSON simple for most people. But a validator needs >> context that a typical JSON parser does not provide.
>
> Can you give an example for that?
>

Given the following:

[
=C2=A0 { "foo" : "bar" }
]

Here is what happens if I use the built-in Ruby parser:

irb(main):017:0> s
=3D> "\n[\n=C2=A0 { \"foo\":\"bar\"}\n]\n"=
irb(main):018:0> JSON.parse s
=3D> [{"foo"=3D>"bar"}]

If a validator wants to ensure that "foo" is "baz" and = not "bar", its
lost the information to tell the user to look at line 2.

By contrast, if a validator were to use Jackson as a stream parser, it
would have access to JsonLocation:
ht= tp://fasterxml.github.io/jackson-core/javadoc/2.1.0/com/fasterxml/jackson/c= ore/JsonLocation.html

> (I'm familiar with a problem like this from CBOR, where CDDL maybe=
> sometimes wants to make serialization choices*), which are no longer > visible at the data model level; I just haven't seen the need with= JSON.)

I'm not sure we are talking about the same thing.

-andy

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--001a11403d540029f80533c0d47b-- From nobody Thu May 26 09:12:31 2016 Return-Path: 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 0728B12D743 for ; Thu, 26 May 2016 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Pg18YmLCJ-Ai for ; Thu, 26 May 2016 09:12:27 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A17012D741 for ; Thu, 26 May 2016 09:12:27 -0700 (PDT) Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 6751EFB974; Thu, 26 May 2016 18:07:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ejY7HX_oIHlX; Thu, 26 May 2016 18:07:40 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 81572FB97C; Thu, 26 May 2016 18:04:22 +0200 (CEST) Message-ID: <57471E84.7010503@tzi.org> Date: Thu, 26 May 2016 18:04:20 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tim Bray References: <5745EE5E.5050801@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 16:12:30 -0000 Tim Bray wrote: > So, to close the loop, here's how I worked around the problem. I > auto-processed my large schema with a Ruby script to generate a small > schema for each of the "Type":"Animal/Vegetable/Mineral" variations, > then if the large schema reports any errors, I run through the objects > validating each with the appropriate micro-schema. This way, I almost > always get a human-comprehensible error message. >From a grammar validation point of view, you believe the type field more than the other fields, so if there is a conflict between them, the type field wins and the other fields can thus be flagged as wrong. In a definite clause grammar (DCG), cuts can be used to elicit similar behavior. There are proposals for cut points in parse expression grammars (PEGs); maybe that is a good subject for further evaluation. Grüße, Carsten From nobody Thu May 26 09:31:47 2016 Return-Path: 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 F249A12D753 for ; Thu, 26 May 2016 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TZbYZyttavzz for ; Thu, 26 May 2016 09:31:44 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 1A21212D75A for ; Thu, 26 May 2016 09:31:44 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x7so61583951qkd.3 for ; Thu, 26 May 2016 09:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=iEsNONXZEOVewWhT7VFrfCFFLsDz6xpGb9YZOSMp6jo=; b=lHoVHW7PiDuljXtBPqJnaFlIbY0R1VLrsXOYcryY6Szt4et0ntK/7dxJqfDv7l31LI ihDghpABI8TPcv8uAe35D21veS56jNdZ3BPw++G4IEEqvxJ38VpgK+uiVaJHBfv70JPk XjEpP4Ddb/iLxHYDf/zEDniuTFTKAQ63MV3fUPWyTUMNCj4AjCXw4jNaZ4gJmLjyQjN8 9iTEYrUmDJeXxDBosMhvCG6M3DQE242s8aTR7O4HmK2qDwhrCdSEcSOjb2VgGyuMQXqo kygZ25wJ4dK1/SYv7/xvfC83PlXrq6KgMrS2P3FCH0YaOZh7MGSWDYYTXONgPdoj1hxc V47Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=iEsNONXZEOVewWhT7VFrfCFFLsDz6xpGb9YZOSMp6jo=; b=i1WocoR/eODH5/aqy3891Y9EkdD1S+nW4iBYK+6hJJzAWNPS6Uqye6msRt9CDgxe5u 9RZvUsa2vMg1nZTRxAyP7GhV4XzQvpuaGNtQUjq77JdQJgxS6xVaNHgXZxIAY/OzYdUo zH/eqa0cBHqApImIAnW8ZFZcF7hUlx0ZdX4FPM9m+gUqz82xTCxTet8/Z5W3cdsUs4jl srqA4T7z63skIjBxSpFl8VbKV90hUFL2bOxpdNQ+jeltFxwdthE/jTsoJbODpe2oaZKE kuhGh11pWyQWI999AxCIcQVN1OKA1Wmk0lcYX6fGjYZRLNqfzuyXqWgnldMcaHGmT9St oSow== X-Gm-Message-State: ALyK8tImsY70Xhw1AZTIifHKjuP5BypaZVaLdGFUgvHEPmX6jKrnqYuIoUk3akd4kxAcZgQV6GjGByA1zQU5tw== MIME-Version: 1.0 X-Received: by 10.55.114.71 with SMTP id n68mr10059478qkc.37.1464280303118; Thu, 26 May 2016 09:31:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 09:31:43 -0700 (PDT) Date: Thu, 26 May 2016 12:31:43 -0400 X-Google-Sender-Auth: hIBfjVHeMNO0PATwEOeFVDHje2I Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=001a114fef8a51b07c0533c1537e Archived-At: Subject: [Json] Schema for config files Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 16:31:46 -0000 --001a114fef8a51b07c0533c1537e Content-Type: text/plain; charset=UTF-8 It isn't on topic for the encoding discussion, but is for the schema we keep discussing. Over the past 20 odd years I have designed a lot of languages. At least 30. And about a dozen of those look very much like a schema sort of language. All that my Goedel tool is, is a front end that allows me to quickly create a parser that reads an input file and converts it to a DOM like tree and a back end that is simply a scripting language that then expands it. This is a very powerful way to code if you want to write stuff quickly. The one thing that I have in Goedel that isn't in the JSON schemas I have seen is that I have a 'Label' construct similar to an XMLSchema ID. Labels are very useful in Goedel because the parser automatically links them in both directions. If I specify a label 'Foo' in one part of the input file, the parsed data structure will have a list of links to every part of the data structure that references it. (And vice versa of course). This is very useful in config files because it allows you to do things like specify the parameters for a network connection in one place and then instantiate it in multiple places. I don't see any need to specify ranges on integers, number of sub items that can appear or anything of that sort. But labels are very very powerful. The other thing that I have found I want but never implemented is to have the backing structure automatically collect up references to lists of options. So in my current UI scheme I have a UI that can contain a list of Wizards, Dialogs, menus and such. [NB, the convention here is label follows type, something else I would like to fix some day] GUI MyUI Wizard CreateProfile ... wizard def Menu MainMenu Dialog Print Dialog Exit So right now, the backing structure in C# is class GUI : Object { Label Name; List Entries; } Which is OK only my scripting language then ends up being full of code to filter on particular types of entry. A better scheme would be: class ObjectSet { List Object; // All objects List Wizard ; // filtered to Wizard List Menu ; List Dialog ; ... } class GUI : Object { Label Name; ObjectSet Entries; } Supporting a JSON like serialization properly would be fairly straightforward. I would just have to work out how to redesign the parser so that the object name always precedes the object data. Which is the JSON way and actually a better way to do things: MyUI GUI CreateProfile Wizard ... wizard def MainMenu Menu Print Dialog Exit Dialog The reason this is better is that a label is always an atom whereas a type can have parameters. I suspect that what it would take is to distinguish between objects and structures. The difference being that an object always has an identifier and can be the target of a label and a structure does not. class Object { Label Name; } class GUI : Object { ObjectSet Entries; } --001a114fef8a51b07c0533c1537e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It isn't on topic for the e= ncoding discussion, but is for the schema we keep discussing.

Over the past 20 od= d years I have designed a lot of languages. At least 30. And about a dozen = of those look very much like a schema sort of language.

All that my Goedel tool i= s, is a front end that allows me to quickly create a parser that reads an i= nput file and converts it to a DOM like tree and a back end that is simply = a scripting language that then expands it.
=
This is a very powerful way to code if= you want to write stuff quickly.

The one thing that I have in Goedel that isn= 9;t in the JSON schemas I have seen is that I have a 'Label' constr= uct similar to an XMLSchema ID. Labels are very useful in Goedel because th= e parser automatically links them in both directions.

If I specify a label 'F= oo' in one part of the input file, the parsed data structure will have = a list of links to every part of the data structure that references it. (An= d vice versa of course).


This is very useful= in config files because it allows you to do things like specify the parame= ters for a network connection in one place and then instantiate it in multi= ple places.

I don't see any need to specify ranges on integers, number of sub= items that can appear or anything of that sort. But labels are very very p= owerful.


The other thing that I have found I= want but never implemented is to have the backing structure automatically = collect up references to lists of options.
=
So in my current UI scheme I have a UI= that can contain a list of Wizards, Dialogs, menus and such. [NB, the conv= ention here is label follows type, something else I would like to fix some = day]

G= UI MyUI
=C2=A0 =C2=A0Wizard CreateProfile
=C2=A0 =C2=A0 =C2=A0 =C2=A0... wizard def
=C2=A0 =C2=A0Menu MainMenu
=C2=A0 =C2=A0Dialog Print
=C2=A0 =C2=A0Dialog Exit

So right now, the backing structure in C# is

class GUI : Obje= ct {
=C2=A0 =C2=A0 Label Name;
=C2=A0 =C2=A0 List <Object> Entries;
=C2=A0 =C2=A0 }

Which is OK only my scripting language then e= nds up being full of code to filter on particular types of entry. A better = scheme would be:

class ObjectSet {
=C2=A0 =C2=A0 = List <Object> Object; =C2=A0// All objects
=C2=A0 =C2=A0 List <Wizard=C2=A0>=C2=A0Wizard=C2=A0=C2=A0; = =C2=A0// filtered to Wizard
=C2=A0 =C2= =A0 List <Menu>=C2=A0Menu=C2=A0;
= =C2=A0 =C2=A0 List <Dialog>=C2=A0Dialog=C2=A0;
=C2=A0 =C2=A0 ...
=C2=A0 =C2= =A0 }

= class GUI : Object {
=C2=A0 =C2=A0 Label Na= me;
=C2=A0 =C2=A0 ObjectSet Entries;
<= div class=3D"gmail_extra">=C2=A0 =C2=A0 }
<= br>
Supporting a JSON like serialization pr= operly would be fairly straightforward. I would just have to work out how t= o redesign the parser so that the object name always precedes the object da= ta. Which is the JSON way and actually a better way to do things:

MyUI GUI=C2=A0
=C2=A0 =C2=A0Cre= ateProfile Wizard=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0... wizard def
=C2=A0 =C2=A0MainM= enu Menu=C2=A0
=C2=A0 =C2=A0Print Dialog=C2= =A0
=C2=A0 =C2=A0Exit Dialog=C2=A0

The reas= on this is better is that a label is always an atom whereas a type can have= parameters.=C2=A0

I suspect that what it would take is to distinguish between ob= jects and structures. The difference being that an object always has an ide= ntifier and can be the target of a label and a structure does not.

class Object {=
=C2=A0 =C2=A0 Label Name;
=C2=A0 =C2=A0 }

class GUI : Object= {
=C2=A0 =C2=A0 ObjectSet Entries;
=C2=A0 =C2=A0 }


--001a114fef8a51b07c0533c1537e-- From nobody Thu May 26 09:56:17 2016 Return-Path: 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 22A2912D671 for ; Thu, 26 May 2016 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 GlyBg2KdyK-r for ; Thu, 26 May 2016 09:56:15 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D5512D0F3 for ; Thu, 26 May 2016 09:56:15 -0700 (PDT) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id E6B7117212E; Thu, 26 May 2016 18:56:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id O-J2DQRDgW3U; Thu, 26 May 2016 18:56:12 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3F3D61720D5; Thu, 26 May 2016 18:56:11 +0200 (CEST) Message-ID: <57472AA9.60405@tzi.org> Date: Thu, 26 May 2016 18:56:09 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: JSON WG Subject: Re: [Json] Schema for config files Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 16:56:16 -0000 Phillip Hallam-Baker wrote: > This is very useful in config files because it allows you to do things > like specify the parameters for a network connection in one place and > then instantiate it in multiple places. Yep, that is exactly why YAML turned out to be more useful for configuration files than other formats I have tried. Grüße, Carsten From nobody Thu May 26 10:15:39 2016 Return-Path: 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 EBB4E12D7AF for ; Thu, 26 May 2016 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 JDtIlE0rfLdb for ; Thu, 26 May 2016 10:15:35 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33C312D7C5 for ; Thu, 26 May 2016 10:15:34 -0700 (PDT) Received: (qmail 3525 invoked from network); 26 May 2016 18:10:42 +0100 Received: from host86-178-51-202.range86-178.btcentralplus.com (HELO ?192.168.1.72?) (86.178.51.202) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 May 2016 18:10:42 +0100 To: Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471309.8040102@tzi.org> From: Peter Cordell Message-ID: <37c6ca77-0178-3448-53c3-330c847afdfc@codalogic.com> Date: Thu, 26 May 2016 18:15:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57471309.8040102@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:15:37 -0000 On 26/05/2016 16:15, Carsten Bormann wrote: > Peter Cordell wrote: >> For me JSON is too simple, and YAML is too complex. I've tried to get >> into YAML a couple of times, but it seems to have multiple ways to do >> the same things, so I end up getting confused. > > I think it would be a great academic subject to study *where* people > stumble that try to pick up something like YAML. Can you relate your > experience in some more detail (off-list if that helps)? > I'll do one round on-list in the hope that it's helpful for some possible future work: - The specification is long! - Having two forms - block style and flow style - doubles the confusion - As a C family programmer, the block format doesn't 'speak' to me, (whereas the JSON format does) - I haven't done YAML for the other reasons, but I imagine getting the indentation right with lists started by '-' is annoyingly fiddly. Hence I'm put off going down that path before even trying it. - Perl-esq levels of non-intuitive magical characters - There looks to be things like namespacing which for most things I probably won't need. Alas, because they are there, at some point some bright spark will use them, which means I will have to support them. So though I could look at things like that as 'optional' at some point they probably won't be, in much the same way that if you attempt to use a simplified XML processor, at some point it will bite you! >> It clearly fails at at >> least one level to be human friendly. Why JSON doesn't have comments >> eludes me. JavaScript does, so missing that bit in the subsetting was a >> big drop off IMO. > > JSON was meant as an interchange format between programs, which don't > need comments to talk to each other. (Also, if you do need to include > commentary material, you way want to process this together with the > other data, so you just add it as fields to your structure, keeping your > data model simple.) > [Just trying to relate the rationale as I have heard it expressed many > times. Doesn't apply that much to config files, of course.] While I understand that rationale, when you have a text based format that can be consumed by services I still think it was naive to not anticipate that people would want to create their own hand edited versions, perhaps for test purposes, and squirt them into services to see what happens. From there, config files are a small step. Indeed, it's also naive to not expect a successful 'thing' to be used beyond the scope it was originally intended for. But that's all water under the bridge, and there's little point crying over it, other than to perhaps note that "anything that can be edited in an editor will be edited in an editor, and anything that will be edited in an editor should allow comments" ;-) Pete. From nobody Thu May 26 10:37:29 2016 Return-Path: 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 A7C5812D7EA for ; Thu, 26 May 2016 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, 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 ra5UORmjRw4S for ; Thu, 26 May 2016 10:37:26 -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 B3C2012D7CF for ; Thu, 26 May 2016 10:37:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1b5zDk-0002Ap-8R; Thu, 26 May 2016 13:37:20 -0400 Date: Thu, 26 May 2016 13:37:20 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160526173719.GA19074@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Tim Bray , "json@ietf.org" , Austin William Wright , Andrew Newton Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:37:27 -0000 Phillip Hallam-Baker scripsit: > I have some very strong opinions on the advantages of strong typing. Even if you accept the principle of strong typing, that is not conclusive as to how many atomic types you have. Most programming languages have only one string type, or at most have a family of types varying only by length or maximum length. But it would be possible to declare the type of a string using a regular expression, and Cobol approximates this with its PICTURE types. On the other hand, statically typed languages typically have multiple types of numbers: C has 14, Java has 7, Pascal has 2, and Algol 68 has a denumerably infinite number (short int, short short int, short short short int, etc.) all statically distinct, though normally only a finite number of distinct run-time representations. If we stick to JSON's mutually exclusive atomic types of null, boolean, number, string, we can devise a very simple schema language for static typing only. Most of the complexity comes from wanting to provide more complex static types such as integer vs. non-integer, exact vs. inexact, or highly constrained strings. =========== Here's a sketch of a simple schema-by-example language: The type 'any JSON number' is encoded by any JSON number. The type 'any JSON boolean' is encoded by any JSON boolean. The type 'any JSON string' is encoded by any JSON string not specially mentioned here. The type 'JSON array of fixed size with fixed types' is encoded by a JSON array whose elements are the encodings of the fixed types. This corresponds to a tuple in some statically typed languages. The type 'JSON array of variable size with fixed element type' is encoded by a JSON array whose first element encodes the element type and whose second element is the string "...". This corresponds to a list in some statically typed languages. It can be combined with the last rule to allow arrays whose first few elements have different element types, and any additional elements have the same type. The type 'arbitrary JSON array' is encoded by the JSON string "[]". The type 'JSON object with fixed keys' is encoded by a JSON object whose keys are the fixed keys and whose values encode the types of their corresponding keys. The type 'JSON object with arbitrary keys' is encoded by the JSON string "{}". The type 'arbitrary JSON value' is encoded by the JSON string "*". Open questions: 1) What about a JSON object with fixed keys that also allows arbitrary additional keys? 2) What about null? It can be treated as the sole inhabitant of a unique atomic type encoded by a JSON null, or as something not mentioned in schemas that is always allowed in place of any JSON value (like SQL null), or as a replacement for arrays and objects only. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org if if = then then then = else else else = if; From nobody Thu May 26 10:56:42 2016 Return-Path: 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 8C59F12D5F9 for ; Thu, 26 May 2016 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gEcK5gwtQwxa for ; Thu, 26 May 2016 10:56:38 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D05AC12D0FF for ; Thu, 26 May 2016 10:56:37 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id y126so63305764qke.1 for ; Thu, 26 May 2016 10:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9S+VLi7LKtbREIkYCyl+LF7X8fwoS9EqXEloCwXNBb4=; b=eG7BEMXo29Q35gARy+LCWHyRiNtW28y67Z0miNrT+r/nx1gE2VnSTsnR1fUAfo5wsw 3kQH3yeC25HdjoPaaBY4K/FwjuiMsXemlvLnfUP2nKohlWHt3mjo7XClYJABcUcHDZim x/o51CHKRc89iUl0Tom3jERU8twzfCO9EOslJPxybAEt0fu0v4G6gauH2sGIPSVHAZ5V WqActbU6UVNuOZyBldxuR55Zt9vI8+IuST3p+trEwt4RwgECLtafCCrg2OBGcjmPoTJT 7UvuaH5TWnDIyempAOFCfzoBnWLP3PjnhEGwm9LnMWUynilACGjiumYZhNLacIZaZaSR Cd8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9S+VLi7LKtbREIkYCyl+LF7X8fwoS9EqXEloCwXNBb4=; b=VIqLeQN7uLslmopejtGftm5vMnbQSc259uOoIdHrRuILY6y9qbLmtq2bsX/YBgdXG9 kbKlQ+qybGajHXdpwP8CC7LVEaDKP8YQ9emMvYQTY6E/zwAe4DinbLoiAlerDD+lbAik Vm0TJusxOsBNUTqCv6Srv4PEFNQuKw7qi2DWBPkmkaThKOjfGcEgFIKXsqm5wVAXLmT2 ivRRqBei0mdIFNGcIciLRswlbeBIlp7xit56sbz4PvasI330lL0MmdbrT4YZZnNK/nxv L20l5yf8AK4hfKcD3FDH7qbQ43pLdOTZjqDiAaK824+vJX06iZZTqAXpz7If33xeVSPO Q+yA== X-Gm-Message-State: ALyK8tJU0QpVApai6XeKrTt85WSMAo03n7p3Ap9+xkZKAj0ReFNI9uJjsG51K3LjxCh59rJ0csZR608DzUWIMA== MIME-Version: 1.0 X-Received: by 10.55.120.196 with SMTP id t187mr9963819qkc.6.1464285396776; Thu, 26 May 2016 10:56:36 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 10:56:36 -0700 (PDT) In-Reply-To: <20160526173719.GA19074@mercury.ccil.org> References: <20160526173719.GA19074@mercury.ccil.org> Date: Thu, 26 May 2016 13:56:36 -0400 X-Google-Sender-Auth: Ic9C6oFjIrvgdRMxDO1gzcqYui0 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=94eb2c05cebcecbff90533c2827c Archived-At: Cc: Tim Bray , "json@ietf.org" , Austin William Wright , Andrew Newton Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:56:40 -0000 --94eb2c05cebcecbff90533c2827c Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 1:37 PM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > I have some very strong opinions on the advantages of strong typing. > > Even if you accept the principle of strong typing, that is not conclusive > as to how many atomic types you have. Most programming languages have > only one string type, or at most have a family of types varying only by > length or maximum length. But it would be possible to declare the type > of a string using a regular expression, and Cobol approximates this with > its PICTURE types. > > On the other hand, statically typed languages typically have multiple > types of numbers: C has 14, Java has 7, Pascal has 2, and Algol 68 has > a denumerably infinite number (short int, short short int, short short > short int, etc.) all statically distinct, though normally only a finite > number of distinct run-time representations. > > If we stick to JSON's mutually exclusive atomic types of null, boolean, > number, string, we can devise a very simple schema language for static > typing only. Most of the complexity comes from wanting to provide more > complex static types such as integer vs. non-integer, exact vs. inexact, > or highly constrained strings. > I don't really consider different types of integer to be different types. They are different representations of whole numbers, they are all intrinsically the same type. There is a similar error in Pascal which in the ANSI standard has the ludicrous insistence that int [2] is a different type to int [3]. And there is no cast operator. Small wonder people used to refer to it as being 'Wirthless' Yes, real numbers and integers are probably things you want to be able to treat differently in code because it is very very rare to need or want a real64 number in a protocol. I have no problem with limiting the intrinsic types to the set given in JSON. What I mean by strong typing is that when I convert a JSON data stream I convert it to a data model that has classes and structures that are in the application data model. So I write code of the form: Profile.Applications.Add (MailApplication); Rather than something like Tree.Append (Profile, "Profile.Applications", MailApplication.Tree()); Yes, if you use a fully dynamic binding language, you can write code that looks like the first example. But what you don't get in that situation is static type checking on your code. My code sill throw a compiler error if I try to add a DeviceProfile in a slot typed as a list of ApplicationProfile. > =========== > > Here's a sketch of a simple schema-by-example language: > Mostly agree as a starting point. But I think that you absolutely want to be able to put binary blobs of data in a stream and distinguish them from strings. I have spec, running code and apps written in it. > > Open questions: > > 1) What about a JSON object with fixed keys that also allows arbitrary > additional keys? > That is an interesting one because it comes down to how do you want extensibility to work. In particular, when do you want adding things to be backwards compatible and when do you want to cause things to halt rather than have an application try to act on data it did not fully understand? > 2) What about null? It can be treated as the sole inhabitant of a unique > atomic type encoded by a JSON null, or as something not mentioned in > schemas that is always allowed in place of any JSON value (like SQL null), > or as a replacement for arrays and objects only. > This is actually a little problematic as in JSON any slot can hold null while many languages don't allow integers or booleans to be null. C# has nullable types for integers and booleans. But lots of languages don't. I am very wary of writing protocol logic that would depend on such a distinction. --94eb2c05cebcecbff90533c2827c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 1:37 PM, John Cowan <cowan@mercury.ccil.o= rg> wrote:
Phillip Hallam-B= aker scripsit:

> I have some very strong opinions on the advantages of strong typing.
Even if you accept the principle of strong typing, that is not concl= usive
as to how many atomic types you have.=C2=A0 Most programming languages have=
only one string type, or at most have a family of types varying only by
length or maximum length.=C2=A0 But it would be possible to declare the typ= e
of a string using a regular expression, and Cobol approximates this with its PICTURE types.

On the other hand, statically typed languages typically have multiple
types of numbers: C has 14, Java has 7, Pascal has 2, and Algol 68 has
a denumerably infinite number (short int, short short int, short short
short int, etc.) all statically distinct, though normally only a finite
number of distinct run-time representations.

If we stick to JSON's mutually exclusive atomic types of null, boolean,=
number, string, we can devise a very simple schema language for static
typing only.=C2=A0 Most of the complexity comes from wanting to provide mor= e
complex static types such as integer vs. non-integer, exact vs. inexact, or highly constrained strings.

I don= 9;t really consider different types of integer to be different types. They = are different representations of whole numbers, they are all intrinsically = the same type.

There is a similar error in Pascal = which in the ANSI standard has the ludicrous insistence that int [2] is a d= ifferent type to int [3]. And there is no cast operator. Small wonder peopl= e used to refer to it as being 'Wirthless'

Yes, real numbers and integers are probably things you want to be able to = treat differently in code because it is very very rare to need or want a re= al64 number in a protocol.

I have no problem with = limiting the intrinsic types to the set given in JSON. What I mean by stron= g typing is that when I convert a JSON data stream I convert it to a data m= odel that has classes and structures that are in the application data model= . So I write code of the form:

Profile.Application= s.Add (MailApplication);

Rather than something lik= e

Tree.Append (Profile, "Profile.Applications= ", MailApplication.Tree());


Ye= s, if you use a fully dynamic binding language, you can write code that loo= ks like the first example. But what you don't get in that situation is = static type checking on your code. My code sill throw a compiler error if I= try to add a DeviceProfile in a slot typed as a list of ApplicationProfile= .

=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Here's a sketch of a simple schema-by-example language:

Mostly agree as a starting point. But I think that you= absolutely want to be able to put binary blobs of data in a stream and dis= tinguish them from strings.

I have spec, running c= ode and apps written in it.
=C2=A0

Open questions:

1) What about a JSON object with fixed keys that also allows arbitrary
additional keys?

That is an interesting= one because it comes down to how do you want extensibility to work. In par= ticular, when do you want adding things to be backwards compatible and when= do you want to cause things to halt rather than have an application try to= act on data it did not fully understand?

=C2=A0
2) What about null?=C2=A0 It can be treated as the sole inhabitant of a uni= que
atomic type encoded by a JSON null, or as something not mentioned in
schemas that is always allowed in place of any JSON value (like SQL null),<= br> or as a replacement for arrays and objects only.

<= /div>
This is actually a little problematic as in JSON any slot can hol= d null while many languages don't allow integers or booleans to be null= .

C# has nullable types for integers and booleans.= But lots of languages don't. I am very wary of writing protocol logic = that would depend on such a distinction.
--94eb2c05cebcecbff90533c2827c-- From nobody Thu May 26 13:50:49 2016 Return-Path: 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 C3AAD12D9BF for ; Thu, 26 May 2016 13:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, 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 2WNAk8rVE1Ni for ; Thu, 26 May 2016 13:50:42 -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 E176212D9D2 for ; Thu, 26 May 2016 13:50:39 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1b62Ej-0000a9-Mh; Thu, 26 May 2016 16:50:33 -0400 Date: Thu, 26 May 2016 16:50:33 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160526205033.GD19074@mercury.ccil.org> References: <20160526173719.GA19074@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Tim Bray , "json@ietf.org" , Austin William Wright , Andrew Newton Subject: [Json] JSON by example X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 20:50:45 -0000 Phillip Hallam-Baker scripsit: > 'Wirthless' "You may call me by value, and call me 'Worth', or you may call me by name, and call me 'Veert'." --Wirth on how to say his name. > Yes, real numbers and integers are probably things you want to be able > to treat differently in code because it is very very rare to need or > want a real64 number in a protocol. Okay, an integer encodes the type "JSON number which is an integer", and a non-integer encodes the type "JSON number". Note that this might be represented as a Java BigDecimal or equivalent. > But I think that you absolutely want to be able to put binary blobs of > data in a stream and distinguish them from strings. Good idea. If the string is "deadbeef", it encodes the type of binary blobs represented in JSON as a string. :-) > That is an interesting one because it comes down to how do you want > extensibility to work. In particular, when do you want adding things > to be backwards compatible and when do you want to cause things to > halt rather than have an application try to act on data it did not > fully understand? I think you want to be able to choose, but I'm not sure how to represent it within the JSON-by-example format. The obvious way is to reserve a key like "...", but I haven't wanted to do that. > This is actually a little problematic as in JSON any slot can hold > null while many languages don't allow integers or booleans to be null. True. We can say then that null is always permitted wherever the schema allows an array or object. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org How they ever reached any conclusion at all is starkly unknowable to the human mind. --"Backstage Lensman", Randall Garrett From nobody Thu May 26 14:27:38 2016 Return-Path: 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 30B7E12D75C for ; Thu, 26 May 2016 14:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 bn-2ueRgijfx for ; Thu, 26 May 2016 14:27:35 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC2012D150 for ; Thu, 26 May 2016 14:27:34 -0700 (PDT) Received: (qmail 25909 invoked from network); 26 May 2016 22:22:42 +0100 Received: from host86-135-56-118.range86-135.btcentralplus.com (HELO ?192.168.1.72?) (86.135.56.118) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 May 2016 22:22:42 +0100 To: John Cowan References: <20160526173719.GA19074@mercury.ccil.org> From: Peter Cordell Message-ID: <064f4df2-75d5-6952-cd18-e22e7510b3a6@codalogic.com> Date: Thu, 26 May 2016 22:27:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160526173719.GA19074@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:27:37 -0000 On 26/05/2016 18:37, John Cowan wrote: > > Here's a sketch of a simple schema-by-example language: > I think sort of thing in JCR by having a directive such as #infer-types, e.g. #infer-types { "foo" : "bar" } 'foo' is then any string, not just "bar". If that is too intrusive, you could have a configuration option to the JCR parser to select similar type inferring. I think that would be useful as 'by-example' is perhaps an easy way to start creating a schema, but I feel you'd want to go beyond what it can offer within a matter of hours. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Thu May 26 14:44:27 2016 Return-Path: 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 5FEB012DB70 for ; Thu, 26 May 2016 14:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o_4udWj2EcPE for ; Thu, 26 May 2016 14:44:25 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 CB19412D75C for ; Thu, 26 May 2016 14:44:24 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n129so115352558wmn.1 for ; Thu, 26 May 2016 14:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=E2MeCYNkWVsQgCiP5p75wa7bVxOekBvvfAqmj/7SOsc=; b=LPTjwIta4RbBbiThgRhZT9Ed29zVBNI49rU6IUltB7DbHmFPzKPj7lU2SP4qPODvbD QzzTlSBQFlRHhyPnaPzk6wm89Gpk+SiYVEKMO6lHlgSfJi4lIgDFVAGXc/rEqr5NU4BM LAyTgxzH5XhecWUVmhg8FlPYzBIXgmVrgxXbgXq8HB6yv65Of1K99KLW3O8pbhGXZWUp YiBQ0JnJ8jpncNS+DsSdNjrQZlxlKX5mJl+klpHqxfazG/r3UhvxV1xfV7Apfz/wMw89 JzQqyZyHv2PNGrj1tbRINnDzv4Hrl0xvEraQv/z46fW9VRWBLit54UcEKbaqdPV8mdkh KL+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=E2MeCYNkWVsQgCiP5p75wa7bVxOekBvvfAqmj/7SOsc=; b=l6N2qb3Qw74bI/LK6OFQWsbkX5oeT3WRRHXaKW4pEqqyRa9O41dJL7SayZNdcf8hv4 p1q+M6lTMl0yUkHRS4CbZXq5JDTPW52P5GW5E173C1zDrUlMi64K7jaUO6p+pZJb6lWF zVI/Kivk8LRogjCjXpb8gWzbvQEkT1mM8bHlZ5KnDkEf+rh8iFy9C/n5h2qq9/xtqcUo yLxfz2RccqDBzdU3TEYt74r4aJraN63ACQ/dguqb9lQAs5uFry8Eg/7NpgjruCV0lvXz BMVe7k2JosrRqv/nkldzO7JjLGUQbUj3yC6kDtK+zPGGw15pXb8QBcwUfdcB+uPRqEA+ aGcA== X-Gm-Message-State: ALyK8tLflXo7dNSd5HppxBpc5luY1GubkQdim7RYW49FJ7WKUi3EyhlXZdKov+wWs3DDrA== X-Received: by 10.194.186.200 with SMTP id fm8mr11442161wjc.174.1464299063437; Thu, 26 May 2016 14:44:23 -0700 (PDT) Received: from [192.168.1.181] (77.116.171.9.wireless.dyn.drei.com. [77.116.171.9]) by smtp.googlemail.com with ESMTPSA id a81sm5437572wma.16.2016.05.26.14.44.22 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 14:44:22 -0700 (PDT) From: Christian Zangl To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> Message-ID: Date: Thu, 26 May 2016 23:44:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:44:26 -0000 On 2016-05-26 16:01, Phillip Hallam-Baker wrote: > A superset of JSON encoding optimized for human input makes a lot of > sense. In particular it should be possible for a single parser to read > data in either strict JSON or JSON-x. Which is what I did with JSON-B, > JSON-C and JSON-D. > > I suggest the following additions: > > 1) Comments > > 2) Use of quotes on labels is optional if the label conforms to C-like > rules (does not start with a digit or contain white space, control or > punctuation marks. > > 3) Allow trailing comas > > 4) Punctuation optional in situations it is not ambiguous. You still have a problem with the backslash in strings. On Windows you can't just copy&paste a path because all \ need to be escaped. Also config files sometimes contain regular expressions and having to escape the \ makes them unreadable. That's why Hjson has quoteless strings that are raw strings ending at LF. From nobody Thu May 26 14:44:50 2016 Return-Path: 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 02C7B12D11E for ; Thu, 26 May 2016 14:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6RHIZb2zDh3Q for ; Thu, 26 May 2016 14:44:47 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 7F76812D0C2 for ; Thu, 26 May 2016 14:44:47 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a136so45966045wme.0 for ; Thu, 26 May 2016 14:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=LHFNKjZpEnejHAB2DQwIj7qHn5MBEVFgFcMsQG1XvpY=; b=ofxUovP15wZCeevJB92//h6O22RDd3ZlF+MWIDiuoX1rTPJWObvjqnFHV0bAS8q3+M Ey4c+ZwO2f8qbWm3o5fM+O++OLo3D25lxpQTO3G4OrQExAyg7gJv6QZMvBEIOZBXTvTo P5lz/QtASr+ZYZ38lvvh7E0PP2lMjjg206LVFOlJi+PSQcA8kTR2Ou3Yi0bDwbanmQxa SRk2emI0andDxoU+LbX3encVa8j5iWEvkyzZwGQxWstu0JELMw7gLkcX73C5b5GatB47 r7SYmFkbocqJklJS4aoHXLxQkc7xjFtlcSVu5FdDQPyZAFd68HJnM4JHkzV0cmXCgpBn eZnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LHFNKjZpEnejHAB2DQwIj7qHn5MBEVFgFcMsQG1XvpY=; b=cc2zaZi1Ccn6sWa/Kfjv1Kp4E1Dh/AjT5c7b6IOdnozni06kAbUvYmfYdHfqccjdYy QvPaoNohtfrajkTBvVVlFQpCWEGHFr8KNKlg658uNutIJKIrX4sC7i7Ab7hE+9Skl6Hv WvTKaH4+dG44wXbd/vaZleUyASGSrIvoD1Jr24Yt48/NMtB5RQNELvvjHJmet3thDZa7 3aVreldi+XwcCpS4QHVrI2Lc/+xn4h8Urm1Kl+QMDkviDzfi/qsjW5uiaPHWUCk5tHvz BddubkkCZKrmwCD8QhLXdGhmgUA5ZEpUb+31Z6r5spMRSM7owOLMeIFP0BEkVguOwWC7 czIw== X-Gm-Message-State: ALyK8tK0F1knzoOBvcKch9qHXtgeWm4f/pbUma/OUbh20U8TAGIPZyD2e4Gp38GNjnqCdg== X-Received: by 10.194.221.37 with SMTP id qb5mr11054748wjc.171.1464299086096; Thu, 26 May 2016 14:44:46 -0700 (PDT) Received: from [192.168.1.181] (77.116.171.9.wireless.dyn.drei.com. [77.116.171.9]) by smtp.googlemail.com with ESMTPSA id d86sm5417254wmh.4.2016.05.26.14.44.44 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 14:44:45 -0700 (PDT) From: Christian Zangl To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <5744E92B.3010704@tzi.org> <57455F43.6010506@tzi.org> <2eec2464-3315-9cd6-f850-ab83d98a94a8@gmail.com> <5746201F.7080707@tzi.org> Message-ID: Date: Thu, 26 May 2016 23:44:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5746201F.7080707@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:44:49 -0000 On 2016-05-25 23:58, Carsten Bormann wrote: > Christian Zangl wrote: >> When you look at YAML it's not easy to guess what it does > > Not so sure about that -- kramdown-rfc is using YAML as its structured > part and people seem to be picking it up from the examples nicely. (I > probably still have to improve those examples some more.) > >> and yaml.org >> only makes it worse. > > Now, there we have strong agreement. > > (But that would be true for any format that tries to offer its spec as > its only documentation, or worse, its documentation as its spec :-) > > This could be fixed without even changing the format at all. > > Curious question: What part of HJSON is actually a subset of YAML? There is no relation to YAML (other than being a superset of JSON), at least not on purpose. > What did you do that YAML doesn't have? I think it's the other way around. Hjson is less complex and easier to understand. Also YAML is based on whitespace for structure while Hjson uses braces. (there are apparently two camps on what is better) From nobody Thu May 26 14:45:05 2016 Return-Path: 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 145AA12D1CD for ; Thu, 26 May 2016 14:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5EBtCIfjRg4o for ; Thu, 26 May 2016 14:45:01 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 0C6BC12D0C2 for ; Thu, 26 May 2016 14:44:59 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n129so115365241wmn.1 for ; Thu, 26 May 2016 14:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RiPQCuoqxLOGoonM1/A0703pnJ3w4aaUyY0ajJszGW0=; b=XbA1L0VFvgwUk+q/7PHm7heDv9pL4KiVp4eTohubYqxolQqcX4pldjB5MorWsDMVKT nZYIGhfJ2vtXneH4lqxfoM51o9wYBNxmQnZhR5Go0f63EYRAExU5ZlG4VsHX91CTnHVn bvDwj8RGinHkS9xHDWsr+it3ITrq9/gw96H1G2j1cVzk/H+71VvAcoTXZh2K29sT59ZK spX0zpLZBbvEFPfqr1/F0VHIpM6oITrBBTxXInvm7RieNI+46OPTB0GkAbnQQxveuL5p EU3UsiXHPkjsf/2frhRS/WYHAjG4Q5Z44bSfgbQY0FInnUvawTIKonuMJIDtTzjkGaA4 /Qug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RiPQCuoqxLOGoonM1/A0703pnJ3w4aaUyY0ajJszGW0=; b=beZgQMKa28cCm2mHxQ6vwHDQ6jolBLH/epLiZp/P7nAwTbF1vHxg/gCLXzzH0lIGXg 5u175pDvcnD4k5ud2ad3tG+DzT9h5aMsz/K5JFnXTt6cx3U1r8vQYOPm32Su55UCibCB 7crFHYmPbzUAWA5dZRrmVcbhQE5tg7yoor+k2vRTQ0ODzcm5xBUjLc2EFCPvxXNAw9Sx bOCZjk/kGsQxvsz9XjeD2MYhRHwtEdFUPzY78taxOFT02xaZnQQOUNLzajkoDgEiaWXG vjx+7boCHTGXKiCptib18Ok61mrf4gT5Z5dHNdoFzELA38Kk8FaoD7MJIUCH2VasTmQF JJAg== X-Gm-Message-State: ALyK8tKTJwASwsp+KTINYWsL+1pkTI24YTbB7vzMPBgG6KRLWdE+WLjUyLdXJQis8c6oIA== X-Received: by 10.28.170.197 with SMTP id t188mr5883354wme.84.1464299097635; Thu, 26 May 2016 14:44:57 -0700 (PDT) Received: from [192.168.1.181] (77.116.171.9.wireless.dyn.drei.com. [77.116.171.9]) by smtp.googlemail.com with ESMTPSA id on2sm16220245wjc.32.2016.05.26.14.44.56 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 14:44:57 -0700 (PDT) From: Christian Zangl To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <07aea2e2-a675-797b-eab6-7cd7ccc5d2d1@seantek.com> <21160816-48c7-169e-5a83-19b7601420a0@gmail.com> <45878809-7718-fc38-a8ec-d8c5654c66cd@gmail.com> Message-ID: Date: Thu, 26 May 2016 23:44:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <45878809-7718-fc38-a8ec-d8c5654c66cd@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Comments in JSON = De facto standard. Re: Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:45:04 -0000 On 2016-05-26 06:53, Anders Rundgren wrote: > Adding comments to JSON would IMO solve the "human" part. > It is already used in Chrome config files since ages back. > > Anders > Most mistakes are made by either missing a comma or adding a trailing one. From nobody Thu May 26 14:45:26 2016 Return-Path: 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 B2A9612D1DF for ; Thu, 26 May 2016 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, 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 R2o0uI7Z9Vns for ; Thu, 26 May 2016 14:45:24 -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 6A8B912D9C3 for ; Thu, 26 May 2016 14:45:24 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1b635n-00051x-21; Thu, 26 May 2016 17:45:23 -0400 Date: Thu, 26 May 2016 17:45:22 -0400 From: John Cowan To: Peter Cordell Message-ID: <20160526214522.GE19074@mercury.ccil.org> References: <20160526173719.GA19074@mercury.ccil.org> <064f4df2-75d5-6952-cd18-e22e7510b3a6@codalogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <064f4df2-75d5-6952-cd18-e22e7510b3a6@codalogic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:45:26 -0000 Peter Cordell scripsit: > I think sort of thing in JCR by having a directive such as > #infer-types, e.g. Pretty good. > I think that would be useful as 'by-example' is perhaps an easy way > to start creating a schema, but I feel you'd want to go beyond what > it can offer within a matter of hours. Remember that I'm aiming only at static typing, not general validation. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Promises become binding when there is a meeting of the minds and consideration is exchanged. So it was at King's Bench in common law England; so it was under the common law in the American colonies; so it was through more than two centuries of jurisprudence in this country; and so it is today. --Specht v. Netscape From nobody Thu May 26 14:52:40 2016 Return-Path: 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 8C4B712D1A1 for ; Thu, 26 May 2016 14:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i-cErb08RVq2 for ; Thu, 26 May 2016 14:52:36 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 05CEF12D1B4 for ; Thu, 26 May 2016 14:52:35 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n129so115533684wmn.1 for ; Thu, 26 May 2016 14:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=VIq6gMT64ws7gxX91hHjEod90IJq+rHe3HUkTaIh1r4=; b=fgBeusB51NBiqGLsDGC9uG4JZLuJoMNBZYdWrTMF0zjJ0cByYBYL+Ck1Shtf1j4VAO 89k3eszp4YlY3UFUqSKM8WvuqY6qft0leyJxwPdMq/e1qm2qk9vNxMlNTH4id9ajr4CY WyU/Rix+byVedIPCynBOd6NfA2m6ocVexEoiAYM/43kge30RGozODixVAsyb7jYD4+2Y S6C4Z56CPcwVvw8mxPAFMK3tdg1BwCH9LqN2nVwkzRDJ/kdyc3W5YOmNa9HDcw6MX/m9 VhUcK6L0eK1Qy24TsDSiHSaPW1l6odAN/NpAoY+XLB3FGXHND2TF8zGJqjw0RZtWZELY jFjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VIq6gMT64ws7gxX91hHjEod90IJq+rHe3HUkTaIh1r4=; b=RyNZPhALoAMWJldhSH+sNee8yAEBsTxQupFDVcJmOWFE3iXXuxVx5/Ze8vhT4oe5/J GV8xJgWAT1eyu/FNZJjPvbktd0+nTunbTN0JitlGj3C7CPtuuC6GGUxDibcN5mDORISj C+EXaxyGTKps9or1WX6NIz4PJ0leWlIZ5jRvmy+IDA03a2RIE8ruMEhsLYetiAKOE354 mPrzMIs8IsN+1iNau04+N0ZKOQqozchKAMDFmjuVSRqtDa7RDOGb0I8p8h+ORP2ZWE2J tEDuxycRL2/L/qWwysDPzXkGUT5oJrC6SAdFIW7m/3FetFXw23LkstL07kYk1KWcKx4l n+ig== X-Gm-Message-State: ALyK8tJ7EUyNLu1AeYIDSeR5DkckcOMROoFspX9ZfAofYdOQo7zhz16ts0tC8C6yLzeH+A== X-Received: by 10.28.213.137 with SMTP id m131mr5956031wmg.24.1464299554366; Thu, 26 May 2016 14:52:34 -0700 (PDT) Received: from [192.168.1.181] (77.116.171.9.wireless.dyn.drei.com. [77.116.171.9]) by smtp.googlemail.com with ESMTPSA id lr9sm16202484wjb.39.2016.05.26.14.52.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 14:52:33 -0700 (PDT) To: Peter Cordell , json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> From: Christian Zangl Message-ID: Date: Thu, 26 May 2016 23:52:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:52:39 -0000 You are quite right that there are a lot of solutions to this problem. The most known ones are JSON5 and maybe CSON. Others are not that easy to find though I remember at least three variants that shared some syntax with Hjson. Most of them, including Hjson, were started because there was no recommended format to be found. On 2016-05-26 13:03, Peter Cordell wrote: > For me JSON is too simple, and YAML is too complex. I've tried to get > into YAML a couple of times, but it seems to have multiple ways to do > the same things, so I end up getting confused. It clearly fails at at > least one level to be human friendly. Why JSON doesn't have comments > eludes me. JavaScript does, so missing that bit in the subsetting was a > big drop off IMO. > > I'd love something that is more flexible than JSON, but less complicated > than YAML. While I might quibble about some of the choices in this > proposal, the fact that it can be described as JSON with 7 lines of > variations is a big win. > > What I find frustrating in this space is that protocols and > specifications are the bread and butter of IETF. And yet the IETF has > put very little effort into developing 'tools' for this area (*). And > the really sad thing is that the reason is not because this is a > difficult problem, but more that it is such a simple problem that > everyone comes up with their own pet solution and they'd rather have no > solution instead of someone else's solution. As a result we end up with > other groups second hand goods like XML and JSON. > > So I'd welcome it going forward in a form that would allow experience > with working with the format and would be simple for a working group to > adopt and put on standards track if they felt it was useful. Perhaps as > an AD shepherded individual RFC that can just be 're-badged' to put it > on standards track if the desire arose. > > (* OK, we have ABNF, but that's the assembly language of protocol design > and we should really be aspiring to higher levels of abstraction in this > day and age.) > > Pete Cordell > Read & write XML in C++, http://www.xml2cpp.com > > On 24/05/2016 22:36, Christian Zangl wrote: >> JSON is used in a lot of places and has helped improve things like data >> exchange and data storage. It is also used in areas it's less suited >> for, like configuration files. People seem to prefer JSON for >> configuration over YAML and other config formats. >> >> I started Human JSON (Hjson) because I found the experience frustrating >> (for example missing/trailing comma problems, no comments). With Hjson >> you get a superset of JSON that allows you to >> >> - add #, // or /**/ comments, >> - omit quotes for keys, >> - omit quotes for strings (terminated by LF, no escapes), >> - omit braces for the root object, >> - omit the comma at the end of a line >> - add trailing commas and >> - use multiline strings with proper whitespace handling. >> >> These changes should make it easer to read and write configs while still >> preserving the power of JSON. >> >> Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You >> can find the draft here: http://hjson.org/rfc.html There are also syntax >> diagrams and more at http://hjson.org/syntax.html >> >> Thoughts? >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> . >> > From nobody Thu May 26 14:57:55 2016 Return-Path: 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 D441E12D526 for ; Thu, 26 May 2016 14:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9l_Bp-Cxw21o for ; Thu, 26 May 2016 14:57:52 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 6207D12D13D for ; Thu, 26 May 2016 14:57:52 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id x7so67535894qkd.3 for ; Thu, 26 May 2016 14:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+2W6wC/6NHUFKjfM0+J2NQXLwteLO88UGfk/r+S7gso=; b=osZIJXSND/eXbH43mNGO5+2Mrp1lMp1yd6P9tK6++HtK31R27qCJjAcrnwcWlxZptw /elfir3GOP9vk/dYczDhZGsraBTuk2V0IIa9iE8GitLzgE5CeENOmY1qiWma4GBQ7xOl +iHus3d4L90i7ZjWTSqmj5UuvEZNqRZT98L1KTTwlMIlu9N2nAWlYC+Oz7nKRHUY795Q eHy+TFbPYKWUCQOL3GTrBFN9o0G4zugyFz9EPmBQzxC8onvvXEsNJ1Jd2jkJkI+C3Fdq dnKxIYtozoMbVTLqLjsVdFw2McGkUpkrlpoBni5v639KJODLSckoyBVGF6x3nkP8nr8M caNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+2W6wC/6NHUFKjfM0+J2NQXLwteLO88UGfk/r+S7gso=; b=NKjEMiizt/vWSxliE1jBsaudS8o5oZ3SSEWrgvNHlTjQPobjeJS3DSQpAbo4ReKOCy J11HUgsdJECY6K3FNNx6AeI+K74fWeggCLHCkc81Kw9bE4Bo4b3oe+aNVpUG4uLTuLBG TrI4qFctZSWINjhqOyxDVOk0hkKCfXgxAlcaHAHe3urS7Irs8V7ZbDmDEa/3XHqtY5gb Yg107BMNe9S9zTqIGAdUxiocibTJdYq7jkx5+xfv9eP3BBzKXmP1nrjRHaStcz9aRH0j MDuhX0M850SA3N4OurhMORZ6eVwBIR3NIwJ4/eqTMJy46B2xVpRoz/4ppCD79SmL5RIC tGgQ== X-Gm-Message-State: ALyK8tJGTU61BedwTVapNBvaiDG0Am9WoEzhLsxzdUHg6249yIL3zfxxNbf/69DSwaXrr/oYr5rDLleu7QlRoQ== MIME-Version: 1.0 X-Received: by 10.55.114.71 with SMTP id n68mr11308216qkc.37.1464299871443; Thu, 26 May 2016 14:57:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Thu, 26 May 2016 14:57:51 -0700 (PDT) In-Reply-To: <20160526205033.GD19074@mercury.ccil.org> References: <20160526173719.GA19074@mercury.ccil.org> <20160526205033.GD19074@mercury.ccil.org> Date: Thu, 26 May 2016 17:57:51 -0400 X-Google-Sender-Auth: uHyIUrQZ_sVLUGQxx61dxLjmSv8 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a114fef8aaea6e00533c5e139 Archived-At: Cc: Tim Bray , "json@ietf.org" , Austin William Wright , Andrew Newton Subject: Re: [Json] JSON by example X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:57:55 -0000 --001a114fef8aaea6e00533c5e139 Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 4:50 PM, John Cowan wrote: > Phillip Hallam-Baker scripsit: > > > 'Wirthless' > > "You may call me by value, and call me 'Worth', or you may call me by > name, and call me 'Veert'." --Wirth on how to say his name. > The nickname I used was given him by someone just as well known in that crowd :) > > Yes, real numbers and integers are probably things you want to be able > > to treat differently in code because it is very very rare to need or > > want a real64 number in a protocol. > > Okay, an integer encodes the type "JSON number which is an integer", > and a non-integer encodes the type "JSON number". Note that this might > be represented as a Java BigDecimal or equivalent. > Yes, there are cases where distinguishing representations is useful. This does not include big nums for crypto in my view, I would prefer those to be in hex or base64. I do think it useful to distinguish integers and reals at the schema level as the treatment is very different. In fact I do that but I have never ever used that code. If you were doing scientific stuff, being able to represent numbers as fractions and such like Wolfram does would be very desirable. > > But I think that you absolutely want to be able to put binary blobs of > > data in a stream and distinguish them from strings. > > Good idea. If the string is "deadbeef", it encodes the type of binary > blobs represented in JSON as a string. :-) > Yes, there are a small number of intrinsic types that we use in protocols. It is slightly larger than JSON gives us but not very much larger. Specifically: * Boolean, Integer, String * Binary (Base64 (data) in string) * DateTime (IETF time format in string) * URI (in string) * Label (String) * Reference (string) * Token (basically a reference but does not require the label to be defined) I have parser generator tools for pretty much every IETF format (ASN.1, TLS Schema, XML, DNS, JSON, RFC822). Those are the only ones I have ever found a need for. (counting OIDs as a subset of URI). > > That is an interesting one because it comes down to how do you want > > extensibility to work. In particular, when do you want adding things > > to be backwards compatible and when do you want to cause things to > > halt rather than have an application try to act on data it did not > > fully understand? > > I think you want to be able to choose, but I'm not sure how to represent > it within the JSON-by-example format. The obvious way is to reserve a > key like "...", but I haven't wanted to do that. > The way that I am doing it now is that I support both as follows: * Fields can be added to any data structure. These are simply ignored if the parser does not understand them. * If the field label changes, the semantics are different and so the decoder should abort. My encodings always give the type of an object as a field name. So if I have a message Hello, the C#, JSON encoding are: class Hello { string Param1, Param2; } { "Hello" : { "Param1" : "Value1", "Param2" : "Value2" } } If you change the protocol so that you can say who you are saying hello to, this is backwards compatible : { "Hello" : { "Param1" : "Value1", "Param2" : "Value2", "To" : "Bob" } } But if we want to add in a completely different message that replaces Hello, we use a different tag: { "Hello2" : { "Param1" : "Value1", "Param2" : "Value2" } } This approach makes it very easy to ensure that an interpreter that does not understand Hello2 does not attempt to do the right thing and get it wrong. This works very well and doesn't give the problems that people are getting wrapped around their axle when they try to use type fields: { "Param1" : "Value1", "Param2" : "Value2", "Type" : "Hello" } } Why should anyone expect "Type" to be more important than the other fields? It really doesn't make any sense. It also comes in last which means that if we have a long message and the type field comes last we have to read the whole thing before we try to make any sense of it. *Object type should always be specified in a key, never a value.* > This is actually a little problematic as in JSON any slot can hold > > null while many languages don't allow integers or booleans to be null. > > True. We can say then that null is always permitted wherever the schema > allows an array or object. > That isn't necessarily what you want though. If you are using a schema, there are actually four possibilities for a boolean slot 'fred': true { "fred" : true } false { "fred" : false } null { "fred" : null } empty { } Now you could in theory write a protocol which distinguished between the four values but I don't think that is very useful at all. I don't think it is practical to rely on a difference between empty and null. You could also argue that omitting a value is equivalent to false. But that is a case where I think you actually should be required to declare it. --001a114fef8aaea6e00533c5e139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2016 at 4:50 PM, John Cowan <cowan@mercury.ccil.o= rg> wrote:
Phillip Hallam-Baker scripsit:=

> 'Wirthless'

"You may call me by value, and call me 'Worth', or you may cal= l me by
name, and call me 'Veert'."=C2=A0 --Wirth on how to say his na= me.

The nickname I used was given him b= y someone just as well known in that crowd :)

=C2= =A0
> Yes, real numbers and integers are probably things you want to be able=
> to treat differently in code because it is very very rare to need or > want a real64 number in a protocol.

Okay, an integer encodes the type "JSON number which is an integer&quo= t;,
and a non-integer encodes the type "JSON number".=C2=A0 Note that= this might
be represented as a Java BigDecimal or equivalent.
Yes, there are cases where distinguishing representations is us= eful. This does not include big nums for crypto in my view, I would prefer = those to be in hex or base64.

I do think it useful= to distinguish integers and reals at the schema level as the treatment is = very different. In fact I do that but I have never ever used that code. If = you were doing scientific stuff, being able to represent numbers as fractio= ns and such like Wolfram does would be very desirable.

=
=C2=A0
> But I think that you absolutely want to be able to put binary blobs of=
> data in a stream and distinguish them from strings.

Good idea.=C2=A0 If the string is "deadbeef", it encodes the type= of binary
blobs represented in JSON as a string. :-)

<= div>Yes, there are a small number of intrinsic types that we use in protoco= ls. It is slightly larger than JSON gives us but not very much larger. Spec= ifically:

* Boolean, Integer, String
* B= inary =C2=A0(Base64 (data) in string)
* DateTime (IETF time forma= t in string)
* URI (in string)
* Label (String)
* Reference (string)
* Token (basically a reference but does n= ot require the label to be defined)

I have parser = generator tools for pretty much every IETF format (ASN.1, TLS Schema, XML, = DNS, JSON, RFC822). Those are the only ones I have ever found a need for. (= counting OIDs as a subset of URI).

=C2=A0
> That is an interesting one because it comes down to how do you want > extensibility to work. In particular, when do you want adding things > to be backwards compatible and when do you want to cause things to
> halt rather than have an application try to act on data it did not
> fully understand?

I think you want to be able to choose, but I'm not sure how to represen= t
it within the JSON-by-example format.=C2=A0 The obvious way is to reserve a=
key like "...", but I haven't wanted to do that.

The way that I am doing it now is that I support bo= th as follows:

* Fields can be added to any data s= tructure. These are simply ignored if the parser does not understand them.<= /div>

* If the field label changes, the semantics are di= fferent and so the decoder should abort.


My encodings always give the type of an object as a field name. So if= I have a message Hello, the C#, JSON encoding are:

class Hello {
=C2=A0 =C2=A0 string Param1, Param2; }
=
{ "Hello" : { "Param1" : "Value1&qu= ot;, "Param2" : "Value2" } }

I= f you change the protocol so that you can say who you are saying hello to, = this is backwards compatible :

{ "Hello"= : { "Param1" : "Value1", "Param2" : "Va= lue2", "To" : "Bob" } }

But if we want to add in a completely different message that replaces He= llo, we use a different tag:

{ "Hello2" = : { "Param1" : "Value1", "Param2" : "Val= ue2" } }

This approach makes it very easy= to ensure that an interpreter that does not understand Hello2 does not att= empt to do the right thing and get it wrong.


<= /div>
This works very well and doesn't give the problems that peopl= e are getting wrapped around their axle when they try to use type fields:

{ "Param1" : "Value1", "Pa= ram2" : "Value2", "Type" : "Hello" } }

Why should anyone expect "Type" to be= more important than the other fields? It really doesn't make any sense= . It also comes in last which means that if we have a long message and the = type field comes last we have to read the whole thing before we try to make= any sense of it.

Object type should always = be specified in a key, never a value.


=

> This is actually a little problematic as in JSON any slot can hold
> null while many languages don't allow integers or booleans to be n= ull.

True.=C2=A0 We can say then that null is always permitted wherever the sche= ma
allows an array or object.

That isn'= ;t necessarily what you want though. If you are using a schema, there are a= ctually four possibilities for a boolean slot 'fred':
true =C2=A0{ "fred" : true }
false =C2=A0{ = "fred" : false }
null =C2=A0{ "fred" : null }=
empty =C2=A0{ =C2=A0}

Now you could in = theory write a protocol which distinguished between the four values but I d= on't think that is very useful at all. I don't think it is practica= l to rely on a difference between empty and null.=C2=A0

You could also argue that omitting a value is equivalent to false. Bu= t that is a case where I think you actually should be required to declare i= t.=C2=A0
--001a114fef8aaea6e00533c5e139-- From nobody Thu May 26 15:24:32 2016 Return-Path: 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 7349D12B025 for ; Thu, 26 May 2016 15:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hUZ83rF_sUIV for ; Thu, 26 May 2016 15:24:29 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 470B812DB72 for ; Thu, 26 May 2016 15:04:57 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id n129so8869046wmn.1 for ; Thu, 26 May 2016 15:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=0M0HAsX03YxcrxTsrko08KYcuuuUCbY5dUKGYfOJ1JY=; b=rp+U1qbC/U6RWZDmn41VkTIpbkZiFE1/SgAx4eaX0UnxSqF+lonm/SwhgyF2t4GcyF HJ2bItc/qT92ewfQZXf1AxuOpx9vaFJ/p6KKlYY2q92DsY1r4o8ZXAYJOiLTfs9YJA2y aZOLC9Wb2rh65on4/+FeRXzyfsKJ/NgecbHkdX7V7HVyBANCatI1E6w/DsB4+kCUAXB6 XLCOef5Te8cV8edRirhJgEUqsbT7Y62xXD2piomo1TeWan23tbCcZu9rxHveU0T5c4T9 8JpCfS8/92yTcyGcjbIOpGeQbbtK+ag63UgbrltQ1P0bXd6ZAwLZBQfIwtv+pH+I/Zef Jv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=0M0HAsX03YxcrxTsrko08KYcuuuUCbY5dUKGYfOJ1JY=; b=h+3wJEavgWwc+pSIujgeDt99SBjkqNq9H8+iq4+R06C22R/hoKcK2CbaSYkPL0uScs Af+HbrWz+ShZRqJNhF7k+EG3/Lz7pfyugOZIR3n/NwwHuvlcsb9Io8tFrD/QdXmQ4rFY uLpvSv6aioCuBzq1obkYzzUE8xnUJCNghIdESPgPh7rfldaOBd0jYqfIZBT/qWzpefNS mdP386MDZeg1k1P3LcWzl5i7b/nrdp2KTjvNqc/DHHR5v+/2fowtxPVmPUUxKZuCXIkA ojMNEjIfhujmj6HCuVUUV7srog35hJjXdIAjUOW4uak3mnz4uQa7nz9UhO5bYjKz8E3b WRCw== X-Gm-Message-State: ALyK8tJuJonxKi32XrA01ocH13vNce8Pjf2Gq2zUrmA0MqmwLK7cQJcHoefCOhjlJEAaig== X-Received: by 10.28.221.136 with SMTP id u130mr5522829wmg.44.1464300295873; Thu, 26 May 2016 15:04:55 -0700 (PDT) Received: from [192.168.1.181] (77.116.171.9.wireless.dyn.drei.com. [77.116.171.9]) by smtp.googlemail.com with ESMTPSA id a63sm5435985wmh.11.2016.05.26.15.04.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 15:04:55 -0700 (PDT) To: Phillip Hallam-Baker From: Christian Zangl Message-ID: Date: Fri, 27 May 2016 00:04:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:24:30 -0000 Phillip Hallam-Baker Thu, 26 May 2016 15:36 UTC wrote: > What I do very much like about YAML is that it is indentation delimited > like Python, occam and most of my languages I have developed using Goedel. > However making that work with JSON which is brace delimited may be hard. I've seen a lot of config files being edited by different people with different editors through their life. Depending on the "level of care" those files usually ended up having different indentations with mixed spaces and tabs. Developers can handle whitespace issues but we shouldn't place this burden on end users or administrators. From nobody Fri May 27 03:06:13 2016 Return-Path: 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 086DC12D0ED for ; Fri, 27 May 2016 03:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0h6cSHqWjkIr for ; Fri, 27 May 2016 03:06:10 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 BB5C712D609 for ; Fri, 27 May 2016 03:06:09 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a136so65065114wme.0 for ; Fri, 27 May 2016 03:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=GP5/FwcVN/uEg38YKMRZXli+8wRMr1ar1bLodPDWVg0=; b=pIorsRrMycfhxX5yDmmIHtTZqkGaF4QENk2MvPvFdd00oVnMaFWWlw+YiQrHrxPQ/O wxbp8UA5Bl5lPhBbe9FIISmKU/0S14LsNWRX18rhA9cy+qWEaQOuHYUp5jX7JavheM8J HKWKs6HR9hX/3VPBCM7jIInCQ5lNSCTlXrINLl26XmSCGzyGAfijeEge5jbboKV39oMK rCspIZYtHU4mbyDDWLKQfXfYTr/v9pdTakBJ9eAIOqrx0ZP6Ws4FX49smwEvXwg31Gzr +wzsreniMp++6XDBoDFesahzaXtVQ1R04Nem1opDJ79SEqGUlUipSO1OUvEFoJMMbiOn vyGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GP5/FwcVN/uEg38YKMRZXli+8wRMr1ar1bLodPDWVg0=; b=bY/r/af3hVeSaarVO/aQa5LOer0G+dS+vxEE4YClE1FWPUozFZYmo+ErbuW9LDIRIQ FB4t3zj6PyDLRg0o4O5aItLydum87UNk+k3wgNwx5Bry1qX0oAfV1RD7eWtV9IPH8AAu /l4qKYy63IiFjU7Xd55sWLe1rVFOMby3aLY3QeuBW7jyx5uyysowrMTAdwpXPRCpnZua 3bSltQuU3S+aqbaBl+JlQx/5eW5qPDBQ1rW5ChCSzY1FT5D88vouTyuqrsBndyNSp1Ps BsmrMYh9lXu0Pgg2JYeCtw6OG24OMF4G55G4oUqno36qKpa+6lUpD8VyuCZdAGB64cJL qHTQ== X-Gm-Message-State: ALyK8tLXWNvbvYnr2Pi77lQJ74aclyiw7QlzoK4lJHgEgf+xBkW57w+oa4I0riMaw3EY8A== X-Received: by 10.28.153.147 with SMTP id b141mr8285869wme.90.1464343568344; Fri, 27 May 2016 03:06:08 -0700 (PDT) Received: from [10.246.233.15] ([212.152.161.90]) by smtp.googlemail.com with ESMTPSA id o4sm18611511wjx.45.2016.05.27.03.06.07 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 03:06:07 -0700 (PDT) From: Christian Zangl To: json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> Message-ID: <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> Date: Fri, 27 May 2016 12:06:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 10:06:12 -0000 On 2016-05-27 00:07, Phillip Hallam-Baker wrote: > You still have a problem with the backslash in strings. On Windows > you can't just copy&paste a path because all \ need to be escaped. > Also config files sometimes contain regular expressions and having > to escape the \ makes them unreadable. > > That's why Hjson has quoteless strings that are raw strings ending > at LF. > > > I don't like quoteless strings with spaces. I think they are going to > cause serious problems. Please explain. > What I suggest instead is using the convention Windows itself uses, the > 'verbatim string literal'. > > var path = @"C:\Users\Phillip\OneDrive\Repositories\Dalek Plans" > > is equivalent to: > > var path = "C:\\Users\\Phillip\\OneDrive\\Repositories\\Dalek Plans" > > The big limitation on @ strings is that the only escape you are left > with is for quotes which are doubled up: > > "quoted" is written """quoted""" @"" does not help readability. Not having quotes is IMO more elegant, makes copy&pasting easier and requires no explanation. From nobody Fri May 27 03:15:49 2016 Return-Path: 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 2653312D630 for ; Fri, 27 May 2016 03:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2XsoEem64Wqa for ; Fri, 27 May 2016 03:15:46 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 4595D12B032 for ; Fri, 27 May 2016 03:15:45 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y126so76056235qke.1 for ; Fri, 27 May 2016 03:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFbGj9gcSaWB3lflOLVlu2FA2TRjvVE0m37aAYprbEg=; b=KCPS2qAjAW+RiiN2+/23PPdKnyPBv4TNkK/mZZlu7ldFKjzNVyHAGjBtpZNQmZqhdQ +6xs1WsNVhNbm7hOSKqsWjvQ9SZ2vab8E3+99xTkba2zkZtPLl7TqT8flqk0N32FgeSB qoPZYrHnnpc12PPSITSuIDJAniV7sWT9y/pMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UFbGj9gcSaWB3lflOLVlu2FA2TRjvVE0m37aAYprbEg=; b=IAdi/fe/Ri57Pn02KTnreM4yh+KABuYP6U9huHJGD0YUnK5qPxlVOcK+b3RlSahFcO nivJToJUKLCC+n4XFHa7l5DrAYFa0uVMy2a1O6yqoMK5R+b+BOiAZIVOMAqpuJY5VsPp FD3qBqD2NAezd6bblZolW4TGVCKsq1BFDDtj9cLMVdfycaLh9qfC11+1kdM0wJ8ZahQA JtT7XdqY3SIuiAeX9vhWwrK/uuCg689Nj5ztZMtFgEbpH4j2lKUN3Y50VPi+poZK7h83 AsaKYiZgYSvZ+OQrUsSt1EcEYOYdv45ASn4trr1C+ifpKVXx6o/i2uo+9zw+tQ2SIJQk Rumw== X-Gm-Message-State: ALyK8tKFOplp4oNBaHeTC5veKAHOnqyPtJ8YDovD89eyGxiof72DsiI2AYKd/F01JEtZVkjjhktGkU7/zzvANw== X-Received: by 10.55.90.130 with SMTP id o124mr13263094qkb.178.1464344144294; Fri, 27 May 2016 03:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.85 with HTTP; Fri, 27 May 2016 03:15:29 -0700 (PDT) In-Reply-To: References: <5745EE5E.5050801@tzi.org> From: Austin William Wright Date: Fri, 27 May 2016 03:15:29 -0700 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=001a114e72028ccaec0533d030bd Archived-At: Cc: Carsten Bormann , json@ietf.org, Andrew Newton Subject: Re: [Json] Another problematic JSON Schema use-case X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 10:15:48 -0000 --001a114e72028ccaec0533d030bd Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 8:56 AM, Tim Bray wrote: > So, to close the loop, here's how I worked around the problem. I > auto-processed my large schema with a Ruby script to generate a small > schema for each of the "Type":"Animal/Vegetable/Mineral" variations, then > if the large schema reports any errors, I run through the objects > validating each with the appropriate micro-schema. This way, I almost > always get a human-comprehensible error message. > > Not optimal, but better than writing a fully procedural validator by hand. > I now recall my earlier solution, which is similar enough to this: If two objects carry different data, they should be described by different schemas. Things of type "Plant" should validate against a Plant schema, which includes (with allOf) a reference to the generic schema. So instead of the schema I listed in my first post to the thread, you would use a schema like: { "id": "http://example.com/Plant", "allOf": [{"$ref":"http://example.com/Thing"}], "properties": { "Type": {"enum":["Plant]} }, "required": ["Thing", "Genus", "Species"] } This would also go over the wire with the profile="http://example.com/Plant" media type parameter. Notice how the allOf acts like the "subclasses" operator in a dynamic language (like PHP or maybe Ruby; as opposed to C++ which is static or maybe ECMAScript which is prototypical): A Plant is also a Thing, but a Thing doesn't necessarily have the data fields found in Plant. Please let us know if you've considered something like this, and how such a solution would work for you. Digging a little more advanced into JSON Schema, there's no reason an instance can't actually be describedby multiple schemas. A server could say "Accept: application/json;profile=Thing" and the client could send back "Content-Type: application/json;profile=Thing;profile=Plant". Or maybe just "Content-Type: application/json;profile=Plant" if the server understands the JSON Schema semantics. I'll have to do some digging and see if this would be legal... Thanks, Austin. --001a114e72028ccaec0533d030bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, May 26, 2016 at 8:56 AM, Tim Bray <tbray@textuality.com>= wrote:

So, to close the loop, he= re's how I worked around the problem. I auto-processed my large schema = with a Ruby script to generate a small schema for each of the "Type&qu= ot;:"Animal/Vegetable/Mineral" variations, then if the large sche= ma reports any errors, I run through the objects validating each with the a= ppropriate micro-schema.=C2=A0 This way, I almost always get a human-compre= hensible error message.

Not optimal, but better than writing a fully procedural vali= dator by hand.

I now recall my earlier solution, which= is similar enough to this: If two objects carry different data, they shoul= d be described by different schemas.

Things of typ= e "Plant" should validate against a Plant schema, which includes = (with allOf) a reference to the generic schema.

So= instead of the schema I listed in my first post to the thread, you would u= se a schema like:

{
=C2=A0 =C2=A0 "= id": "http://example.com/Pla= nt",
=C2=A0 =C2=A0 "allOf": [{"$ref"= :"http://example.com/Thing&qu= ot;}],
=C2=A0 =C2=A0 "properties": {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 "Type": {"enum":["Plant]}
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "required": [&quo= t;Thing", "Genus", "Species"]
}

This would also go over the wire with the profile=3D"= http://example.com/Plant" med= ia type parameter.

Notice how the allOf acts like = the "subclasses" operator in a dynamic language (like PHP or mayb= e Ruby; as opposed to C++ which is static or maybe ECMAScript which is prot= otypical): A Plant is also a Thing, but a Thing doesn't necessarily hav= e the data fields found in Plant.

Please let us kn= ow if you've considered something like this, and how such a solution wo= uld work for you.

Digging a little more advanced i= nto JSON Schema, there's no reason an instance can't actually be de= scribedby multiple schemas. A server could say "Accept: application/js= on;profile=3DThing" and the client could send back "Content-Type:= application/json;profile=3DThing;profile=3DPlant". Or maybe just &quo= t;Content-Type: application/json;profile=3DPlant" if the server unders= tands the JSON Schema semantics. I'll have to do some digging and see i= f this would be legal...

Thanks,
Austin.
--001a114e72028ccaec0533d030bd-- From nobody Fri May 27 03:32:31 2016 Return-Path: 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 371EC12D6E6 for ; Fri, 27 May 2016 03:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 7K2gWd4qFu7u for ; Fri, 27 May 2016 03:32:28 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D3212D79B for ; Fri, 27 May 2016 03:32:28 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 351DFA80C6; Fri, 27 May 2016 12:32:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id JfW4F1pcs8Ya; Fri, 27 May 2016 12:32:25 +0200 (CEST) X-Originating-IP: 134.102.48.248 Received: from eduroam-pool5-248.wlan.uni-bremen.de (eduroam-pool5-248.wlan.uni-bremen.de [134.102.48.248]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EBC2CA80E6; Fri, 27 May 2016 12:32:24 +0200 (CEST) Message-ID: <57482236.2030402@tzi.org> Date: Fri, 27 May 2016 12:32:22 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> In-Reply-To: <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 10:32:30 -0000 >> I don't like quoteless strings with spaces. I think they are going to >> cause serious problems. > > Please explain. They sure work very well in YAML. But the rules for what you can and cannot do there are sometimes perceived as complicated (why do you need quotes here? Oh, the colon.): title: "6LoWPAN: the Wireless Embedded Internet" But then YAML has additional, more powerful quoting mechanisms, such as: title: >- Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Grüße, Carsten From nobody Fri May 27 04:07:01 2016 Return-Path: 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 C76EA12D971 for ; Fri, 27 May 2016 04:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 QdYloagQKWj6 for ; Fri, 27 May 2016 04:06:57 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9016B12D9C2 for ; Fri, 27 May 2016 04:06:51 -0700 (PDT) Received: (qmail 8304 invoked from network); 27 May 2016 12:01:59 +0100 Received: from host86-135-56-118.range86-135.btcentralplus.com (HELO ?192.168.1.72?) (86.135.56.118) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 May 2016 12:01:59 +0100 To: Carsten Bormann , Christian Zangl References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> From: Peter Cordell Message-ID: <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> Date: Fri, 27 May 2016 12:06:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57482236.2030402@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 11:07:00 -0000 On 27/05/2016 11:32, Carsten Bormann wrote: >>> I don't like quoteless strings with spaces. I think they are going to >>> cause serious problems. >> >> Please explain. > > They sure work very well in YAML. > But the rules for what you can and cannot do there are sometimes > perceived as complicated (why do you need quotes here? Oh, the colon.): > > title: "6LoWPAN: the Wireless Embedded Internet" > And the '6' would prevent you using unquoted strings in HJSON. That seems a bit error prone and worries me. Something like the following might work: title :> 6LoWPAN: the Wireless Embedded Internet But then it's not that much harder just to quote the whole string. Hum! Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com From nobody Fri May 27 04:14:25 2016 Return-Path: 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 5DC8012D8C5 for ; Fri, 27 May 2016 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rRqdPw6K6BbY for ; Fri, 27 May 2016 04:14:23 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C39C12DB99 for ; Fri, 27 May 2016 04:14:22 -0700 (PDT) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 47F24C5AB5; Fri, 27 May 2016 13:14:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id pbMDgej1HWel; Fri, 27 May 2016 13:14:18 +0200 (CEST) X-Originating-IP: 134.102.48.248 Received: from eduroam-pool5-248.wlan.uni-bremen.de (eduroam-pool5-248.wlan.uni-bremen.de [134.102.48.248]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 1F985C5AAA; Fri, 27 May 2016 13:14:17 +0200 (CEST) Message-ID: <57482C07.7070403@tzi.org> Date: Fri, 27 May 2016 13:14:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Peter Cordell References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> In-Reply-To: <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Christian Zangl , json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 11:14:24 -0000 Peter Cordell wrote: > And the '6' would prevent you using unquoted strings in HJSON. Hmm, http://hjson.org/syntax.html says something different (but what it says clearly cannot be true). Grüße, Carsten From nobody Fri May 27 04:25:11 2016 Return-Path: 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 446E012D531 for ; Fri, 27 May 2016 04:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 pxWbauaEOHDH for ; Fri, 27 May 2016 04:25:08 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAE212D964 for ; Fri, 27 May 2016 04:25:07 -0700 (PDT) Received: (qmail 9334 invoked from network); 27 May 2016 12:20:15 +0100 Received: from host86-135-56-118.range86-135.btcentralplus.com (HELO ?192.168.1.72?) (86.135.56.118) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 May 2016 12:20:15 +0100 To: Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> <57482C07.7070403@tzi.org> From: Peter Cordell Message-ID: <75d0ca2c-b8a5-5b08-87b3-6e70ba4228df@codalogic.com> Date: Fri, 27 May 2016 12:25:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57482C07.7070403@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Christian Zangl , json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 11:25:09 -0000 On 27/05/2016 12:14, Carsten Bormann wrote: > Peter Cordell wrote: >> And the '6' would prevent you using unquoted strings in HJSON. > > http://hjson.org/syntax.html > > says something different (but what it says clearly cannot be true). I was going by section 8.2 of http://hjson.org/rfc.html Pete. From nobody Fri May 27 05:08:10 2016 Return-Path: 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 1E9A612D0BA for ; Fri, 27 May 2016 05:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gcRDmyvs-shP for ; Fri, 27 May 2016 05:08:05 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 6833112D0AE for ; Fri, 27 May 2016 05:08:05 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 90so49659131qgz.1 for ; Fri, 27 May 2016 05:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=0Jd2sn3XYf31bOj2GWxC+4Ksmw8gqsvFY3PcGySdTN4=; b=kgQ8qcvq4MMwAhX/Y/jtRfB4huIgpFd1yLsajXnDN+4j1ojr+ZyaVbWmjMmljjgOLd cPcNdZJo1Ec5b3bxN2aAthEpbvDblORcxIu4dPWtlChbkRmmBuUMHiVO2W538/dtXRXS NtCjXwlblPyJxh40fWuH68Ick934yl1+WdK9UBzrFyVsm1+8sza3AsZlYRc5JDXMfjYd JjQ5QQ1UD2OO0HDXQ6vGh9CeLxbHRNzqRMABoZ2as5cJjmCz4i44VnhJIgGcyT2Z3mTw um5IQ+7CeTrFWkZK8+6aLiwWJ0Kq04A+5n5dQr0FogpAwDpOkJ1nKLmP1r3JwgyyRTgT Cc+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0Jd2sn3XYf31bOj2GWxC+4Ksmw8gqsvFY3PcGySdTN4=; b=hqDw35e9SNu91U4Lg6mkH3gdqscy3yv5dy4pfnVf/+G4VtY4NrY6lH99z0fHxbVa79 IgIwqNWFL2lzA8Uko5GE36p+5Lyd4PjfwgRGxwlTGCRl7dAQL8wXw7zm3BQFrDcCdBzU jxAZOYduC7by9cx5W+4//RugICXHnt+PSVJGWguQxn7CMOLwqc7ZnFPk+57jk6hZexFK lUYvOw4hcBBcEoyKccW3C/fzY8qEK6HrfcWr26hYeIpSyOw/SVWmfpuNFZTqndXSOD2D A9T3/Kp0AT18cD6s/NRSdIrNstUopm9YNrKUHnROzVatqi1JABEmgf0Wbk40N/HMSoKP HNtg== X-Gm-Message-State: ALyK8tJeCDguG267srEMEOmgLZH0Y9UZNqbq+YbGNmVglqwVpW0sNIDEf9UezCGIW7I7HKyiaczhM90w/10Uew== MIME-Version: 1.0 X-Received: by 10.140.238.66 with SMTP id j63mr13161686qhc.48.1464350884456; Fri, 27 May 2016 05:08:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Fri, 27 May 2016 05:08:04 -0700 (PDT) In-Reply-To: <57482236.2030402@tzi.org> References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> Date: Fri, 27 May 2016 08:08:04 -0400 X-Google-Sender-Auth: kKkf3ndhXnQljnLnr5wJDn3bv70 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1135933c4b71170533d1c2f0 Archived-At: Cc: Christian Zangl , JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:08:07 -0000 --001a1135933c4b71170533d1c2f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2016 at 6:32 AM, Carsten Bormann wrote: > >> I don't like quoteless strings with spaces. I think they are going to > >> cause serious problems. > > > > Please explain. > > They sure work very well in YAML. > But the rules for what you can and cannot do there are sometimes > perceived as complicated (why do you need quotes here? Oh, the colon.): > > title: "6LoWPAN: the Wireless Embedded Internet" > > But then YAML has additional, more powerful quoting mechanisms, such as: > > title: >- > Information Technology -- ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical Encoding > Rules (CER) and Distinguished Encoding Rules (DER) > > Gr=C3=BC=C3=9Fe, Carsten Where does whitespace get added to the final string and what whitespace is added? Does the string have two newlines or none? Are these strings different or identical? This is a test string. This is a test string. This is a test string. I am not even sure that the example will survive email. It certainly won't survive auto formatting on a lot of editors that prune away trailing spaces= . Verbatim strings have a long history going back to Pascal. The @ escape isn't pretty but it is a well established mechanism familiar to millions of coders. The user base of YAML really isn't in the same league as C#. --001a1135933c4b71170533d1c2f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 27, 2016 at 6:32 AM, Carsten Bormann <= cabo@tzi.org> wrote:
>> I don't like qu= oteless strings with spaces. I think they are going to
>> cause serious problems.
>
> Please explain.

They sure work very well in YAML.
But the rules for what you can and cannot do there are sometimes
perceived as complicated (why do you need quotes here? Oh, the colon.):

=C2=A0 =C2=A0 title: "6LoWPAN: the Wireless Embedded Internet"
But then YAML has additional, more powerful quoting mechanisms, such as:
=C2=A0 =C2=A0 title: >-
=C2=A0 =C2=A0 =C2=A0 Information Technology -- ASN.1 encoding rules:
=C2=A0 =C2=A0 =C2=A0 Specification of Basic Encoding Rules (BER), Canonical= Encoding
=C2=A0 =C2=A0 =C2=A0 Rules (CER) and Distinguished Encoding Rules (DER)

Gr=C3=BC=C3=9Fe, Carsten

Where does whitesp= ace get added to the final string and what whitespace is added? Does the st= ring have two newlines or none?=C2=A0

Are these st= rings different or identical?

=C2=A0 =C2=A0 =C2=A0= This is a test string.
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2= =A0 =C2=A0This is a=C2=A0
=C2=A0 =C2=A0 =C2=A0test string.
<= div>=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0This is a =C2=A0
=C2=A0 =C2=A0 =C2=A0test string.

I am n= ot even sure that the example will survive email. It certainly won't su= rvive auto formatting on a lot of editors that prune away trailing spaces.<= /div>

Verbatim strings have a long history going back to= Pascal. The @ escape isn't pretty but it is a well established mechani= sm familiar to millions of coders. The user base of YAML really isn't i= n the same league as C#.


--001a1135933c4b71170533d1c2f0-- From nobody Fri May 27 06:43:51 2016 Return-Path: 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 DC58412DAA7 for ; Fri, 27 May 2016 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Oz2Cb59jI1Kb for ; Fri, 27 May 2016 06:43:48 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 D5DCE12D10D for ; Fri, 27 May 2016 06:43:47 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id h185so46455492qke.2 for ; Fri, 27 May 2016 06:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=8ehx8GokUsrF9B/knla12a11jwoB7O/R2MrxfyUiqaw=; b=Dmrag9vIoY5rFFLkmQfE5Qzx0E/xrNxuwUUZAg4YfXBLuOmnXA9GDtaOJfFYj0NGy7 dFi+z132wIR+e6xPkModQOnoWIQ4lpjsSMjgNE1XkbYB13Kz94SOHl3TMlWK8xfZjKJC lYaJH/l7cWYpusiTqvADKZLOINDsfsz6NNHTvCLb5ISq1f3nlaBjZGWPuKPuOBLJ/KRe y5PkBEyce2rJrDjjYGyugDPFoR/dUf8/YN2csvk17CLogNa0vg6Ta1kvtedtskF4kEdg mY7/Pf2qlK2Ra3BSTsO4WS/86HNFMYb+wEzmpw1QGqKIHQgdVqRynCCkxCTvA/f64eUI WqIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=8ehx8GokUsrF9B/knla12a11jwoB7O/R2MrxfyUiqaw=; b=BFl8lhcBBUavfXkyungfkgszO1p60iFTb5smCDoMR5CLn1Zub+zacEt8m40JsCpwNH zC2xuIrybsLTo5EN0TBT1r5Dy0UHJafpuj/ljM8/gyrBlMvM2Sp9tCb8duqN9PcJ4c/E gaWsxjll4/DpdjXehb5ZpAqWenszP+OduXxCCtFRPZF3Ci+KHVLpPvqzGl8mKxa0LY7u H7qe5elbuyb5ANHWuTKNdoa6rdcGEa1LLO3LQ+QlmbyoXJ2NC7l42CSgr1OJb3y+nrOQ KXcPZyLI+6/b2HKin83Ojlv8cbBJJAm+OI+EnTrVgZhlT6FnxMNQTYuCh54cgBQdA9jP zKSQ== X-Gm-Message-State: ALyK8tJilECzfQLI+lIHXx7qhtF8gbHrfUGaz2JYuriv65ocLCOupuIw394KgE7s11wXBsMSw2ODxN+Z4sClQA== MIME-Version: 1.0 X-Received: by 10.55.165.11 with SMTP id o11mr14262181qke.196.1464356627017; Fri, 27 May 2016 06:43:47 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Fri, 27 May 2016 06:43:46 -0700 (PDT) Date: Fri, 27 May 2016 09:43:46 -0400 X-Google-Sender-Auth: Xw3WC7eVtJ7KroieInABZgc0IoM Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=001a114d8fdc93f7ff0533d3186f Archived-At: Subject: [Json] Wrapped objects X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 13:43:50 -0000 --001a114d8fdc93f7ff0533d3186f Content-Type: text/plain; charset=UTF-8 One of the ugliest features in Assinine.1 is Macros. The mechanism is horrible. But it does come in very handy when you want to do encryption or signature. Since I have written a JSON based PKI, I am very interested in having such features and keep the ability to do type checking. Consider the following CurrentProfile Class Master SignedObject Devices List SignedObject Applications List SignedObject Obviously the three slots require the lists to contain signed objects of specific types. But I can't express that right now. I would like to be able to integrate JOSE signing and encryption into the serializer/deserializer and have the code do the work of unwrapping and wrapping signed and encrypted blobs for me. And for that to happen I have to be able to express what type of data the blobs contain. The serializaion is going to look something like { "CurrentProfile" : { "Master" : { "Data" : "base64 deadbeef", ...} .... } } "base64 deadbeef" = { "ProfileMaster" : { .... } } My current plan is to introduce parameterized types into the schema for handling these wrapped objects. So my schema now becomes: CurrentProfile Class Master SignedObject Devices List > Applications List > I haven't yet decided on whether the <> syntax is desirable or not. Or for that matter how to map it to JSON-X. CurrentProfile Class Master SignedObject Of MasterProfile Devices List Of SignedObject Of DeviceProfile Applications List Of SignedObject Of ApplicationProfile --001a114d8fdc93f7ff0533d3186f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the ugliest features in Assinine.1 is Macros. The m= echanism is horrible. But it does come in very handy when you want to do en= cryption or signature.

Since I have written a JSON based= PKI, I am very interested in having such features and keep the ability to = do type checking. Consider the following

CurrentPr= ofile Class
=C2=A0 =C2=A0 Master SignedObject
=C2=A0 = =C2=A0 Devices List SignedObject
=C2=A0 =C2=A0 Applications List = SignedObject

Obviously the three slots require the= lists to contain signed objects of specific types. But I can't express= that right now.=C2=A0

I would like to be able to = integrate JOSE signing and encryption into the serializer/deserializer and = have the code do the work of unwrapping and wrapping signed and encrypted b= lobs for me. And for that to happen I have to be able to express what type = of data the blobs contain.

The serializaion is goi= ng to look something like

{ "CurrentProfile&q= uot; : {
=C2=A0 =C2=A0"Master" : {=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0"Data" : "base64 deadbeef", ...= }
=C2=A0 =C2=A0.... } }


&= quot;base64 deadbeef" =3D

{ "Profile= Master" : { =C2=A0.... } }


My = current plan is to introduce parameterized types into the schema for handli= ng these wrapped objects. So my schema now becomes:

CurrentProfile Class
=C2=A0 =C2=A0 Master SignedObject <= ;MasterProfile>
=C2=A0 =C2=A0 Devices List <SignedObject &l= t;DeviceProfile>>
=C2=A0 =C2=A0 Applications List <Signe= dObject <ApplicationProfile>>

I hav= en't yet decided on whether the <> syntax is desirable or not. Or= for that matter how to map it to JSON-X.=C2=A0

CurrentProfile Class
=C2=A0 =C2=A0 Master SignedObject=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Of MasterProfile
=C2=A0 =C2= =A0 Devices List=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Of SignedObjec= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Of DeviceProfile
=
=C2=A0 =C2=A0 Applications List=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Of SignedObject
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Of ApplicationProfile






--001a114d8fdc93f7ff0533d3186f-- From nobody Fri May 27 13:46:51 2016 Return-Path: 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 C318012D8EB for ; Fri, 27 May 2016 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SrRyzZraQZ6Z for ; Fri, 27 May 2016 13:46:48 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 37B6012D8DF for ; Fri, 27 May 2016 13:46:48 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so6004543wmn.1 for ; Fri, 27 May 2016 13:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=EQg/JSVjL+fbu+J84nB11AqBrJ59g9tPhTpzzt9Ro9M=; b=B1jiAiou//nshdJVo0yp8W3QQE2xOgq9yA+P3lKCoowG0oJOKsGLE85qOYboyF//fP yZKhh47JhL3T7up6WIkriNiU27FZEb96XFWqGyrTySB0bObaN9AK32jsurmBc79qvkSj NGSQuBdZFVG/VKSWY7Y2dhFw0Bami7sk2Blyiy/ecEfclSIAEYUWZqWeKnS8L3XkPIgT /WL36X9XKIMUQxEni37q27GHpnDVn98OsJun7f+4gOH7U+WYeeOpzWkexI2WhUz39D5P HzT6p01u0bDjEM6JxFOC/1ObWfMHGCrV0Ci9p97HhnY4Dp+Oqy8QU3Zn2MY+Z1RayYcQ FP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EQg/JSVjL+fbu+J84nB11AqBrJ59g9tPhTpzzt9Ro9M=; b=KOrNR8a6HWlz+Nsm19wOJQ8rY0O8oKQeolYzxSFdWJGeuHjgNQPi+2pHFO4Q2lJcPf p8g2AKvE2szuWvexXaBeL/7rvC8TkVCj7083gpj5qiGAfRK2ohPKLpATboDF19Ni/Vku ojAD821gEnv+yl9a7ykZ3+tAkf3lwhlzL50YEX6PVW/rEUkn1KZoaHaLj84VpIWB/Qze 8F9UwZRI7MULvi8qE7KqE14rBid3TKsAaRwbvWIZ801BlosSe6Ur2ljnb9+NfR7bHmDp 5TM/CvfxwkrrwLjX17kJ9rhw5gjc4mP0SgTKj9B2DInLeyn4JREe43Koup9F0TnBVGCJ xV0A== X-Gm-Message-State: ALyK8tIcJdEmfM/YTRDHUpKkF2vHVrgAGc5QJ/r+61/2YV2kvJK/mIoKymRumL1BO5gyog== X-Received: by 10.194.242.65 with SMTP id wo1mr16076778wjc.54.1464382006757; Fri, 27 May 2016 13:46:46 -0700 (PDT) Received: from [192.168.1.181] (178.112.50.109.wireless.dyn.drei.com. [178.112.50.109]) by smtp.googlemail.com with ESMTPSA id dd7sm21079997wjb.22.2016.05.27.13.46.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 13:46:46 -0700 (PDT) To: Carsten Bormann , json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> From: Christian Zangl Message-ID: Date: Fri, 27 May 2016 22:46:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57482236.2030402@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 20:46:50 -0000 On 2016-05-27 12:32, Carsten Bormann wrote: >>> I don't like quoteless strings with spaces. I think they are going to >>> cause serious problems. >> >> Please explain. > > They sure work very well in YAML. > But the rules for what you can and cannot do there are sometimes > perceived as complicated (why do you need quotes here? Oh, the colon.): > > title: "6LoWPAN: the Wireless Embedded Internet" If you look at the syntax it says "Because the punctuator characters {}[],: are used to define the structure of the Hjson text, you need to use quotes [..] if your string starts with a punctuator" so your example is valid without quotes, after the first character anything is allowed. title: 6LoWPAN: the Wireless Embedded Internet > But then YAML has additional, more powerful quoting mechanisms, such as: > > title: >- > Information Technology -- ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical Encoding > Rules (CER) and Distinguished Encoding Rules (DER) This is similar to Hjson's multiline except that Hjson will keep all LFs while YAML eats them sometimes. From nobody Fri May 27 13:52:59 2016 Return-Path: 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 63A4712D73D for ; Fri, 27 May 2016 13:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YmH_G4dlxaMz for ; Fri, 27 May 2016 13:52:57 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 C500812D1AD for ; Fri, 27 May 2016 13:52:56 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a136so7449724wme.0 for ; Fri, 27 May 2016 13:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ywqBJ3bgJHCWFdc2N4tcFUS17dAVYD+3Vqm/OyQe0L8=; b=FTr5BFoZXkg9CqqFIgEmyo9bxPysMIQVa2ooD1K4NlvVWg/iNjYkqZEgT1XWl4+kCv A6DrcJwlokYP8ZyxMPzUKbAPEHfUIBREqdXsOEM05ndkvEk6D2qQxOveDnyP7y8tNMj2 9LcmmoO3g6KmuGWKI+EDjz+0Q+79cDIPEuG92St58kLpOaVhQ0un2QsMbSzQ5P4O5g+g V2/KGyDM0LXQSRVmMgaLTAYoQjEA5skG8IchAaGxj2Zxas68YLqmWrMDm7Ta8VijMcbg 9TkLpFj4PAH4M1WDhPNCBJr7Fn0UHtCAW3adoA7VUUo6oJ3k3fMWzFe7Jnrj3yOklcwl TRPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ywqBJ3bgJHCWFdc2N4tcFUS17dAVYD+3Vqm/OyQe0L8=; b=kxzUA1DmFTFUo3zTimREWV/Fp/pe+65VLVuewf3vw6pTlYBt2O1FKNiCDIh23NKBM4 QdwKHDKyIuKl1qB0yGuPMkmHhZWGv1E6ytGrRu3jdgtUR4ie5vgT3FnwHWMb0jN9zVCt dTqg5W2AEuItfS6lM3ndL6sfc72DQqB/eQrUonAlI6RNJ+HOErWwQJ31ZR6p/faa/WAB EgP7WhZgkgX15CWlqA8ylz9UgtZdDYrZKq61jaSPxlOzYcSsAWSp8JdlLfAzlkYm9Cdq ixKDVKPH4le8DMqs7kAOPhK9nCCDCAT/NSkd/1itr/Rwm13aNcwACCbal4NKLI34LYKC viUw== X-Gm-Message-State: ALyK8tL3L53qMDW46+AY1ubudHl97ia0TtUkayY7tqLsx7D9poP7BKxyIKXazpDQNReY1A== X-Received: by 10.28.54.204 with SMTP id y73mr455928wmh.59.1464382375325; Fri, 27 May 2016 13:52:55 -0700 (PDT) Received: from [192.168.1.181] (178.112.50.109.wireless.dyn.drei.com. [178.112.50.109]) by smtp.googlemail.com with ESMTPSA id az2sm21110761wjc.6.2016.05.27.13.52.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 13:52:54 -0700 (PDT) To: Peter Cordell , Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> From: Christian Zangl Message-ID: Date: Fri, 27 May 2016 22:52:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: json@ietf.org Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 20:52:58 -0000 On 2016-05-27 13:06, Peter Cordell wrote: > On 27/05/2016 11:32, Carsten Bormann wrote: >>>> I don't like quoteless strings with spaces. I think they are going to >>>> cause serious problems. >>> >>> Please explain. >> >> They sure work very well in YAML. >> But the rules for what you can and cannot do there are sometimes >> perceived as complicated (why do you need quotes here? Oh, the colon.): >> >> title: "6LoWPAN: the Wireless Embedded Internet" >> > > And the '6' would prevent you using unquoted strings in HJSON. That > seems a bit error prone and worries me. That's not correct. The following is a valid unquoted string: title: 6LoWPAN: the Wireless Embedded Internet In fact you can just paste this line into http://hjson.org/try.html From nobody Fri May 27 13:59:56 2016 Return-Path: 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 3BBC612D1A4 for ; Fri, 27 May 2016 13:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C1jBLrbTDThT for ; Fri, 27 May 2016 13:59:53 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 73E0B12D190 for ; Fri, 27 May 2016 13:59:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id a136so7633595wme.0 for ; Fri, 27 May 2016 13:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=WmqBiiEsQAzIm1CIQogeKZ2beNp6FIN1sGFNy5qgdZs=; b=tG28N5+TB2pcROm9f80jjMHYkUyvLYdYL02cstqUhvG0DzSzWrPcuu/7jkDv1w5iMN WiR3PBjvjvw0Nilk3kRiMfBQInHQsanRzVL8oolKYxi9KJ2ju6cE3rshPpYp62yJofMI mV0ma7J5VMI0ugTWzU5C7TAbV8LRVjWiaKpXkherPnOFs5cgzMYbwHKYS7wqNjpLlZbh C5WjVz5FZIs+9Bs9i6REjQ8HGlxKP9PzaopQ8EhrzHg76VnXOH5fTx+FLQwb7N8jtVXZ xQS76PTq+6ZtvaJ3YuPjz+9a4FJRDROSc6OMTSf31LOgNq0Ld5Q5uVf0wPnoqE2cbQSQ kfhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WmqBiiEsQAzIm1CIQogeKZ2beNp6FIN1sGFNy5qgdZs=; b=kqxHdoHk2gkCT0bngJ7txpikg3rQVL6KM9vXDk+fnlzwFrS3zlpRTioWoeMpBmj9Eh Xokj2hcJBHOS2j2hGnYSNb6saLDG+0L5WVyTWOXYJGXZbG21OyfzNDgy4wXoeOGOC4ow lSUGRgXMqnDay+gFy+iBkNR86NCcc8fs++cWun6q/ikKxi9WcD9IUKeuvt9DCLDZG0hY vCQwrmikRMw3SrSjwAoCkfJqDTKMRhtexyFFysjX4RHnFH6xz2Vj4BKOzl4m3WlD4yv+ BEbOzpsWMzVnX1yD45AaGmyYZ4cl4aVfBo8h7HS4A2q+HrJuzMQQq5h5OPuEoljQSoWe O3hw== X-Gm-Message-State: ALyK8tIPeMiHkvWs9mboQphdO3DCSqbtmnY57Qnzzqp4XRqbqKow/49Thlo4g2pK/OuOcA== X-Received: by 10.28.125.86 with SMTP id y83mr534496wmc.8.1464382791801; Fri, 27 May 2016 13:59:51 -0700 (PDT) Received: from [192.168.1.181] (178.112.50.109.wireless.dyn.drei.com. [178.112.50.109]) by smtp.googlemail.com with ESMTPSA id g192sm8013847wme.15.2016.05.27.13.59.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 13:59:51 -0700 (PDT) From: Christian Zangl To: Carsten Bormann , json@ietf.org References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <3902e167-6a07-9311-4569-484f015f08be@gmail.com> <2a9060c3-7f2a-6675-2eba-9a14dc823138@gmail.com> <57482236.2030402@tzi.org> <620cd39b-1648-1b8f-57f4-c58678ff1ede@codalogic.com> <57482C07.7070403@tzi.org> <75d0ca2c-b8a5-5b08-87b3-6e70ba4228df@codalogic.com> Message-ID: Date: Fri, 27 May 2016 22:59:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <75d0ca2c-b8a5-5b08-87b3-6e70ba4228df@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 20:59:55 -0000 On 2016-05-27 13:25, Peter Cordell wrote: > On 27/05/2016 12:14, Carsten Bormann wrote: >> Peter Cordell wrote: >>> And the '6' would prevent you using unquoted strings in HJSON. >> >> http://hjson.org/syntax.html >> >> says something different (but what it says clearly cannot be true). > > I was going by section 8.2 of http://hjson.org/rfc.html Not sure how you came to that conclusion. My (S)ABNF is IMHO correct as it passes all test cases. 8.2 also has some examples: A Hjson parser must still detect values (number, true, false or null) and parse them correctly. For example ‘3’ is the number 3 ‘5 times’ is the string “5 times” ‘true’ is the boolean true ‘7 # minutes’ is the number 7 followed by a comment ’\s#([0-9a-fA-F]{3})’ is the string “\\s#([0-9a-fA-F]{3})” From nobody Fri May 27 14:05:19 2016 Return-Path: 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 1DC2712D101 for ; Fri, 27 May 2016 14:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ImkyaRGznUx3 for ; Fri, 27 May 2016 14:05:16 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 BD24512B069 for ; Fri, 27 May 2016 14:05:15 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n129so7715212wmn.1 for ; Fri, 27 May 2016 14:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Dx6z6cax3pYGWI5hKBH0cP0eiRxF3EeuJY25S3mrJpA=; b=tcN2nFU40Y8wIWLJQcnQJPwWCF/9Yqhb8g5c6M9hGtRf3YT5bNeWAqa6OeX789RF1q LiX7NtpQ9MGhEXvgcbQyRiFg3v0+YhnXlqRqkNDVlPXpPtxOqaQikhY85hQm7qT1e8Uh q9Zar2sLN052iwTZXRRiG8ZeJ/uW9L0Ffnv8DnIqALcNCyVbHwZ/5Ozavnl1t5nPCxbv dUFmsJ07spb9QT9QXPFIGohp73D/5R4XPilAMAZovmWxjllr4uiPTxojguimD8pdfXGt 6sZXexXryq3mvCuwk/JM7VNlyUUMvYMDEZtNQgd8qSnpEFEBpy21CdstuNy2Pt4zcj55 3VSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Dx6z6cax3pYGWI5hKBH0cP0eiRxF3EeuJY25S3mrJpA=; b=E8P8n5TfUHS86cmbTHcaG/LDG3yjbKxd8Zqm2f0PHxSGuSrDp6dd7LPQokysPBXgIG 3dyyMfnn72mLj0kJ9F3dZcvEcgL2CFFK23RvpYTt++/xfesO0ywCJr/5IdatdghAOZta EMNPBPSRoY8zDIXX0dX/cx9KZ6zo/p2deRxAUY2e0i6e61W9hpK3FhQKtcA84zcX90ze w/0O0OkfCqtXFS4VKv+u32h486rSLdornTMvs29P4xBo36XF3pXV2ZrYXyoGVHjApw9a +IQw1uqb7I+xn78arYiJN9v0C55ozQIJnSNb+H4iXrEwsu4VpQ6SoXTbSCD95aUAa3yG 7DCQ== X-Gm-Message-State: ALyK8tLbMTGT4TJBIxikxOwnUuS4KonnNa2Y41x/z10WwLYKOZuPxaJ8QoNf+1kO+dNHog== X-Received: by 10.194.109.65 with SMTP id hq1mr16361657wjb.45.1464383113193; Fri, 27 May 2016 14:05:13 -0700 (PDT) Received: from [192.168.1.181] (178.112.50.109.wireless.dyn.drei.com. [178.112.50.109]) by smtp.googlemail.com with ESMTPSA id i3sm21132056wjx.30.2016.05.27.14.05.12 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 14:05:12 -0700 (PDT) To: JSON WG From: Christian Zangl Message-ID: Date: Fri, 27 May 2016 23:05:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 21:05:17 -0000 Just to clarify, when I say Human JSON I actually mean all humans that are somewhat computer literate. I got the impression that some (most?) people here think that config files are edited only by developers. From nobody Sun May 29 18:56:41 2016 Return-Path: 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 A29FB12D0E0 for ; Sun, 29 May 2016 18:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 oAiMyMaG_96L for ; Sun, 29 May 2016 18:56:37 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0126.outbound.protection.outlook.com [104.47.93.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC5612B041 for ; Sun, 29 May 2016 18:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tO5appI9DtjEWvpOawpsuFeVJK7mRECrmnm6X/H/8Ck=; b=pMoe8jQgiZ3LtcHKo+q6tO6IVf0+wJpFaH7WONpsGsfPhliRHMy7NoIUOw5/2KeLZEMMf4Ct7k1JUiYHpAa66FGPeS08NQfY7aI4NkFE9kduaCu+9yb+xdpAY//SD7eDX4j7sNgrn/IoZWwLaQ715QjIipwkAmApnuRbuoJSWYw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR01MB0918.jpnprd01.prod.outlook.com (10.167.148.148) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 30 May 2016 01:56:34 +0000 To: Phillip Hallam-Baker , Carsten Bormann References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471154.1050107@tzi.org> <574711EE.2010405@tzi.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 30 May 2016 10:56:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0016.jpnprd01.prod.outlook.com (10.161.74.154) To OSXPR01MB0918.jpnprd01.prod.outlook.com (10.167.148.148) X-MS-Office365-Filtering-Correlation-Id: f1fc0924-54be-4364-4f8e-08d3882da0d0 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 2:14cZTaU3HWvhEoXjxxYsWVpbSiMw3MXI6mgS4NKOOukyLqy3eQYDUVk+uNjWej2wKjmg6Z5pjukV7vy/yCfxipRnSaawLzyJ4zHmkErhvXpqzoMhBmRQlBhDrHxAibwOxvKheIwgFt7RezxT2m8z6TwFiZTkPaUni0qkK2nlFOYa5tBALI6e7osqH3dGE+SQ; 3:duQ5wpfTbGBK4BrkKshMcigaM7xyFxHXEqmkSH+X+Jxje7oo5jsXTL3bZ1OguPAtsiYod0uuwrcl6Uj5qHZMUrUAHzvMgNjMDhQ9Zv7Lcp4VoplmVTo/fcIWjnlsxTLA; 25:K9FO8w0TGfb9AA/dJbmyXMvcJ85Sej/pPxRLNjDsFAvLV+NmNylBERUkkUc3BeUiZ4UO8DyymtETjFDNI9rWhr14G0d7eJGZ7T5UsGXOQsGvuBImzgReUAL8kcsIN5/dTOlLUZ3Hccob9b2MAQL/LmuRCdbwEPIOHdGUmPlVRE37Qi0O/JdZWd3QvBAnPaFgF4YMok9TfY7jgCAdsCLpPPa7JiPR3SNmeSyIeUMjjWrsKZxVc2VlXy0GPNjU26mPn6TkcjzaRMxt8lcLsV1ms7UjimG1HX63oOR/nSWlomFVOLBcAudXHggWAIoXpavOH8C82b/ApVQj/XArvzl6O7GCW8Mex+6Nq61HkkrKWGjBsiyfyAf8a8m47RAoLGr/XKLtCHZQ83f4oOSD2sw5DnRgJaNL09UELrsPAL56kzY= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0918; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046)(6042046); SRVR:OSXPR01MB0918; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0918; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 4:rF6jYM7rktxFCFjQDeM+4ISY4luiVIT7jVE86XagHYNzQNXCdOwjObbCT3XfWr1piavxj2kJs+SygjauuDbGTW44IKcMsdfOy96xFo9h6vbEDEm395Zh0BKB2vEHQAY1jwPbirZzxsITQNSgEgy7eGNM5wjRL+/IZd87EEUPqgt03KY1Oc7mpEgKj9G3CJdSRbH8S3ftQD4PDgWEhYorl7lVz1FzzBmq/65xRqpuhn1F6b79G6780b6esnctBj8sT0ZkLc030fjKWoez/lqe60Bi+uq2iLe1cwCTsbEJpCwoxiTZ8RPEwA3vtQ9ifEZF4jx0EEiaYAHPmgH+zHXz9+PY2Duqt/Jxy3f4YGHcMv/kVxcUfaXc4Qc8XllZHNjypFT1hfazqOEf/u7axE1xqeGm29WFPxGI2m9be3ukNpeESWG9FofcYB8PhLAbtEkC X-Forefront-PRVS: 09583628E0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(83506001)(77096005)(33646002)(76176999)(54356999)(23676002)(5004730100002)(2906002)(6116002)(65806001)(47776003)(2950100001)(230700001)(3846002)(586003)(65956001)(66066001)(93886004)(86362001)(42186005)(81166006)(31686004)(8676002)(4001350100001)(4326007)(189998001)(74482002)(5008740100001)(64126003)(31696002)(5001770100001)(50986999)(92566002)(65826006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0918; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwOTE4OzIzOkpUQXhDN2ZFeFcxbzFGWmgrZUtBb2d1QnRD?= =?utf-8?B?cWdMN1hHVnp2VHg1NzZraEtvVVdMUmNCajdsalpvam1Rc1BWcXhLOXp4eS9t?= =?utf-8?B?OEJ1V09HOHBmckh6aGh2YnpmdW12dCs5dGVuV3U2akJCSnkwM1hQZk1XTmNu?= =?utf-8?B?QXRtNXllOURiNTIvMzArS1lEOEdzSlpxdU95Z3drblk0YVRPUVdmMGV3a1F0?= =?utf-8?B?NFNJRDl6TU5YYUFEUEI3OFRGQnozZHB2Y2tMQy9XaE9xU0dBY2RuNG9rSmlN?= =?utf-8?B?eW9BMHZjaXVpUEZWTTJQbTh1eGhxS3hHeWlTMWFWQnhxMU9IUXY3WXNnVXRn?= =?utf-8?B?VkoyVXUxSmhzNWEwTWx0WGpUeDNtNGtWdFpENk5KM1BRZEVIYWs5dmtiNDdi?= =?utf-8?B?MUJ4RmRkUVl0TGVCV3MwZ1EwSGp2d2JuVzFYR0Z2N2ZkbUczaHhLSkY1VW5E?= =?utf-8?B?VlpCUUF3L2VQU3ZrRFkrMFpEcjV6OTJsQmVVa01YWUhzQTdUSlRiVytvbmQ3?= =?utf-8?B?ckZMRTNWWTFqdGFrY205aUNTeHUyck1XcUlUak1sUXRFT0VVdCtCd09pck5w?= =?utf-8?B?Q1N3aWErcWEzTmlhcTQ5R1NIM09wZXdQN2krdVVKZ1VOV243OWdCeWRUQXRE?= =?utf-8?B?bVJiMmtEOUtWOXhKTytsRG1OWWdmeGE0Q2lobkpCN0g5cEw4VktjMnJMeE83?= =?utf-8?B?Ull2eFIxbHVPUC9FejZyOWdrekZDanZxa0xzL0FIVTVVRmNwUms1bnVUZDcw?= =?utf-8?B?K0wzaFFFUlpFRFc4Wkk5RUlIUXQrVS9hSnY3YnFWR1lDK0tmLzY5dUNTc2Jv?= =?utf-8?B?ZnBPYkdFcSs5Szg1T091c0NWaDRCQndOSk5SMTBZUlBQSkIwMzRGbWNaK1Y1?= =?utf-8?B?SDJyNFdzRzdzNWJPMkZHS1F3ZiszQ0tJVUhabmhHTmR2S1U0blhrTjVNcTY2?= =?utf-8?B?aU85ZFptWDZkZFpRcVNVVTljTXBaRTh2UDlNSTFPVjJ6bG5mby9mazErQjZm?= =?utf-8?B?bW55dngxT3ZFdVhWVTFFS1dIMnVVdUk3SEplSnpGWUFoTHBNMHBLbFlVVG1u?= =?utf-8?B?VSsvck9KZE9TNmZmUXdrWTNPWi80SGtMeUI4ODdMZXZnb1lZREFWKzNubmlF?= =?utf-8?B?MC9Na3NQczJNekMrbHJaM1k2aVdHUGNOMGlhWFFxU3Y5QlRnYVRqUWVJdGZV?= =?utf-8?B?SVlYR0xpS0hiTmIwTUFocysxUm0razBjZU8zZzV2cHpoOHRJdHYxTmlhNHFH?= =?utf-8?B?aS9jT3NDUExWelQ4Wk9qZFFkMEQ5MGNBekVIVllNUktkSEtmTnhYRWFSUGpQ?= =?utf-8?B?d2pzMTVtOUd0c2tSbFZwMnJ1Z043OEdnNG9GcHQ4OS9RNklKa3RkUGVsWUxM?= =?utf-8?B?SHdTVmg2bEhUaE85MlJIL0dVVEFRT2dFeDRoYmZ3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0918; 5:fh1ieXwB82UaQ36UxfketKrAclz05ZN5faZfjyFVyUWO3cFwUx48w709K3f9nCARloX4RctFQFi/5yTZSmiwRZWaPfDD6eiVicHCBjFS/yKWCnD4SV+jeATCbEmIXfmWJCMlHhnSO37bvkXoDod/uA==; 24:tghxJcB/g4aBht85hf2ag9YNnZy1FEClUI7LlliX1b8UalAsjgXk2lZ3RCGIycw0zHK3/E4mSowcS4ZNCdU2gSlBgTwmZXwkKPa/U/yzSls=; 7:i9TPNkzAn46x7p3YPp9pdV1IEZzCbRL3bTRmHsanks7cVaKsR2LfHpokp+4GNTsOZ1grd4WekivbqYchdemyphljXcoZrUeqOmF0yuYm2KnLUDLfVWj40zSa0bQG2IEpC9xTSGtpoLWgnVDWgTvYD5qofCcsfehozyZjpquNZfswycuMawBpvUDrlIjCJfWE SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2016 01:56:34.1034 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0918 Archived-At: Cc: JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 01:56:39 -0000 On 2016/05/27 00:36, Phillip Hallam-Baker wrote: > So the following would all be equivalent: > > { "Tag1" : { "Tag2" : { "Tag3" : "Data" } } } > > Tag1 > Tag2 > Tag3 "Data" > > Tag1 { "Tag2" : { "Tag3" : "Data" } } } > > > The second version is pretty much the Goedel syntax. I can show that is > unambiguous as I define it as a FSM and then produce the grammar from the > FSM. Just a quick comment: As far as I understand, a FSM (finite state machine) isn't able to grok any of the above, unless you limit the number of indentation/nesting levels. An FSM leads to a regular grammar, whereas a context-free grammar is needed to parse nesting constructs with arbitrary depth. The corresponding automaton is a push-down automaton. Regards, Martin. From nobody Sun May 29 19:02:08 2016 Return-Path: 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 214B112D0E0 for ; Sun, 29 May 2016 19:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 csAFqxE6HkJ0 for ; Sun, 29 May 2016 19:02:05 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 860B112B013 for ; Sun, 29 May 2016 19:02:05 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n63so114114911qkf.0 for ; Sun, 29 May 2016 19:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=EC5LXasZMmaF3MvzheDep2DwcMdFcw2JKbuP2E5llGU=; b=ZaKp/LbMKMoDISqUaSO3M1BIUqYDqTZ097C/2DBuEIdg++79EQHHc6jEA4KNb01t+c +e7AAW1Wf7sqerF6y7P/Tw59i6tfJGdc+SQM2cJnjlON6ANTcb16rz/VN5notE9Ijmfi bZkUoqqf48yitV3mNVGSmGr+ITo228g57xGHt19l1UY+G3lg86KcACV1AWeXSn3UajN3 ZBKvnNj6GOStFDbcWK+o5J48jPeUycL45So9eBKjvZr8KTgbxhyS6wPcRsTyVEneBblw Ia4WfemxSBGj7E+IeUQHWmxTWZ4gMNMnVUybaG670Fn93PlgzHbgNb1673JoMIVCYj9E RnUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EC5LXasZMmaF3MvzheDep2DwcMdFcw2JKbuP2E5llGU=; b=JYjQMHm6g1cPzJ4y1IUfecu+RJSQAQoTbA7/hZCl477e6N83p0dQxJvdW+OOrsdH6r tOaSbIcsYNYspfCeumukhks4UX6ZMIb+4MpFYiQvmMUKkZG+tFHoi4u6/rEL6AkW6VHB SGLMTvin7htlXSsaTfChwe2w1+jpqj/GblE9467F4jj1ZueHFWuy2S1+J+9EU8AgG0Eh zgJbeY7lLCAvBE6/M5sEIcftavm4bVxVypxV8Zjv6i8ffZ5bTap8keJHDv3QPGzgvvLp BEVNUSevreLWbkyl88ZF+NvCBqEKGaXZFB7cqOz8IaUliN/gKvJPO6iMBQfYc5n+NFfF B1xA== X-Gm-Message-State: ALyK8tJ5zMNcfbymboISURFvnepCW/2K060VRLlJxtYPgM+44f4n7x8pdDskQnRfzj0SYBsndwYTMCEj8pkYeQ== MIME-Version: 1.0 X-Received: by 10.200.54.170 with SMTP id a39mr23577115qtc.104.1464573724684; Sun, 29 May 2016 19:02:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.55.25.85 with HTTP; Sun, 29 May 2016 19:02:04 -0700 (PDT) In-Reply-To: References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com> <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com> <57471154.1050107@tzi.org> <574711EE.2010405@tzi.org> Date: Sun, 29 May 2016 22:02:04 -0400 X-Google-Sender-Auth: _rLfG6FIAo1ENZZOkVv7G5uoMig Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a1141a6129b75dc053405a4c0 Archived-At: Cc: Carsten Bormann , JSON WG Subject: Re: [Json] Human JSON (Hjson) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 02:02:07 -0000 --001a1141a6129b75dc053405a4c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2016 at 9:56 PM, Martin J. D=C3=BCrst wrote: > On 2016/05/27 00:36, Phillip Hallam-Baker wrote: > > So the following would all be equivalent: >> >> { "Tag1" : { "Tag2" : { "Tag3" : "Data" } } } >> >> Tag1 >> Tag2 >> Tag3 "Data" >> >> Tag1 { "Tag2" : { "Tag3" : "Data" } } } >> >> >> The second version is pretty much the Goedel syntax. I can show that is >> unambiguous as I define it as a FSM and then produce the grammar from th= e >> FSM. >> > > Just a quick comment: As far as I understand, a FSM (finite state machine= ) > isn't able to grok any of the above, unless you limit the number of > indentation/nesting levels. An FSM leads to a regular grammar, whereas a > context-free grammar is needed to parse nesting constructs with arbitrary > depth. The corresponding automaton is a push-down automaton. > > Regards, Martin. > You have to add a stack. But you have to do that to parse JSON anyway to parse the braces. Indentation delimited is pretty easy to code, just count leading spaces, if the number increases, emit a brace, if it reduces emit as many braces as necessary --001a1141a6129b75dc053405a4c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 29, 2016 at 9:56 PM, Martin J. D=C3=BCrst <duerst@it.= aoyama.ac.jp> wrote:
On 2016/05/27 00:36, Phillip Hallam-Baker wrote:

So the following would all be equivalent:

{ "Tag1" : { "Tag2" : { "Tag3" : "Data&q= uot; } } }

Tag1
=C2=A0 =C2=A0 Tag2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tag3 "Data"

Tag1 { "Tag2" : { "Tag3" : "Data" } } }


The second version is pretty much the Goedel syntax. I can show that is
unambiguous as I define it as a FSM and then produce the grammar from the FSM.

 Just a quick comment: As far as I understand, a FSM (finite state machine) = isn't able to grok any of the above, unless you limit the number of ind= entation/nesting levels. An FSM leads to a regular grammar, whereas a conte= xt-free grammar is needed to parse nesting constructs with arbitrary depth.= The corresponding automaton is a push-down automaton.

Regards,=C2=A0 =C2=A0Martin.

You have to add a s= tack. But you have to do that to parse JSON anyway to parse the braces.

Indentati= on delimited is pretty easy to code, just count leading spaces, if the numb= er increases, emit a brace, if it reduces emit as many braces as necessary<= /div>


--001a1141a6129b75dc053405a4c0--