Zusammenfassung

  • Das W3C genehmigte die Charta der WebAssembly Working Group am 20. August 2026. Sie läuft bis 27. August 2028 und umfasst Revisionen der drei vorhandenen Spezifikationen sowie Code Metadata und drei Legacy-Extensions-Spezifikationen.
  • Das Component Model ist nur bedingt als Arbeitsergebnis vorgesehen. Die Working Group will es erst als normative Spezifikation liefern, wenn der Vorschlag im Verfahren der WebAssembly Community Group Phase 4 erreicht hat.
  • In der auf den 10. August festgeschriebenen öffentlichen Vorschlagstabelle steht das Component Model noch in Phase 1. Die Zahl bezeichnet einen institutionellen Zustand, keine Bewertung von Nutzen, Implementierung oder Marktreife.
  • Das Component-Model-Repository dokumentiert WASI Developer Preview 0.2.0, 0.3.0 und 0.3.1. Aktivierte Funktionen werden laut Repository von Producer- und Consumer-Werkzeugen stabil gehalten, damit sie außerhalb des Browsers produktiv eingesetzt und praktisch erprobt werden können.
  • Phase 4 verlangt Implementierungen, Tests, eine vollständige Spezifikation, einen vollständigen Referenzinterpreter und Konsens in der Community Group. Nach der Übergabe muss die Working Group eigenständig Konsens herstellen und das W3C-Verfahren abschließen.
  • Ein Zwei-Schlüssel-Promotionsdossier sollte die unveränderliche Vorschlagsrevision und kriterienscharfe Belege mit der Entscheidung der Community Group verbinden und anschließend die Annahme durch die Working Group sowie den W3C-Publikationsstand separat dokumentieren.

Die Charta genehmigt einen Weg, keinen erreichten Zustand

Die Genehmigungsnachricht des W3C ist knapp. Den institutionellen Rahmen liefert die Charta: Sie beginnt am 20. August 2026, endet am 27. August 2028 und nennt Vorsitz, Teamkontakt, Arbeitsumfang, Ergebnisse und Entscheidungsregeln.

Mehrere Vorhaben gehören ohne Vorbedingung zum Mandat. Die Gruppe soll Revisionen der WebAssembly Core Specification, der JavaScript Interface und der Web API erarbeiten. Neu hinzu kommen eine WebAssembly Code Metadata Specification und drei Texte, die veraltete, möglicherweise noch verwendete Erweiterungen für Core, JavaScript und Web API abtrennen.

Beim Component Model verwendet die Charta eine andere Konstruktion. Die Working Group „strebt“ die Spezifikation an, sofern der Vorschlag im Phasenprozess der Community Group Phase 4 erreicht. Das ist weder eine Ablehnung noch eine erfolgte Aufnahme. Die Klausel sagt, wer handeln darf, nachdem eine überprüfbare Eintrittsbedingung erfüllt ist.

Diese Bedingung stand bereits in der Charta von 2023. Das Mandat von 2026 verlängert die Konstruktion. Es verwandelt drei Jahre Inkubation nicht rückwirkend in eine unausgesprochene Promotion. Eine Charta kann Zuständigkeit für künftige Arbeit schaffen; sie kann aber weder die Phasenentscheidung treffen noch die dafür verlangten Artefakte herstellen.

Die Formulierung „in der W3C-Charta“ sollte deshalb nicht als Kurzform für „W3C-Standard“ dienen. Zwischen beiden Aussagen liegen mindestens eine Entscheidung der Community Group und eine eigene Entscheidung der Working Group.

Das reproduzierbare Register steht weiterhin auf eins

Das Repository WebAssembly/proposals dient als öffentliches Zustandsverzeichnis. Für diesen Bericht wurde der Stand vom 10. August fixiert. Die Tabelle ordnet Vorschläge den Phasen 1 bis 5 zu; das Component Model steht in der Liste für Phase 1.

Dieses Register ist belastbarer als Rückschlüsse aus Konferenzpräsenz, Repository-Aktivität oder Produktankündigungen. Sein Aussageumfang bleibt jedoch eng. Phase 1 bedeutet nicht, dass das Vorhaben bedeutungslos, verlassen, nicht implementiert oder produktionsuntauglich sei. Es bedeutet, dass in diesem veröffentlichten Verfahren keine spätere Phase registriert ist.

Ebenso beweist ein bis zum Stichtag unveränderter Eintrag nicht, dass seit dem 10. August keine Gespräche, noch nicht eingepflegten Entscheidungen oder unveröffentlichten Änderungen existieren. Wenn der Datensatz fortgeschrieben wird, gilt der neue datierte Stand. Eine spätere Promotion darf aber nicht so erzählt werden, als hätte der frühere Zustand nie eine institutionelle Bedeutung gehabt.

Phasen sind keine Schulnoten und kein Fertigstellungsprozentsatz. Phase 1 sagt, dass die Community Group einen in den Arbeitsbereich passenden und plausiblen Vorschlag angenommen hat, dessen Träger nun Entwurf und Konsens vertiefen sollen. Nutzerzahlen, Investitionen, Codeumfang oder Spezifikationsseiten misst die Zahl nicht.

Phase 4 ist eine belegte Übergabe

Das Phasenmodell verteilt Reifeprüfung und Standardisierungsgewalt auf zwei Institutionen. Ein Aufstieg wird auf die Tagesordnung einer Sitzung der Community Group gesetzt. Die Gruppe entscheidet, ob die Eintrittsanforderungen der nächsten Phase erfüllt sind.

Phase 2 fordert einen präzisen, vollständigen Überblick und einen hinreichend hohen Konsens. In Phase 3 kommen Testsuite und Implementierungsarbeit hinzu. Phase 4 setzt deutlich mehr voraus: Soweit anwendbar, müssen mindestens zwei Web-VMs die Funktion implementieren und die Tests bestehen. Mindestens eine Toolchain muss sie umsetzen. Spezifikation und Referenzinterpreter müssen vollständig sein, der Interpreter muss die Tests bestehen, und die Community Group braucht Konsens sowohl zur Funktion als auch zur Vollständigkeit der Spezifikation.

Erst danach wird die Funktion vollständig an die Working Group übergeben. Dort endet die Prüfung nicht. Die Mitglieder untersuchen Randfälle, bestätigen ihren eigenen Konsens und erfüllen den W3C-Standardisierungsprozess. Erfordert das erhebliche Änderungen, geht die Arbeit an die Community Group zurück. Phase 5 setzt wiederum den Konsens der Working Group voraus, dass die Funktion fertig ist.

Die Abfolge schließt zwei Abkürzungen aus. Die Working Group darf einen frühen Entwurf nicht allein wegen seiner Erwähnung in der Charta als reif behandeln. Die Community Group kann aus ihrer eigenen Phasenentscheidung nicht ohne Weiteres einen W3C-Standard machen. Implementierungen liefern beiden Seiten Belege, doch ausgelieferter Code betätigt keinen institutionellen Schlüssel.

Produktionsnahe Previews können in Phase 1 existieren

Das wichtigste Gegengewicht zu einer rein formalen Lesart liegt im Component-Model-Repository. Es enthält Entwurfsunterlagen, Binär- und Textformat, Verknüpfungs- und ABI-Dokumente, eine wachsende Testsammlung und mehrere Developer-Preview-Meilensteine.

WASI Developer Preview 0.2.0 war der erste auf dem Component Model beruhende Preview. Version 0.3.0 brachte native Nebenläufigkeit, 0.3.1 weitere Typen und Annotationen. Das README erklärt, die in diesen Previews aktivierten Funktionen würden durch Producer- und Consumer-Werkzeuge stabil gehalten. Damit könnten sie außerhalb des Browsers in Produktionsumgebungen eingesetzt werden, während praktische Rückmeldungen einfließen.

Damit ist die Gleichsetzung „Phase 1 bedeutet, es gibt nichts“ unhaltbar. Ein Ökosystem kann eine begrenzte Oberfläche stabilisieren, reale Systeme betreiben und Kompatibilitätszusagen geben, bevor formale Standardisierung abgeschlossen ist. Diese Erfahrungen können besonders wertvolle Reifebelege liefern.

Dasselbe README kündigt eine formale Spezifikation und einen Referenzinterpreter erst für die Zukunft an. Der Satz erklärt, warum technische Substanz und institutionelle Phase auseinanderliegen können. Ein ausgewähltes Produktionsprofil kann stabil sein, obwohl nicht sämtliche Artefakte und Konsensanforderungen für Phase 4 erfüllt sind.

Der umgekehrte Fehlschluss wäre folgenreicher. Produktionsnutzung führt keine Abstimmung der Community Group durch, vollendet keinen Referenzinterpreter, übergibt den Vorschlag nicht an die Working Group und veröffentlicht keine W3C Recommendation. Laufender Code ist ein Beleg, kein selbständiges Mandat.

Community Group und Working Group sind verschiedene Rollen

W3C beschreibt Community Groups als offene, gebührenfreie Foren für frühe Zusammenarbeit. Wer ein W3C-Konto besitzt und dem Community Contributor License Agreement zustimmt, kann der WebAssembly Community Group beitreten. Zugleich weist ihre öffentliche Seite darauf hin, dass Community Groups von ihren Gemeinschaften geführt werden und nicht zwangsläufig die Auffassung der W3C-Mitglieder oder des Teams vertreten.

Auch die Dokumentenlehre zieht eine klare Linie. Community Group Reports sind weder Standards-Track-Dokumente noch W3C-Standards. Sie können als Ausgangsmaterial in den formalen Prozess einfließen. Rechtliche Vereinbarungen und eine bereits zuständige Working Group erleichtern den Übergang, heben den Übergangsakt aber nicht auf.

Die Grenze schützt beide Arbeitsweisen. Die Community Group kann schnell experimentieren und Nichtmitglieder einbeziehen. Die Working Group kann reife Ergebnisse übernehmen und zugleich eigene Pflichten zu Konsens, Horizontal Reviews, Patent Policy und Publikation erfüllen. Breite Teilnahme verbessert die Urteilsgrundlage; sie macht Anwesenheit nicht zu einem allgemeinen Mandat.

