Кратко

  • Рассмотрение проекта устава Web of Things Working Group в Консультативном комитете W3C заканчивается 31 августа 2026 года в 23:59 UTC. На момент отсечения материала итог не был опубликован.
  • Проект добавляет WoT Binding Registry и намечает на 2027 год переходы к Registry Draft, Candidate Registry и W3C Registry.
  • Публичный документ реестра пока остается пилотным. Несколько привязок, подготовленных группой, не могут выйти из состояния Initial; внешние заявки предполагается открыть после пилота.
  • Для перехода в Current нужны отдельная проверка с точки зрения целевого протокола и проверка соответствия WoT. Если один специалист владеет обеими областями, проект разрешает ему подготовить два отдельных заключения.
  • Current означает, что хранитель рекомендует привязку для новых реализаций и считает накопленный опыт достаточным. Это не W3C Recommendation и не доказательство всеобщей совместимости.
  • Каждый переход должен сопровождать протокол ролей и доказательств: один или два человека проверяли, что рассмотрела каждая роль, какие операции тестировались и почему хранитель изменил состояние.

Окончание рассмотрения еще не решение

Прежние уставы WoT относились к привязкам протоколов прежде всего как к документам. Новый проект предлагает структурированный обновляемый список, куда смогут поступать материалы как из W3C, так и от внешних сообществ стандартов. Появляется постоянная функция управления: принять запись, рекомендовать ее, заменить новой или признать устаревшей.

Дата 31 августа лишь закрывает период рассмотрения. Действующий устав продлен до 16 октября, а в проекте даты начала и окончания по-прежнему оставлены как шаблонные поля. Три этапа 2027 года — план, а не свершившийся переход.

При этом обсуждать приходится не абстракцию. Пилот Binding Registry уже определяет поля, требования к заявке, жизненный цикл, тесты и обязанности. Он прямо говорит, что еще не является W3C Registry. Пока в нем только несколько внутренних привязок со статусом Initial; внешний прием должен начаться позже.

Такой барьер полезен: процедура испытывается на реальном материале, но пробный статус не выдается за институциональную рекомендацию.

Current может направлять внедрение

Предусмотрены четыре состояния: Initial, Current, Superseded и Obsolete. Записи не удаляются. Новая версия получает отдельную строку, а прежняя остается с измененным статусом.

Current — не просто «последняя версия». В проекте это привязка, которую хранитель рекомендует для новых реализаций и за которой видит достаточный практический опыт. Инструменты, интеграторы и закупочные документы могут использовать метку как быстрый фильтр. Поэтому реестр влияет на внедрение, хотя сам не определяет протокол.

Процесс W3C ограничивает это влияние. Реестры документируют значения, а не архитектурные или межоперабельные требования. Такие требования должны оставаться в спецификациях, которые ссылаются на реестр. Registry Report не подпадает под Patent Policy W3C и не становится Recommendation из-за стабильности записей.

Проект устава сохраняет полномочия внешних организаций. Если разработка привязки выявит необходимость изменить MQTT, Modbus, BACnet, CoAP или другой исходный протокол, группа WoT должна обратиться к его владельцу процесса. Включение в реестр не передает право менять чужой стандарт.

Чем короче метка, тем важнее явно указать границы ее смысла.

Два вопроса может рассмотреть один человек

Перед Current стоят две разные задачи. Экспертиза целевой спецификации проверяет, точно ли операции WoT сопоставлены сообщениям протокола. Экспертиза WoT проверяет согласованность с Thing Description и способность Consumer понять и выполнить описанные взаимодействия.

Проект рекомендует назначить минимум двух экспертов: одного по целевой спецификации и одного по WoT. Следующая фраза допускает, что обе роли возьмет один человек, если он компетентен в обеих областях. Но заключения должны оставаться раздельными.

Это может быть разумно. Специалистов, одинаково глубоко знающих отраслевой протокол и веб-абстракцию, мало. Формальная вторая подпись без нового знания лишь увеличит очередь.

