Add Use cases section #130
Conversation
There was a problem hiding this comment.
As I recall it the consensus on this PR from the WoT Architecture call last week seemed to be:
- Introductory text belongs in the introduction section
- Use cases belong in the Use Cases and Requirements document
I've provided some additional feedback inline.
index.html
Outdated
| Several of these domains require easy integration of devices from multiple vendors, | ||
| in other words, out-of-the-box interoperability. | ||
| However, the descriptive approach taken by the WoT specifications generally leads | ||
| to a very large space of possible devices which can work against out-of-the box interoperability. | ||
| </p><p> | ||
| For example, a WoT Thing Description (TD) can in theory include a description based on a | ||
| networking protocol unknown to a device that wishes to connect to it. | ||
| To ensure interoperability without additional setup or configuration, | ||
| the range of such choices needs to be limited to a finite set so that a consumer | ||
| of a Thing Description can be sure it will be able to interact with any possible Thing. |
There was a problem hiding this comment.
This seems to be duplicating text which is already in the Introduction section:
The W3C WoT Architecture [wot-architecture] and the WoT Thing Description [wot-thing-description] have been developed as a versatile format, that allows describing the interactions between multiple devices and protocols.
This flexibility permits an easy integration of new device types and protocols, however it risks interoperability, since there are no guarantees that two devices which are formally spec-compliant, will be able to communicate.
To increase adoption of the WoT specifications, interoperability between on premise devices, edge devices and the cloud is essential. Even if every manufacturer is implementing the current Thing Description specification in full flexibility, there is no interoperability guarantee; many choices are still left to the implementations and there are very few normative requirements that a device has to fulfill.
There was a problem hiding this comment.
I don't think this we have duplicated text, perhaps this comment applied to the outdated version of this MR?
There was a problem hiding this comment.
Yes, this is marked as "outdated"
There was a problem hiding this comment.
Is there anything left to be done?
|
I retarget the use case summary to the introduction section as we discussed in a recent arch call. |
There was a problem hiding this comment.
Hi @mlagally, thanks for the updated PR. My previous feedback still applies though:
As I recall it the consensus on this PR from the WoT Architecture call last week seemed to be:
- Introductory text belongs in the introduction section
- Use cases belong in the Use Cases and Requirements document
Whilst I broadly agree with the original "Multi-Vendor System Integration - Out of the box interoperability" and "Cross Protocol Interworking" use cases from the Use Cases & Requirements document, I don't really agree with the way they are characterised here.
I suggest it would be better to link to the original use cases rather than try to reinterpret them here.
I don't really think we need re-worded versions of the use cases written in the document in this way, and it's not clear to me that profiles really do fulfil the use case of cross-protocol interoperability.
I think the fundamental disconnect we have here is that we agree that profiles provide interoperability between devices within the same profile, but I don't really agree that they provide interoperability between devices using different profiles.
The variety of protocols, data formats and application domains that can theoretically be described by a Thing Description is so vast and diverse, that I don't believe that a common set of constraints beyond those already defined in the Thing Description Information Model can realistically be set, or that they would really do much to aid interoperability. It will still always be necessary for a gateway or software adapter (or "agent" as you put it) to translate from one protocol and/or data format to another.
Let's discuss this further in tomorrow's call.
|
Hi @mlagally, thank you for responding to some of my comments. Please note that there are still 8 comments which have not yet been responded to. You may need to click "Load more..." to see them. More importantly, I think we still need to discuss the high level point I raised in #130 (review) regarding interoperability within profiles vs. interoperability between profiles. I have doubts about whether Profiles can really help with the "Cross Protocol Interworking" use case, which seems more relevant to the protocol-agnostic Thing Description specification. |
I think CPI is off the table at this point - I have removed the text.
There may be cases where a profile is a subset of another one (think about the small embedded case), but this should not be a general assumption. I have incorporated most of your proposed changes and suggest we merge this PR. We can handle further improvements in new issues. |
index.html
Outdated
| <p> | ||
| A set of over 30 use cases for the Web of Things were contributed by stakeholders | ||
| from multiple industries for various application domains. | ||
| These have been published in the WoT Use Cases and Requirements document [wot-use-cases]. |
There was a problem hiding this comment.
[wot-use-cases] -> [[wot-usecases]]
(Broken reference)
index.html
Outdated
| </p> | ||
| <p> | ||
| In addition to multiple vertical use cases that will use HTTP(S) for their implementations, | ||
| there are two key horizontal use cases that are addressed by this profile specification. |
There was a problem hiding this comment.
There's now only one. Might want to re-structure this.
index.html
Outdated
| <section id="profile-use-case-MVSE"> | ||
| <h2>Multi-Vendor System Integration - Out of the box interoperability</h2> | ||
| Users of devices want to process data from all devices that conform to a class of devices in a uniform way. | ||
| They need a guarantee that he is able to correctly interact with all affordances of the Thing |
index.html
Outdated
| This separation makes it possible to define common protocol agnostic | ||
| rules that enable these use cases. |
There was a problem hiding this comment.
This sentence feels out of place since the cross-protocol interworking use case was removed.
- There is now only one use case listed
- What kinds of protocol-agnostic rules does this separation make possible?
There was a problem hiding this comment.
I changed the text to:
This separation makes it possible to define common protocol agnostic
rules that enhance interoperability between different protocols.
Examples of rules/bindings are common brhavior and data structures for different protocols.
Think of the sync and async actions, the same behavior could also be provided in other protocol bindings.
index.html
Outdated
| Users want to integrate devices in existing scenarios out of the box, i.e. with close to zero configuration tasks. | ||
| </section> | ||
| <p> | ||
| A major benefit of the WoT architecture and the Thing Description is the clear |
There was a problem hiding this comment.
The following text will be eliminated.
Preview | Diff