Meeting minutes
Organization
<kaz> agenda for today
<MM shows the agenda>
McCool: I created some issue about the overall organisation
… Michael Lagally is not here today, will do Architecture topics tomorrow then
McCool: are there any other topics?
Ege: there is a issue from Ben about protocol binding
McCool: ok, I will add this to the agenda
<McCool> w3c/
Strategy funnel
Kaz: I have a comment on the schedule. We need to create an entry for the strategy funnel
<MM updates the agenda>
Review Issues and PRs
Things to Fix
PR Add W3C group coordination list
<McCool> w3c/
McCool: PR is about the group coordination
… we have currently two CG, Global and Japanese CG
… don't feel comfortable making one more important than the other
… the PR removes the redundant work items
… now the PR shows better that both CGs have the same purpose
Kaz: Regarding the WoT CG and the WoT-JP CG, we should call them Global vs Japanese rather than English vs Japanese. Also we should clarify what those CGs are working on. We should ask Mizushima-san and Toumura-san about the WoT-JP CG.
Luca: does this prevents to have, e.g., a French CG?
McCool: it's kind of political. I think we should call this global
Luca: setup a CG in Spanish, French, etc might have a wider audience for people which are not comfortable with English
… we should mention that we would be open for a language specific CG
Kaz: any cooperation is welcome, however, we should concentrate on the existing CGs for this Charter.
McCool: so far, Spatial Data on the Web is missing in this PR. I will merge it and reopen the corresonding issue to add the missing entry
PR Suppress Charter History
<McCool> w3c/
McCool: just suppress the history section
no objection of the group -> PR is merged
PR - Clean up and consolidate work items
<McCool> w3c/
McCool: removes the big list of protocols.
… and updates the text for discovery
Ege: Regarding TD features we can call this "TD updates"
McCool: any objections?
Kaz: I'm ok with the PR. We should clarify which part should in which specification
McCool: is "Add normative ECHONET Lite Web API binding" relates to protocol binding?
Ege: in today's TD call we want to clarify the relations of ecosystems etc
Kaz: again, OK with merging the PR. However, after merging that we need to think about high-level items on industry collaborations including ECHONET and OPC. So I'd suggest we add a tentative category like "Stronger industry collaboration" for those items so that we can continue further discussion around that.
merged
<MM provides a comment in issue #24>
Ege: in my understanding, ECHONET uses http binding and defines own json structure. Eg, the name of the affordances has to be in the payload.
… it may makes sense that TDs are able to design reusable payloads
MJK: I think we should not discuss the details here. There is a large unanswered question about payload schema
Kaz: agree, we shoud discuss details in TD/Binding call later. for the Charter itself, we can simply describe what "Binding Templates" handles in general including several IoT ecosystems.
PR - Point to proper GitHub repo
Daniel: just a typo fix in the url
merged
<MM review the 'Things to Fix' overview #20>
Review status
<MM asigned Ege to consilitate work items>
McCool: there are no PRs about Arch 2.0 and Profiles yet
McCool: there is some confusion in issue #26
<MM shows the current rendered charter version>
<kaz> draft Charter
McCool: will be the binding template document a Note or REC?
<mjk> Agree with Ege
Ege: We should not have REC for each binding, it means having too many requirements in the charter, raising issues in different levels
<Ege> my comments are w3c/
Luca: for outsiders there is no different between Note and REC status
Luca: are we sure Notes are enough to ensure interoperability?
Kaz: this is a W3C Charter document for AC review
… we need to describe what the WoT WG will do so that all the AC Reps can understand that.
Kaz: and what is important here is identifying the normative specifications which require the Royalty Free commitment from the other informative deliverables.
Sebastian: maybe we should postpone the discussion the details on the structure of the Binding Templates spec
… we'll have dedicated discussion during the TD/Binding call later today
McCool: agree
… probably easier to have it as a Note than having 5 normative specs
… anyway, the detailed structure is still to be discussed
… you guys can figure out the mechanism during the TD call later today
<McCool> w3c/
McCool: we need summary and how conclusion whas reached w.r.t. issue 33
… we also need PR to add TD deliverable
… let's defer discussion to TD call
Kaz: I strongly suggest we don't mention to much details. Charter cannot be changed afterwards.
McCool: I see, description can be abstract
… adding things like "we might add a registry"
McCool: Anyhow, we must state which deliverable is normative
Ege: shall we state how collaboration between WoT CG and WG works
McCool: We do have coordination section
Kaz: as we did for WoT IG charter. We can describe relation between groups.
… can add link to detail policy document
… should clarify relationship between spec documents within the scope section too.
Ege: CG inviting should go into this policy?
Kaz: Too much details
… let's start with important portions
… in collaboration section
McCool: current charter does not say anything about website
Ege: Simple thing. When we create events that about WoT. We are not allowed to inform WG
McCool: Maybe we can re-word the current para
Kaz: please remember detail policy should not be clarified in this charter
Ege: Is there a policy template?
Kaz: No, I would ask you to create one
McCool: Can we link other documents?
Kaz: Yes
McCool: perfect, we can point to policy document
Kaz: Let's start with something we did for the WoT IG Charter first, then think about what would be the better solution later.
Remaining Issues
Issue #20
<Github> w3c/
<kaz> wot-charter-drafts issue 20 - Things to Fix
McCool: Let's mark some issues as optional
… should talk about version numbers, liaison and decision policy
McCool: Let's start with liaison
Sebastian: I think this was already partly discussed
… important topic
… should work on placing WoT in other SDOs
… we should mention this in mission statement also
… we have good exchange with OPC-UA, Echonet and BACnet folks
… we should work on strategy to bring WoT in these ecosystems
McCool: What exactly should we put in charter?
… shall we list work items for each liaison
Sebastian: Do we want to have these details in charter?
McCool: maybe less explicit
Sebastian: w.r.t. DTDL we should talk with Lagally also
McCool: TBDs need to be cleaned up
… I marked the owners
Sebastian: I can do that
… I also plan to clean-up/remove some institutions
McCool: oneM2M is still of interest but we didn't talk too much with them
… GS1 is somewhat similar
… maybe just keep "active" list
… ITU is missing
Kaz: charter document is there that all AC reps understand what the WG will do
Kaz: if all the listed SDO liaisons are simple liaisons as we've been doing, that's fine. However, if we want to try stronger collaboration with some of them for some joint work, we need to identify that within the Charter. For that purpose, we can read the SDW WG Charter as an example, though we don't need to copy everything from that.
<kaz> fyi, Spatial Data on the Web Working Group Charter
Kaz: Also please remember we got a message from PLH volunteering to help us figure out the liaisons within the Charter.
Ege: in charter draft under "Connexus" there is a para that introduces the previous list
… that's what I added
… we should highlight where we have strong collaboration
McCool: Maybe have "active" collaboration
<McCool> w3c/
McCool: I assign issue #37 to Ege/Sebastian for liaison
<Github> w3c/
McCool: A PR by tomorrow would be fantastic
Version numbers
McCool: discussed in TD, discovery ..
… right now discovery does not have version number
… Shall we create issue to come to a conclusion
Ege: There is issue in TD already
McCool: for discovery I do not plan to have version number.
<Ege> w3c/
McCool: Issue with URLs exist also
Ege: Maybe we have to speak about backwards compatibility
Ege: I don't think we should do that
… unless there is a VERY good reason
McCool: TD1.1 was supposed to be a fix version
… it ended up to be much bigger
Ege: For W3C the work for 1.1 vs. 2.0 is the same
… when talking about TD documents we need to find a way that people talk about the same "version"
Sebastian: I would try that each deliverable has the same version number
… e.g., Arch 2.0, TD 2.0 et cetera
… in AAS we also started with version 3.0 to indicate that 3.0 points to the core document
… otherwise it confuses people
<Ege> +1 to syncing version numbers
McCool: version date is somehow a version number
… each document should have version nr
… I am also okay with dropping backwards compatibility
… for TD1.1 this was another discussion
Luca: I do agree that we should make things simpler
… a single version for all documents makes sense
… as implementer: moving from 1.0 to 1.1
… run into issues
… I suggest to start new with no issues ... going directly to 2.0
Sebastian: a profile is one possible candidate ...
… have 1.0 note and then start with 2.0
… Note: some W3C specs did not follow that
<kaz> Version management guideline
Sebastian: CSS and HTML do not have the same version numbers
Kaz: There is a basic guideline document. Also each WG has specific policy on version management, e.g., HTML doesn't use version number like 5.1 any more and CSS uses "Level" to identify compatible modules.
… we can think about which way to go
… should identify compatible modules
… a consolidated document should clarify the compatible module specs, and I think WoT Profile could do that.
Ege: a *new* document should also start with same number
McCool: Right
Sebastian: Another idea
… bring "WoT" term first with numbers?
… WoT 2.0 Discovery ?
<Ege> +1 to numbering the WoT term
McCool: Let's capture thoughts in issue #38
<kaz> wot-charter-drafts issue 38 - Versioning of Specifications
Kaz: Maybe use "Level 2" instead of Version 2
Daniel: What about non-normative documents like Scripting API ?
Kaz: Should have document that states compatibility of all the WoT specs in addition to the version number itself. And I think the WoT Profile should provide that kind of information.
Luca: A pointer document can link all the other documents
McCool: Okay, added this as "hub" document
… Arch document has these capabilities
… we still have backlink problem.. if someone goes directly to TD or so
… w.r.t. Scripting, updating during development use dated version
… some kind of combination
McCool: Please comment on issue 38 in wot-charter-drafts
Kaz: This issue has 2 viewpoints
… a) version number of each spec itself
… b) how to manage compatible modular specs
McCool: Let's look at concrete proposal
Sebastian: suggest to start with TD/binding 20 past
<kaz> [adjourned]