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://
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://
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
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
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
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]