Web of Things (WoT) Binding Registry

The mechanism is as follows:

• We work with issues only. The information for the entry format is submitted as a list. This way, non- W3C members can submit a binding. Reviews from the custodian happen on the issue. The submitter is expected to answer until the custodian makes a PR to add the binding to the registry or change its status.
• A purpose built GitHub project for tracking submissions is used. When a submission comes in form an issue, it is automatically added to column "Binding Submitted". When the custodian and reviewers start looking at it, it goes to the "Under Review" column. If the review is in favor, the custodian makes the PR to add it to the registry and the issue goes to column "Accepted". If the review is not in favor, it goes to the column "Rejected". All these changes are reflected as comments in the original issue.
• If a new entry conflicts with another entry, the reviewer MUST mark the new submission accordingly. As two bindings that do the same are not allowed, either the old one MUST be deprecated or the new one MUST be rejected. See also point 13 under "Requirements on the Submitted Document".

An entry can have the following status values: Initial -> Current -> Superseded or Obsolete

• Initial : : Document is correctly written but no implementation experience has been necessarily documented.
• Current : : Custodian recommends it for new implementations and it has enough implementation experience. While this is also called as stable , , given that it can be superseded later, it is recommended to use the term current . .
• Superseded : : A previously "current" entry that is now superseded with a newer one
• Obsolete : Custodian does not recommend the usage of this binding

The diagram below represents the lifecycle sates and the possible transitions between them. Please refer to transitions for the requirements and process for each transitions.

Different bindings may share the same version string, but each version of a binding MUST be unique within that binding's history. The version string SHOULD contain a UTC-based date in ISO 8601 format in the form of YYYY-MM-DD . . The content of a registry entry MAY not be updated for a given version. If anyone wants to submit a newer version of an entry, it MUST be a new submission. As indicated in transition to superseded and transition to obsolete , , the newer versions results in state changes. Review of a new version of an existing binding SHOULD take the previous reviews into account.

No entry is ever deleted. Deprecated entries are moved to another table or are clearly marked deprecated, colored differently, and moved to the bottom.

A change in the registry MUST be confirmed by the Custodian . . The custodian of this registry is the WoT WG in the beginning. If the WoT WG no longer exists, the W3C Team or its delegated entity MUST be the Custodian . . For example, a dedicated W3C community group can be created to maintain the registry. This way, the registry can be maintained for a long period.

A binding that uses a protocol MUST map at least one WoT operation ( op keyword value such as readproperty ) to a protocol message and vice versa.

A binding that uses a serialization format via the contentType keyword MUST mention how the Data Schema terms should be used to describe the messages. This avoids submission of a binding like "XML Binding" that says "Use contentType:application/xml and nothing more. That alone would not be enough to serialize correct messages based on the data schema.

The WoT binding MAY be just one section of the document. In that case, the "Link to the binding document" in the registry entry MUST point to the specific location. PDF or similar document types MAY be submitted if the "Link to the binding document" in the registry entry contains a text pointing to the section. However, HTML and Webpages SHOULD be favored.

The WoT binding document MAY follow another copyright than the W3C copyright. The submitter is free to choose based on the process they or their organization follows.

The binding document linked in the registry entry SHOULD be open to read, use, and implement, but that is not required for the document to be added to the registry.

Reviewers MUST have access to the binding document and to the protocol or media type specification (what the binding specifies).

The submitter MUST fill in the GitHub form provided by the custodian to generate a summary document , , which is hosted by the custodian together with the registry. This form contains the following:

• Abstract - It MUST contain an abstract with the following information : :
  • What is the content of the binding about, e.g., what is this protocol?
  • Who should use it?
  • For what purpose(s) should it be used, e.g., monitoring, process control? This SHOULD use terminology of the submitter, i.e., the custodian does not provide definitions for this.
