Closed mmccool closed 1 year ago
benfrancis
commented
5 years ago I would caution against rushing to define multiple profiles (I personally wouldn't have called it a "profile" in the first place, but rather a default protocol binding). I suggest starting with a single core profile as a baseline for interoperability and only define additional profiles if there are compelling reasons which justify the resulting fragmentation in interoperability.
mlagally
commented
4 years ago Call on 23.7. In the previous call we discussed and agreed on a single profile addressing a limted (and defined) set of requirements for the FPWD. Resolution was: Accepting the following requirements for the FPWD: Interoperability, Limit and reduce complexity, Eliminate ambiguities, Limit resource consumption, finite set of features and capabilities, follow security and privacy best practices subject to group feedback (For full list of proposed requirements see: https://github.com/w3c/wot-profile/blob/master/REQUIREMENTS/requirements.md)
benfrancis
commented
4 years ago I understand from the meeting minutes that this was discussed in the last use cases call and it was hoped I might respond here so I thought I'd provide some feedback.
When we first discussed the profile mechanism I saw it as an opportunity to enable ad-hoc interoperability on the Web of Things by defining a more constrained and concrete set of requirements that a WoT client could support in order to guarantee interoperability with any WoT device following a common core profile. This would achieve the kind of interoperability we had been advocating for at Mozilla, by providing something closer to Mozilla's Web Thing API which provides a more concrete HTTP-based protocol specification for greenfield devices to implement. This was my reason for recommending a single core profile and particularly for avoiding multiple application domain specific profiles (e.g. separate profiles for industrial and smart home applications) which I felt would work against that goal.
I think the set of requirements proposed above for the FPWD are mostly in line with that original goal and I support them.
However, having read the latest Working Draft of the WoT Profile specification I tend to agree with @mmccool that there are currently some potentially conflicting requirements mixed in there and that ideally the focus of the core profile should be on interoperability. In particular the desire to limit resource consumption seems at odds with the desire to improve human readability and the suggestions for increasing the number of mandatory and recommended fields inside a Thing Description.
We can discuss the merits of the individual constraints as we move forward (I think some of them should probably just be moved to the Thing Description specification itself, or removed altogether). But one thing in particular that sticks out to me is the presence of constraints designed to limit resource consumption by limiting the sizes of certain values to 64 or 512 characters, whilst also making many more members like description, support, created, modified, version etc. mandatory and many others like serialNumber, loc_latitude, loc_longitude, loc_altitude, loc_height and loc_depth recommended.
If a device is so constrained that it can only handle titles up to 64 characters in length then there are other factors which are going to be far more important for those devices, such as the protocol and serialization format being used.
So to address the point of a single vs. multiple profiles, I think some bad examples of profiles would be:
However, if we define a core profile which has an HTTP protocol binding as a minimum requirement but there are some devices for which HTTP is just too heavyweight due to hard technical limitations, I do agree there could be an argument for a separate "constrained" profile for constrained devices. E.g.
This would result in all clients which support the core profile being able to communicate with all devices which use the core profile, and all clients which support the constrained profile being able to communicate with all devices which support the constrained profile, but would mean that clients which only support the core profile might not support devices using the constrained profile or vice-versa. This would mean a bit more fragmentation, but may be a necessary compromise to improve interoperability among constrained devices.
An alternative approach could be a single core profile which requires a device either supports HTTP + JSON or CoAP + CBOR such that all clients must support both but devices may support only one or the other.
Either way, I'd suggest starting with the core profile but evaluating whether the constraints designed to limit resource usage are actually of any practical use if such constrained devices couldn't support HTTP anyway. And before defining a profile for constrained devices, we should look at existing work in this area like that of the OCF and consider whether their work could form the basis of that profile.
As an aside, if the core profile does in fact mandate HTTP support as a minimum requirement and describes a more complete set of defaults for communicating with a device over HTTP, I'm hopeful that the Web Thing Protocol Community Group could defer to that specification rather than define its own HTTP protocol binding and instead focus on defining a WebSocket sub-protocol.
Currently this spec lists three goals: improve interoperability, limit implementation complexity for resource-constrained devices, and improve human readability.
I think we should focus profiles on the first goal, or at the very least, break things up (for example, by defining multipe profiles) so it is clear which restrictions contribute to which goals.
The last goal (human readability) in particular may also be at odds with the second goal (resource constraints); needing to process long descriptive strings means resource-constrained devices may have to allocate memory for these strings even if they have no way to use them.
A compromise here might be to make title required and descriptions recommended. This still makes it possible to display, for example, controls on dashboard UIs.
Another way to resolve this would be to include in the distribution mechanisms for TDs (which we also need to work on standardizing...) a way to control the human-readable content in TDs and filter it out when it is not needed. If a resource-constrained device is accessing a TD (say, a light switch looking for a light to control) then the human-readable information is just a waste of bandwidth.
I actually agree however with the desire to encourage human-readable content in "master" TDs stored in databases or provided to gateway systems that need to present UIs. However in this case we probably also need to worry about internationalization, etc. So perhaps we need a "HumanReadable" profile that includes not only "title" and "description" but has multilanguage content.