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

Carsten Bormann <cabo@tzi.org> Fri, 13 November 2020 14:21 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 7C6B43A0C88 for <asdf@ietfa.amsl.com>; Fri, 13 Nov 2020 06:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 elyMZ4gdQ-wA for <asdf@ietfa.amsl.com>; Fri, 13 Nov 2020 06:21:11 -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 CBD6B3A0C82 for <asdf@ietf.org>; Fri, 13 Nov 2020 06:21:09 -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 4CXgch2KLtzyVy; Fri, 13 Nov 2020 15:21:08 +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: <6985F367-2151-4D91-BDAD-94EBB38D0E75@tzi.org>
Date: Fri, 13 Nov 2020 15:21:07 +0100
X-Mao-Original-Outgoing-Id: 626970067.715711-9962bc7350947322daf1ba3dbc9ac442
Content-Transfer-Encoding: quoted-printable
Message-Id: <D63C4657-129C-4512-9A48-AB3C8DDA3221@tzi.org>
References: <HE1PR0702MB38188CC0718362F82974C7B38AE70@HE1PR0702MB3818.eurprd07.prod.outlook.com> <6985F367-2151-4D91-BDAD-94EBB38D0E75@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/o21Z-si4V1gh1KN0lZ61s5KRUF8>
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:21:14 -0000

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

Note that strawman-examples/CAP/sdfobject-motion-sensor.sdf.json still contains a 1.0 style sdfOutputData:

      "sdfEvent": {
        "stateChange": { 
          "sdfOutputData" : [ "#/sdfData/activityState"]
        }
      }

(Which validates with the new CDDL as “1.0”.)

strawman-examples/Bluetooth-Mesh/sdfdata-sensorstate.sdf.json has a weird “properties” value that seems to try being a compound type:

      "properties": {
        "SensorDataType": {
          "type": "array", 
          "items": [
            {
              "type": "array", 
              "items": [
                {
                  "sdfRef": "#/sdfData/PropertyIdType"
                }, 
                {
                  "sdfRef": "#/sdfData/SensorData/properties/SensorDataRawValueType"
                }
              ]
            }
          ]
        }, 

There was also a minumum and a Funciton in exploraty; I have repaired those.

To be fixed:

strawman-examples/IPSO/sdfproperty-generic.sdf.json
** Features potentially used: subtype-ext: ["float”]

Is this a proposal?

strawman-examples/IPSO/sdfthing-ipsoVacGauge.sdf.json
** Features potentially used: thing-ext: ["productTypeListing”]

We probably should discuss which of the following are fluff and which are actual proposals:

strawman-examples/OCF/sdfthing-ocf-airflowcontrol.sdf.json
** Features potentially used: object-ext: ["semanticTag", "name"], thing-ext: ["name"], data-ext: ["sdfEnum", "name”],

(I think we replaced “name” with “label”, no?)

This is at the wrong level (these should be parallel to “items”, not nested in them:
items-ext: ["minItems", "uniqueItems”]


Do we want the data quality to be “unit” or “units”?
(I have changed this to “unit” for 1.1 — a bit of Brownian motion, maybe, but a good opportunity to fix this.)

There is also a “scaleUnit” in strawman-examples/ZCL/sdfobject-onoff-v7.sdf.json; is that the same as “unit” or something different?

There are also a few sdfEnums I haven’t examined more closely.

The playground validates as “1.0” with the new CDDL.

Grüße, Carsten