From nobody Mon Apr 1 20:06:49 2019 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 51A8512004D for ; Mon, 1 Apr 2019 20:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.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 eae3e0YIUidu for ; Mon, 1 Apr 2019 20:06:45 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 893AA120013 for ; Mon, 1 Apr 2019 20:06:45 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id f22so2771890ita.3 for ; Mon, 01 Apr 2019 20:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=zMpKKaL4wr2lhgri2xG/THtFwVdzfhMCnLCrWQm9+2I=; b=nImFIOmQdk58ft3n57J4Mb9yVO8TiAY7GrNmpHe4iGwnxOvK1bTI2Q3gNOBlVQZQOz yQStpuSOyP2ePdSq58xzGrn+OH+1+yTc4aBmj+onRCjhdKhBEYIpTYiTdc9XFVtO6tNi VkdTyJmgU/sji89Rx9+gL4E94UTpoj273zfKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zMpKKaL4wr2lhgri2xG/THtFwVdzfhMCnLCrWQm9+2I=; b=UpvbOgm4cZftQdyLUzy3BZG7Of5DZ9PdzVG0v2KEJo7eGyJYV79hw1PHzChZC/Xnry qnx1K/TMGo0vnMK6xPvHe/WzAvDWzxqKXjC86fO7/RTcDnx1fpIgz7QFlYM9sqXFaQ0P QhM6iw/7ayHS1FfGvi+xaAveqmsgj9MKU4ypSKRJC8bvjy6KAooqy+9D+6imbNclg3EV CVJeXI3OZe9okWi6U5wUfR/7jhufaP5++clU+aLjiUx6KVB4q5eTMBLs3QKLvXEn8veB sIUqlvUSEeKuVyDAli+RRVrdTQQq49oRmfTBlO/nexZMmN8n5xyeXUpav8WsuZxwEPam T+xg== X-Gm-Message-State: APjAAAWZC37Pn4KCT/krdBpDe6PRS29KOO3fbz3bkUKJMVft4HIJsAUX HjMLrLwNwnvPQG25ZqmTQ6BoEBwLDIAbfVDpcNmAJ3Oqj/Y= X-Google-Smtp-Source: APXvYqw4usDUjnl07ML2FnDIMJSwvZc0z/tVVBwn4nq3TN4670mvr4+1H+ML92KERGuhE2aIGR8VI/1U8s36ed0fKlA= X-Received: by 2002:a02:c4c2:: with SMTP id h2mr20385837jaj.86.1554174404565; Mon, 01 Apr 2019 20:06:44 -0700 (PDT) MIME-Version: 1.0 From: Ulysse Carion Date: Mon, 1 Apr 2019 20:06:33 -0700 Message-ID: To: json@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Json] A schema language for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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, 02 Apr 2019 03:06:48 -0000 Hi all, Would folks in this list be interested in working on a schema language for JSON? I am aware of JSON Schema , which has appeared in this list before. But in my experience JSON Schema is not reliably interoperable, perhaps as consequence of its complexity. The errors it generates also leave something to be desired. When writing data pipelines or simple JSON APIs (e.g. JSON-RPC), I find myself wanting an interoperable schema language that I can generate validators, classes/types, and fixtures from. It just needs to be powerful enough to express structs, dictionaries, tagged unions / discriminators, and homogeneous arrays. In the immediate, I ask if anyone would be interested in collaborating on such a project, or helping to get it on the standards track. I have written a tentative I-D for a JSON schema language. I am not married to the proposals in the below I-D, but I do think they may form a useful starting point. https://github.com/simple-json-schema/simple-json-schema/blob/master/json-schema.md Best regards, Ulysse Carion From nobody Tue Apr 2 04:04:37 2019 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 656811200EC for ; Tue, 2 Apr 2019 04:04:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xAENLn28LsXn for ; Tue, 2 Apr 2019 04:04:32 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [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 9145212009C for ; Tue, 2 Apr 2019 04:04:31 -0700 (PDT) Received: (qmail 21947 invoked from network); 2 Apr 2019 12:02:52 +0100 Received: from host86-182-43-190.range86-182.btcentralplus.com (HELO ?192.168.1.72?) (86.182.43.190) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 2 Apr 2019 12:02:50 +0100 To: Ulysse Carion , json@ietf.org References: From: Pete Cordell Message-ID: <15d34816-5b98-88a6-65fb-1465753cfbf5@codalogic.com> Date: Tue, 2 Apr 2019 12:04:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] A schema language for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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, 02 Apr 2019 11:04:36 -0000 A number of us have put together "JSON Content Rules" or "JCR". The syntax of JCR is not JSON but is "JSON-like", possessing the conciseness and utility that has made JSON popular. More details at: http://json-content-rules.org/ Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- On 02/04/2019 04:06, Ulysse Carion wrote: > Hi all, > > Would folks in this list be interested in working on a schema language for JSON? > > I am aware of JSON Schema , which has appeared in > this list before. But in my experience JSON Schema is not reliably > interoperable, perhaps as consequence of its complexity. The errors it > generates also leave something to be desired. > > When writing data pipelines or simple JSON APIs (e.g. JSON-RPC), I > find myself wanting an interoperable schema language that I can > generate validators, classes/types, and fixtures from. It just needs > to be powerful enough to express structs, dictionaries, tagged unions > / discriminators, and homogeneous arrays. > > In the immediate, I ask if anyone would be interested in collaborating > on such a project, or helping to get it on the standards track. > > I have written a tentative I-D for a JSON schema language. I am not > married to the proposals in the below I-D, but I do think they may > form a useful starting point. > > https://github.com/simple-json-schema/simple-json-schema/blob/master/json-schema.md > > Best regards, > Ulysse Carion > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Tue Apr 2 04:53:52 2019 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 A605B120513 for ; Tue, 2 Apr 2019 04:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 VN3ZLHfbKwKD for ; Tue, 2 Apr 2019 04:53:39 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EC2120514 for ; Tue, 2 Apr 2019 04:53:39 -0700 (PDT) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44YSKD4l06z10PP; Tue, 2 Apr 2019 13:53:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 2 Apr 2019 13:53:36 +0200 Cc: json@ietf.org X-Mao-Original-Outgoing-Id: 575898814.909138-1773460a25f8888ebcb25a0e321d1a7d Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] A schema language for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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, 02 Apr 2019 11:53:51 -0000 On Apr 2, 2019, at 05:06, Ulysse Carion wrote: >=20 > Would folks in this list be interested in working on a schema language = for JSON? That depends a lot on what a =E2=80=9Cschema language for JSON=E2=80=9D = is for you. Generally, this WG has been hesitant to adopt any specimen out of this = loosely defined species, but has also been open to letting some flowers = bloom. Pete mentioned JCR, which is one of the more expressive = proposals. Over at the CBOR WG, we now have a specification approved for the = =E2=80=9CConcise Data Definition Language=E2=80=9D, CDDL, which can = describe CBOR data items, and, since the JSON data model is a subset of = that of CBOR, JSON data items as well. This has been used to define a = number of JSON protocols, e.g., RFC 8007 and RFC 8428 (*). It is not = using JSON as its presentation language, but is more concise (**). = Since I don=E2=80=99t know your requirements, I=E2=80=99m not sure = whether CDDL would be useful for you. Please see = https://tools.ietf.org/html/draft-ietf-cbor-cddl =E2=80=94 currently in = the RFC editor queue. Gr=C3=BC=C3=9Fe, Carsten (*) Full list: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/referencedby/ = https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/refe= rencedby/ (**) An old comparison between what was then a version of =E2=80=9CJSON = Schema=E2=80=9D (Gallege/Zyp/Court branch) and CDDL: = https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications= -hurts.pdf From nobody Tue Apr 2 05:28:57 2019 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 4152612018B for ; Tue, 2 Apr 2019 05:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b-310btLxhVI for ; Tue, 2 Apr 2019 05:28:53 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (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 87E1B1200F4 for ; Tue, 2 Apr 2019 05:28:53 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id i21so10250057oib.11 for ; Tue, 02 Apr 2019 05:28:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KpPVkRgzDU9YH+8e9gG39W/Za2djHcru2pC1Asi/lHc=; b=e5voHU9ODTIohIfuHt5FvgcGsXUj/GlH4MiFxFXHrPy7EMaxfLrSgIbmELYtyJrKeh 5WEonzy+R8RYDwDJnW5IY/ZT7tn7tRp+T18MHenrrHkwsIc1nX10qKzj4Ank7ipYXb1b 6FwUj1XYFGkEXlqLZzhsS4xbimc+tycSrgCHc499fdqhZtbX8+GN2bAGAFnzxLlVfZSL MrlXH9r7F5B/EXVGVX+/lzQ3zIqqtaTxwSNvBo5FKXIDqy9fL2dCfyUwPpbHu2SjK/MR OMX8P9LlKSKszKAIA0U7amxGZepzP+2RE8Mj2X+SmuDl2veVXUihig/vSVq4pEJrB7jY 9sTA== X-Gm-Message-State: APjAAAWIfldVxe29PGYP8qFvrwYxgYoigvqoOw3K1c010rlh2cCQJpKc 92tOTen2u7A7oYajrhlN3Az5yC8kApbtzhLgLkI= X-Google-Smtp-Source: APXvYqwXNLwlpj1qG0hANrmdgIcAKqAuK3TIhxjm29xyyt8P9p/Ga4PQw4oUWGWUlp9XS5UFfPkoXRY7lIJuCvxYsVI= X-Received: by 2002:aca:c68b:: with SMTP id w133mr16860939oif.58.1554208132143; Tue, 02 Apr 2019 05:28:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 2 Apr 2019 08:28:41 -0400 Message-ID: To: Carsten Bormann Cc: Ulysse Carion , JSON WG Content-Type: multipart/alternative; boundary="0000000000009f9fa605858b47b1" Archived-At: Subject: Re: [Json] A schema language for JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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, 02 Apr 2019 12:28:56 -0000 --0000000000009f9fa605858b47b1 Content-Type: text/plain; charset="UTF-8" I have a schema tool as well. But it is more focused on the data model of the source data than that of the JSON, XML, ASN.1 or TLS serialization. The main use I make of the ProtoGen tool is actually generating documentation rather than the code. The schema language includes slots for the description to put in the reference manual. It is very much in the DEC/VMS style of tooling: http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html Using ProtoGen, I can generate documents where the reference material and the code examples are all generated from a single source. Which means that when you see an example in one of my specs, that comes from running code that was generated from the same source as the reference section. XML Schema has a lot of features that turn out to be precisely useless for exchange of data between network objects. And a lot of the same nonsense is carried over into attempts to create JSON schemas. For example, lots of schema proposals have the ability to restrict integers to a range of values. I have used programing languages that have that type of restriction but none of them is widely used for programming. If the features are not widely used for coding the applications, they are not required for a schema language either. Same with the number of entries in a list. I have found that more than 95% of the time, the only values for the minimum number of entries are 0 and 1 and the only useful values for the maximum number of entries are 1 and infinity. The data objects on either end of a communication can make use of complex, rich data structures like sets, dictionaries, etc. etc. But the serialization of all these encodings is the same, they all map to lists of entries. So a protocol schema language is not the same thing as an application program schema language. My Protogen tool is available on GitHub but if we were to go for a standardization effort, I would consider it an input rather than the intended final product because as I said, it is not the only schema language I have. Right now I have about 5 and I would like to collapse these to 1 so that I can design a protocol without considering the encoding. The Mesh is mostly in JSON but backwards compatibility requires code that serializes/deserializes DNS protocol, TLS protocol, ASN.1, XML and of course RFC822/821 style interactions. All this code is generated using synthesizers. Right now, the reference code is all in C# but I am fully aware that I need C/C++ libraries for deployment. My deployment strategy is to retarget the code synthesizers to produce the different language(s). As far as I am concerned, ASN.1 schema and XML schema are outputs from my schema tools, not inputs. So for example, I am currently looking at implementing Calendar and vCard functionality. While I want to have all information available in JSON form, I have to be able to import and export in the legacy formats. Unfortunately the legacy encodings are not regular or consistent. So I write a schema language that allows the idiosyncrasies to be encoded as hints. --0000000000009f9fa605858b47b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ave a schema tool as well. But it is more focused on the data model of the = source data than that of the JSON, XML, ASN.1 or TLS serialization.=C2=A0

