View source for Breakout topics 12-04-2016 13-04-2016



=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 [http://w3c.github.io/wot/current-practices/wot-practices.html#thing-description])

- 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.