Meeting minutes
Agenda
McCool: wrote a simple agenda
… aob?
Sebastian: I saw a email for Tpac registration. Maybe we should talk about that too
McCool: added
Sebastian: I also updated the wiki page
Kaz: two comments
… I suggested to consolidate the main wot topic agenda, we can then link it back in the wiki call agenda
… about the website update it has been communicated with emails in the past weeks.
Sebastian: added links
minutes review
McCool: names look correct
<kaz> June-7
McCool: any problems?
McCool: minutes approved
Quick updates
W3C web page redesigned
<kaz> W3C main page
Kaz: the new webpage is now public
… the content should be identical or at least very similar
McCool: I find interesting that it looks similar to our page
… maybe we should align our page to the official website.
Kaz: it is not strictly needed
McCool: logo is changed too
Kaz: yes, but it is due to the legal entity change
… remember to update the logo
McCool: any other quick updates?
TPAC registration
McCool: individual registration
<kaz> TPAC 2023 registration
<kaz> Early Bird rate – until 15 July (23:59 UTC): EUR 290 [Rate limited to the 4 first persons of a given organization]
Sebastian: there is an early bird registration
publication schedule
<kaz> publication schedule
McCool: we need more resolution?
Kaz: no more resolutions needed for Discovery
McCool: how requests now are labeled as awaiting publication
<kaz> PR Transition request for Architecture
McCool: one of it (architecture) is still in awaiting working group state
… I need to reply to one comment
Kaz: The purpose of the Proposed REC Transition request is simply checking the status of the wide reviews and so on by the Director.
McCool: Arch PR was reviewed by Sebastian and I made a couple of fixes
… do not put link in abstract
… as far as I know we don't have patent disclosures. Let me know if otherwise
… any questions about these points?
… with TD I did similar changes
… discovery similar
… TD and discovery got approval
Kaz: for the architecture PR Request you could add the email, it should be archived in our mailing list
McCool: I don't have access right
McCool: let's do it later
Binding WD publication
McCool: any updates?
Sebastian: waiting for publication
Kaz: sorry I could not work for the publication last week because I was busy
… I will talk about Scripting API publication
McCool: ok no problem
McCool: aob?
McCool: ok main call adjourned
Thing description
ege: we have a single presentation where multiple people contributed
<Ege> https://
ege: above you can find the link to the presentation
… if you want to contribute just drop an email
… is anybody interested in this already?
… ok, just let me if you change your mind
… the presention is mostly to put things in one place
* ege is presenting guidelines to contribute to the slides *
Kaz: do we need about the slide structure?
ege: in a bit we will talk about the topics
McCool: I want to step back and talk about organizational
… topics
… probably md files are better
… because it keeps the focus on the content and not the style
ege: ok no problem
… we have shared this a week ago
Kaz: Before that discussion, I strongly suggested we not have the discussion but should have the planning discussion during this call. However, you had some preliminary discussion last week and that's fine. However, let's concentrate on the planning discussion today and skip this part about the slide structure
McCool: let's focus on the content
* ege continues with the next topics *
ege: be aware there are topics that are not covered in this slide deck
McCool: I plan to do work for discovery in another document
ege: just talk with cristiano is was looking at query filters
… with Michael Koster we decided to hold presentations
… Luca did a nice presentation. The format works well
ege: I found different categories
* Ege presents the different categories of working items
ege: any category to add ?
McCool: not sure how to improve, but the categories are a little bit vague
Kaz: are we ready for this level of discussion? meaning how to deal with categories of issues.
… it is probably too early
… we should focus on how to refactor the documents
… we need the concrete discussion of course, but probably later
McCool: it is a useful way to organize the work. It is a good idea
Kaz: the problem is that this is discussion is orthogonal
… it can be done for all repositories
McCool: we could take the md file and check the topics that we collected there
Kaz: I partially agree, the "what" is important
… it is that we should talk about it as a discussion about everything
… is that ok to change the title of this discussion?
Sebastian: I worried about discussion, we should let the TD group to present these slides. I understand your concern kaz, but instead of changing the title why don't we take that as an input for a future more generic discussion?
… please let continue the presentation
<McCool> (agree with sebastian; let's go through slides as Ege has prepared, then after we see we can discuss how to uplevel and apply to wider refactoring)
Kaz: I was concerned about this complication
<McCool> (regarding kaz's objections: let's consider this a "prototype" of how we can proceed)
Kaz: I am not happy to accept this proposal as the output of TD task force. It should be put more open to the whole group
McCool: let's consider this as a prototype or as a proposal
ege: the categories is specific to TD
… it is really narrowed down to TD
… should I also remove the not TD related topics?
McCool: let's move with stuff
*ege continues with the presentation of categories*
ege: we should decide how we mange the generation of the specification document
… currently is very complicated
… and slow contributions
… it influence the whole refactoring discussion
Sebastian: sounds good
<kaz> (scribe switches to Sebastian)
Koster: we plan sections about protocol binding
… have section for people that explains the usage of specific binding, and there are sections that explains how to write new binding
MCCOOL: how to better organize testing?
… its not only about TDs
… should also cover behavior
KOSTER: is this about the TD specification?
MCCOOL: no, more about an implementation report
… should also help about design decission
Sebastian: having physical PlugFest again would be great in the new Charter
MCCOOL: right, but we need to distinguish plugfest and testfest
<Zakim> McCool, you wanted to react to sebastian
Kaz: brainstorming is fine, but please clarify the work items first and then think about how to deal with the work items next.
EGE: ok, I will assign this as work item
ca: we should track the item how to generate the implementation report (which tooling?)
Luca: we should check that in-person meeting share all the information
Kaz: what do you mean by single source of truth?
Ege: we have a process that genarates the index.html
… different edits have to done in different documents (JSON Schema, JSON-LD file, ...)
… we need to bring it to a single source which needs to be edit
Kaz: today's process is too complex. Someone else should also able to edit. That's true. However, we should rather concentrate on the fact we have difficulty with TD spec maintenance rather than thinking about possible solutions.
Sebastian: agree here, that the process should be more simplified
McCool: we should keep it editable in a single place
Koster: work on well-defined interface to incorporate exeteranl bindings
… need to be clear how to handle external specifications
… should be explained well when an own protocol binding is used
Kaz: improving bindings template mechanism is fine
Kaz: However, we ourselves are not sure about what is really needed for that purpose, and we need to ask actual IoT developers for ideas.
Kaz: Japan such as Takanaka uses WoT for smart building management
… we can ask for some feedback
Ege: this should be useful for both sides
Kaz: For today's discussion, brainstorming is fine. However, we need to think about concrete work items on Binding Templates as well, then think about how to deal with them how and with whom next.
Koster: thats important for the design phase
… intersthing to see how the payload format look like, uri parameters used, etc.
Kaz: list of slide 17 are ok, but we should derive specific work items
Koster: agree with it
Sebastian: cooperations with partners and SDOs very important that WoT gest adopted
Koster: working on liaisons could be broadened out to all of the these types of interactions
Ege: <ege gives an overview of the different TD topics>
… managing actions
… timeseries
… linting
… versioning
McCool: some work items should have different literals
… we should clearifiy, where normative definitions in Archictecure should be moved, when Arch will be a Note in the future
<mjk> +1 sebastian... how do we test architecture?
McCool: we need to track all work items
McCool: chairs can split responsiblity of the deliverables and talk each week, would be a idea
ca: use cases are mainly applied to TD
… less for discovery
McCool: biggest issue with discovery is not to filter results
Kaz: Firstly, let's handle Arch on friday
<McCool> (is HOW to filter results - can't just return entire database every time, which right now is all we can do!)
Kaz: secondly, chairs don't need to be responsible for technical detail of the specs but can ask the Editors to work on that. However, should coordinate with the Editors and manage the progress and schedule.
<mjk> +1 use cases to motivate all features
Kaz: thirdly, we should not generate features only based on our own intention, but should work on specs based on the use cases based on the industry needs.
Luca: just to mention that the part where Cris is working on is also related to TD
Tomorrow's agenda
Sebastian: Liaisons including wot deployment, JSON-LD, Web&Networks, Spatial Data, Digital Twins, OPC UA and asset administration shell
… then Discovery
[adjourned]