ASDF 110 meeting minutes

CodiMD for notes



All ASDF notes at:

jabber count: 30 entries, 24 unique people,

Introduction, meeting logistics, agenda bashing

Note takers, jabber scribe

note takers: Michael Richardson, Ari Keränen,

ASDF Outreach

Have been doing outreach to various orgs (OMA, ISO/IEC, W3C WoT, ...). OneDM was inclued in recent IIC white paper.

Happy to hear from other orgs working in this space!

Hackathon Results

Niklas gave overview of the hackathon; more details coming at the T2TRG meeting in 4 hours.

ASDF status update (chairs)

Chartered October 2020! (not 2021)

SDF 1.1 -- Implementation Draft call for consensus

- concluded March 9.

Had call for consensus for implementation draft; concluded without objections. Minor comments to be addressed.

Three PRs: - IANA considerations - info block required part of syntax? Often TBDs in the blocks during development time if required (as currently). Suggesting to make info block optional. - Clarifying scaleMin/max realized they don't work exactly like intended with mapping. Details to come later today. Suggesting to have them only in 1.0 version of SDF (models in OneDM playground not using these yet). First activity will come up with right quality to support this properly.

None change the format in way that tools that create/consume SDF need to change.

Michael Richardson (MCR): interested do discuss min/max issue with the detailed slides

Ari Keränen (AK): first PR obvious thing to do, the second seems useful, third probably benefits from more discussion

Carsten Bormann (CB): in OneDM have linter that can be more strict than the grammar

Michael Koster (MJK): on info block, one useful feature is version. Early wanted to track contributions. Copyright would contain information. Optional info block should not get in way though.

Niklas Widell (NW): some investigation needed on merging copyrights; machine readable license and TOS useful. First PR simple, second PR has some things for consideration but doesn't break anything, third technically more complicated. Takes some time to solve. Good to sort out the details in so we can finish 1.1 now.


MCR: making optional does not eliminate issue if it'f present how to merge. Need to solve still. If someone has put info block don't lose the copyright info even if block is optional.

AK: seems to favor making info block optional so that have mechanism to say "I don't have anything useful to say here".

NW: may need some text on merging

MJK: some early discussion on this, but the approach here seems correct. On scalemin/max models would still validate as 1.0. Can also be experimented as mapping file entry. Can be used as our first experiment here.

NW: hear that 2 and 3 have side effects, but would work to do the changes as suggested. And can get going solving the problems in the next cycle.

AK: could take a poll on the #3 after detailed presentation

NW: can take 1 & 2 as accepted now and come back to 3 later today. Any objections?

(no objections)

discussion about scaleMin/Max

skipped to slide 23, for discussion about scale-min/Max.

Carsten explained issues on scaleMin/Max and plan for

JSON schema has perception that describing things on the wire. However in SDF describing information model ("physical side") here. No single standard for digital representations, e.g. of temperature.

(should be deciKelvins insted of centiKelvins in slide)

"digital numbers" (on wire) should be provided by mapping file. Question is which side should get JSO min/max keyword. In playground min/max seems to be used for physical quantities.

One issue: JSO probably wants to stay in I-JSON constraints for values but IEEE 754 has been designed so that it's not problem for most physical quantities.

MCR: JSO side now would have to set filters etc on the physical side, not digital

CB: people actually seem to be using on physical side.

CB: proposal is to attack the digital side in version of SDF to enable new scaling. This is not a change but just acknowleding scaleMin/Max would cause issues we don't have to tackle in 1.1

MJK: in thinking through this more seems we have more discussion to do. In SDF have physical quantity, scale*. In actual system SDF file might have quntity min/max and in protocol side have converted to suitable JSO. Insted of reusing JSO for physical side could have something else too. But that's for

NW: for finalizing SDF 1.1; with the suggested PR we can postpone the problem to

CB: yes, we're not changing how people are using these and have gathered information on where we want to take this.

NW: any objections folding in the proposed changed for scaleMin/Max? Or need to discuss more? (PR 3)

(no objections)

NW: seems we're OK merging all three and publishing new version of the draft.

(request to be able to send heart-emojis in Meetecho)

CB: will take about one hour to merge the changes and publish -04

ASDF Issues

NW: are looking into new features for SDF. In addition to what discussed today, more issues discussed last week. Now discussing 3 things to be address in next version of SDF.

Properties/Actions/Events (P/A/E) and scaling

Slide 17.

