TD Breakout 1 (12th of April)

Participants

Sebastian, Dave, Matthias, Kajimoto-san, Michael, Victor, Taki, Naka-san

Topics

New TD structure
TD templates and collections of things

Minutes

New TD structure
- Sebastian reports on changes

Implications of current structure
- Dave: How does the script select a specific property?
- Matthias/Mike: URI is just the handle in the background

TD tempalates
- How should manufactuerer prepare the TD?
- URIs will be specific
- Matthias: Relates to the lifecycle of the TD we briefy discussed in Nice. The information in the TD will grow during the different lifecycle phases.
- Could use something liek macro pre-processing on the thing, or the $variable style string processing from PHP
- Only works for pre-known values, cannot create new nodes
- There should be a generator for the TD, since JSON-LD is only one serialization, there might be others.
- Things might have an internal structure (maybe like DOM in browser), which allows to update information later.
- Might be even more dynamic changes when TD is in a managemnt system
- focus on TD on device for now, since we have not defined the lifecycle yet. Later, there might be need to patch in lots of metadata in some management repo.

- Two appraoches:
  - Code first: Framework could provide means to add resources and prompt for TD field values and then generate TD
  - TD first: TD can construct code stubs; might also be useful to instantiate thing proxies

collections of things
- one thing - multiple interactions
- one thing - array of identical interactions
- multiple things - identical interaction
- multiple things - heterogeneous interactions

TD Breakout 2 - TD&AP: Protocol Mapping

Participants

<all>

Topics

Data type and restrictions
implicit vs explicit assumptions in TD

Minutes

Data type and restrictions
- Sebastian shows usage of XSD types in TD
- ... No support for complex types
- ... Should this be part of encoding or where?
- Matthias: problem of tight coupling when we enforce internal representation, that is, implementation details
- ...
- Schema.org has a type system with restrictions
- Named types
- Johannes: Would this be a working concept?
- Dave: What about sets? They don't have them...
- Johannes: We can build this from these scalar types.
- Dave: What about precision?
- ...
- We can add more properties to these scalars to make them fit our need.
- Agreement on "Let's use schema like solution for our data type problem".
- Sebastian: Agree on the abstract way to define values, but allow for restrictions such as min, max to be more specific. Need to check if this is enough
- Dave: Also have precision in this model.
- Victor will work on a proposal.
- Johannes: Let's now look at how to build
- Daniel: JSON schema does not work for XML
- Johnnes: RAML 1.0 has a generic way to describe schemas, like a minimal meta-schema
- Mike: Arent' they using Schema.org
- Johannes: 0.8 was Schema.org only, 1.0 now can support multiple schemas
- Mike: Can this describe multiple elements in some kind of structure? Should we restrict to describing maps? Would make things simple.
- Johannes: Need to make sure it works with multiple encoding, JSON, XML, etc. Let's go for the most simple solution and extend it when we hit a deadend.
- Sebastian: Let's investigate how abstract we can make data structure descriptions. Taki, could you look into this?
- Dave: What about more restrictions across multiple values?
- Daniel: Not even possible in XML
- Dave: Integrity constraints
- Victor: It does not need to be part of the TD. There can be other channels to validate, check, etc.
- Dave: Roadmap to have this
- Johannes: The decision does not restrict us from doing this in the future. We need to think about this, but there is no need to solve this right now.
- Sebastian: Let's separate this into another discussion.
- Prepare
- Matthias: Let's not rule out other schema concepts compeletely.
- Kaz: The UPnP data model was integrated into OCF. So this might be a place at which to look.
- Victor: Schema.org is nicely integrated with JSON-LD
- ???
- Daniel: XSD was what we started with, so it might be a problem.
- Sebatsian: XSD is also a schema.
- Dave: This will be hidden in the context anyway.

implicit vs explicit

- Sebastian: Properties have the implicit assumption that you need to do a GET on them.
- ... We coud have a field explicitly stating it needs to be a GET.
- Mike: What if it is MQTT and it should be Subscribe? Should this be a hypermedia control?
- ... Media Type? I imagine that the hrefs point me to another Media Type that will tell me the hypermedia controls (links, forms).
- ... It might be bad if I have to give up this flexibility when the TD instructs something directly.
- Johannes: We experimented with this in the first Plugfest. It did not solve the problem: "what should I expect when I get there?"
- Mike: Media Types would be my prefered way.
- Matthias: If we leave "TD land" at this point, we need to fully understand what comes behind, e.g., "OCF land"
- Mike:
- Johannes:
- Dave: Communication metadata
- Johannes: Not everything goes into the TD.
- Dave: I would like to work in parallel on the different aspects. People have different interests.
- We need to at least focus this discussion on a specific issue. We decided on discussion ways to provide explicit information for clients how messages are constructed.
- Mike: OCF uses both PUT and POST for Create
- Matthias: If we have one action that requires a POST and another action that requires a PUT (because that is how the server/platform/thing is implemented), we need to express this in the TD.
- ...
- Mike: The information might need to go into the binding.
- Sebatian: Could introduce binding-specific context.
- ...
- Johannes: 2 possibilities:
- ... Generalize the different message types / protocol methods into a common abstraction used in the TD
- ... Define binding configuration structures that are linked for each case (OCF CoAP, LWM2M CoAP, Nice Plugfest CoAP)

- Volunteers for analysis:
  - MQTT: Mike, Soumya
  - BLE: Louay
  - OCF: Mike
  - BACnet: Matthias

- Volunteers for implementations:
  - CoAP: Matthias, Kazuaki, Daniel
  - HTTP: Mike, Louay
  - BLE: Louay

TD Breakout 3: Explicit Protocol Binding on BTLE as an example

Participants

Sebastian, Dave, Matthias, Kajimoto-san, Michael, Victor, Naka-san, Louay

Topics

How to represent BLE protocol in TD?

Minutes

BLE/Homekit demo by Louay
Quick review of GATT (services, characteristics, attributes, ...)
Strawman for BLE-based TD
Action items:
- Create GitHub Wiki
- Document progress on all explicit Protocol Binding information (HTTP, CoAP, BLE)
- Identify and discuss common issues in abstraction
- Wiki also used by data type and restrictions task force (Victor, Daniel, Taki)

Proposed topics for breakout sessions

- discussion about new TD structure (also see [1])

- how to define (complex) data types and type restrictions in TD?

- discussion about a commmon vocabulary for TD

- ...

Dave suggests we consider clarifying the formal type system, and integrity constraints as a basis for robust operation. This can be formalised independently of the syntax for serialising data models. In essence, we need to allow for a superset of the types used by common IoT platforms.