• Examples - It SHOULD contain examples (can be one) TDs or TMs demonstrating the use of the binding
• It MUST contain Access/Usage restrictions about the binding, protocol, implementation, etc., using the terminology and/or documents of the submitter. A non-exhaustive list of examples of restrictions:
  • Reading the binding document
  • Reading the protocol specification
  • Implementing a non-commercial device/Thing
  • Implementing a non-commercial Consumer application/driver
  • Conditions for commercial use, e.g., building a commercial product with the binding
  • Making a statement about your product's supporting that binding
• If the entry depends on another one, it MUST specify the exact version of the dependency upon which it depends at the time of submission.
• The availability of the machine-readable documents MUST be indicated in the summary document using the submission mechanism. Also see Req-Docs . .
• The previous version of the summary document MUST be listed as a link . .
• If the chronological ordering of the entries is not clear from the version string, the summary document MUST explain the ordering mechanism.

Every transition including the initial submission is triggered by an issue, which can be made by the submitter, the custodian or anyone who creates an issue using the correct template. For each transition - defined in lifecycle status - the following sections explain the requirements and rules that need to be followed by the submitter, custodian and reviewers.

As a general rule, a transition MAY be triggered by the submitter, the custodian or anyone who creates an issue using the correct template. However, the custodian MUST notify the initial submitter and the organization related to the entry of any transition request using the contact information provided in the submission issue. In the case of no replies within 30 days from the initial submitter or the organization related to the entry, the custodian MUST process the transition, consulting reviewers when necessary for the transition in question. The custodian MUST assign reviewers for the submission and transitions who are different from the initial submitter and the organization related to the entry. The custodian MUST wait 15 days after the end of the review process before making a decision on the transition to allow for any further comments or discussions to take place. The custodian MUST make a decision on the transition within 30 days after the end of the review process. If there are other entries in the registry with Initial or Current status targeting the same specification, the reviewers MUST take them into account. For example, a newer version of the same binding would result in a transition to Superseded for the older version, which should be used in the review. While the custodian is tasked with assigning reviewers, the custodian MAY NOT be able to assign reviewers As there are no guarantees that reviewers complete their reviews, the custodian MAY reassign reviewers if necessary.

The submitter MUST use the correct transition issue template for each transition request and conform to the requirements defined in the template.

The binding MUST contain the following sections in the order presented below. The binding CAN contain other sections anywhere, including between the required ones. The submitters are encouraged to look at the existing submissions. There MUST be at least one operation mapped to a protocol message/vocabulary term. The submitter SHOULD use the table template provided in the document for the vocabulary. Each entry after the first version of the binding MUST contain a changelog in the entry itself.

• Introduction
• Binding Content:
  • URI Format
  • Form Vocabulary Definition as Table
  • Default and possible mappings to operations as a Table
• Examples
• Changelog

The requirements for the machine-readable documents are as follows:

• There MUST be a JSON Schema (version to be defined) that allows validating the elements added by the entry.
• There SHOULD be a JSON-LD Context and an ontology for the registry entry. Note that, when converting the TD to an RDF format, the lack of JSON-LD Context will create an RDF representation that will cause issues in RDF triple stores.
• There MAY be other documents which are helpful to implementers, such as code, diagrams, and/or standalone examples.
• These documents MUST be available to the reviewer.
• The reviewer MUST include these documents in their review.
• All documents associated with the registry entry MUST have the same version string, i.e., the versions of all associated documents MUST be updated when there is a change to any of them.
• The version MUST be a string that is visible in all the documents.

The binding entry SHOULD NOT conflict with other entries in the registry, such as its other versions or its dependents , , by redefining the same concepts, such as redefining the URI Scheme, the vocabulary terms, or the default assignments. If a previously stable binding is being improved upon by the same organization, that previous binding MUST be deprecated once the new one reaches the stable status.

The namespace (prefix and its values) defined in a binding SHALL NOT be redefined or extended in any other binding, e.g., cov:method values shall not be extended in LWM2M and cov:newTerm shall not be added in LWM2M binding.

If parts of the entry require the existence of another binding, i.e., has dependencies, the dependency MUST first be submitted as a separate entry. For example, before LWM2M can be submitted, the CoAP Binding must exist.