The main use I make of the= ProtoGen tool is actually generating documentation rather than the code. T= he schema language includes slots for the description to put in the referen= ce manual. It is very much in the DEC/VMS style of tooling:

http://mathmesh.com/Documents/draft= -hallambaker-mesh-reference.html

Using ProtoGen, I can generate documents where the referenc= e material and the code examples are all generated from a single source. Wh= ich means that when you see an example in one of my specs, that comes from = running code that was generated from the same source as the reference secti= on.=C2=A0

<= /div>

XML Schema has a lot of f= eatures that turn out to be precisely useless for exchange of data between = network objects. And a lot of the same nonsense is carried over into attemp= ts to create JSON schemas.

For example, lots of schema proposals have the ability to restrict intege= rs to a range of values. I have used programing languages that have that ty= pe of restriction but none of them is widely used for programming. If the f= eatures are not widely used for coding the applications, they are not requi= red for a schema language either.

Same with the number of entries in a list. I have found that mor= e than 95% of the time, the only values for the minimum number of entries a= re 0 and 1 and the only useful values for the maximum number of entries are= 1 and infinity.

The data= objects on either end of a communication can make use of complex, rich dat= a structures like sets, dictionaries, etc. etc. But the serialization of al= l these encodings is the same, they all map to lists of entries. So a proto= col schema language is not the same thing as an application program schema = language.

<= /div>
My Protogen too= l is available on GitHub but if we were to go for a standardization effort,= I would consider it an input rather than the intended final product becaus= e as I said, it is not the only schema language I have. Right now I have ab= out 5 and I would like to collapse these to 1 so that I can design a protoc= ol without considering the encoding.

The Mesh is mostly in JSON but backwards compatibility requires= code that serializes/deserializes DNS protocol, TLS protocol, ASN.1, XML a= nd of course RFC822/821 style interactions. All this code is generated usin= g synthesizers. Right now, the reference code is all in C# but I am fully a= ware that I need C/C++ libraries for deployment. My deployment strategy is = to retarget the code synthesizers to produce the different language(s).

As far as I am concerned, AS= N.1 schema and XML schema are outputs from my schema tools, not inputs.

So for example, I am current= ly looking at implementing Calendar and vCard functionality. While I want t= o have all information available in JSON form, I have to be able to import = and export in the legacy formats. Unfortunately the legacy encodings are no= t regular or consistent. So I write a schema language that allows the idios= yncrasies to be encoded as hints.
--0000000000009f9fa605858b47b1--