CB (presenting): The types (T) are in general the same. How reading/writing is done (REST, message queue), is not relevant here. Property can be written/read/observed. Action is something you throw input data to, something happens in physical world, and then you get something out. Similarities to RPC but not necessarily same. "Making a coffe" typical example. Event puts out data of certain type; not much different from property. Don't say if getting needs to be solicited. Only thing defined about events so far is they throw data at you.

In industry very different concepts mashed together in Events. For example door bell press can be event (not changing state of the door bell). We should focus our discussion on "genuine events". SDF 1.1 is fine as it is but it just doesn't tell what kind of events are provided.

Sensor value with threshold alarm is non-event. Historical data is something to tacle in next version of SDF but not really event.

Observable in SDF is not the same as CoAP Observe. Does not imply readable. Read/Write/Observable are independent. Many pub/sub style affordances are SDF observable in that sense. Should not use Event when Observable is the right model.

sdfAction looks fine, but pressure testing TBD. Can't model spawning P/A/E yet; further work to be done here.

MCR: e.g., ask coffee maker to start making coffee and that spawn something that has controls on it

CB: yes, progress property that goes away when action is done.

Michael McCool (MMC): cancellable actions example we've seen. Played with returning new TD for such. Here could be returning new SDF.

CB: cancellable parallel actions example would be good (better than coffee machine example)

NW: seems more details & functionality for sdfAction in future needed but can remain as such for the current spec.

MMC: have separate data model in TDs; action would be used for subscribing?

CB: maybe want to implement new functionality for that

MJK: subscribing and unsubscribing might belong to protocol binding

NW: different actions can be cancellable (or not)


MJK (presenting): SDF definitions are protocol neutral. Can have semantic interop across ecosystems. "Mapping file" catch all term for separating protocol specifics. Augmenting SDF definitions (see slide 33).


Juan-Carlos Zuniga (JC): trying to figure out if want to have semantic def for binary data on wire. E.g., not byte-aligned data. How would mapping work out?

MJK: have few examples of raw models. Packed array of items. Can size each item. Have in bluetooth example of widthinbits. Can describe the full mapping.

MJK: next need to do pressure test with these features. Need to introduce extension schemas and mapping formats. Probably need to be separate drafts to spec these.

MJK: (one more thing) value scaling likely going to be big thing for interop (slide 40)

NW: makes sense to have as separate spec from the SDF spec

CB: very good talk that leads to question how we pursue this kind of work. Next virtual interims?

NW: in mapping files need good understanding of what different ecosystems need. We know quite well for IPSO and OCF, but could come up with template cases of how to map to different ecosystems.

MCR: seems we need 3 things: 1) what we need to clarify befor we can do mappings 2) what is the work needed to generate mapping specs 3) what are example mappings. Need to do some of that work before virtual interim to discuss about it.

MJK: in TD examples could be as simple of providing data schema elements and (protocol details?). For OCF maybe need to intro swagger files. Will there be common ontology for protocol bindings? In WoT each binding is separate ontolgy. Easy way out to use those patterns.

NW: will work on some examples. Hackathon oriented meeting could make sense here. Should have interim ~month from now? Week of April 12th?

CB: mid April might be right thing with hackathon before that.

NW: will do a doodle. After Easter hackathon. Goodd if MJK can throw out strawman proposal.

MJK: not maybe read for I-D but next step would be making a little bit more documentation now. And see what others have done.

NW: have way forward; doodle going out soonish.

AK: could also look into expressing relationships between things and objects.

MJK: thing model that worked on would benefit a lot from such

AK: could be mapping file concept, SDF concept, or something else

SDF Compact

CB (presenting): SDF is optimized for tools, but need ways to help humans use it too. Example from XML: Relax-NG compact designed for whiteboard use of XML. Question came up during hackathon: can something similar be done with SDF?

Slide 44 showing example from slide 43 in proposed "compact form".

For example "r-o!" means readale and observable and required.

Plan to complete the implementation and publish the tool in April. This could be informational doc along with SDF spec (that is normative).

MCR: is intention that this be round-trippable

CB: yes; in this case doesn't make sense to have compact format that doesn't have that.

MJK: was idea of building visual code / atom handler. If want to see JSON can see that but can use this while developing.

AK: seems like useful addition to our toolbox. Could be considered as one of the "ecosystems" we provide translation to. Would expect the JSON format to be used for tools still because of wide availability of JSON tooling.

MJK: good to collect these tools together

MCR: can have tools in Github org or provide pointers

NW: will be sending a doodle for the interims.

(meeting adjourned)

Future planned Virtual Interims