摘要

  • W3C 对 Web of Things 工作组拟议章程的审议将于 2026 年 8 月 31 日 23:59 UTC 截止。本文截稿时，审议结果尚未公布。
  • 拟议章程把 WoT Binding Registry 纳入交付物，并计划在 2027 年依次进入 Registry Draft、Candidate Registry 与 W3C Registry 阶段。
  • 当前公开文件仍自称试点：少量由工作组编写的绑定只能停留在 Initial，外部提交要等试点结束后才开放。
  • 未来进入 Current 需要两份独立审查：一份看目标协议是否映射正确，另一份看是否符合 WoT Thing Description。规则同时允许一名兼具两类专长的人完成两份审查。
  • Current 表示托管方建议新实现采用该绑定，并认为已有足够实现经验；它不等于 W3C Recommendation，也不证明普遍互操作性。
  • 每次状态迁移都应配一份“角色—证据凭据”，说明由一人还是两人承担审查、各自检查了什么、测试覆盖到哪里，以及托管方为何改变状态。

截止日期不能替代审议结果

过去的 WoT 章程主要把协议绑定列为说明性文档。新章程提出的是一个可以持续更新的结构化注册表，既收录 W3C 自己的绑定，也为外部标准组织和个人提交留下入口。这不是换一种发布格式，而是增加了一套能给条目贴上状态、并随时间改变状态的制度。

8 月 31 日只是审议期的终点，不是自动批准日。现行章程已延长到 10 月 16 日，拟议章程的起止日期仍是占位符。页面所列的 2027 年三个里程碑属于计划，不能写成已经发生的转换。

与此同时，工作组并非从零开始。公开的 Binding Registry 草案已经规定条目字段、提交材料、生命周期、测试和审查职责。文件明确说，它尚未成为 W3C Registry。试点阶段只放入少量工作组绑定，状态不得越过 Initial；外部提交将在试点之后开放。

这条边界很重要。它让工作组可以用真实材料检验流程，又不把试验中的标签包装成正式背书。

Current 不只是“最新”

草案定义四种状态：Initial、Current、Superseded 与 Obsolete。条目不会被删除；新版本另建条目，旧版本保留并改变状态。

其中，Current 不是日期描述。草案给它的含义是：托管方建议新实现采用，而且已有足够的实现经验。开发工具、集成商或采购文件很容易把这一格当作快捷判断。注册表虽然不编写协议，仍可能改变部署选择。

W3C《流程文件》为这种影响力划了边界。注册表负责记录值，不得在表内定义架构或互操作要求；这类要求必须留在引用注册表的规范中。注册表报告也不适用 W3C 专利政策，不能因为条目稳定就被当成 Recommendation。

拟议章程还写明：若制作绑定时发现底层协议需要修改，WoT 工作组应交由该协议的负责组织处理。收录 MQTT、Modbus、BACnet、CoAP 等绑定，并不会把相应协议的控制权交给 W3C。

因此，状态越简短，边界越要清楚。Current 能证明什么、不能证明什么，都应跟着决定一起公开。

两个问题可以由同一个人回答

从 Initial 进入 Current 前，要回答两个不同的问题。目标协议审查看映射是否忠实：WoT 操作是否对应到正确的协议消息。WoT 审查则看 Thing Description 的语义与交互是否成立，Consumer 能否按文档理解并执行。

草案先说，托管方应至少安排两名审查人，一名熟悉目标规范，一名熟悉 WoT。紧接着又说，如果同一人同时具备两类专长，可以由此人承担两项审查，但仍须形成两份独立审查文件。

这不必被理解成自相矛盾。工业协议与 Web 抽象的交叉专家可能很少，一名真正理解两边的人，反而最容易发现边界处的误配。为了人数好看而增加一名不带来新知识的签字者，只会拉长队列。

但两份文件也不等于两次独立印证。如果同一人误解了版本依赖、接受了偏弱的测试假设，或两次都漏掉同一条错误路径，盲点会相关联。反过来，两个人也可能共享雇主、代码、测试工具和设计前提，人数并不能自动制造独立性。

最诚实的做法不是把“一人双岗”禁止或隐藏，而是把审查拓扑写出来。谁以什么角色看了什么材料，是否由同一人承担两个角色，应成为显式状态。

测试门槛已经存在，证据格式尚未定型

试点草案并非只要求书面意见。绑定所定义的每项操作都必须在测试活动中自动验证。Test Report 需要说明环境、场景，以及从 Thing Description 到实际通信的逻辑路径；还必须至少包含一个 Consumer 与一个 Exposer，能够覆盖文档所述操作和功能。

也就是说，Current 前面确实放着运行证据。

不过，草案同时承认 Test Report 的精确内容尚未决定，并链接到 2025 年 2 月开启、截稿时仍未关闭的 issue 3。这里的空白不是“要不要测试”，而是“测试结果怎样成为可复核的公共证据”。

例如：可选错误路径是否算进“每项操作”？同一代码库的两端能否算 Consumer 与 Exposer？共用的测试框架如何披露？失败记录和修正历史是否保留？只是消息能往返，是否足以证明语义适配？

这些问题最好在外部条目进入 Current 前回答。否则，第一批案例会用先例替代明文规则。

给状态迁移配一份“角色—证据凭据”

现有草案已经使用公开 issue、审查、pull request 和等待期，不需要再造一个裁决机构。缺的是把分散材料连接到决定上的小型凭据。

凭据首先固定绑定版本、目标规范、机器可读附件和所适用的注册表定义版本。两种审查角色分开记录：谁承担、相关专长是什么、是否由同一人兼任。与提交者、协议或受测实现有关的任职和利益关系也应按相关性披露，但不应扩张为个人档案。

测试部分列明日期、环境、Consumer、Exposer、逐项覆盖、共用代码和未测路径。两份审查分别保留结论、保留意见与修改要求。随后记录评论期、异议、托管方的日期化决定、理由和授权依据。

每个 Current 凭据还应附带四条否定说明：它不是 W3C Recommendation；不证明所有实现互通；不修改底层协议；不为注册表文件自动产生专利承诺。

条目日后变为 Superseded 或 Obsolete 时，凭据仍应保留。只保存旧行、不保存当初为何推荐，不能算完整历史。

Heng Lu 对专长、证据与授权的区分在这里很适用：审查人提供判断，运行实现提供证据，托管方依规则改变状态。三者互相依赖，却不能互借权力。

试点期正适合公开集中程度

现有材料并未证明一人双岗已经导致失败，也没有证据表明某名参与者控制了流程。外部条目尚未被证明在这套未来规则下进入 Current，章程也仍在审议。

正因为还没有危机，现在调整记录成本最低。一旦工具和采购者把 Current 当成默认选项，事后补回审查来源会困难得多。

两项审查可以来自两个人，也可以来自一个兼具双重能力的人。注册表不必假装这两种情况完全相同。把差异保存下来，才是试点真正要验证的治理能力。

来源

  1. W3C 拟议 WoT 章程审议通知
  2. 拟议 Web of Things 工作组章程
  3. 现行 Web of Things 工作组章程
  4. WoT Binding Registry 试点草案
  5. 固定版本的注册表源文件
  6. issue 3：定义 Test Report 内容
  7. W3C《流程文件》：Registry Track
  8. Heng Lu：《多利益相关方幻象》