Re: [Asdf] ASDF IETF 109 Hackathon (Friday)

Carsten Bormann <cabo@tzi.org> Fri, 13 November 2020 14:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: asdf@ietfa.amsl.com
Delivered-To: asdf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378763A0D17 for <asdf@ietfa.amsl.com>; Fri, 13 Nov 2020 06:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 p7b0RXDO1jhA for <asdf@ietfa.amsl.com>; Fri, 13 Nov 2020 06:29:09 -0800 (PST)
Received: from gabriel-vm-2.zfn.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 C0F843A0D05 for <asdf@ietf.org>; Fri, 13 Nov 2020 06:29:08 -0800 (PST)
Received: from [192.168.217.120] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CXgnt5MMbzyWY; Fri, 13 Nov 2020 15:29:06 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <D63C4657-129C-4512-9A48-AB3C8DDA3221@tzi.org>
Date: Fri, 13 Nov 2020 15:29:06 +0100
X-Mao-Original-Outgoing-Id: 626970546.2029459-0083a0d927fb85175b7a0cf71fc04005
Content-Transfer-Encoding: quoted-printable
Message-Id: <387CA413-3419-4DDC-B06D-6F3B9E288BE6@tzi.org>
References: <HE1PR0702MB38188CC0718362F82974C7B38AE70@HE1PR0702MB3818.eurprd07.prod.outlook.com> <6985F367-2151-4D91-BDAD-94EBB38D0E75@tzi.org> <D63C4657-129C-4512-9A48-AB3C8DDA3221@tzi.org>
To: "asdf@ietf.org" <asdf@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/asdf/vuBN7_rIa8QQTFrgbyS_7BTNbVc>
Subject: Re: [Asdf] ASDF IETF 109 Hackathon (Friday)
X-BeenThere: asdf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A Semantic Description Format \(SDF\) for Things and their Interactions and Data" <asdf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/asdf>, <mailto:asdf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/asdf/>
List-Post: <mailto:asdf@ietf.org>
List-Help: <mailto:asdf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/asdf>, <mailto:asdf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2020 14:29:11 -0000

On 2020-11-13, at 15:21, Carsten Bormann <cabo@tzi.org> wrote:
> 
> I created an sdf-1-1.cddl in branch "1-1" in https://github.com/ietf-wg-asdf/SDF"
> 
> https://github.com/ietf-wg-asdf/SDF/blob/1-1/sdf-1-1.cddl

And here is a narrated diff:

This is a new production that goes into what was pointer-lists in 1.0 and are dataqualities (our extended version of json-schema.org) now in 1.1:

62a63,66
> parameter-list =
>   pointer-list .feature "1.0" /
>   dataqualities .feature "1.1"  ; cddl-tool currently blurts out the value

(The comment points out a missing feature of “.feature” — can’t suppress a diagnostic output of the actual value, which is distracting here.)

This parameter-list is now used for sdfInputData (actions) and sdfOutputData (actions, events).
Note that sdfRequiredInputData is now deprecated in 1.1 (use required in the data qualities); I didn’t catch that one in the CDDL.

65c69
<  ? sdfInputData: pointer-list   ; sdfRequiredInputData applies here (a bit redundant)
---
>  ? sdfInputData: parameter-list   ; sdfRequiredInputData applies here (a bit redundant)
67c71
<  ? sdfOutputData: pointer-list  ; sdfRequired applies here
---
>  ? sdfOutputData: parameter-list  ; sdfRequired applies here
74c78
<  ? sdfOutputData: pointer-list  ; sdfRequired applies here
---
>  ? sdfOutputData: parameter-list  ; sdfRequired applies here


Trying to correct the “units” typo:

82c86,87
<  ? units: text
---
>  ? ("units" .feature "1.0") => text
>  ? ("unit" .feature "1.1") => text

Addition to “allowed-types” (e.g., value after “default”:):

96a102
>               / {* text => any}

Define a group for compound type.
I started to make use of co-occurrence here, so “required” and “properties” can only occur if type=object.  (I will hate having done this when I update the CDDL-to-json-schema.org converter for this; json-schema.org cannot do that.)

98a105,110
> compound-type = (
>   "type" => ("object" .feature "1.1"),
>   ? required: [+text],
>   ? properties: named<dataqualities>,
> )
> 

Use the compound type in dataqualities:

100,101c112,115
<  ? type: "number" / "string" / "boolean" / "integer" / "array" ; / "object"
<            / (text .feature "type-ext")                       ; EXTENSION-POINT
---
>  ? (("type" => "number" / "string" / "boolean" / "integer" / "array")
>     // compound-type
>     // (type: text .feature "type-ext")                       ; EXTENSION-POINT
>    )

Same in the nested “items”:

128,129c142,145
<      ? type: "number" / "string" / "boolean" / "integer" ; no "array" / "object"
<            / (text .feature "itemtype-ext")                       ; EXTENSION-POINT
---
>      ? ((type: "number" / "string" / "boolean" / "integer") ; no "array"
>         // compound-type
>         // (type: text .feature "itemtype-ext")                       ; EXTENSION-POINT
>        )

Comments welcome.
“See” you all in half an hour…

Grüße, Carsten