# WISHI virtual meeting
July 15th (Tuesday), 7:00-8:30 PDT (16:00-17:30 CEST)

https://github.com/t2trg/wishi/wiki/Agenda-items

Attending (your name here):
* Ari Keränen
* Carsten Bormann
* Klaus Hartke
* Christian Amsüss
* Ines Robles
* Ivaylo Petrov
* Michael Koster
* Michael McCool
* Milan Milenkovic
* Russ Housley

Draft agenda:
* WISHI related activities at IETF 105
- CoRE Applications side meeting
* [WISHI hackathon at IETF 105](https://github.com/t2trg/wishi/wiki/Preparation:-Hackathon-Planning#planned-hacking-topics)
- Data Model convergence and automatic translation with OneDM and W3C WoT TD
- CoRAL and hypermedia for IoT
* WISHI [research planning](https://github.com/t2trg/t2trg.github.io/wiki/Research-Agenda)
* Modeling data and interaction
* REST-based hypermedia
* Connectivity for IoT
* In-network and edge computing
* Security
* Terminology

# CoRE Applications side meeting

Klaus: Was CoRAL side meeting in Prague. Will be similar in Montreal. This time focus wider: CoRE apps in general. In particular proposal for pub/sub broker improvement that's interesting to discuss; new proposal uses more hypermedia and CoRAL. Small design team so far for the proposal but would like to modernize API descriptions.
Meeting on Tuesday IETF week, right before CoRE.

# WISHI hackathon at IETF 105

McCool: short intro to SDF?

MJK: SDF is JSON format, DSL based on JSON. Semantic definitions for devices. Planning to use as front-end for iotschema definitions. OneDM want to go to high level of details for devices. Events, actions properties wrapped in objects.

Ari: link to SDF in the IETF 105 hackathon page

MJK: moving now issues etc to the official repo

MJK(in the chat): https://github.com/one-data-model/language

MJK: goal in hackathon to take JSON format (SDF) and want to create tools that can be used to put to other formats. In particular RDF. JSON schema processor that is able to take JSON schema and pull out matching fragments of schema. Idea is to be able to generate Thing Description that is protocol binding. CoRAL can be a protocol binding, OCF can be too. TD is definitely; want to work on that. Do TDs that are annotated with OneDM. Also iotschema definitions as OneDM. Particularly CoRAL interesting. Also OMA becomes LwM2M protocol binging. Already 4 well known open source stacks we can experiment with.

Ari: also LwM2M TD generator.
MJK: can annotate TDs with OneDM now
...
MJK: plan to take things from OneDM and bring to iotschema; depends how licensing works. Could take IPSO numbers and use that to index.
Ari: also will have a look how

Russ: you're building catalog, similar to YANG catalog.
MJK: object definitions would be interesting thing to look at. Some WISHI participants looking into YANG.
Russ: for yangcatalog.org different orgs contributing. Operations on that site transferred to IETF secretariat. If this things gets similar maybe that's a path forward.
Ari: Ivaylo has been looking into YANG
Ivaylo: will have a look at the catalog
MJK: when have translation can just automate things -- bunch of device definitions in this format and could have access to in the yang catalog.
Russ: if this format is registered, could do something similar as yang catalog. For OneDM one of the big questions is how these are published. Licensing issues etc.
Russ: yang catalog sorted that so that IETF trust and IEEE are happy with that
MJK: interesting to look at the model
Russ: even non-open orgs who want their model files publicly accessible. Like code fragments in RFCs.

Carsten: Objective of CDDL tooling to find places in various forms that use data description and make it available in CDDL form. Hopefully in both directions. Wrote converter for JSON-schema.org -04 (old but most used version). Mostly works. When done with benchmark of iota want to apply other places too to see if we can get good CDDL out of there. Good to see if we can CDDL as tool for describing models. RFC8610. Want to make also JSON representation so that tools don't need to make parser for CDDL format. Tools could be useful for looking into models with data description in them. Plan to have gem like existing CDDL. Probably need one more day of coding. Tomorrow or hackathon.

MJK: have bit of nodeJS code that functions as selector with schema fragments. Not much stuff working yet or before Saturday. Can send a pointer.

Ari: CoRAL hacking?
Christian: no full plans yet; maybe
Ari: RIOT OS Leandro planning to join remotely. Would be great to have CoRAL / CoAP hypermedia client.
MJK: interesting to have something like API generating part where you can plug in sensors. Even a library that would use CoRAL. Semantic annotations that make things easy to use.

Ari: any discussion topics? Pub/sub broker design was one.
Klaus: yes, way too many
MJK: ways to use and extend REST

# Research agenda

MJK: metamodel between data and interaction. How we map to consistent way to hypermedia so that don't have to pass schemas around. How to create robust hypermedia model. How to use forms for actions, all that. Modeling data and interaction - the interaction important.

Cabo: timely discussion because Klaus brought up that we're still writing RFCs with stone-age tech. Want to get better there.

MJK: CDDL part of that as well. See primarily CDDL/CoRAL and connected to high-level tools like iotschema. How we build robust run-time stack and use that with hypermedia controls. Also how we bend/extend REST while doing that.

Carsten: if using CoRAL as language for hypermedia objects, do we have a way to abstract away instance info so that can get classes of objects? So that can exchange data and describe something in spec? Coral is great for providing instance of hypermedia object. If want to describe collection of similar instances, how do you turn CoRAL description into class.

McCool: looking at same thing in WoT. Have templates. Good to look at general category. Which elements should be instantiated, etc.

MJK: key to be able to generate interaction model over protocol binding. What building in OneDM and iotschema is high level classes. Need to make protocol bindings from that level. And create control information; invoke action that may have rich response. How can be create classes and map those mechanically.

McCool: often instantiate devices from categories. OCF has resource types and capability model that used together to create a device.

MJK: OCF has lots of standard practices, boilerplate to create Swagger. Classes map to interface patterns but more generic pattern like how to do sensing -- OCF doesn't have to define brand new resource types since it's 90% boilerplate. Same thing with CoRAL; what are the common patterns that get mapped? How you abstract instance data to classes? Probably small set of classes that define how patterns work. How to track long running action and get status back for example.

Klaus: useful to explore questions like these in concrete cases. Like Carsten's coffee machine. Have been writing down description. Could share class examples from here. Idea to model coffee machine as bunch of resources. Menu resource tells that the machine is capable providing. Order as collection resource; one or more items there currently brewed.
Interesting point that ended up writing lots of boilerplate text repeatedly. "If authorized to coffee menu provide this link" etc.
...
Different clients get different CoRAL docs. Similarly for order, depending on state get different links. Is this class description? If yes, can we do better than boilerplate descriptions?

MJK: interesting way to look at this. It is repeating pattern of all hypermedia controls. Could be interesting trying to generalise this to common description. This is the level we need to model things. Interestingly also partial functional description

Klaus: this is what Fielding tried to capture in state transfer. Really modeling a state machine and state transfers.

MJK: really good example of hypermedia REST state machine. Also why Swagger file is not a real REST API description. Does CoRAL file capture this?

Klaus: CoRAL doc gives you precise description of the current state of the coffee order.

MJK: each state would have set of hypermedia controls; if has ability to do that would describe it

Klaus: get description of state and list of affordances that enable to change the stae

MJK: part what needs to be standaridzed are the affordances and how they work. High level pattern probably the only pattern. Affordances and state machine of what affordances are available.

Klaus: in the end different levels of hypermedia. Perfectly valid bunch of links and forms that are not applicable to current state and then have out of band knowledge when it's OK to invoke one or other. But if want real high level hypermedia the approach is to have only actions applicable in current state and desribe possible future states. That would be pure hypermedia.

MJK: real devices have more than one of these going on. But captures the fundamental pattern really well. In terms of research we should remember this what we mean by the hypermedia part of what we are doing.

Ari: could work on this at tha hackathon continuin dscrip and build clients to act on

Klaus: one thing would be to get CoRAL based app to work during the hackathon but also very interesting to use different modelin techs like IPSO and OneDM to model Carsten's coffee machine. Already have SPLOT from Robert Q of Carsten's coffee machine. Could make more of those implementations and compare how the coffee machine looks like.

MJK: very interesting. Could also look into Vorto if that provides something. OneDM and TDs are very static models and don't have capabilities to describe in convenient way. Interesting area to have a look at.

Ari: generating code with Vorto? or something else?

MJK: does Vorto have capabilities to model state machines? Enountered at SmarThings when modeling devices. All really ad-hoc. Once info-science and representing as state machine -- consistency and simple meta models -- how do we describe state machines. Maybe Vorto with function blocks may have some secret sauce here. But would not know how to use it but could investigate. Motivating factor to bring Vorto to picture. Even something like Swagger could do this since it has the primitives, but not to all links and forms. Could model something like CoRAL, but since CoRAL has strucuture workin on that could look at other things, like OneDM and how would TD look like if we convey that information in TD for example.

MJK: another food example: media controls that enable you to search media but have play button. When playing have stop and pause. Sometimes only other. All those things needed to accommodate dynamically. Describe what things are currently accessible. Common problem and we could use that as example why hypermedia is fundamental for machine control.

Ari: also interested for IIoT use cases

MJK: do we need to define more models or build testbeds? Or all above?

Ari: all above but depending how deep we want to go to legacy integration

MJK: idea of pressure test to see what can you do and what not. Interested in testing the models against the use cases.

Ari: could take some of the existing models we have in this space and perhaps some of the OneDM models being done.

Milan: could suggest something related to Singapore meeting. Met mr Chinn who is leader of singapore smart nation work. Have very much interest in this kind of things. Is there interest in creating a meeting and having a discussion there? Integrating data and systems. Could do joint development. Idea would be primarily to get input from large complex area with multiple domains. Could take action to work with Ari to arrange meeting.

Ari: yes, planning something here already

Carsten: to really build classes we like to do things like odd and even number doors and build predicates out of data we have somewhere. Quickly grows to full-grown programming language. Is there something we can adopt?

Ari: probably in the RDF/semantic web world something done.

Carsten: anyone can come up with something in an afternoon; how do we avoid coming up with yet another one.

Ari: would need to do some landscaping

Carsten: probably talk to people who have done programming languages and ask what has worked and what hasn't

Ari: would be good to check before IETF (but short on time now)

Carsten: example of related thing; in CDDL needed regex language. There are 10 of them. Not easy to focus on just one. In YANG world schism since some are using W3C regex and others pattern statements with different regex (posix?). One can waste lots of time on things like that.

McCool: wonder why not single schema langauge for XML, JSON, CBOR, YANG.

Carsten: YANG is a schema language

McCool: lots of interop issues in payload encoding different ways. CBOR, YAML, XML etc have similar constructs. What would be master schema to describe these all. Currenly JSON schema used in various forms. Used to describe non-JSON too but that' s not really correct. Need more inclusive schema language.

MJK: need schema langauge that allows avoiding corner cases

McCool: need a few tweaks to make each more interoperable. Need able to describe all 4 possible payloads with a single lang. Give prevalence of JSON schema could make sense to extend that.

MJK: adding additional keywords to extend JSON schema, to get fields etc in OneDM

McCool: should be in standard.

MJK: we're making language that hopefully would be usable in JS processors.

McCool: callin "data schema" since take JSON schema and extend to code data. Should be official activity for JSON Schema. Need standardized extensions.

MJK: first libraries and then get integrated

McCool: let's discuss at the IETF

MJK: the modelin item Carsten has been talking about. Universal modeling language.

McCool: don't need everything but structural aspects of these 4 encodings. Would make easier to describe like TDs with different payload types.

MJK: could do small scope thing. But also been discussing classes etc that's a bigger problem.

McCool: for steps forward let's find the small steps for way forward. The small step: common data schema. That's valuable. Time to get together and do it right.

MJK: when lookin at programming languages we have tons of types, and then unions etc that not part of JSON. Not sure how much of that needs to be done but part of discsion. Common data model discussion useful.

Carsten: there are modeling languages out there in the wild. For structural interop have been using BNF for long time. That's why CDDL structured on BNF. Reasonable theorethical foundation. Set of lego blocks that versions of JSON schema org do is kind of random. Would be good to define the lego block with something more fundamental.

McCool: both CDDL and JSON schema reasonable starting points. Think that CDDL has defined own grammar that needs a new parser. Rather to see JSON based format. All metadata descriptions based on JSON. Would like to see JSON serialization of CDDL.

Carsten: part of tool workin on

McCool: CDDL has the extra things to work on CBOR, but also would need XML payloads.

Carsten: not sure of XML. Rather bizarre generic structure. Anything that can describe XML tree is going to inherit some of the bizarrenes.

McCool: content and attributes doesn't map nicely

Carsten: people using XML for years say that's a superfluous feature of XML

MJK: ...

McCool: short term goal: extend TD to cover OPC-UA. They have XML. How we write those schemas in TD. Currently use JSON schemas. Pretty sure we'll run into problems.

Carsten: Relax-NG? (ISO 19757-2)

McCool: currently embed things in TD. That part of problem. Issue is that want one way to write schemas that map the types. Also need to express concepts in OPC UA schemas.

# CoAP transports design team

Klaus: will be slot in summary meeting for transport

Carsten: what ever transport DT does will reflect in protocol bindings.