From nobody Tue Jun 4 10:21:10 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 CF7761200DB for ; Tue, 4 Jun 2019 10:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 7klTPixFZTbY for ; Tue, 4 Jun 2019 10:21:06 -0700 (PDT) Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 1D43B1200C4 for ; Tue, 4 Jun 2019 10:21:00 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id d7so3715197vkf.1 for ; Tue, 04 Jun 2019 10:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=dX/9g0vsKwkdeNzUr2HIUGI5bfUPmd+5noA6YaSPuNw=; b=UU9Zl2PLzjmvMynZMfxBCV+UM0sXnwexkqBY5jA34Y4mD8VrODxiHM3MVmJU3RFiaW HD5lYBxV+XZ7f0LDRCO1nRuMHMtmyDUvCjQtMQes0ZUmYIW9LudRW//ghoM0Wf3iXuKF y0jskUeprVkhvTG4LIldzXRqDOq1wrkE93hhgTXu0LdPBf1X61BWN3YaF681W8BuCZck f6EYAQwLCzD3MHfuY+uPULV1AaldrwdElpTgnnr/y+GU2KscLfld3lSoTkHBJYQNx9Aa RxhqIy3rdWzzTh/vHKvpJMXjC36kyHyzDdWQWULjgkSTpjNL8oGdqRDi4FqBk0t8fHNx BGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dX/9g0vsKwkdeNzUr2HIUGI5bfUPmd+5noA6YaSPuNw=; b=FD4afTVSKPJk62ALoIA4SHVYMVRzGzmgr3yrg1bF1cl1X8ek+weulD7/d/rYWLgYuJ iKyflcZ4npYHw+fkrhqX6qB2N4BT2p6c1+VYSUWn5J6NpveaV86EK7Ix9dQ91WpEyFGF 7EfKaLnDG1ihKnYUFfusrm3TybpIZzNvYwAa4XEeHvI1Xmweb13GjIU4vQCDZo3MzYJo 2/X+c+IavhPIj38bwu51XBxzSgJSW/AxBno7CxtT1PUK2vbrRXILqEWZ0MUwdMENDVaQ SfIHI7b7C8b5ypkirCgHU2ZkxTyyR3G5NcgI6fUPfl19EkvUlAbTGRnjuPS3olmfLNgl xeKw== X-Gm-Message-State: APjAAAUTOBphwSIaxSsbhNQumMw27UP9mQ/wPFm9WhINjuLxRQRlgJyB YWubJmjbf7tTsV4SNMCb2SWr1Udzh5g= X-Google-Smtp-Source: APXvYqxYFcmkChSYWzT/w3u4KTVxU2yX4Y1yJPpxvVeTsKAb0kfaVCFBbHcBw2GxqgkQMGGoUBeREg== X-Received: by 2002:a1f:12d5:: with SMTP id 204mr225925vks.4.1559668858643; Tue, 04 Jun 2019 10:20:58 -0700 (PDT) Received: from [129.10.224.37] ([129.10.224.37]) by smtp.gmail.com with ESMTPSA id j13sm2816353vke.52.2019.06.04.10.20.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 10:20:58 -0700 (PDT) From: Qianqian Fang To: json@ietf.org References: <72cccaa7-d2d6-e7ce-57ee-a86a98626d36@gmail.com> Message-ID: Date: Tue, 4 Jun 2019 13:20:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <72cccaa7-d2d6-e7ce-57ee-a86a98626d36@gmail.com> Content-Type: multipart/alternative; boundary="------------5A4BA8492B17B58D59DFD79C" Content-Language: en-US Archived-At: Subject: Re: [Json] JData: A general-purpose data storage and interchange format - Draft 1 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, 04 Jun 2019 17:21:09 -0000 This is a multi-part message in MIME format. --------------5A4BA8492B17B58D59DFD79C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI, after a list of deliberated updates, I felt comfortable to tag the "Draft-1" of the JData specification. https://github.com/fangq/jdata/blob/Draft_1/JData_specification.md The major changes include 1. switch from column-major to row-major order to serialize N-D arrays (in both annotated and direct form) 2. define _ArrayData_ as 2-D arrays for better grouping of similar data types for space-efficiency 3. add support for generic byte-streams, non-string keyed maps, and weighted graphs 4. fix the incorrect UBJSON extended syntax for N-D array storage I also noticed recently that the MATLAB Production Server (mps) included in MATLAB R2018a or later had adopted a very similar data annotation schemes like in JSONLab/JData: it uses "mwsize", "mwtype", "mwdata" instead of "_ArraySize_", "_ArrayType_" and "_ArrayData_".  The serialization for complex arrays is also very similarly defined. Eventually, all software that intends to handle complex arrays/data structures will have to consider the additional serialization schemes for complex data, which I believe JData will be able to make this process easier. Qianqian On 5/13/19 7:52 PM, Qianqian Fang wrote: > > Dear list, > > (I am new to this mailing list, apologize if this is not the right > place to post proposals of new JSON-based specifications - in that > case, I am appreciated if you can point me to the right direction). > > I am a researcher/professor working in a university. A big part of my > work, aside from teaching, involves writing computing software and > processing medical image data. Over the past 10 years, I gradually > migrated the software I wrote, most of them are open-source, some > funded by the NIH, to use JSON as the input/output - I really love > this format because it is human readable, easy to manipulate, compact, > with parsers widely available. > > In 2011, I wrote a JSON encoder/decoder MATLAB toolbox > , > called JSONLab , and the toolbox has > grown a small user community since. In 2013, I added support for > UBJSON (http://ubjson.org), a simple binary JSON > format, into my toolbox. Around 2015, I felt strongly that a > combination of text and binary JSON is well capable in handling a wide > variety of scientific data that I, and many of my colleagues, handle > on a daily basis. Compared to the more "advanced" and "feature-rich" > data formats such as HDF5, CDF and NetCDF, JSON/UBJSON has clear > advantage of being so simple, excellently readable and requiring much > low programming overhead to implement. Many other less complicated but > still somewhat "opaque" imaging data formats such as DICOM, Analyze7.5 > and NifTi, can also benefit from a more human-readable version if one > can find a data mapping to JSON/UBJSON. > > So I started a project > called "JData" to use JSON constructs to map common data structures, > such as N-D arrays, hashes, tables, trees, graphs etc, as the > foundation to store/interchange scientific data in a more readable and > easy-to-operate fashion (many of these are already supported in > JSONLab). After much procrastination, I finally finished the first > draft of this specification, and would like your thoughts. > > The current draft of the specification can be found here > > https://github.com/fangq/jdata/blob/master/JData_specification.md > > the repository dedicated to the development and maintenance this > specification is > > https://github.com/fangq/jdata > > The overall idea is to define complex data structures using a set of > dedicated "name" tags in JSON/UBJSON without changing the syntax of > the format. This makes the generated file JSON/UBJSON compatible and > can be readily parsed by most existing parsers. > > Currently, this specification supports the following major features: > > 1. N-D arrays with and without data compression > 2. Trees, tables, hashes, graphs, linked lists > 3. Inline metadata and metadata node append-able to all elements > 4. Data grouping tags similar to HDF5 > 5. Indexing and query interface > 6. Referencing and link support > 7. dual interface text <-> binary > > The keyword names were choose to minimize conflict with other JSON > features that are under development (such as JSON-LD, JSON schema). > > I am sure there are typos and minor issues that I overlooked as an > early draft. What I would like to hear from this community are > > 1. well, what do you think? is this a project that you would consider > useful (in general and for the research community)? > 2. any major loopholes in the design of the specification? I am new > to writing a specification from scratch, I don't want to miss > anything important from the start > 3. if there is a value to continue developing this specification/file > format, what is the typical path way for such development? what > are the appropriate community/group to discuss ideas and get > suggestions? > > again, I have no experience writing an RFC or specification from > scratch, so, please be gentle, and I appreciate your guidance and > pointers. > > Qianqian > --------------5A4BA8492B17B58D59DFD79C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
FYI, after a list of deliberated updates, I felt comfortable to tag the "Draft-1" of the JData specification.

