W3C

– DRAFT –
WoT-WG - TD-TF

22 September 2021

Attendees

Present
Ben_Francis, Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Fady_Salama, Jan_Romann, Kaz_Ashimura, Klaus_Hartke, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian/Ege
Scribe
kaz, mjk

Meeting minutes

Sebastian: announced Klaus Hartke has joined Siemens

minutes

<kaz> Sep-15

Sebastian: any objections to approve the minutes?

no objections, minutes approved for publication

plugfest

Sebastian: focus on functional testing

TPAC meeting

Sebastian: collecting topics for TPAC

Sebastian: we have the thingmodel and SDF topic

Sebastian: any other topics:

McCool: versioning topic wrt. TD versions, forms optionality, as part of 1.1 to 2.0 topic

Cristiano: how to reduce verbosity of TDs
… reduce duplication, etc.

Cristiano: will collect some examples and pointers

<benfrancis> https://github.com/w3c/wot-thing-description/labels/Defer%20to%20TD%202.0

Ben: re-assess issues wrt. 1.1 to 2.0 transition

PR #1232

<kaz> PR 1232 - Add queryallactions operation

Ben: it adds another operation for queryall ongoing actions
… like we already have for events etc.
… it is a gap in the protocol binding

Sebastian: any comments?

Ege: what happens if an action isn't queryable?

Ben: we need to discuss default payloads for the new operations
… how the composite data schema is assembled from the individual source schemas
… there is more work in progress on new section that describes these payload constructions

Sebastian: it's a big topic and we will handle it separately

Sebastian: any objections?

PR #1230

<kaz> PR 1230 - [editorial] fix wrong or missing use of code brackets

Sebastian: typo

Ege: there were some extra quotes

Ege: we need to close the branch when it's merged

Sebastian: objections?
… merged and deleted branch

PR #1207

<kaz> PR 1207 - WIP: Updates for TM Chapter

Sebastian: addresses the subsystem design pattern

Sebastian: uses link relation "subthing"

Sebastian: comment from Jan that sdfObject is similar
… may introduce a "tmObject" term for this pattern
… works with tmRef

Koster: probably add a link to SDF
… and add notes
… need use case where sometimes hierarchical
… would support both
… the language should allow both
… still need some best practice
… need to provide some guidance

+1

Sebastian: link concept for SDF as well?

Koster: yes
… don't see many examples yet
… OneDM working on reusable examples
… the best example would be OMA spec works
… probably need to add links
… also hold relation type
… focus on model

Jan: agree with Koster

Jan: do we also need to map a tmObject to a flattened TD?

Sebastian: each object could have its own TD, but you could combine them

Sebastian: the object only seems to make sense as a TM concept

Koster: we need to figure out the pattern for hierarchical objects that have properties

<benfrancis> https://github.com/w3c/wot-thing-description/issues/1078

Ben: there could be a lot of types of link relations
… issue #1078 covers this
… can we put a link in a spec that says a TD implements a particular TM?

Sebastian: this is on the list for TPAC, the linking approach as well as object
… how do we generate the TD?
… two subtopics: links + objects in TM, and how to generate objects in TD

issue 1205 discussion

Ege: just returned, need more time to address it

bit mapped data

Cristiano: how do we express bit fields in a schema?
… also there is some other type information that is sometimes needed (sign/width)
… also scale multipliers
… issue #1220

<kaz> Issue 1220 - Specify sub-byte semantics

Ege: we need to map this to things we already have in the schema

Koster: in SDF we mapped things to schemas and added a small extension to flag the bit-map

Kaz: the TD should express the canonical data model and let the device (or intermediary) binary mapping, maybe in a binding template extension

Koster: like a protocol binding for schemas

Cristiano: we need to look at the specific cases of API descriptions that might need these features

Sebastian: it's a payload binding, like the SenML discussion we had last week

Sebastian: more on the bit level

Koster: maybe a general case of payload binding, information model vs. data model

Sebastian: hand the meeting over to ege

Binding

Ege: main point is restructuring

PR 123

PR 123 - WIP: Restructuring the Main Document

Ege: changed introduction
… split it into 3 parts

Preview for PR 123

Ege: changed Section 4 too

