Clarify Expectations for Coverage Table

[mmccool]

It's not clear what the expectations are for the coverage table. Are we identifying gaps (e.g. need for geolocation in discovery), requirements, or whether or not a given use case impacts the definition of a particular deliverable, or whether the current deliverable definition satisfies the requirements of the use case?

We need a README or something clarifying what needs to be done here.

See also similar issue #392 in the Scripting API. Suggest we consolidate discussion here since this relates to other deliverables as well.

[mmccool]

What I think we really want is:

1. A (separate) list of requirements, ideally numbered, captured from the entire set of use cases.
2. For each use case, a list of the requirements it has
3. For each deliverable, which requirements are satisfied by the current spec and which are NOT.

So in the end this table could have something like "1, 5, 6; gaps: 7, 8" under "Discovery" for instance (where the numbers refer to a different table giving all requirements.

For an example of how we could organize this, see Edge Computing Use Case and Requirements analysis from WNIG.

[mmccool]

See also Natural Language Interface Accessibility User Requirements (for accessibility), but this only talks about requirements, not use cases.

[sebastiankb]

For TD, I started to comment on the use cases in this issue here. I'm not sure what have to be recorded in the table exactly. There are already comments like "device shadow" or "simple rules/automatic onboarding/configuration" in the TD column. Does this comments mean "this is missing" or "is possible"?

[mmccool]

What we discussed in the minutes from March 20:
MM: I understood we wanted three states: "partial", "gap", "null" for whether or not the current specification of the given deliverable satisfies the requirements for a given use case. Maybe "satisfied" as well? Edit: empty means "satsified"

[mlagally]

For TD, I started to comment on the use cases in this issue here. I'm not sure what have to be recorded in the table exactly. There are already comments like "device shadow" or "simple rules/automatic onboarding/configuration" in the TD column. Does this comments mean "this is missing" or "is possible"?

We want to identify the gaps at high level, i.e. the table should contain requirements that are not satisifed. Please add just a few words to denote the requirements, if there's no gap please mark with "-".
Due to the nature of the table, these need to be separated with "/"

[egekorkan]

I think that there should be a couple of example lines that show possible values these cells can take. Also, we need a way to say that this use case is not clear or it is not applicable to this specification. For example:

• https://w3c.github.io/wot-usecases/#smart-agriculture is clear but is not applicable to binding templates since it does not mention protocol, media type or specific platforms.
• https://w3c.github.io/wot-usecases/#smart-building shows a clear gap of the lacking protocol binding template for KNX and BACnet. However, this is only understood from the text, which is dependent on the author.

I think Scripting API will have many not applicable use cases since the use case is very low level and if the underlying implementation supports the protocol etc., it is implementable in scripting API. There is one I see at https://w3c.github.io/wot-usecases/#smartcity-dashboard that mentions image streaming and I am not 100% sure if it is possible in scripting API (@danielpeintner @relu91 ?)

[mlagally]

@sebastiankb , @danielpeintner , @mmccool , @egekorkan :
To clarify the expectation and format, I have created a corresponding README in: https://github.com/w3c/wot-usecases/blob/main/USE-CASES/README-coverage.md

Note that I added a "Comments" column to the table, so please put further comments there.
Please leave the "requirements" column blank for now, @mmccool is working on a requirements table that will be enumerating requirements to allow for clear reference.

[mmccool]

I'd like to propose the following: if you want, rather than trying to squeeze in a definition of each requirement into the cell in the coverage table, reference a requirement from the (proposed) requirements summary table, e.g. "R1f, R2".

However, in some cases people might want to identify things that ARE satisfied rather than gaps, so I would like to suggest the format "gap R1f, R2" means they are not satisfied (this can be assumed if there is no label) and then "sat R5, R6" means these ARE satisfied.

You should first scan the requirements table for an existing requirement and reuse one if possible (creating a PR to add in a new Use Case for that requirement if necessary), but otherwise, if you find a new requirement, adding it to the table with a PR and citing it.

Then as people go through the use cases we ALSO collect a table of requirements cross-referenced with use cases - which we need for the document anyway.

Also, gaps/satisfied should be relative to the current specs on the table, e.g. TD 1.1, Arch 1.1, Discovery (1.0), etc. "Proposed" things, like an OPC UA binding, should be considered gaps...

[mmccool]

I think to Ege's point, an additional value of "not clear" may be needed in some cases.

[mmccool]

If a use case does not mention a requirement, but you think it applies, maybe "poss R5"?

[egekorkan]

I will take over some of the load for TD and Binding templates and go through the Smart Building use cases.

[relu91]

There is one I see at https://w3c.github.io/wot-usecases/#smartcity-dashboard that mentions image streaming and I am not 100% sure if it is possible in scripting API (@danielpeintner @relu91 ?)

In principle is possible, but we lack implementation experience (i.e., node-wot does not support it).