Ungenaue Statuswörter verändern Investitionen

Statusbegriffe verlassen die Standardisierungsgremien. Ein Anbieter kann Unterstützung für „das Component Model“ versprechen, ohne Preview und Revision anzugeben. Ein Einkäufer kann aus der Charta-Erwähnung eine Prüfung auf Recommendation-Niveau ableiten. Ein Entwickler kann Phase 1 als völlige Instabilität missverstehen, obwohl Werkzeuge für ein begrenztes Profil Stabilität zusichern. Ein Beitragender kann an der falschen Stelle auf eine Entscheidung warten.

Das sind nicht bloß Kommunikationsfehler. Eine verbreitete ABI- oder Linking-Entscheidung erzeugt Umstellungskosten. Selbst wenn spätere Belege ein anderes Design nahelegen, wächst der Druck, die bereits installierte Lösung zu ratifizieren. Dieser Druck kann ökonomisch vernünftig sein, sollte aber als Beleg und Übergangskosten sichtbar werden – nicht als lautlose Verlagerung der Entscheidungsgewalt.

Umgekehrt verliert auch ein zu langsamer institutioneller Datensatz an Wert. Zeigt die Tabelle nicht, welche Kriterien bereits erfüllt und welche offen sind, können Außenstehende den verbleibenden Abstand nicht beurteilen. Ruf und private Koordination ersetzen dann einen prüfbaren Fortschrittsnachweis. Eine gute Zustandsdarstellung muss reale Nutzung und unvollständige Promotion zugleich zeigen.

Ein Dossier, zwei Schlüssel

Es braucht kein neues Oberkomitee. Nötig ist eine schmale Verbindung zwischen bestehenden öffentlichen Zuständen.

Auf Seite der Community Group beginnt sie mit einer unveränderlichen Vorschlagsrevision, der aktuellen Phase, Datum und Beleg der letzten Phasenentscheidung und den Kriterien des beantragten Schritts. Jedes Kriterium verweist auf Beweise: benannte Web-VMs, genaue Testsuite und Ergebnisse, Toolchain, formale Spezifikation, Referenzinterpreter und offene Ausnahmen. „Nicht anwendbar“ erhält Entscheider und Begründung.

Der Entscheidungseintrag nennt öffentliche Tagesordnung, Methode, Ergebnis und protokollierte Einwände. Er darf Teilnehmerzahl nicht als universelle Zustimmung ausgeben. Wird nur ein begrenzter Funktionsumfang promoviert, muss dieser eingefroren werden; andere Preview-Bestandteile überschreiten die Grenze nicht wegen eines gemeinsamen Namens.

Die zweite Hälfte beginnt mit dem Empfang durch die Working Group. Sie erfasst die übernommene Revision, Call for Consensus oder anderes Verfahren, zurückgereichte Fragen, Horizontal Reviews, Patentstatus, Implementierungsbericht und W3C-Publikationsstand. Eine Rückgabe wegen wesentlicher Änderung erzeugt einen neuen Zustand, statt den alten Übergabebeleg umzuschreiben.

Private Rechtsberatung, Produktplanung oder jedes Sitzungswort müssen nicht veröffentlicht werden. Es genügt die minimale institutionelle und evidenzielle Spur, die erklärt, warum beide Schlüssel gedreht wurden.

Was sich am 31. August sagen lässt

Das W3C hat eine aktuelle Charta für die WebAssembly Working Group. Sie ermächtigt die Gruppe zu den unbedingten Ergebnissen und erlaubt die Annahme des Component Model, sobald die genannte Bedingung erfüllt ist. Die öffentliche Tabelle führt es in Phase 1. Sein Repository dokumentiert substantielle Preview-Arbeit und begrenzte Produktionsnutzung außerhalb des Browsers.

Die geprüften Quellen belegen weder eine abgelehnte Phase-4-Anfrage noch eine Verzögerung durch das W3C oder eine Umgehung des Verfahrens durch Implementierer. Sie belegen keine Inkompatibilität, Unsicherheit, Anbietervereinnahmung oder Patentstörung. Ebenso belegen sie keine W3C Recommendation.

Der genaue Zustand ist unspektakulär und nützlich: Die Technik ist real, die formale Promotion nicht abgeschlossen. Die neue Charta hält den Weg zwischen beiden offen. Der nächste Zustandswechsel sollte einen überprüfbaren Entscheidungsbeleg hinterlassen.

Quellen

  1. W3C – Genehmigung der Charta der WebAssembly Working Group
  2. W3C – Charta der WebAssembly Working Group, gültig ab 20. August 2026
  3. WebAssembly – Vorschlagsregister, festgeschrieben am 10. August 2026
  4. WebAssembly – Verfahren für den Phasenaufstieg
  5. WebAssembly – Meilensteine im Component-Model-Repository
  6. W3C – WebAssembly Community Group
  7. W3C – FAQ zu Community und Business Groups
  8. W3C – Arten veröffentlichter Dokumente
  9. Lu Heng – The Multi-Stakeholder Mirage