https://github.com/fangq/jdata/blob/Draft_1/JData_specification.md


The major changes include

1. switch from column-major to row-major order to serialize N-D arrays (in both annotated and direct form)
2. define _ArrayData_ as 2-D arrays for better grouping of similar data types for space-efficiency
3. add support for generic byte-streams, non-string keyed maps, and weighted graphs
4. fix the incorrect UBJSON extended syntax for N-D array storage


I also noticed recently that the MATLAB Production Server (mps) included in MATLAB R2018a or later
had adopted a very similar data annotation schemes like in JSONLab/JData: it uses "mwsize",
"mwtype", "mwdata" instead of "_ArraySize_", "_ArrayType_" and "_ArrayData_".  The serialization
for complex arrays is also very similarly defined.

Eventually, all software that intends to handle complex arrays/data structures will have to consider
the additional serialization schemes for complex data, which I believe JData will be able to make this
process easier.


Qianqian


On 5/13/19 7:52 PM, Qianqian Fang wrote:

Dear list,

(I am new to this mailing list, apologize if this is not the right place to post proposals of new JSON-based specifications - in that case, I am appreciated if you can point me to the right direction).

I am a researcher/professor working in a university. A big part of my work, aside from teaching, involves writing computing software and processing medical image data. Over the past 10 years, I gradually migrated the software I wrote, most of them are open-source, some funded by the NIH, to use JSON as the input/output - I really love this format because it is human readable, easy to manipulate, compact, with parsers widely available.

