Meeting minutes
Minutes Review
<kaz> Feb-8
Ege:: We started with a Binding Templates PR but the discussion evolved into a general one regarding the Binding Template structure/purpose
… a lot of opinions were exchanged
… I think the consensus was to have more descriptive content in the specification
… the minutes seem to be missing PR subtopics
Kaz: I just fixed the names and will make additional fixes regarding a change of the scribenick later
Ege:: Minutes look good, minutes are approved with the scribenick changes that will happen later
Ege:: (goes over the agenda)
… we could start with your slides, Sebastian
Binding Template 2.0 Slides
<kaz> slides
Sebastian: We can do so, is a proposal for how to deal with Binding Templates in the future
Kaz: Are the slides available somewhere already?
Sebastian: Have them only locally for now, will upload them later
Sebastian: For now the slides refer to TD and TM as the same document, independent of a potential split in the future
… as both have an impact on the Binding Template specification
… everything that is binding-template-related and currently part of the TD document should be moved to the Binding Template specification
… regarding the content: The Binding Template document should be the main entry point to the binding concept
… should clarify that the concept of bindings is very broad (can refer to protocols, content type, and ecosystems)
… all three concepts can be described by a binding
… the core document should clarify the expectations for a concrete Binding document normatively
… e.g., defining assertions for how to map a protocol concept to an operation type
Sebastian: The core document should also provide a link or registry to the actual Binding Documents
… non-normative in order to allow future additions
… concrete description of bindings should not happen in the core document but in the individual Binding Documents
… which should then follow the assertions defined in the core document
Sebastian: Another question is what kind of document the individual Binding Documents should be
… in our opinion, it would be totally fine in a WoT context to have the individual documents as notes
… and not as normative specifications
… this is also related to the fact that Binding Documents can be defined by other SDOs
… so for example, OPC UA or ECHONET could define and publish their own Binding specifications
… since Binding Documents build on already defined normative assertions
… in a discussion with Michael Lagally, we arrived at the conclusion that Profiles can also be seen as Binding Documents which should also follow the assertions from the core document
… which itself will become a Recommendation in the future
Kaz: I am kind of confused because last week we already asked Ege and Michael to work on the reorganization for the Binding Templates spec.
… is this a proposal for the work by Ege and Michael?
<kaz> wot-binding-templates issue 232 - Next WD Path
Sebastian: You are right, we kind of reversed the order
… but from my understanding this is your understanding as well?
Ege:: I think we are also on the same page
… the overall work we have to do is to define the mechanism
… a main technical question is also how to construct payloads
… but overall we are on the same page
Koster: I also agree, we mostly talked about how to reorganize the document, the last section would mostly be instructions for creating a new Binding Document
… we did not actually talk about the structure on a level this high, but I mostly agree with the proposal
… there might be cases, however, where protocols might be extended and further constrained by a Binding document
… you can assume that there is always an additional layer on top of a protocol, with WoT being one of them, defining defaults and a vocabulary for specific parameters
… there will be the need to define additional constraints but we don't have the vocabulary to do so yet
… the ecosystem bindings, however, are going to describe how certain aspects are going to be mapped in practice, for example, LED colors
… what we need is a semantic hook/interoperability to make bindings work
… the diagram in the presentation implies that we already know how to it, but have not figured it out yet
… also the "WoT" in the diagram implies that all bindings are equally "WoT", but there might be differences in the "WoT"ness of a Binding Document, especially when it is defined by an external SDO
Kaz: I mostly agree with Michael Koster's view and think this diagram is inline with what I also mentioned last week.
… we can include this kind of diagram into the Binding Overview section of the WoT Binding Templates spec.
… However, the WoT Binding Templates document should not assume this kind of prescriptions for ecosystems but should simply explain the binding mechanism like (1) how to use forms element, (2) how to use data schema, content type, href, etc., for actual binding. Then we can describe examples of concrete binding, e.g., HTTP, MQTT, OPC UA. If needed, we can describe them in separate sub documents.
Sebastian: In the diagram we also propose to remove the term "Template", to avoid confusion
Ege:: I think the main question concerns the light-blue boxes (i.e., OPC UA, Profile Binding), the "simple" protocol bindings like HTTP should be pretty straightforward
<kaz> /
Ege:: also a question is how to refer to other binding documents, especially when it comes to payload bindings)
Sebastian: I think if a Binding Document reuses a definition from another document, it should rather refer to a normative document (?)
Koster: This is a very important point to clarify in order to avoid conflicts
… we don't need to already define this in the charter, but we need to talk this through
… question is also if a Binding Document like HTTP can be used standalone
Ege:: the WoT HTTP Binding document cannot be used standalone since you need to use a payload binding
… but the data schema from the TD could be used for JSON
… however, you should always use a Binding Document, e.g. for payloads and ecosystems
Koster: I agree, you cannot leave ambiguity in certain places
Kaz: I agree, we need to clarify what should be defined by which (kind of) document
Sebastian: It is hard to generalize this, should be up to the Binding authors in the end, however, the core document should define the requirements
… it is good, that we already have existing documents we can use as best practices
Kaz: I am not objecting to the diagram, but I am still kind of confused. I think we should simply let the Ediors, Ege and Koster, continue their work on improving the Binding Templates spec.
… the diagram could be included in the new core document
… but there is still necessary work to be done to clarify what to be described by which documents including the Binding Templates core document and the possible sub documents.
Daniel: Not necessary to define all the details right now
… I think what we have now is sufficient to write a paragraph into the charter, but we should then continue the discussion regarding the details
Sebastian: The question is now if the abstraction we see here is the right direction for now for the new charter
Koster: I think this the right direction for the charter. Details need to be clarified afterwards
Sebastian: Core (Binding Template) document would be a REC
… concrete Bindings could then be defined in Group Notes or even in sections of other (external) normative documents
… for now we could agree on this structure and then move forward
<Ege> +1
Kaz: What is important for the Charter document is our intention to make the Binding Template specification a normative one and then parts of the document could become registries
Ege:: I agree, we don't need the details, the overall structure is agreed upon
… we could make a resolution for the new structure
… if no one disagrees I would make a proposal
<kaz> Issue 232
Kaz: As I said before, I am okay with the structure, and we should integrate the diagram into the Binding Templates spec. So would suggest we add yet another checkbox to record this item for the document improvement within the Issue 232.
<Ege> proposal: The TF agrees that the next charter there will be a REC document called WoT Binding Templates 2.0 which will have Note documents for specifying the individual bindings
<Ege> proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates 2.0 which will have other separate documents for specifying the individual bindings
Koster: I don't think we need to mention "Note documents" in the proposal
<Ege> proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates 2.0 which links to other separate documents for specifying the individual bindings
Ege:: (updated the proposal)
<Ege> proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates which links to other separate documents for specifying the individual bindings
<sebastian> +1
RESOLUTION: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates which links to other separate documents for specifying the individual bindings
Kaz: Calling the document "WoT Binding Templates 2.0" is a bit confusing, should be removed from the resolution, versioning should be decided later
The Task Force makes the resolution above.
Sebastian: Going forward, we should focus on the base concept and figure out the details of the sub documents later
TM Document
Sebastian: The situation regarding TM and TD is that we need to clarify whether we want to have a separate document for TMs
… or only one Recommendation for both
… should collect pros and cons
… I think the big "pro" is that it be that it would be more lightweight
… the TM parts would also be easier to find
Luca: It is worse than that: "Thing Model" currently points you to a completely unrelated document
… separating the TM and TD improves searchability, which is already a big plus
<Ege> also see w3c/
Sebastian: One "con" I see would a lot of duplicated definitions
<luca_barbato> I was exactly thinking of that
Sebastian: question is whether we put the information in the TM document or point to the TD document
Kaz: I would, once more, suggest to focus on what we want to achieve. A separate document might make things easier for the editors, but it is also harder to keep things in sync
… we should think about what to describe by which document
… regarding the search results from search engines, we cannot avoid these kind of overlaps
Sebastian: I think it is not only this kind of search aspect
… if someone asks me about the Thing Model, I need to tell them to scroll down to a section down below
… and then they need to scroll back to understand the information model
… I think this could be simplified by a standalone document
Kaz: The core issue here is that is unclear what the purpose of the Thing Model is in the current specification
… rather than document separation
<Mizushima> +1 kaz
Kaz: in any case, we should clarify what the purpose of Thing Models and how to generate Thing Descriptions
Ege:: This is already a normative part of the current specification, though
Kaz: As I said, we should clarify what we need before discussing separation
Sebastian: The main change in TD/TM 2.0 would be the updated information model
… so there is not really much new content
Sebastian: One feedback I got from a coworker at Siemens was that it is difficult to distinguish a TM from a TD, especially at the RDF level
… for many use cases it is important to be able to separate the two
… so ideally, you would have a different namespace
… which might be difficult to accomplish since TDs and TMs share a lot of concepts
Jan: my impression on the TM section is something added later, and think it's better to keep it within TD to avoid confusion
Sebastian: we could think about further improvement even with the current structure with TM inside the TD spec
… think that's what you're proposing
Luca: the whole TM description is conceptually not based on the Thing Description model itself
… so think Thing Description is enough from my viewpoint
… implementing TM is kind of burden
Ege:: What kind of burden do you see?
Luca: I would argue to keep them as separate as possible due to the fact that TMs require additional processing
dape: I would agree with using TMs as the base and then extending from TM to TD
… making it also clear that the document is about TMs and TDs
Kaz: I agree with Daniel's view
… maybe we can think a bit more about what the issues with TMs currently are
… and then revisit thinking about separation
Sebastian: I think one of the big plusses of having one document is avoiding the need for another REC
Koster: I just wanted to echo, we should elaborate a bit more why we need TMs
… also TMs are the generalization and TDs are an instantiation or extension
<dape> +1
Koster: also using TMs make it possible to trace the place where a TD originates from when looking at a concrete implementation
… regarding the document, an improved section might also make it easier to understand the differences between TDs and TMs (?)
Sebastian: Regarding the overall structure, we can use the TM as the basis that is enhanced by a Binding Document and Security Schemes
… to create a TD
Luca: That is very problematic. What happens if we an ontology that is not a Binding Document or a Security Scheme
… we have an overlap of concerns and definitions, which is problematic
Sebastian: I just wanted to focus on our current structure, but I can clarify that additional ontologies can be used as well
Kaz: We are running out of time, we should continue the discussion on how to improve the description on TM within the Thing Description (Section 9). next time
<kaz> Thing Description 1.1 - 9. Thing Model
Ege:: Wanted to reply to Luca
… there are two types of TMs
… the ones where only certain information is plugged in
… and the ones that are used in the context of ontologies
Luca: We continue this next time.
Sebastian: I would postpone, we collected a lot of arguments
<kaz> [adjourned]