Summary

  • W3C's Advisory Committee review of the proposed Web of Things Working Group charter closes at 23:59 UTC on 31 August 2026. The result was not public at this Article's cutoff.
  • The proposal adds a WoT Binding Registry, with Registry Draft, Candidate Registry and W3C Registry transitions projected for 2027.
  • The public registry document is still a pilot. Its few Working Group bindings cannot yet move beyond Initial, and external submissions are expected only after the pilot.
  • A future move to Current requires separate target-protocol and WoT-adherence reviews. The draft asks for at least two reviewers, but also allows one person with both kinds of expertise to perform both reviews as separate documents.
  • Current means the custodian recommends the binding for new implementations and finds sufficient implementation experience. It does not mean W3C Recommendation, universal interoperability or patent assurance.
  • A role-and-evidence receipt should show whether one or two people performed the two tests, what each examined, which implementations and operations were covered, and why the custodian changed the state.

The review closes before the registry opens

The proposed charter gives the Web of Things Working Group a new kind of deliverable. Earlier WoT charters treated protocol bindings mainly as documents. The new text would maintain a Binding Registry: a structured, updateable list that can contain bindings originating inside W3C or from external standards communities.

Public comments and Advisory Committee review remain open until 23:59 UTC on 31 August. The incumbent charter has been extended to 16 October. Those dates matter because a proposal is not an approval. The charter page still carries placeholder start and end dates, and its timetable should be read as a plan: Registry Draft in the first quarter of 2027, Candidate Registry in the second and W3C Registry in the third.

Work has not waited for the formal transition. A public Binding Registry draft already defines entry fields, submission requirements, a lifecycle and review duties. It says plainly that it is not yet a W3C Registry. The pilot contains only a small number of Working Group bindings, and those entries remain Initial. External submissions would open when the pilot ends.

That is an appropriate boundary. It lets the group test the machinery without presenting a trial state as an institutional endorsement. It also gives the charter review something concrete to examine: not merely the word “registry,” but the decisions the registry would make visible.

Current is a consequential verb

The proposed lifecycle has four states: Initial, Current, Superseded and Obsolete. Entries are not deleted. A new version receives a new entry, while an older one remains available with its later status.

Current carries more weight than a timestamp. The draft defines it as a binding the custodian recommends for new implementations and that has enough implementation experience. Software, documentation and procurement teams may reasonably use that label as a shortcut. A registry can therefore influence deployment without itself defining the protocol.

The W3C Process keeps that power bounded. A registry documents values; it may not define architectural or interoperability requirements. Those requirements must remain in the specifications that reference the registry. Registry reports are not subject to the W3C Patent Policy and cannot acquire Recommendation status merely because their entries are useful.

The proposed charter preserves another boundary. If a binding reveals that the underlying protocol needs to change, the WoT Working Group must rely on the organization responsible for that protocol. Listing a binding is not authority to rewrite MQTT, Modbus, BACnet, CoAP or another external system.

These limits make the transition record more important, not less. A reader needs to know exactly what Current proves and what it does not.

Two questions can pass through one mind

To move from Initial to Current, the registry draft asks for two different reviews. One examines the binding from the target specification's point of view: does it map the protocol accurately? The other examines adherence to the WoT Thing Description standard: can a WoT Consumer understand and execute the documented operations as claimed?

The draft says the custodian should appoint at least two reviewers, one expert in the target specification and one WoT expert. It then allows the same person to serve as both if that person has both kinds of expertise, provided two separate review documents are produced.

There is no contradiction in the underlying objective. The system needs two analytical lenses. Sometimes expertise is scarce, especially for an external industrial protocol and a specialist Web abstraction. A dual-domain expert may be the person best able to locate a mismatch at their boundary. Requiring a second name for appearance alone could add delay without adding knowledge.

But two documents are not the same as independent corroboration. If one person misunderstands a version dependency, accepts a weak test assumption or overlooks the same edge case in both roles, the error becomes correlated. The public state should not make readers infer whether two experts converged or one expert completed two checklists.

Nor would two people automatically solve the problem. They may share an employer, implementation, test harness or design assumption. Independence is a property of evidence and incentives as well as headcount.

The honest answer is to publish the review topology. One reviewer serving twice can be a legitimate state. It should be a visible state.

The test floor exists, but its exact shape is unfinished

The pilot draft already asks for meaningful implementation evidence. Every operation defined in a binding must be validated automatically at a testing event. The Test Report must describe the environment, the scenario and the logical path from a Thing Description to communication. It must include at least one Consumer and one Exposer capable of covering the operations and features described.

That is not a paper-only test. It puts running implementations between Initial and Current.

The same draft also says the exact content of the Test Report has not been decided. It links to an open GitHub issue created in February 2025 to define what testing events must produce. The uncertainty is therefore bounded and public. It concerns the evidence schema, not whether evidence matters.

The missing details can change the meaning of success. Does “every operation” include optional error paths? Are the Consumer and Exposer independently implemented, or can two ends of one codebase count? Must a report preserve failing runs, environment versions and later corrections? How are shared test libraries disclosed? What result demonstrates semantic adherence rather than message exchange alone?

Those questions should be settled before external entries can acquire a recommendation-bearing label. Otherwise the first accepted cases will define the evidence standard by precedent.

Give each transition a role-and-evidence receipt

The registry already uses public issues, reviews, pull requests and waiting periods. The required improvement is not a new tribunal. It is a compact record joining those artifacts at the decision boundary.

For a move to Current, the receipt should identify the immutable binding version, target specification and registry-definition version. It should list the two review roles separately, name the person serving each role, state relevant expertise and disclose whether one person performed both. It should record affiliations or conflicts relevant to the submitter, protocol and tested implementations without turning the document into a personnel file.

The evidence section should identify test dates, environments, Consumer and Exposer implementations, operation-by-operation coverage, shared code and untested paths. Each review should link to its own findings, reservations and requested changes. The record should then preserve the comment window, objections, the custodian's dated disposition and the precise meaning of the resulting state.

Four non-claims belong beside every Current decision. The label does not make the binding a W3C Recommendation. It does not prove universal interoperability. It does not change the underlying protocol. It does not create a Patent Policy commitment for the registry document.

The receipt should follow the entry when it is superseded or made obsolete. Because the draft never deletes entries, the decision history can remain as durable as the data history.

This design follows Heng Lu's useful separation among expertise, evidence and mandate. A reviewer supplies judgment. Implementations supply operating evidence. The custodian changes the registry state under the definition. None should borrow the authority of the others.

A pilot is the right time to expose concentration

Nothing in the present record proves that a dual-role review has failed, that a transition has been captured or that an external binding is deficient. No external entry has been shown to reach Current under the future process. The charter itself remains under review.

That is why the question belongs now. A pilot exists to test not only whether forms and automation work, but whether a later reader can reconstruct the decision. Once tools and buyers begin treating Current as a default, missing provenance will be expensive to restore.

The WoT registry draft has already chosen a pragmatic route through scarce expertise. It should preserve the truth of that route. Two reviews may come from two people or one. The public record should never make the difference disappear.

Sources

  1. W3C proposed WoT charter review notice
  2. Proposed Web of Things Working Group Charter
  3. Current Web of Things Working Group Charter
  4. WoT Binding Registry pilot draft
  5. Pinned WoT Binding Registry source
  6. Open issue 3: Defining Test Report Content
  7. W3C Process: The Registry Track
  8. Heng Lu, The Multi-Stakeholder Mirage