Meeting minutes
Review draft minutes
<Ege walks through minutes>
<Ege> subtopic "PR #1807 TM namespace not active yet" should be changed to "Issue #1807 TM namespace not active yet"
Ege: Any further change requests?
-> none -> minutes approved
Timeslot and length preference
Ege: We would like to ask people about time and length
… we should prioritize people that are joining
Cristiano: about the length... we could try to stay in 1 hour
… depends on topic
… I am also ok with moving the slot to a different time
Kaz: Agree with Cristiano
Ege: with big design topics we need to focus on some topics
Daniel: Do we plan to start Doodle call for all the WG participants including those who are not here?
Ege: Yes
Explaining the share of moderation between Ege Korkan and Michael Koster
Ege: share of moderation was discussed last week
… MK and myself were discussing this further
… Koster: Basic architectural design, doc structure etc
… Ege: concrete description based on the design
… We are working together
… and we talk to each other
… both responsible
Ege: If there is feedback please let us know
Koster: from my point of view. Single point of contact for different functions
… not exclusive
… is starting place and we look for feedback
… we were asked to categorize who is doing what
Cristiano: Looks fine
… w.r.t. testability. What does it mean when it comes to testing?
Ege: Testing is in the hand of testing task-force
… designing of *new* keyword is in my responsibility (at the moment)
Cristiano: Keeping an eye whether something is implementable.. got it
Ege: Still a draft
Koster: We are trying to make sure to split workload
Kaz: Testing is just one step from the spec generation procedure
… each task force and editors should be responsible for testing
… of course, the Testing TF can help with the testing mechanism and the tools.
… testing data should be installed on TD repo
… while the tooling in testing repo
Koster: role of governance
Binding Templates
PR 290
Ege: I have worked on publication preparation
… looked at it last week
… completed all todos and checkers
… link checkers -> no errors
… css checkers -> no errors
<Ege> https://
Ege: CSS issue, not sure why it reports center array
Cristiano: HTML should be static, right?
Ege: Yes, after ReSpec
… checking again.. <center> comes from Netlify
… means we are fine
Ege: Link checker reports 1 issue since the document itself is not published
Ege: pub checker reports netlify issues
Kaz: Which filename are you using?
Ege: it is Overview.html ... but Netlify uses lowercase overview.html
Kaz: I think you can merge everything and check static versions again .. without Netlify
Ege: changes done are
… Github vs GitHubAPI
… local vs absolute urls
Jan: is the date correct ?
Ege: During publication it will be changed
… will merge PR and do final checks
… I also documented the process in README.md
… merging PR 290
Ege: Next step? Re-check with deployed documents?
Kaz: I can double check document
… and publish note with automatic publication tool
Koster: Sounds good also from side
Ege: All checks seem to be fine on the following document
<Ege> https://
Kaz: I suggest we make quick resolution
<Ege> proposal: After doing the publication checks, the TD/Binding TF agrees to proceed with the publication of the https://
RESOLUTION: After doing the publication checks, the TD/Binding TF agrees to proceed with the publication of the https://
Ege: Thank you everyone!
TD
Publication Preparation
Ege: Implementation Report Update: w3c/
Ege: McCool working on implementation report update
… in testing call we had a look
… editorial changes
Cristiano: I think I am missing on contribution list
Ege: Correct
… Mizushima-San seems to be missing also?
Mizushima: Not sure I understand
… I think I didn't submit implementation report
Ege: McCool will have a final look and than we can merge
At risk items section
w3c/
Ege: PR should resolve ReSpec warning
Ege: Question to Kaz. Para after removed section.. should we keep that?
Kaz: Boiler template which should not be changed
Ege: Any objection before merging PR 1783?
--> none -> merging
PR 1837
w3c/
Example Tabs
w3c/
Ege: PR fixes issue with examples
Ege: default values check box
… should be able to close issue "by PR transition"
Daniel: issue we had in the past, https://
… no issue anymore
Ege: Objections to merge PR 1836
-> none -> merging
TD.next discussion
<kaz> Slides
Koster: we want to start with a revision, a big picture revision, not necessarily technical
Koster: I see 3 big bits: general structure, integrating protocol binding and better integrating Thing Model
… regarding tm optionality: TD is really towards hypermedia, it is concrete. TM is different
Cristiano: We have a nice information model but it is very tied to JSON LD (serialization). DID did it better.
Koster: you have said it better. that is what I have in mind
Ege: we also put some important conceptual part in the serialization section, it is confusing
… and examples are only in the serialization section
Luca: I would like to make sure that if we are refer to another spec, we are clear about it
Luca: some terms we specify in data schema are slightly different than what is in JSON Schema
Luca: we should be clear about this, I have opened an issue as well
Koster: it is an important point
Luca: we should not have redundancy
Luca: where do you need json-ld processor for example? json or jsonld processor need different requirements
… consuming a TD has no minimum requirements at the moment
… and reducing redundancy like not making sure that we do not need to parse a form twice to understand if you can use that form
Kaz: we need more input from developers. No need to go into detail today
<Mizushima> +1 kaz
Koster: WoT is not a protocol
Koster: We have the concepts of different types of bindings but we have design that a bit better
… we have the need for external work for the protocol bindings
… the registry option is definitely to be considered
… TMs are currently not consumed by the clients but by tools
… we need to think more about the TD expectation from the TM
Luca: Thing Models are a templating system. Some use TMs to validate TDs is a bit weird but can be done. Some use it like a semantic annotation. it conflicts with JSON-LD mechanism
McCool: we should wrap up and create agenda items for the planning meeting
Implementation Report Update
<kaz> wot-thing-description PR 1835 - Update Implementation Report
McCool: it is PR 1835 in TD
Ege: we made a small comment regarding cristiano being missing
McCool: I need to copy it to the template as well
McCool: I have done the changes
McCool: we also miss an implementation description for zion
Cristiano: i can submit it
McCool: good, can you do it by tomorrow
McCool: we can remove it from here and add a reference to architecture
Kaz: all the implementation reports will have the same list?
McCool: arch will have all, td almost all since not all discovery implementations expose TDs, some only read TDs (not consume)
Kaz: in that case, having all the descriptions of all the implementations in both the specs separately would make sense (than putting a link from the TD Implementation Report to the Architecture Implementation Report.
McCool: would confirm how to deal with that during the main call on June 7.
McCool: (shows the changes)
McCool: I took out a section about explaining lacking feature implementation
McCool: associated organization and then the old one
… any objections?
<McCool> proposal: Distribute the draft of the IR report for TD 1.1 for 1 week of review and include it (after incorporating any final changes brought up during review and finalizing the System descriptions) as part of the TD 1.1 PR transition request.
<McCool> proposal: Distribute the draft of the Implementation Report for TD 1.1 for 1 week of review and include it (after incorporating any final changes brought up during review and finalizing the System descriptions) as part of the TD 1.1 Proposed Recommendation transition request.
RESOLUTION: Distribute the draft of the Implementation Report for TD 1.1 for 1 week of review and include it (after incorporating any final changes brought up during review and finalizing the System descriptions) as part of the TD 1.1 Proposed Recommendation transition request.
<kaz> [adjourned]