Однако два документа не равны двум независимым подтверждениям. Одна ошибка в версии, одно слабое допущение теста или один пропущенный путь отказа могут попасть в оба анализа. И наоборот, два имени не гарантируют независимость: люди могут делить работодателя, код, испытательный стенд или стимулы.

Нужна не арифметика, а видимая схема проверки. «Один человек — две роли» может быть законным состоянием, но не скрытым.

Минимум испытаний задан, форма доказательств еще открыта

Пилот требует не только письменного мнения. Каждая операция привязки должна пройти автоматическую проверку на испытательном мероприятии. Test Report должен описать среду, сценарий и логический путь от Thing Description до связи. Нужны как минимум один Consumer и один Exposer, покрывающие заявленные операции и возможности.

Таким образом, перед рекомендацией действительно стоит работающий код.

Но тот же проект признает, что точное содержание Test Report еще не определено, и ссылается на issue 3, открытую в феврале 2025 года. Неопределенность касается схемы доказательств, а не необходимости тестировать.

В итоговых правилах предстоит решить, включаются ли необязательные пути ошибок, могут ли обе стороны происходить из одной кодовой базы, как раскрываются общие библиотеки и тестовые стенды, сохраняются ли неудачные прогоны и исправления, а также чем подтверждается семантическое соответствие помимо самого обмена сообщениями.

Если внешние заявки появятся раньше ответов, первые успешные переходы создадут норму прецедентом.

Протокол ролей и доказательств

Публичные issues, рецензии, pull requests и интервалы ожидания уже заложены. Новая инстанция не нужна. Нужен компактный документ, связывающий их с изменением состояния.

Он фиксирует версию привязки, целевую спецификацию, вспомогательные файлы и примененную редакцию определения реестра. Две роли записываются отдельно: исполнитель, релевантная компетенция, явное указание на совмещение. Связи и конфликты, относящиеся к заявителю, протоколу или тестируемым реализациям, раскрываются в необходимом объеме без создания личного досье.

Раздел доказательств перечисляет даты, среды, Consumer, Exposer, покрытие по операциям, общий код и непроверенные пути. Каждое заключение сохраняет выводы, оговорки и требуемые изменения. Затем идут период комментариев, возражения, датированное решение хранителя и его мотивировка.

Рядом с Current нужны четыре отрицания: это не W3C Recommendation, не доказательство универсальной совместимости, не изменение исходного протокола и не патентное обязательство для реестрового документа.

При переходе в Superseded или Obsolete протокол сохраняется. Сохранить строку, но потерять причину прежней рекомендации — значит сохранить лишь половину истории.

Узкое применение идеи Heng Lu здесь полезно: эксперт дает суждение, работающий код — доказательство, хранитель — ограниченное решение по правилам. Ни один элемент не получает полномочий двух других.

Пилот — самый дешевый момент для прозрачности

Источники не показывают, что совмещенная проверка уже провалилась, что процесс кем-то захвачен или что конкретная привязка дефектна. Нет и внешней записи, которая доказанно получила Current по будущей процедуре. Устав остается проектом.

Именно поэтому документацию можно улучшить до кризиса. Когда инструменты и закупщики начнут считать Current значением по умолчанию, восстановить происхождение решения будет сложнее.

Две экспертизы могут выполнить два человека или один. Реестр должен сохранить эту разницу, а не позволить итоговой ячейке стереть путь к ней.

Источники

  1. Уведомление W3C о рассмотрении проекта устава WoT
  2. Проект устава Web of Things Working Group
  3. Действующий устав Web of Things Working Group
  4. Пилот WoT Binding Registry
  5. Зафиксированный исходный текст реестра
  6. Issue 3: определение содержания Test Report
  7. Процесс W3C: Registry Track
  8. Heng Lu, The Multi-Stakeholder Mirage