In the Thing Description call this week there was a consensus that rather than having a separate normative WoT Binding Templates 2.0 specification, the binding mechanism should be defined in the Thing Description 2.0 specification. It seems likely that the TD spec will also include registry sections with tables of links to individual binding documents, which may themselves be published as non-normative W3C Notes.
I suggested that if the binding mechanism is defined inside the TD spec, then perhaps the profiling mechanism should be defined there too, since the two mechanisms are "two sides of the same [interoperability] coin". Others pointed out that having both the binding and profiling mechanisms defined in one place might also help to explain to readers when each should be used, and how the two work together.
In the charter call today @mlagally rightly pointed out that the decision about where the profile mechanism should be defined should also be discussed in the Architecture/Profile task force, so I am posing the question here.
Should the profiling mechanism section of WoT Profile be moved into the Thing Description specification in TD 2.0?
Note that I'm not suggesting a change in WoT Profile 1.0, for which I expect things to stay as they are, consistent with the separate WoT Binding Templates document.
For me this then also raises the related question of:
Should the list of profiles be maintained as a registry section in the Thing Description specification? (as with binding documents)
My first reaction when it was first suggested to maintain a registry of profiles was to resist it, because I am very worried about the potential negative effects of having too many profiles. Profiles only provide interoperability within a profile not between profiles so, unlike protocol binding templates, we ideally want there to be as few profiles as possible. (I think the DID methods registry is a good example of where a registry causes an explosion of diverging approaches and ends up harming interoperability because no single dominant approach emerges.)
However, as @egekorkan has explained more about how registries work I understand better that the Working Group can define the criteria for including an entry in a registry, and strictly curate which ones are allowed. This would allow us to set the bar for inclusion in the registry very high (e.g. at least two independent Producer and Consumer implementations, or evidence of wide adoption or maturity), or perhaps have separate tables for stable and experimental profiles.
If the profiling mechanism and a registry of profiles were maintained in the TD specification, then this wot-profile repository could be used for containing separate profile documents (which themselves may be published as non-normative W3C Notes), and incubating experimental ones.
I'm still not sure whether this is a good approach for Profiles (vs. defining a small number of profiles in a single normative specification with a set of common constraints), and we would have to agree the criteria for including new profiles in the registry, but I wanted to raise the question for discussion. Taking this approach would open up the possibility of eliminating another normative specification (the WoT Profile specification), and I personally think that reducing the number of interdependent normative WoT specifications would be a good thing.
In fact if the binding and profiling mechanisms were rolled into the Thing Description specification and WoT Architecture 2.0 was made informative (under discussion), then that would mean the only normative specifications would be WoT Thing Description 2.0 and WoT Discovery 2.0, which I think would greatly simplify things for implementers.
It would also give us more freedom to experiment with and incubate non-normative profiles which not everyone necessarily agrees should be a W3C recommendation.
In the Thing Description call this week there was a consensus that rather than having a separate normative WoT Binding Templates 2.0 specification, the binding mechanism should be defined in the Thing Description 2.0 specification. It seems likely that the TD spec will also include registry sections with tables of links to individual binding documents, which may themselves be published as non-normative W3C Notes.
I suggested that if the binding mechanism is defined inside the TD spec, then perhaps the profiling mechanism should be defined there too, since the two mechanisms are "two sides of the same [interoperability] coin". Others pointed out that having both the binding and profiling mechanisms defined in one place might also help to explain to readers when each should be used, and how the two work together.
In the charter call today @mlagally rightly pointed out that the decision about where the profile mechanism should be defined should also be discussed in the Architecture/Profile task force, so I am posing the question here.
Should the profiling mechanism section of WoT Profile be moved into the Thing Description specification in TD 2.0?
Note that I'm not suggesting a change in WoT Profile 1.0, for which I expect things to stay as they are, consistent with the separate WoT Binding Templates document.
For me this then also raises the related question of:
Should the list of profiles be maintained as a registry section in the Thing Description specification? (as with binding documents)
My first reaction when it was first suggested to maintain a registry of profiles was to resist it, because I am very worried about the potential negative effects of having too many profiles. Profiles only provide interoperability within a profile not between profiles so, unlike protocol binding templates, we ideally want there to be as few profiles as possible. (I think the DID methods registry is a good example of where a registry causes an explosion of diverging approaches and ends up harming interoperability because no single dominant approach emerges.)
However, as @egekorkan has explained more about how registries work I understand better that the Working Group can define the criteria for including an entry in a registry, and strictly curate which ones are allowed. This would allow us to set the bar for inclusion in the registry very high (e.g. at least two independent Producer and Consumer implementations, or evidence of wide adoption or maturity), or perhaps have separate tables for stable and experimental profiles.
If the profiling mechanism and a registry of profiles were maintained in the TD specification, then this wot-profile repository could be used for containing separate profile documents (which themselves may be published as non-normative W3C Notes), and incubating experimental ones.
I'm still not sure whether this is a good approach for Profiles (vs. defining a small number of profiles in a single normative specification with a set of common constraints), and we would have to agree the criteria for including new profiles in the registry, but I wanted to raise the question for discussion. Taking this approach would open up the possibility of eliminating another normative specification (the WoT Profile specification), and I personally think that reducing the number of interdependent normative WoT specifications would be a good thing.
In fact if the binding and profiling mechanisms were rolled into the Thing Description specification and WoT Architecture 2.0 was made informative (under discussion), then that would mean the only normative specifications would be WoT Thing Description 2.0 and WoT Discovery 2.0, which I think would greatly simplify things for implementers.
It would also give us more freedom to experiment with and incubate non-normative profiles which not everyone necessarily agrees should be a W3C recommendation.
What do you think?
CC @mlagally