In 2011, I wrote a JSON encoder/decoder MATLAB toolbox, called JSONLab, and the toolbox has grown a small user community since. In 2013, I added support for UBJSON (http://ubjson.org), a simple binary JSON format, into my toolbox. Around 2015, I felt strongly that a combination of text and binary JSON is well capable in handling a wide variety of scientific data that I, and many of my colleagues, handle on a daily basis. Compared to the more "advanced" and "feature-rich" data formats such as HDF5, CDF and NetCDF, JSON/UBJSON has clear advantage of being so simple, excellently readable and requiring much low programming overhead to implement. Many other less complicated but still somewhat "opaque" imaging data formats such as DICOM, Analyze7.5 and NifTi, can also benefit from a more human-readable version if one can find a data mapping to JSON/UBJSON.

So I started a project called "JData" to use JSON constructs to map common data structures, such as N-D arrays, hashes, tables, trees, graphs etc, as the foundation to store/interchange scientific data in a more readable and easy-to-operate fashion (many of these are already supported in JSONLab). After much procrastination, I finally finished the first draft of this specification, and would like your thoughts.

The current draft of the specification can be found here

https://github.com/fangq/jdata/blob/master/JData_specification.md

the repository dedicated to the development and maintenance this specification is

https://github.com/fangq/jdata

The overall idea is to define complex data structures using a set of dedicated "name" tags in JSON/UBJSON without changing the syntax of the format. This makes the generated file JSON/UBJSON compatible and can be readily parsed by most existing parsers.

Currently, this specification supports the following major features:

  1. N-D arrays with and without data compression
  2. Trees, tables, hashes, graphs, linked lists
  3. Inline metadata and metadata node append-able to all elements
  4. Data grouping tags similar to HDF5
  5. Indexing and query interface
  6. Referencing and link support
  7. dual interface text <-> binary

The keyword names were choose to minimize conflict with other JSON features that are under development (such as JSON-LD, JSON schema).

I am sure there are typos and minor issues that I overlooked as an early draft. What I would like to hear from this community are

  1. well, what do you think? is this a project that you would consider useful (in general and for the research community)?
  2. any major loopholes in the design of the specification? I am new to writing a specification from scratch, I don't want to miss anything important from the start
  3. if there is a value to continue developing this specification/file format, what is the typical path way for such development? what are the appropriate community/group to discuss ideas and get suggestions?

again, I have no experience writing an RFC or specification from scratch, so, please be gentle, and I appreciate your guidance and pointers.

Qianqian


--------------5A4BA8492B17B58D59DFD79C-- From nobody Thu Jun 6 17:19:02 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 51D7B120247 for ; Thu, 6 Jun 2019 17:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Ad5XqvcOI5-x for ; Thu, 6 Jun 2019 17:18:52 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 EED1C12023B for ; Thu, 6 Jun 2019 17:18:51 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id e3so58923ioc.12 for ; Thu, 06 Jun 2019 17:18:51 -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=zE/u3Iu9DWxB+aeGAdmPRjP3OIdLs379oQNBtJQYcXY=; b=cjuNkkTjLb3ZY5GSab8f8B+pzsC/rbf9vbl4BcpFkbzedIKFdV0n16T9icPoOz4ft7 tIuyfz4tPNrm4X/NSUtf3ktZ/0oCDrdMBhHXeKfrYAi/Qytg507H+AxB/KJ3v1mXdAsC RtcjSKIgEt2whTiSOwH28AbriBkdgXehLLDp4= 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=zE/u3Iu9DWxB+aeGAdmPRjP3OIdLs379oQNBtJQYcXY=; b=FWPvzW3fHw32ycZfEM5tYI8blIULxoywuEOgmO67NHPb6jMpEW+6qJaNmO3z6FOont qDUIKstv7q2I+d/gi1mMPVGNQW/hxN+GqCFSOArYxsxbasWGBqnPwZhNknhYKx9Ad+ye oX3ofv9xlDHQF9o/SWNH0ndF1ku/Hak2GiRE7tlO8RT4Pi3SGOYZBJ7EovZ6KlTvNFYR 4wDuBMJByYKZv+984oQOALMDNWaXmyGM209M6WU1g2w1fjfJvQNhgD7WMGOnAj/IqRSS y9UAMlQ1Uxn4W6hQ7ca1dZ6qKlQ1Lb0xxbsTMhDO6JcT0Reth5j3yoS4A1wKhYVoYZMl 35mg== X-Gm-Message-State: APjAAAVDsGCy2wMU7AvlOfdsxQt6M92BC10ySCF7b+yeIm94QuHxKpG3 r2lowXdJpdFtaw3ZbZs+BHya29NVRaDZzMihqipf+QJM5ag= X-Google-Smtp-Source: APXvYqyvBZOJY/LU7JC5OewuN1cWEqFW17uJiiUiZXGQhSZHtH7+T6rc6raoqdldSIy/5ejrjicAQ6qb6uuuTVE/S9c= X-Received: by 2002:a05:6602:2296:: with SMTP id d22mr30201233iod.209.1559866730989; Thu, 06 Jun 2019 17:18:50 -0700 (PDT) MIME-Version: 1.0 From: Ulysse Carion Date: Thu, 6 Jun 2019 17:18:40 -0700 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="00000000000065f287058ab0c689" Archived-At: Subject: [Json] JSON Schema Language, Draft 01 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: Fri, 07 Jun 2019 00:19:01 -0000 --00000000000065f287058ab0c689 Content-Type: text/plain; charset="UTF-8" Hi folks, Working off discussion in this mailing list, I've published a draft -01 of JSON Schema Language: https://tools.ietf.org/html/draft-json-schema-language-01 Notable changes are the addition of "timestamp" (RFC3339) as a type, as well as the addition of enums. The syntax of JSL is now defined mostly through CDDL, and an informative appendix maps some JSL schemas to CDDL ones. The rest of the changes mostly serve to make the spec easier to read and implement, nothing dramatic. Would love feedback! What more should be removed or added to move this forward? Best, Ulysse --00000000000065f287058ab0c689 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Working off discus= sion in this mailing list, I've published a draft -01 of JSON Schema La= nguage:


Notable changes are the addition of= "timestamp" (RFC3339) as a type, as well as the addition of enum= s. The syntax of JSL is now defined mostly through CDDL, and an informative= appendix maps some JSL schemas to CDDL ones. The rest of the changes mostl= y serve to make the spec easier to read and implement, nothing dramatic.

Would love feedback! What more should be removed or = added to move this forward?

Best,
Ul= ysse
--00000000000065f287058ab0c689-- From nobody Thu Jun 6 20:04:16 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 7CF07120156 for ; Thu, 6 Jun 2019 20:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 moWxRf4YQeIX for ; Thu, 6 Jun 2019 20:04:12 -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 33F7A12010D for ; Thu, 6 Jun 2019 20:04:12 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id a186so630937itg.0 for ; Thu, 06 Jun 2019 20:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2qr4H8IEbTS+kkuBWryiE+pGaNjwsrU0qG7W480PEUM=; b=oBwZRrTuzvJ309XCwmeB9qXlgnUoKTQ4P153X5vFBBJo85CWS+GQ3shBj6vpcffohB bGwql+WV4dXURTHjnSAi01uuWcJGBTsmxdfT3enCoAMCu5zGxycva7B/IocP0WrIyY03 N4zjZOagPuEWCNqmshQHRGqp0PMUfgX1dF2hM= 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; bh=2qr4H8IEbTS+kkuBWryiE+pGaNjwsrU0qG7W480PEUM=; b=oSZzoaYFO6+ozpCslfWUfA9C1Zp0gGkdHdFIwrA56JzwVto+6qzZ3DJwpWZhfUSp9D BlHSzZ3HTiBSxaa0/LIuZMJweF5kS1L1QeI/dxJen8XxwoKcGL+lW65MiKWZ9fRXIXwg RX2ixdZTv/xdeIasfnwnFiYvXMo/YP99fcF7sPKuacQc0h2NqzJxAH/xxBef/aIWrmoK Fj4RPd6E11pIImZFLPK4qEmOJy8uNA5fsbLbUnwlQOBsxtjM63WyAbo+UCMIWyX5Fijo IzEAUbTdhtZYW6Q6mpz0DyyATMLsxbrIOApt8tvcl+2NKrpFh5ZDBAd1NHwOp7RUriLO lItg== X-Gm-Message-State: APjAAAUqyN+HhZGss5O99z19aYBtYLuq0vPDCa7lfv79PevKdIQ7YngM 2FxLkP+Mkxhzx+T1kqL3WoEcfgV6g7WuJMy6BYI4XwTR X-Google-Smtp-Source: APXvYqxv6iD6AY2kS7ZOxTdkcMauUx3NSnM5W7NT0XtxobUcdxEz4m+9Gy0zz1gT0kPISuJ7HUTr62cYnTr+nzAopfw= X-Received: by 2002:a24:da83:: with SMTP id z125mr2834898itg.126.1559876651278; Thu, 06 Jun 2019 20:04:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Thu, 6 Jun 2019 20:04:00 -0700 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="000000000000b18155058ab3152c" Archived-At: Subject: Re: [Json] JSON Schema Language, Draft 01 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: Fri, 07 Jun 2019 03:04:14 -0000 --000000000000b18155058ab3152c Content-Type: text/plain; charset="UTF-8" Oh wait, another big change -- I got rid of the URI-based reference stuff. Thanks to Tim Bray for pointing out it's kind of needlessly complex. On Thu, Jun 6, 2019 at 5:18 PM Ulysse Carion wrote: > Hi folks, > > Working off discussion in this mailing list, I've published a draft -01 of > JSON Schema Language: > > https://tools.ietf.org/html/draft-json-schema-language-01 > > Notable changes are the addition of "timestamp" (RFC3339) as a type, as > well as the addition of enums. The syntax of JSL is now defined mostly > through CDDL, and an informative appendix maps some JSL schemas to CDDL > ones. The rest of the changes mostly serve to make the spec easier to read > and implement, nothing dramatic. > > Would love feedback! What more should be removed or added to move this > forward? > > Best, > Ulysse > --000000000000b18155058ab3152c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh wait, another big change -- I got rid of the URI-b= ased reference stuff. Thanks to Tim Bray for pointing out it's kind of = needlessly complex.

On Thu, Jun 6, 2019 at 5:18 PM Ulysse Carion <<= a href=3D"mailto:ulysse@segment.com">ulysse@segment.com> wrote:
<= /div>
Hi folks,

Working off discussion in this mailing= list, I've published a draft -01 of JSON Schema Language:

Notable changes are the addition of &= quot;timestamp" (RFC3339) as a type, as well as the addition of enums.= The syntax of JSL is now defined mostly through CDDL, and an informative a= ppendix maps some JSL schemas to CDDL ones. The rest of the changes mostly = serve to make the spec easier to read and implement, nothing dramatic.

Would love feedback! What more should be removed or ad= ded to move this forward?

Best,
Ulys= se
--000000000000b18155058ab3152c-- From nobody Sat Jun 29 12:00:45 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 8DFCA1201E6 for ; Sat, 29 Jun 2019 12:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=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=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 3TMv87wpdt9U for ; Sat, 29 Jun 2019 12:00:27 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 40790120232 for ; Sat, 29 Jun 2019 12:00:27 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id m24so19733626ioo.2 for ; Sat, 29 Jun 2019 12:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1eeIdj3FKKBNoBycW/ANFZAyKpznK7jOhAxBQByTHtY=; b=VKNLFwtgwQjD4f7kJTja/uhuHmHo0uS0HdQRQeu9hyNokLZCvtQn91pNBZIYHIKzh4 1X3MRR4bsppa+KxlBvOT81ovfnZJ/BaLokiHpAREOQrVsVLWrxu+UeWjRKzs/RN5o+nN dj9v2kIsCtqJ1NJvkdQARW87LcTu57zagzIXk= 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; bh=1eeIdj3FKKBNoBycW/ANFZAyKpznK7jOhAxBQByTHtY=; b=iKB2QVki8uRUCXVapT/zkRDgk1SM9z9B33fBqenA8/WiaHx6J+B69hS2x06vh0VmKU PtSrjtBKPXkVf2G5Z/ndQhA9IsahrGBQqdMvLfXyRU+wgWDVWPOWjVSP03dpeO8Hq/TG jwkkiDx3LA0x0/qnzI+gF/yAT2Q7EoUqYPzGXUeuzj4F16DVAEUuFII3k0FITxLGe43M Rj6bGMc2KVtebH0KP5GiYm1UMYuf4rG7W0H2lBTuzOl09xDUS6PgOz+cBsXLA4cPJswf kF1TUlfTrAZeZf3YDFKsJu98riou2QtJMbbrzDD367UnKoxFIMOKwiQSIYP3W+UDoSlx aX1w== X-Gm-Message-State: APjAAAVanT/VCbYxK51V1E47PCYtB/VjmL0ZCN9eXBQgRrwl71mIA+Ic E94xtQC6znG+KSORyEaQQCd/l+z+xmxK96O1lTTS7KjFRUY= X-Google-Smtp-Source: APXvYqx94GVdUDrTcKW2jV/708rmTlOCsgxjf8ZLpu3Do0Xa0wJj37iQiT/LLDSmGHasLZp6FMtIQSKbIIWp9Dd+Au8= X-Received: by 2002:a02:ce37:: with SMTP id v23mr18488753jar.2.1561834826262; Sat, 29 Jun 2019 12:00:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sat, 29 Jun 2019 12:00:15 -0700 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="00000000000004b48d058c7b0294" Archived-At: Subject: Re: [Json] JSON Schema Language, Draft 01 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: Sat, 29 Jun 2019 19:00:44 -0000 --00000000000004b48d058c7b0294 Content-Type: text/plain; charset="UTF-8" Hi all, I wanted to provide an update on working tooling I've built on top of the latest draft of JSON Schema Language. I believe the ease with which such tooling can be written can be seen as an important reason why a minimal schema language for JSON is useful. I've made a code generator (jsl-codegen), a schema inference tool (jsl-infer), and a test data generator / fuzzer (jsl-fuzz). They're all open-source and available here: * https://github.com/json-schema-language/jsl-codegen * https://github.com/json-schema-language/jsl-infer * https://github.com/json-schema-language/jsl-fuzz The jsl-codegen tool supports Java, Golang, and TypeScript. It's similar to protoc in the gRPC world, or the OpenAPI code generator tools. The final tool, jsl-fuzz, is similar to the "json-generate" feature in the CDDL tool in: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-F jsl-infer can be seen as the inverse of jsl-fuzz. The small size of the JSL spec means that making tooling like this is rather trivial. jsl-infer and jsl-fuzz are 350 and 150 LOC, respectively. I'm curious if folks have thoughts / criticisms on this tooling? Regards, Ulysse On Thu, Jun 6, 2019 at 8:04 PM Ulysse Carion wrote: > Oh wait, another big change -- I got rid of the URI-based reference stuff. > Thanks to Tim Bray for pointing out it's kind of needlessly complex. > > On Thu, Jun 6, 2019 at 5:18 PM Ulysse Carion wrote: > >> Hi folks, >> >> Working off discussion in this mailing list, I've published a draft -01 >> of JSON Schema Language: >> >> https://tools.ietf.org/html/draft-json-schema-language-01 >> >> Notable changes are the addition of "timestamp" (RFC3339) as a type, as >> well as the addition of enums. The syntax of JSL is now defined mostly >> through CDDL, and an informative appendix maps some JSL schemas to CDDL >> ones. The rest of the changes mostly serve to make the spec easier to read >> and implement, nothing dramatic. >> >> Would love feedback! What more should be removed or added to move this >> forward? >> >> Best, >> Ulysse >> > --00000000000004b48d058c7b0294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I wanted to provide = an update on working tooling I've built on top of the latest draft of J= SON Schema Language. I believe the ease with which such tooling can be writ= ten can be seen as an important reason why a minimal schema language for JS= ON is useful.

I've made a code generator (= jsl-codegen), a schema inference tool (jsl-infer), and a test data generato= r / fuzzer (jsl-fuzz). They're all open-source and available here:

* https://= github.com/json-schema-language/jsl-infer

The jsl-codegen tool support= s Java, Golang, and TypeScript. It's similar to protoc in the gRPC worl= d, or the OpenAPI code generator tools.

The final = tool, jsl-fuzz, is similar to the "json-generate" feature in the = CDDL tool in:


jsl-infer can be seen as the invers= e of jsl-fuzz.

The small size of the JSL spec = means that making tooling like this is rather trivial. jsl-infer and jsl-fu= zz are 350 and 150 LOC, respectively.

I'm curi= ous if folks have thoughts / criticisms on this tooling?

Regards,
Ulysse

On Thu, Jun 6, 2019 at 8:04 PM Ul= ysse Carion <ulysse@segment.com> wrote:
Oh wait, another big change -- I got rid of the URI-base= d reference stuff. Thanks to Tim Bray for pointing out it's kind of nee= dlessly complex.

On Thu, Jun 6, 2019 at 5:18 PM Ulysse Carion <ulysse@segment.com&= gt; wrote:
Hi folks,

Working off discussion = in this mailing list, I've published a draft -01 of JSON Schema Languag= e:


Notable changes are th= e addition of "timestamp" (RFC3339) as a type, as well as the add= ition of enums. The syntax of JSL is now defined mostly through CDDL, and a= n informative appendix maps some JSL schemas to CDDL ones. The rest of the = changes mostly serve to make the spec easier to read and implement, nothing= dramatic.

Would love feedback! What more should b= e removed or added to move this forward?

Best,=
Ulysse
--00000000000004b48d058c7b0294--