Skip to content
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

Open
benfrancis opened this issue Mar 2, 2023 · 4 comments
Labels

Comments

@benfrancis
Copy link
Member

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.

@benfrancis
Copy link
Member Author

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.

@mmccool
Copy link
Contributor

mmccool commented Mar 15, 2023

IMO:

  • Prescriptive content should be normative.
  • Profiles are prescriptive, so they should be normative.
  • Personally, I also feel that protocol bindings should be normative in most cases. However, we can work with a normative profile referencing an informative protocol binding.
  • Not against this proposal in principle, but in general think that profiles need to be in their own documents. I also think profiles need their own dedicated TF.
  • Right now we only have one profile, basically. I agree putting a bunch of unrelated profiles into one document gets troublesome, but I don't think we're at the point that we will have so many that we have to split them up, just yet.

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.

@benfrancis
Copy link
Member Author

@mmccool I'm OK with that approach, but:

  1. Is it allowed for a normative Recommendation to reference a non-normative Note as a dependency?
    1. Can a profile have a normative assertion like "Web Things conformant with the HTTP+JSON Profile MUST use the HTTP Protocol Binding and JSON Payload Binding and comply with all of their defaults" if the binding documents are Notes?
  2. How should we incubate experimental profiles which not everyone necessarily agrees should be recommendations?
    1. At least four new profiles in addition to the existing three have been proposed for Profile 2.0 and adding them to one monolithic normative specification will not scale. It would be good to have a way to incubate proposed new profiles and only add them to a list of stable recommended profiles once they have proven to be implementable and gained wide adoption. If not a registry then perhaps a non-normative section in the Profile specification which links to separate experimental profile documents?

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.

@mmccool
Copy link
Contributor

mmccool commented Mar 16, 2023

Mark as "deferred", meaning we can work on it during the charter under the heading of "refactoring" which was just added to the scope.

@sebastiankb sebastiankb changed the title Should there be a WoT Profile 2.0, or should it be rolled into TD 2.0? Profile: Should there be a WoT Profile 2.0, or should it be rolled into TD 2.0? Jun 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants