Handling Binding Submissions for Existing Bindings

[egekorkan]

Raised at #393 (comment) and at #378 (comment) , we can have the case where the a binding is submitted for a protocol/media type etc. that is already existing. We need to define how to handle this case. Some potential variations that come to mind:

1. The new submission improves the old one in an objective way, e.g. adding a new vocabulary term. I think this is not a controversial one unless it comes from another entity.
2. A new submission comes when there is another one in the initial state. I think this should be accepted since we can have two legitimate proposals for a binding as alternatives and based on implementation experience (or other criteria), one will be chosen.
3. A new submission comes when there is another one in the stable state. If there is no visible improvement but just doing things differently, I would not be sure how to proceed. Maybe fine in initial state and if there is enough implementation, we can review it. However, what happens when the old one also has enough implementations. What if the old one is from the SDO that owns that binding and vice versa?

From my point of view, only the 3rd point is difficult to solve in an objective way. We can require more reviewers and not take responsibility... Given that the URI scheme is a major way of differentiating bindings, we cannot let two bindings for the same URI scheme coexist with the same status.

EDIT: This is also part of https://github.com/w3c/wot-binding-templates/blob/a052686548bec6aed802e7e309fabe5232c1556e/registry-requirements.md#lifecycle under point 5 subitems. The opinions there are:

• @egekorkan At least per TD version, it should be avoided, but multiple initial entries should be allowed in case of diverging opinions to collect implementation feedback. If there is a drastically new binding of an existing one, two can be kept, but this should not be encouraged. This will cause issues with prefixes, URI scheme-based detection, other form elements, etc.
• @relu91 Additional fields in the form can indicate the binding version. Also, the prefix can be changed, e.g., cov1.2 vs cov1.3
• @lu-zero Prefix versioning would require calling a new binding driver inside the implementation. Not using the prefix versioning implies JSON-LD processing, which not all implementations use.
• In the meeting, there was the idea to look at RFC 6838 but @egekorkan could not find anything relevant in there.

[benfrancis]

@egekorkan wrote:

Given that the URI scheme is a major way of differentiating bindings, we cannot let two bindings for the same URI scheme coexist with the same status.

I agree that ideally there should be a 1:1 mapping between URI scheme and protocol binding document so that the URI scheme alone can be used to determine which binding document to use and there aren't multiple bindings for the same protocol causing fragmentation.

One slight amendment to this is that the subprotocol member may be used to further differentiate, e.g. a Server-Sent Events binding document might use the http:// URI scheme but with subprotocol set to sse. (An SSE binding could be part of the HTTP binding, but it might be a separate document).

[egekorkan]

@benfrancis that is correct :) Also see point 4 under https://github.com/w3c/wot-binding-templates/blob/main/registry-requirements.md#entry-format . This is a bit open for discussion at this point

[egekorkan]

Overall proposal for this from @egekorkan and @mjkoster :

• Do not allow two bindings to coexist that do the same thing but in different flavors.
• Allow case-by-case review if there is a potential overlap/conflict/confusion. This can even a checkpoint in the review process, e.g. "Do you see an overlap/conflict with another binding in the registry?"
• Let the original submitter (e.g. the sponsoring organization) to submit revisions in all cases.

[egekorkan]

TD Call of 12th of February: No objections to the proposal from the comment above. A PR can be made to https://github.com/w3c/wot-binding-templates/blob/main/registry-requirements.md reflect this proposal and further discussion can be made there.