Meeting minutes
Minutes
<kaz> Oct-26
Mizushima: from Oct 26 last year - uc call has been suspended for a while
… we discussed discovery and security
… if there are issues please tell me...
<Ege> looks good to me
Mizushima: ok, no comment, minutes are approved.
Process
Mizushima: many issues and PRs in repository, but need also to discuss some organizational issues
Mizushima: Issue 257 raises the issues of functional vs. technical requirements
… would like to first discuss goals and purpose of use case requirements
… so wrote this document
<Mizushima> proposed process
Mizushima: draft; many task forces that have different deliverables
… want to define several phases: use cases, requirement extraction, gap analysis, feature definition, spec generation, testing, publication, backlog
… use cases should be the starting point
… for each phase, say which group is responsible for it
… and so UC role is UC definition and requirement extraction
… gap analysis also checks if some other standard already exists that is appropriate
Kaz: think this is a good direction
… and consistent with TD task force has been doing
… we should ask participants for input, more precise definition of each phase
… then next time we can think of more concrete template and process
<Ege> relationship document as part of the Charter discussion
Ege: some overlap with relationship document, e.g. testing
… should make sure these are aligned
… should also add if no gap detected, don't proceed to step 4
… next, do we collect any use case? Do we collect use cases for things we know work, or ones that we know there is a gap?
Mizushima: is a draft, want to revise
Ege: what do others think about 3?
Kaz: in morning Mizushima asked for help - regarding gap analysis, need to brush up definition
Kaz: need to consider how to generate potential use cases to address gap
McCool: do feel strongly we need to justify our current feature set and capture requirements from our current set
Mizushima: WoT WG is working on deliverables for new Charter period
… we need to figure out role of UC tf for that charter
… are many stakeholders - many are not WoT-specific
… we need to think about what we want to gather for use cases
Kaz: comments on Mizushima's point - WoT WG is working on new deliverables, and further deployment; WG and IG collaboratively should be considering new use cases as well as existing ones
Cristiano: reusing what we have so far, but noticed we have a lot of feature requests written as use cases
<Ege> +1 to cristiano
Cristiano: should review and categorize these issues before we go looking for new use cases
… we have a lot still to look at
Mizushima: that is important also
Lagally: think this is useful, and help to structure the process and make it more formal
… at a high level do not see any significant misalignment with Ege's and this document
… uc has a number of purposes
… one is to identify gaps
… but has other purposes
… for one, it can show to potential adopters some potential applications
… it can also show interest by stakeholders in using WoT
… so I think the current document needs to be refined to show what can and can't be accomplished with current specs
… for example, for multimedia and digital twins there is still some work to do
Lagally: state of requirement analysis - there are already many use cases that cannot be satisfied
McCool: agree with Lagally's points: we already have many use cases which we cannot address; template for requirements can indicate whether satisfied by current specs.
Kaz: today's discussion is brainstorming, we should refine phase definitions. based on today's discussion, we should think about concrete template to describe use cases, requirements and gap analysis, then also how to transfer the results to each spec TF.
Ege: to comment on outreach functionality, arch document also does this
… e.g. chapter 4 and 5 in architecture
… if we also use UC doc for that, it is redundant
… talking to people outside, they use the arch doc for that purpose
… one thing we can do - if we find no gap, perhaps we can put it into the arch document as a "where things work" example
… but should be group opinion
<Ege> w3c/
Lagally: thanks for bringing up arch; I think UC doc has different information, showing interest of stakeholders
… that information is not in architecture
… regarding the templates, was motivated by multimedia group, it can at least be a starting point; same for requirements
… e.g. start with existing basis, going back to greenfield only if there is a good reason
Mizushima: we should be discussing gap analysis with each task force
Mizushima: after this discussion we should merge that idea
McCool: should be clear what we want out of the process: we need clear connections between features and use cases, via requirements, for reviewers to see
Kaz: consider possible feedback from each phase back to specifications
… need to involve TF editors
<mlagally_> +1 to Kaz
McCool: I think TFs are the experts, and can propose requirements, as the uc proposers often cannot
… a good example is security, where uc proposers often did not provide enough detail
McCool: however, *prioritizing* requirements is something the entire WG should decide
Lagally: need to distinguish between business and technical requirements
… do need to involve uc as much as possible to understand what capabilities they need
McCool: think we need a level of detail between business and technical requirements (e.g. functional)
Kaz: so need to think about how to deal with wide review points, e.g., security and privacy, within the use case description and requirement description.
Ege: return to an earlier point, arch vs uc
… if we value people aspect, I think we could still remove uc from architecture
<JKRhb> +1
Ege: also, since we are talking about two goals, perhaps should separate them
<cris_> +1
Ege: we have been talking about user stories in TD
… these are much easier to turn into requirements, more specific
… the current use cases are quite broad and often non-technical
Kaz: need to include user's viewpoints and needs in uc description
… but should think about arch and uc doc separately
McCool: do think a few examples in arch are useful, but right now is quite long
… do think we don't need a complete analysis of all deployments there
Ege: in that case we may want another section in use case document that is a distillation of patterns
… that would correspond to current sections 4 and 5 in architecture
<mlagally_> +1
Kaz: agree with McCool and Ege
… for concrete uc proposals, can accept various ones
… but should think about what is the "typical" use case, categorize some of the duplicate ucs, prioritize
… generate "atomic" descriptions
Mizushima: is use case section in architecture document, but those are different from those in UC & R
McCool: so the UC&R document is also supposed to have *requirements*. Right now this requirements analysis is also done in Arch redundantly
… I think the UC&R doc should collect use cases, analyse them, extract requirements, and arch should just state arch that satisfies them
Kaz: think we can port the appropriate sections from arch to UC&R document
Ege: would prefer to see that material from arch 4&5 moved to UC&R
… I think this is mostly a historical thing
… at the very least, there has to be a clear connection
Lagally:
<kaz> Section "4. Application Domains" from WoT Architecture 1.1
Lagally: section 4 is application domains, e.g. verticals
… having verticals in architecture makes sense, but agree in principle that details belong in UC&R
… would not be too religious but we should look into having alignment and consistency
… application domains are not use cases
… these do help the reader understand the goals and applicability of WoT
Kaz: this is a good starting point for both UC&R and Arch, but regarding Arch itself, we should discuss that during the Architecture call.
Kaz: during UC&R call should discuss what to be imported from the Architecture spec to the UC&R document.
<mlagally_> Unfortunately we are out of time. I have to move on to a different call
Ege: however, even chapters are structured very similarly, and think that the material in arch would in fact move over very easily; I do think the audience is the same
… think the audiences for these documents are the same
Sebastian: want to support kaz that we should discuss Arch
… should organize a meeting for Arch
McCool: need actually to discuss at the WG level
… but we can make the proposal
Ege: agree, but still the same people
McCool: true, but procedurally we need a resolution in the WG call; suggest making an issue in the wot repo
Kaz: or an Issue on wot-architecture
Sebastian: time check
<kaz> [adjourned]