Ege: (goes through section "4.1 Protocols" then "4.2 Payload Representation")
… "4.3 Platforms"
… lists Philips Hue, ECHONET and OPC-UA as examples
… Example 10 shows SenML exmaple

Example 10

Jan: any document on possible future protocols, etc.?

Ege: yes, if you have new protocols, we can add them
… the ED on GH is a live document

Jan: ok

Sebastian: it's easier to update the binding doc than the TD spec

Cristiano: do you think we can have content type
… byte encoding, etc.
… can be related to the content type

Ege: octet stream can be added

Cristiano: would it be OK if I added some information?

Ege: yeah
… note that each section has some specific structure
… you can add new payload spec one by one

Cristiano: so I can add something on Modbus

Ege: yes
… note that there are other binding documents for each protocol and data format

Cristiano: maybe we should move some of the content to the TD
… and add links from the TD spec to this document

Sebastian: this (e.g., section 4.1.2.2) can be removed

Koster: would make sense to say "this is binding template"
… what is missing is what is binding template and what is payload
… would avoid keeping the content payload within the binding template

Ege: can move the content of section 4.1.2.2 to TD
… or should remove it?

Koster: how the information model abstract the payload
… for example, OCF has its own format

Kaz: should think about all the three related documents, Binding, TD and Profile
… and clarify what content to be described by which document
… at the moment the main target of this document, i.e., how to bind the vendor-specific data model to our standard TD is not described enough
… if we'd like to use your proposed update for future discussion, maybe we can merge this content as part of appendix as the basis, and see which part to be included in TD, Profile or still included here in the Binding Templates doc

Daniel: interested in binding to CoAP
… would like to see is payload
… somewhat connected but we can make it possible rendered published version
… so that we can choose the protocol and the data format later
… not having too many links but within this document itself
… from developer's viewpoint, it's misleading to have actual content as links

Ege: it's kind of complicated to describe the content without cross-referencing using links

Ben: to address the concern on the overlap with Profile
… to tell the truth wondering about why the binding document was needed
… this spec provides the template for concrete binding
… so these protocol binding templates describe existing protocols
… where the Profile document describes how to implement

Ege: the defaults apply non-profiled devices

McCool: coordination with Profile
… we should watch out different terminology from Profile
… the current Profile is based on HTTP, and should be aligned with the HTTP binding here
… profile should be prescriptive

Cristiano: should we mention some specific discovery mechanisms as well?
… what should be done, e.g., for Modbus?

McCool: good point
… discovery has 2 phases
… we should be clear about there is HTTP URL and HTTPS URL
… interesting question is self-describing Modbus devices
… let's make an issue and have discussion during the Discovery call

Cristiano: ok

Ege: (shows the "1. Introduction" section)

McCool: let's think about non-HTTP devices for Discovery as well

Ege: how to proceed?
… would suggest we close this PR 123 without merging it

Sebastian: ok

(marked as "Draft")

Sebastian: would see the rendered content on the main branch
… as the basis of further discussion

Kaz: if we can identify the changes from the previous published version, I'm OK to merge this PR

Ege: can identify and summarize the changes
… given that issue identifies the changes, can I merge this PR 123 itself?

all: ok

Issue 124

<Ege> Issue 124 - Specifications of Protocols submitted to node-wot

Ege: don't want to include vendor-specific protocols

Cristiano: would agree

Koster: possible combination of 1 and 3?

Ege: can think of adding another table to section "4.1 Protocols" to mention additional proprietary protocols

Sebastian: we should be careful

<sebastian> if providing a link we should be clear if the link goes to an official document or more to an inofficial/experimental space

Kaz: I have 2 questions here
… 1. do we need to include all the protocols handled by node-wot implementation?

Ege: don't think so

(McCool leaves)

Kaz: my 2nd question is how to manage this information
… possibly a registry mechanism like the DID registry

DID Specification Registries

Kaz: we need to think about what to be included in this document
… and also how to maintain this document
… including how to add new entries for protocols and data formats
… and define the criteria and procedure clearly
… given that, my impression is that this document is getting closer a registry document rather than definition of "Binding Templates" itself
… anyway, we should continue the discussion next time, i.e., next TD call or TPAC vF2F

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).