Кратко

  • W3C утвердил устав WebAssembly Working Group 20 августа 2026 года. Мандат действует до 27 августа 2028 года и включает пересмотр трех существующих спецификаций, а также Code Metadata и три спецификации Legacy Extensions.
  • Component Model назван условным результатом работы. Working Group намерена подготовить его как нормативную спецификацию лишь после того, как предложение достигнет четвертой стадии по процедуре WebAssembly Community Group.
  • В зафиксированной на 10 августа версии открытого реестра Component Model остается на первой стадии. Номер описывает институциональное состояние, а не оценивает полезность, внедрение или качество технологии.
  • Репозиторий Component Model перечисляет WASI Developer Preview 0.2.0, 0.3.0 и 0.3.1 и сообщает, что инструменты производителей и потребителей сохраняют стабильность включенных возможностей для применения в производственных сценариях вне браузера и сбора практического опыта.
  • Четвертая стадия требует реализаций, тестов, полной спецификации, полного эталонного интерпретатора и консенсуса Community Group. После передачи Working Group должна отдельно выработать собственный консенсус и пройти процедуру W3C.
  • Нужен реестр продвижения с двумя ключами: неизменяемая ревизия и доказательства по каждому критерию связываются с решением Community Group, а прием Working Group и статус публикации W3C фиксируются как отдельный акт.

Устав открыл маршрут, но не объявил прибытие

Уведомление W3C об утверждении короткое. Институциональные границы находятся в самом уставе: начало 20 августа 2026 года, окончание 27 августа 2028 года, председатели, контактное лицо, сфера работы, результаты и правила принятия решений.

Некоторые задачи вошли в мандат без условий. Группа подготовит новые редакции WebAssembly Core Specification, JavaScript Interface и Web API. Добавлены WebAssembly Code Metadata Specification и три документа, отделяющие устаревшие, но потенциально используемые расширения для Core, JavaScript и Web API.

Для Component Model выбран другой глагол. Группа «намерена предоставить» спецификацию при условии, что предложение достигнет четвертой стадии по процессу Community Group. Это не отказ и не состоявшееся принятие. Пункт определяет, кто сможет действовать после выполнения проверяемого входного условия.

Такое условие существовало и в уставе 2023 года. Редакция 2026 года продлевает эту архитектуру, а не превращает три года разработки в молчаливое повышение статуса. Устав может дать полномочие принять будущую работу; он не может одной ссылкой провести голосование, создать недостающие артефакты или сформировать консенсус принимающей группы.

Поэтому выражение «есть в уставе W3C» не сокращается до «является стандартом W3C». Между ними находятся как минимум решение Community Group о готовности к передаче и отдельное решение Working Group о формальном принятии.

Воспроизводимая запись все еще показывает единицу

Репозиторий WebAssembly/proposals выполняет роль открытой таблицы состояний. Для этой публикации взят зафиксированный коммит от 10 августа, чтобы исходное состояние можно было проверить позднее. Предложения распределены между стадиями с первой по пятую; Component Model указан в первой.

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

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

Стадии не являются отметками или процентом готовности. Первая стадия означает, что Community Group сочла предложение относящимся к своей сфере и достаточно правдоподобным, чтобы его авторы развивали проект и добивались согласия. Число не измеряет пользователей, финансирование, объем кода или число внедрений.

Четвертая стадия — передача с доказательствами

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

На второй стадии нужны точное и полное описание и достаточно высокий уровень согласия. На третьей добавляются набор тестов и работа над реализациями. Четвертая требует существенно большего: когда условие применимо, не менее двух Web VM должны реализовать возможность и пройти тесты, а не менее одной инструментальной цепочки — поддержать ее. Спецификация и эталонный интерпретатор должны быть полными, интерпретатор должен пройти тесты, а Community Group должна согласиться и с самой функцией, и с полнотой текста.

Только тогда происходит полная передача Working Group. Принимающая группа не просто ставит печать. Она рассматривает крайние случаи, подтверждает собственный консенсус и выполняет процедуру W3C. При существенном изменении работа возвращается в Community Group. Для пятой стадии требуется уже консенсус Working Group о завершенности функции.

Последовательность исключает два сокращения. Working Group не может назвать раннюю идею зрелой только потому, что устав допускает ее в будущем. Community Group не может одним своим повышением создать стандарт W3C. Разработчики дают обеим сторонам важные доказательства, но выпуск кода не поворачивает ни один институциональный ключ.

Первая стадия совместима с производственными preview

Главный противовес бюрократическому прочтению находится в репозитории Component Model. Там есть материалы проектирования, двоичный и текстовый форматы, документы по связыванию и ABI, растущий набор тестов и несколько вех Developer Preview.

WASI Developer Preview 0.2.0 стал первым предварительным выпуском на базе Component Model. Версия 0.3.0 добавила нативную конкурентность, 0.3.1 — дополнительные типы и аннотации. README говорит, что инструменты производителей и потребителей сохраняют стабильность включенных функций, чтобы их можно было использовать вне браузера в производственных условиях и одновременно получать обратную связь.

