Meeting minutes
Agenda
<EK shows the agenda>
Minutes
https://
Ege: we need to change the names. E.g., chris -> CA
Ege: any objections?
minutes are approved
Charter Related Topics
Binding Templates Naming
wot-charter-drafts issue 14 - Confusing use of the term "protocol binding"
<Ben shows the different definitions of Protocol Binding from the Architecture and Binding Template documents>
<Ege> also see https://
Ben: having different documents such as HTTP protocol binding and HTTP profile is confusing
… the proposed terminology in the charter is different than what the definition of those terms currently are
Ege: I think there is no problem with the general concept, its more about the naming
Kaz: I think, Ben's question is inline with my question about the binding template and architecture in general. We need to clarify the structure of the whole WoT specifications as a family, and what kind of descriptions and definitions should be included in which specifications in what level of description.
Cristiano: this discussion already takes very long already.
Sebastian: (describes his proposal on TD/TM and WoT Binding Templates 2.0 he showed two weeks ago)
Sebastian: would make sense to use the names in this diagram
Ege: maybe that should be discussed later?
Kaz: we need clarification about what we want to describe for "Protocol Binding" and "Binding Templates" so that developers can generate concrete Thing Descriptions including forms element with protocol binding for their IoT systems.
… the presented overview of Sebastian is different of Ben's points
… The question here is not (only) the name of the specifications but the fact that there are descriptions on "Protocol Bindings" and "Binding Templates" within various specifications like WoT Architecture, WoT Profile, WoT Thing Description, WoT Binding Templates and protocol-specific binding template subdocuments. We need to clarify which spec should describe what in which level using what kind of description..
Daniel: in the overview there are 2 REC documents, TD 2.0 and Binding Template 2.0
… I would propose to have the binding definition only in the TD 2.0 document, we can skip Binding Template REC
… this would simplify everything, we would have only one document
<kaz> (Kaz notes that is what he also suggested last week :)
<shows the place where the information would be provided in the TD spec about the binding definition>
Ben: I support the idea to remove the term "template" in the specific protocol binding document
Ben: why is the WoT Profile Basic Binding also in this picture?
Sebastian: profile uses a combination of a specific protocol and an expectation of the payload. This is what ecosystems typically do
Koster: agree what Sebastian, this would enable the option to reuse protocol vocabularies
… its like configuration file
Luca: we need to be careful when we compose different binding approaches such as profile and protocol binding. What happen when not everything is implemented?
Cristiano: profile is only a platform binding
Koster: I don't like the idea of using defaults
Ben: the names apply a lot, we need to decide
… to respond to Luca: you can override default and it is assumed that consumer will always implement the default assumptions
Kaz: I can agree with MK and OK with stopping discussion today
… we should split Ben's issue into two pieces, (1) Charter topic and (2) detail discussion on TD and Binding.
Cristiano: why don't we simply refer to a document with a specific protocol name
Sebastian: (referring to the discussion last week on including the Binding Templates content into the TD spec)
… OK with the idea, but still want to have protocol-specific documents
Sebastian: support the idea to integrate Binding Mechanism only in the TD 2.0 sepc, a seperate Binding Template REC document is needed anymore
Ben: I do not mind, if this will go in one document. However, the Profile mechanism should then also go in the TD spec
Ege: we checked the number of pages the TD spec, its around 138 pages
… we compared this with JSON-LD 1.1 it has over 200+
… I think it is not a big deal to have everything in one document
… would simplify that everything in sync
<kaz> related wot-charter-drafts issue 33 - TD and TM restructuring
Kaz: 2 comments. First, we should have had the wot-charter-drafts issue 33 as part of the wot-thing-description repository instead of the wot-charter-drafts repo. We don't need to move it now, but please be careful about which issue to be discussed on which repo.
… Second, regarding the discussion on the structure of TD and Binding, I myself suggested we merge the Binding Templates spec into the TD spec. So I'd support that direction if it's still a possible option.
<benfrancis> +1 to the general idea of having fewer normative specifications to keep in sync with each other
Koster: +1 for single deliverable
Cristiano: I think we have a consensus here.
<mjk> +1 cris idea to manage multiple content sources
<kaz> related wot-charter-drafts issue 62 - Moving the core binding document into the TD
<McCool> (sorry I'm late, conflict...)
<Ege summarize the discussion in w3c/
Ben: Will the registry stay in the TD spec?
Ege: yes
McCool: i think the registry section can be kept short
… can only the registry table be updated when a new REC is published?
Ege: no, new protococols can be integrated without publishing new REC
… registry table is informative
Kaz: the registry management should be described by a seperate note
Ege: we are flexible in defining the registry. We can reject when duplicated prefix is used
Kaz: we should not define too much details in the Charter. I thought the DID WG had similar question, so we can look at their work (and ask them for help).
<Ege finalized the comment in w3c/
Propose different naming for reusable connections
wot-charter-drafts PR 73 - Propose different naming for reusable connections
Koster: we need to be careful of the name. e.g., base is not only a URI it also encapsulate the protocol scheme
Ege: what would be a better name?
<benfrancis> "re-usable endpoint"?
Koster: e.g reusable connection for persistent endpoints
Cristiano: I would prefer to have it more abstract
<mjk> "connection context"?
Cristiano: WS are keep open the connection to subsequent send messages and the consumer need to keep the state.
Ben: stateful interactions forasync actions go in the same direction
Kaz: I'd agree to all the possible use cases here in the comment of PR 73. However, I'd simply agree with McCool's comment a bit above.
… I myself a OK with the current list of examples but we can add something from the possible use cases. In any case, we can't list all the possible use cases here.
Ege: what do you think removing the term?
Ben: I would prefer to keep it but is not a big deal to remove it
Cristiano: if it's helpful for everyone then it is ok
Versioning
-> Looking at CSS versioning mechanism
<Ege> https://
<kaz> https://
THE CSS STANDARDIZATION PROCESS
Ege: please have a look on this
… I think it is better to simple call everything "2.0"
TF Lead in the Future
Ege: if someone is interested please let us know
<benfrancis> I'm afraid I need to drop off now, thank you for discussing the issue I raised.
ok, thanks for joining
Binding Templates
Netlify issue
Kaz: Jose from the Systeam handled the problem with Netlify configuration within the wot-marketing repo. Please see also his message about the problem.
Schedule
wot PR 1077 - Add 2 weeks review period for binding templates
Ege: publication schedule updated
PR - Interaction Patterns
<Ege> w3c/
251 PR 251 - Temporary Section Reorg - Part 5: Interaction Patterns
<sebastian> w3c/
Ege: any objections?
no
PR merged
PR - Generate CoAP vocabulary from RDF
Ege: Klaus Hartke started to review this week
<kaz> i/templates#251/scribenick: sebastian/
Jan: one topic was if the ontology is integrated int CoAP Binding document as well
Koster: is it only about vocabulary
… ?
Ege: try to follow how HTTP does
… with the RDF definition
<mjk> ackmjk
Cristiano: the goal was also to describe older protocols
… we tried as much as possible with the modbus protocol
McCool: we need definitly ttl files for validation
… I vote for modularity
Ege: do we need a separate top level ontology directory?
Jan: @@@
Jan please can you provide your point
Sebastian: +1 MM to keep modularity
… feedback to Jan: maybe we can put ontology details in the appendix?
Koster: agree with MM and SK
Kaz: one comment and one question. First, we should work with the SDO who defined the protocol for the vocabulary definition (if they still exist).
… Second, I thought we wanted to host all the resources, HTML and TTL files, under the W3C Namespace. Is that still the case?
Ege: yes, that is the assumption.
Kaz: In that case, we should look into the other ontology work within W3C as well./
<kaz> [adjourned]