You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has been proposed that the discovery/directory service, which is planned for the next charter, should be a prescriptive specification.
If it is prescriptive, it would put obligations on implementers of existing systems that are endangering the adoption of the family of WoT specifications.
In multiple deployments there are already directories / discovery mechanisms in place, so WoT should be just able to describe, adopt and use these.
We should not put additional obligations on existing systems without a very clear discussion of the use cases and requirements that would not be possible without them.
The text was updated successfully, but these errors were encountered:
My idea here was that the discovery service we define would be prescriptive in that it would be fully specified, which we need to do to have a "full system" that we can evaluate for eg security and privacy. However, it would not be MANDATORY; we certainly should allow other ways to distribute TDs than the discovery service. The point of the service is to discover TDs. Other ecosystems can have their own discovery mechanism but currently will not return metadata in the form of TDs, so a "new" discovery mechanism is reasonable. However, I think we should certainly build it on top of existing mechanisms, such as CoRE Resource Directories, and not reinvent the wheel.
It has been proposed that the discovery/directory service, which is planned for the next charter, should be a prescriptive specification.
If it is prescriptive, it would put obligations on implementers of existing systems that are endangering the adoption of the family of WoT specifications.
In multiple deployments there are already directories / discovery mechanisms in place, so WoT should be just able to describe, adopt and use these.
We should not put additional obligations on existing systems without a very clear discussion of the use cases and requirements that would not be possible without them.
The text was updated successfully, but these errors were encountered: