-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Profile: Should there be a WoT Profile 2.0, or should it be rolled into TD 2.0? #80
Comments
One other thought on this. If profiles do end up referencing defaults in protocol binding documents rather than defining a protocol binding in the profile itself (as discussed in w3c/wot-profile#285 (comment)), it might be strange that the profiles are normative but the protocol bindings they depend on are non-normative Notes. Separating out profiles into individual non-normative Notes (with only the profiling mechanism and registry section being normative) would solve that problem, but I'm not sure whether profiles being non-normative (like binding documents) is really what we want. |
IMO:
I would like to propose that we keep the current structure (for now), having one document with multiple Profiles (* with an s) in it. Using a registry in the future might be a good idea but I feel that for now it just adds unnecessary complications. |
@mmccool I'm OK with that approach, but:
My underlying concern with defining the binding mechanism (and registries of bindings) in the TD specification but defining the profiling mechanism (and list of profiles) externally is that it raises the visibility of the binding mechanism above that of the profiling mechanism. Greenfield implementers reading the TD spec may think that providing a custom protocol binding using a binding template is the only way to use a Thing Description and not realise the added interoperability benefits of conforming with a common protocol binding defined in a profile instead. This could harm interoperability on the Web of Things. My hope is that in 2.0 we can find a better way for bindings and profiles to work together such that profiles just reference protocol bindings as a set of defaults defined in binding documents, rather than having two separate mechanisms for defining protocol bindings (which is effectively the situation in 1.0). If we can achieve that then I'm OK with the profiling mechanism and set of profiles being defined separately, because "profiles" would build on top of "bindings" rather than being an alternative to them. Making the current protocol bindings from profiles into defaults in binding documents would provide more interoperability by default. |
Mark as "deferred", meaning we can work on it during the charter under the heading of "refactoring" which was just added to the scope. |
Should there be a WoT Profile 2.0 specification, or should the profiling mechanism be rolled into the TD specification with a list of profiles maintained as a registry, as with the binding mechanism and binding documents?
This issue is only to discuss potential impact on the deliverables named in the charter, please see issues in the wot-profile repo for detailed discussion on where the 2.0 profiling mechanism should be defined, and how the 2.0 profiling mechanism should work.
The text was updated successfully, but these errors were encountered: