Meeting minutes
Agenda Review
Ege: Does anybody has something specific to discuss today?
<kaz> (none)
Minutes
<kaz> Dec-13
Ege: There is a typo, beside that anybody has other issue to address?
(none)
<kaz> (typo fixed)
Ege: minutes approved
TD Call slot
Ege: Everybody received the notification ?
Luca: I did, so others should
<kaz> Wed slot 1
<kaz> Thu slot 2
Daniel: The calendar is showing this slot as 2hours still
Kaz: people should remove the old entry on their calendar, then import the new entry
Luca: it is fine for me, probably refreshing fixes it.
Ege: From mid January, Wed we prioritize TD.next topics, on Thur we prioritize Bindings topics
Wiki organization
Ege: I propose to move the old entries in per-year subpages
Ege: Anybody against it?
<kaz> https://
<kaz> (none)
Daniel: we should also clean up the other wiki pages
WoT Resources
Ege: how do we want to do the versioning?
Ege: How do we want to do this?
Kaz: I suggest we clarify what we mean with versioning, both as TF and as whole WG
Kaz: we should also describe clearly which are bugfixes and which are new features
Ege: for 1.1 I would only consider bugfixes
<Zakim> kaz, you wanted to react to kaz
Kaz: so bugfixes can cover ttl jsonschema and html, each might have different meaning
Koster: I agree with MM we should track all changes, and I suggest to use semantic versioning with its 3 levels, major.minor.patch
<kaz> semver.org
Koster: <summary of semver.org>
<cris_> +1
Luca: semver is easy for us since we are already 1.0 and 2.0, with 1.1 we are backward compatible with 1.0, do we want 1.1.1 with other bugfixes? How much time are we going to devote to it?
Ege: how we explain to the users?
Ege: also how we maintain compatibility regarding our urls?
Luca: we can use incremental uris, the uri for v1.1 always picks v1.1.{latest}, if you request v1.1.n you get this, if you as v1 you get v1.{latest}
Ege: we should make sure the jsonschema is not having breaking changes introduced unwillingly since adding items adds restrictions
Kaz: We should clarify which are the resources provided now
Kaz: shall we start from 1.1.0 for TD 1.1? and use 1.1.1 for the first bug fix? ?
Kaz: also we need to think about how to map the latest/fixed version to the published URI.
Daniel: For the time being, this should be done for TD.next
… for TD 1.1 we have the release done, so it is not high priority
… hopefully we might not need that in 1.1
Kaz: agree, so suggested we think about how to deal with bug fixes for 1.1 specs and big changes for 2.0 specs separately.
Ege: in case we have to do bugfixes, we will have to decide if to do that in-place or make a patch version as 1.1.1
Ege: for TM.html and svg I'd do that in-place
Ege: I'll open an issue to track this
Specific Bindings Templates
Ege: no new PRs beside what we discussed in the previous call
TD
Repo snapshot for REC 1.1
Ege: I tagged REC 1.1
<Ege> https://
Merged folder deletion PRs
<kaz> PR 1943 - Delete images directory
<kaz> PR 1942 - Delete test-bed directory
Ege: I merged the PRs that remove unused directories
Work items
<kaz> work-items.md
<kaz> (quickly skimmed)
PR #1946
<kaz> PR 1946 - SVGs in editor's draft instead of pngs
Ege: this replaces PNG files with SVG files
… any objections to merging?
… merged
Kaz: the architecture spec used the PNG as a fallback
… do we want to do this? I myself am OK with SVG only, though.
Ege: our use case is different, the PNGs are not auto-generated
Daniel: best case is we could use SVG only
PR #1945
<kaz> PR 1945 - Assertion id alignment
<kaz> wot-thing-description/testing/assertions.csv
Ege: manually changed all the entries to align them.
… this is a one time change and will impact some of the tooling
… any comments or concerns?
Kaz: is the same style used for all of our specifications (TD, Discovery and Architecture)?
Ege: there are similar patterns in the assertions for the other specs
Kaz: we need a unified style for the 2.0 publications
Ege: any objections or comments?
Ege: convert PR #1946 to draft
Issue #1926
<kaz> Issue 1926 - Aligning formatting accross files
Ege: does anyone have a preference on formatting standards?
Kaz: what kind of style and which documents?
Ege: there are differences in whitespace that make diffs hard to work with
… propose a standard editor config file
Kaz: we can use html tidy
Daniel: people are using different tools, so maybe we should implement CI checking
Cristiano: there is prettier for diverse file types
… can be used in vscode
… the CI approach could result in a feedback message to the committer to fix the whitespace
… the functions are similar but editorconfig files can't be used in the CI pipeline
(see https://
Ege: will look at integrating editorconfig and prettier into the CI pipeline
Kaz: remember that we already have a solution of htmldiff for html files
Ege: only the editors need to worry about this
project management
Ege: continuing the discussion from last week
editorconfig - revisited
Kaz: is editorconfig for UNIX file systems? Remember the W3C server is UNIX-based.
<kaz> charset = utf-8
<kaz> insert_final_newline = true
<kaz> end_of_line = lf
<kaz> indent_style = space
<kaz> indent_size = 2
<kaz> max_line_length = 80
<kaz> on https://
Cristiano: it is an issue
… but it can be made to work
Ege: is the only issue line endings?
Cristiano: yes
Project management - revisited
<kaz> @@@ Kaz will fix the subtopic sections later
Ege: PR #1944
… overview of workflow
<kaz> PR 1944 - More concrete project management proposal
<kaz> Strategy Pipeline
Kaz: W3C strategy has a project management framework defined with specific phases that we should use
… and for us as the WoT WG, we could define several phases for spec generation => testing, foe example, use cases => requirements => gap analysis => spec generation
Kaz: it seems the proposal in PR 1944 is focusing on the "spec generation" phase, but we might want to think about a broader workflow like above.
Ege: yes, this is the idea
Ege: this is too complex
Cristiano: this is better than nothing
Koster: it's a good starting place
Cristiano: we can improve later while we go along
… but we should capture this now
Ege: merged PR #1944
use case analysis
Ege: not sure about how to do this, so reviewing how we did it in the past
… using synchronous action interaction method as an example, the use case involves adding a keyword and develops an underlying robot behavior use case
… so there is a feature ("synchronous" keyword) and the underlying use case that sets the requirement
Kaz: are we discussing topic 10 or #11
Ege: the discussion includes both
Ege: this is one example of how we developed features from use cases in the past
Kaz: is this for creating a use case?
Ege: this is how a use case can justify a feature
Kaz: this isn't a good example for a use case process
Ege: no, this just an example how we did it in the past, not a proposal
Ege: some other examples from past use case work show use cases that are difficult to extract requirements from
… the use cases need to be much more specific in order to derive requirements from them
Kaz: the problem is caused by the use case document itself. Smart city is too big a topic
… there could be multiple topics that aggregate to the higher level topic
Ege: even a subtopic like traffic control is too big
Ege: this is why we need to restart the use case discussions as soon as possible and decompose some of these to the right level of granularity
Ege: we should get use cases that are not yet met by WoT
Kaz: we should clarify which level of description is appropriate for driving the next specification
Kaz: go beyond use cases to include scenarios
… we should not handle everything here but concentrate on the most important pieces
Ege: we could filter everything that doesn't have a gap analysis
Cristiano: use cases make sense to understand the overall picture but user stories are closer to what we need to derive feature requests
Cristiano: the framing of user stories is easy to apply, where the user is a developer using TDs
Kaz: we need to think about how to extract requirements from use case descriptions
… instead of thinking about each use case one by one we need to have use case grouping
Ege: ajourned