W3C

– DRAFT –
WoT Use Cases

09 October 2024

Attendees

Present
Ege_Korkan, Jan_Romann, Josh_Thomas, Kaz_Ashimura, Luca_Barbato, Michael_McCool, Tomoaki_Mizushima
Regrets
-
Chair
McCool, Mizushim
Scribe
EgeKorkan, kaz

Meeting minutes

Agenda

<kaz> Agenda for today

Mizushima: (goes over the agenda). Minutes review, tpac wrap up, use case internal trial, requirements

Meeting schedule

Mizushima: I will not be available on oct23

McCool: but let's keep the meeting and I can chair it

Minutes Review

<kaz> Sep-18 minutes

Mizushima: (goes over the minutes)
… we discussed TPAC planning, schedule. Then talked about the internal trial.
… any opinions on the minutes?

Mizushima: Minutes are approved

Wrap up TPAC24

<kaz> TPAC WoT Meeting - Day 1 - Use Cases and Requirements

McCool: There is a small mistake in the requirements section
… "use case story" should be "user story"

McCool: I think we should look at how the Spatial Data in the Web WG does it

Mizushima: we can approve minutes from TPAC24 on the use case session

Use Case Trial

Mizushima: Is there any issues on the trial?

McCool: we should put a deadline for the changes to the template. If there is any feedback, please open an issue

McCool: people can comment on the issue to improve the template

McCool: Rob said that there are use cases and use case scenarios

McCool: they are not end user cases
… for Rob, they are user stories

McCool: ege's examples were more feature requests

McCool: the TD examples are feature requests that are placed in use case scenario

Kaz: I have asked the group to include the scenarios in the use case descriptions

McCool: it would be also weird to include two types of "submissions" in the use case document

McCool: we want people outside to submit features since they are not able to do something

Kaz: from my viewpoint, "use case scenario" a sequence of device or user behavior or results.
… but maybe the SDW guys use "use case scenario" for a bit different meaning, so I'd suggest we should look into their definitions in their document

Ege: "who is the user" is not clear for me. the developer or end user of an application?
… also I want to see examples for each of these terms

McCool: feature comes from developer and use case comes from a business point of view

Ege: If use cases are end user view, then the current use case document has just that and is merely a marketing document

McCool: if there is no end user scenario but it is a developer pain point, that can be a category but even a developer is working under a context

Ege: not always if they are building a library, e.g. node-wot which is used in multiple domcains

McCool: they can be all written down as application areas

Ege: can you give an example of an end user use case driving a technical feature

McCool: in a farm with contrained battery powered devices, they need to support CBOR-LD so that they be more efficient

Ege: ok I understand

Ege: in this case, even this submission would have a feature request in it

McCool: yes in a way

Ege: I would be fine if there is always a "demand" from the submission to the standards

McCool: not really. A use case can be explaining how WoT is used

Ege: why do we care?

McCool: because the W3C is asking for it when we go to REC

Luca: somebody can ask for a feature but there has to be a why.
… we also have the other side. I want a pony but there is no detail on what is going on

Luca: we should welcome use cases when a company says "we want to use WoT because we cant and here is the reason why"

Luca: I also agree that categories is a good idea

McCool: we have several problems

McCool: in a use case, people may not provide enough detail

McCool: then developers who have a limitation that is blocking them

McCool: and in the end going to REC, we have explain why we are working on the standards

McCool: last problem is that we also have a lot of use cases.

<McCool> my proposal: separate use cases and feature requests. Feature requests can be in the form of user stories, and link a feature to a purpose. The purpose can be a single use case or a category of use cases (e.g. use cases needing efficiency). If accepted, a feature request becomes a requirement.

Ege: we can use the current template since if they don't provide a technical expectation it can be a user story

<kaz> Transition Issue for CR

<kaz> Process Doc

McCool: it can work but it would be cleaner to separate

Jan: I agree with separation

Kaz: I would like to remind you all of the W3C Process which requires us to show the fact the specification (as a CR) meets all the WG's requirements. For that purpose, we need a document of use cases
… and feature requests can be formed from requirements

Mizushima: feature request driven by use case is good. We need evidence of feature request requirements
… I agree with mccool

Ege: could you provide definition and example of each terminology we want to use?

McCool: I will try that in an issue

Kaz: and McCool, please talk with Mizushima-san again about how to organize the UC calls./

McCool: will do

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 237 (Fri Oct 4 02:31:45 2024 UTC).