Поэтому формула «первая стадия означает, что ничего нет» неверна. Экосистема может стабилизировать ограниченный профиль, запускать реальные системы и давать обязательства по совместимости до завершения формальной стандартизации. Операционный опыт способен стать сильным доказательством для следующего решения.

Тот же README сообщает, что формальная спецификация и эталонный интерпретатор будут добавлены в будущем. Это объясняет расхождение между инженерным прогрессом и институциональной стадией. Выбранная поверхность может быть стабильной, не удовлетворяя всем требованиям к артефактам и консенсусу четвертой стадии.

Обратная ошибка опаснее. Использование в производстве не проводит голосование Community Group, не завершает интерпретатор, не передает предложение Working Group и не публикует W3C Recommendation. Работающий код — существенное доказательство, но не самостоятельный мандат.

Community Group — не уменьшенная Working Group

W3C описывает Community Groups как открытые бесплатные площадки для раннего сотрудничества. Любой владелец учетной записи W3C может присоединиться к WebAssembly Community Group после принятия Community Contributor License Agreement. На странице также сказано, что группы управляются своими сообществами, а их работа не обязательно отражает позицию членов или сотрудников W3C.

Статус документов тоже разделен. Отчеты Community Group не являются документами стандартного трека и не считаются стандартами W3C. Они могут послужить входом в формальную процедуру. Правовые соглашения и уже уполномоченная Working Group облегчают переход, но не отменяют необходимости самого перехода.

Граница защищает обе модели. Community Group может быстро экспериментировать, приглашать людей вне членства W3C и проверять идеи до более тяжелого Recommendation Track. Working Group может использовать зрелый результат, сохраняя собственные обязанности по консенсусу, горизонтальным проверкам, патентной политике и публикации. Широкое участие улучшает суждение, но посещаемость не равна всеобщему мандату.

Сжатие статуса меняет реальные решения

Слова о статусе выходят за пределы собраний. Поставщик может заявить поддержку «Component Model», не назвав preview или ревизию. Покупатель может услышать «в уставе W3C» и предположить проверку уровня Recommendation. Инженер может увидеть первую стадию и отвергнуть профиль, для которого инструменты уже обещают ограниченную стабильность. Участник может требовать решения в репозитории, когда формальное повышение должно стоять в повестке Community Group.

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

Есть и противоположный риск. Если публичная таблица не показывает, какие доказательства уже собраны и какое условие еще не выполнено, внешний пользователь не понимает реального расстояния до передачи. Репутация и частные объяснения заменяют проверяемую запись. Хороший статус должен одновременно показывать действительное внедрение и незавершенное формальное продвижение.

Одно досье для двух ключей

Новый верховный комитет не нужен. Достаточно тонко соединить существующие открытые состояния.

Сторона Community Group начинается с неизменяемой ревизии предложения, текущей стадии, даты и записи последнего решения и входных критериев запрашиваемой стадии. Каждый критерий указывает на доказательство: названные Web VM, точную ревизию набора тестов и результаты, toolchain, формальную спецификацию, эталонный интерпретатор и открытые исключения. Если критерий неприменим, должны быть указаны автор решения и причина.

Запись решения содержит публичную повестку, метод, результат и зафиксированные возражения, не выдавая присутствие за универсальное согласие. Если повышается только ограниченный поднабор, он должен быть точно определен; другие функции того же Preview не переходят границу вместе с брендом.

Вторая половина начинается при приеме Working Group. Она фиксирует принятую ревизию, Call for Consensus или иной механизм, вопросы, возвращенные на инкубацию, горизонтальные проверки, патентный статус, отчет о реализациях и публикационный статус W3C. Возврат из-за существенного изменения создает новое состояние, а не переписывает старую передачу.

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

Что известно на 31 августа

W3C утвердил действующий устав WebAssembly Working Group. Группа может выполнять безусловные задачи и принять Component Model после выполнения названного требования. Публичная таблица указывает первую стадию. Репозиторий документирует значительную инженерную работу и ограниченное производственное использование preview вне браузера.

Проверенные материалы не показывают, что Community Group отклонила запрос на четвертую стадию, W3C задержал работу или разработчик обошел процесс. Они не доказывают несовместимость, небезопасность, захват поставщиком или патентную проблему. Они также не делают Component Model рекомендацией W3C.

Точное описание менее драматично и полезнее: технология реальна, формальное продвижение не завершено, новая хартия сохраняет маршрут между этими состояниями. Следующее изменение должно оставить проверяемую квитанцию решения.

Источники

  1. W3C — уведомление об утверждении устава WebAssembly Working Group
  2. W3C — устав WebAssembly Working Group, действующий с 20 августа 2026 года
  3. WebAssembly — реестр предложений, зафиксированный 10 августа 2026 года
  4. WebAssembly — процедура перехода между стадиями
  5. WebAssembly — вехи репозитория Component Model
  6. W3C — WebAssembly Community Group
  7. W3C — FAQ о Community и Business Groups
  8. W3C — типы публикуемых документов
  9. Lu Heng — The Multi-Stakeholder Mirage