Meeting minutes
Organization
Kaz: we can quickly skim the existing PRs on wot-charter-drafts, but if some of them describes too much detail, we should rather concentrate on the mission, scope, deliverables, etc., within the draft Charter itself.
PR42 - Mission statement
<McCool> https://
<kaz> Preview
<kaz> Diff
McCool: (goes through the proposed changes)
Kaz: The mission statement should provide the mission of the WG
… it should be more terse
… we should think about what we want to do for the new charter period
McCool: We are clarifying the mission statement but not changing it
Kaz: We do not put too many details in the mission about the building blocks
Kaz: we can use a bullet point list to avoid making the statement too verbose
McCool: We can do incremental improvements, let's merge the PR and iterate over
Ege: I can rebase the PR
PR 40 - Binding
<kaz> PR 40 - Simplify the binding mechanism
McCool: (overall description of the PR)
Ege: The term Ecosystem is open for rewording
<kaz> Diff
McCool: if we say standards it conflicts with de-facto standards
… also platforms may not fit completely
… ecosystem is more encompassing
Kaz: Note that there was some discussion during the TD call yesterday, and the binding template core document may be included in the main TD document. So we should think about how to deal with the Binding Templates spec (i.e., core part vs protocol-specific parts).
<Ege> see also the related issue 62 - Moving the core binding document into the TD
McCool: That would actually make sense. We also discussed about publishing all the specs in one go
McCool: but lets focus on merging the current PRs first
McCool: Objections on merging?
Lagally: I want to see the overall look first
Lagally: Are the separate binding documents also normative?
Ege: The separate binding documents are not REC
… the main binding document is providing the requirements so it is normative
Lagally: who is going to provide the individual bindings?
Ege: The individual bindings can be provided by the third party, but in order to fit the registry there are requirements
lb: just to be clear, the idea is we can have individual binding for something
… and we define some rules based on vocabulary
… to support interoperability for implementations using some registry
… the specific entry within the registry should be compatible for the developers
Ege: right
Kaz: Given the situation so far including the discussion during the TD call yesterday, the first sentence here (what Binding Templates does) is OK, but the second sentence should rather say (1) there is a possibility of making the Binding Templates spec back into the TD spec and (2) concrete protocol-specific vocabulary should be defined in an informative manner.
Kaz: However, we need to make decision on which way to go, (a) Binding Template as part of TD or (b) a separate normative deliverable, before submitting this Charter to the AC review.
McCool: (updates the comment to the PR)
McCool: We should explain that the individual bindings are vetted before entering the registry
… we should clarify the binding mechanism
Lagally: Architecture can contain the binding mechanism description
McCool: Clarify as binding policy and its mechanism
Lagally: the policy should be in the Architecture, the mechanism in the TD
McCool: The technical details should be in the TD document
Ege: The mechanism has to be normative
<benfrancis> +1 Architecture should be informative
McCool: The PR should be reworked again before merging it
Kaz: agree we should wait for further clarification
PR 46 - Digital Twins
<benfrancis> PR 46 - Update wot-wg-2023-draft.html: Adding digital twins
McCool: My overall feeling is still too broad as work item category
<kaz> Diff
McCool: lots of overlap with other work items
… needs to be focused
… shadowing service and linking as separate work items
Kaz: we should not put detailed items in the scope section
… can we imply those use-cases in other work items
McCool: Move the details to the summery and keep the work items as bullet point list
Ben: digital twin is more a marketing term, better to focus on the underlying requirements
Lagally: It is more than a marketing term, there is enough material around the concept
Lagally: I believe it is important to use the term
Kaz: We maybe need more discussion, but from my viewpoint, "Digital Twins" is a possible use case for WoT as already described in the WoT Use Cases document. Also (as already I suggested) it would be better to remove the detailed topic descriptions from the Scope section and put a summary list like McCool did. The question is if the summary list covers a use case like Digital Twins.
McCool: Concern that the term has a very broad definition
… Add in the summary section a list of specific features within the scope of digital twins
<Zakim> McCool, you wanted to react to mlagally_
Ege: (agrees in moving the term up)
Lagally: ask for consensus
McCool: let's expand in the details document
McCool: remove the detailed work item list from the charter and consolidate in the detail document
Lagally: work on it now
McCool: (prepares the PR)
Kaz: We should clarify where each work item belongs to (e.g., actual WG work items, potential use case areas, survey on the other standards) in the detail document
Ben: Make sure the charter document won't be too small
… the detail document, but that clarification should be done separately later. must be reviewed and updated
McCool: Ask Ege to rebase the PR
Next steps
McCool: Use Discovery and Use-Case slots next week?
Lagally: OK with using Use-Case slot.
McCool: Rebase and make the pending PR ready to merge
Ege: I need clarification on what should be described in the two documents about binding templates in Architecture and TD
Kaz: We need to make decision on how to deal with the WoT Binding Templates spec itself (=as part of TD or a separate normative spec), then generate concrete text accordingly.
[adjourned]