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

From: Niklas Widell <[email-masked]>
Date: Thu, 12 Nov 2020 18:52:46 +0000

Hi, 
Wrap-up session for ASDF hackathon, at 1500Z

Cheers, 
Niklas

ASDF Working Group invites you to join this Webex meeting. 

Meeting number (access code): 178 889 4557 

Meeting password: JmPZPQia733

Friday, November 13, 2020 
7:00 am  |  (UTC-08:00) Pacific Time (US & Canada)  |  1 hr 

https://ietf.webex.com/ietf/j.php?MTID=m67db933abf3375c6e4f7d17b670e1aef

Tap to join from a mobile device (attendees only)
tel:+1-650-479-3208,,*01*1788894557##*01* Call-in toll number (US/Canada)

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
https://ietf.webex.com/ietf/globalcallin.php?MTID=m67d4cc71b9b570ec3f643bf966cf048b

Join from a video system or application
Dial  sip:[email-masked]
You can also dial 173.243.2.68 and enter your meeting number.

Join using Microsoft Lync or Microsoft Skype for Business
Dial  sip:[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Nov 2020 00:27:27 +0100

I have now put in the pointer checker into the CI of the exploratory repo.
The universe currently is exactly that repo (i.e., all *.sdf.json files in there).
You can, of course, manually call the pointer checker on a larger or smaller universe (see run.sh for how).

I have fixed all the reference problems in the repo, except one, where I have no idea what was intended.

The travis-CI build (*) is currently queued, but here is a sneak peak of the output of the checker:

---
:missing:
- :ref: https://onedm.org/exploratory/#/sdfProduct/SKU_19934774/sdfObject/>>3300~10<<
  :fn: "./strawman-examples/IPSO/sdfthing-ipsoVacGauge.sdf.json”

This is a terse way of saying that 

strawman-examples/IPSO/sdfthing-ipsoVacGauge.sdf.json

is trying to reference (curie expanded):

https://onedm.org/exploratory/#/sdfProduct/SKU_19934774/sdfObject/3300~10

All the tree except the last entry in the path is there, so that is marked in the message with >> <<:

https://onedm.org/exploratory/#/sdfProduct/SKU_19934774/sdfObject/>>3300~10<<

(It could also say that we have HighRangeSensor and LowRangeSensor but not 3300~10, but that would be bordering on catering to the weak.)

See you tomorrow/tonight!

Grüße, Carsten

(*) https://travis-ci.org/github/one-data-model/exploratory/builds/743296587

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Nov 2020 15:21:07 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Nov 2020 15:29:06 +0100

> 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

---

From: Michael Koster <[email-masked]>
Date: Fri, 13 Nov 2020 06:59:46 -0800

I just merged a PR to fix most of these

> On Nov 13, 2020, at 6:21 AM, Carsten Bormann <[email-masked]> wrote:
> 
Fixed 
>                  "sdfRef": "#/sdfData/SensorData/properties/SensorDataRawValueType"

This may need to be revised now. It's supposed to model the application-visible contents of the Bluetooth data record format.

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

Thanks!
> ** Features potentially used: subtype-ext: ["float”]
Removed
> ** Features potentially used: thing-ext: ["productTypeListing”]
Removed
> (I think we replaced “name” with “label”, no?)
Replaced all "name" with "label"

> items-ext: ["minItems", "uniqueItems”]
Oops... fixed
> (I have changed this to “unit” for 1.1 — a bit of Brownian motion, maybe, but a good opportunity to fix this.)
Unit is good

> There is also a “scaleUnit” in strawman-examples/ZCL/sdfobject-onoff-v7.sdf.json; is that the same as “unit” or something different?
I think we can use unit here and figure out some scale modeling that makes sense like powers of 10

> -- 
> ASDF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/asdf