Das WoT-Register des W3C verlangt zwei Prüfungen – aber nicht zwingend zwei Prüfer

Zusammenfassung

• Die Prüfung der vorgeschlagenen WoT-Charta durch das W3C Advisory Committee endet am 31. August 2026 um 23:59 UTC. Zum Redaktionsschluss lag kein öffentliches Ergebnis vor.
• Die Charta soll ein WoT Binding Registry einführen und sieht für 2027 die Stufen Registry Draft, Candidate Registry und W3C Registry vor.
• Das öffentliche Registerdokument bezeichnet sich weiterhin als Pilot. Die wenigen vom Arbeitskreis verfassten Bindings können Initial noch nicht verlassen; externe Einreichungen sollen erst danach beginnen.
• Für Current sind eine Zielprotokoll- und eine WoT-Konformitätsprüfung erforderlich. Der Entwurf erlaubt einer in beiden Gebieten qualifizierten Person, beide Prüfungen in getrennten Dokumenten vorzunehmen.
• Current heißt, dass der Verwalter das Binding für neue Implementierungen empfiehlt und ausreichende Implementierungserfahrung sieht. Es ist weder eine W3C Recommendation noch ein allgemeiner Interoperabilitätsnachweis.
• Ein Rollen- und Evidenzbeleg sollte offenlegen, ob eine oder zwei Personen prüften, welche Belege jede Rolle verwendete, was getestet wurde und warum der Verwalter den Zustand änderte.

Das Ende der Prüfung ist noch keine Genehmigung

Frühere WoT-Chartas behandelten Protokoll-Bindings vor allem als Dokumente. Der neue Vorschlag schafft eine strukturierte, veränderliche Liste, in die auch externe Standardisierungsgemeinschaften einreichen können. Damit entsteht eine dauerhafte Entscheidungsoberfläche: Einträge werden aufgenommen, empfohlen, ersetzt oder für obsolet erklärt.

Der 31. August beendet nur den Prüfungszeitraum. Die bestehende Charta wurde bis 16. Oktober verlängert, und der Vorschlag enthält weiterhin Platzhalter für sein endgültiges Anfangs- und Enddatum. Registry Draft im ersten Quartal 2027, Candidate Registry im zweiten und W3C Registry im dritten Quartal sind Planwerte, keine bereits erreichten Reifestufen.

Gleichwohl liegt ein konkreter Pilot vor. Der Binding-Registry-Entwurf definiert Felder, Einreichungsregeln, Lebenszyklus, Tests und Zuständigkeiten. Er erklärt ausdrücklich, noch kein W3C Registry zu sein. Während des Piloten bleiben wenige interne Bindings bei Initial; externe Beiträge sollen anschließend geöffnet werden.

Diese Trennung erlaubt reale Erprobung, ohne einem Versuch vorzeitig institutionelles Gewicht zu verleihen.

Current kann zum Entscheidungskürzel werden

Der Lebenszyklus kennt Initial, Current, Superseded und Obsolete. Einträge werden nicht gelöscht. Eine neue Version erhält einen neuen Datensatz, während die alte Version mit verändertem Status bestehen bleibt.

Current bedeutet mehr als „zuletzt aktualisiert“. Der Entwurf beschreibt damit ein Binding, das der Verwalter für neue Implementierungen empfiehlt und dem er ausreichende praktische Erfahrung zuschreibt. Entwicklungswerkzeuge, Integratoren und Beschaffer können dieses Wort als Vorauswahl nutzen. Das Register beeinflusst damit Umsetzung, auch wenn es das Protokoll nicht selbst definiert.

Der W3C Process begrenzt diese Wirkung. Register dokumentieren Werte; Architektur- und Interoperabilitätsanforderungen müssen in den referenzierenden Spezifikationen stehen. Registry Reports unterliegen nicht der W3C Patent Policy und werden durch einen stabilen Eintrag nicht zu Recommendations.

Auch die Zuständigkeit für externe Protokolle bleibt erhalten. Zeigt die Arbeit an einem Binding Änderungsbedarf bei MQTT, Modbus, BACnet, CoAP oder einem anderen Protokoll, muss die WoT Working Group die verantwortliche Organisation ansprechen. Ein Registereintrag ist keine Änderungsbefugnis.

Gerade deshalb muss jede Statusentscheidung ihre Aussagegrenzen mitführen.

Zwei Fragen, möglicherweise ein Kopf

Vor Current stehen zwei analytisch getrennte Prüfungen. Die erste untersucht die Abbildung des Zielprotokolls: Werden WoT-Operationen korrekt in dessen Nachrichten übersetzt? Die zweite untersucht die Einhaltung der Thing Description und damit, ob ein Consumer die beschriebenen Interaktionen verstehen und ausführen kann.

Der Entwurf empfiehlt mindestens zwei Prüfer, einen für die Zielspezifikation und einen für WoT. Unmittelbar danach erlaubt er derselben Person, beide Rollen zu übernehmen, wenn sie in beiden Gebieten sachkundig ist. Zwei getrennte Prüfberichte bleiben vorgeschrieben.

Das kann vernünftig sein. Fachleute, die ein spezialisiertes Industrieprotokoll und die Web-Abstraktion gleichermaßen beherrschen, sind selten. Eine zweite Unterschrift ohne zusätzliches Wissen wäre nur Verzögerung.

Zwei Dokumente sind aber keine zwei unabhängigen Bestätigungen. Dieselbe falsche Versionsannahme, derselbe schwache Test oder dieselbe übersehene Ausnahme kann beide Berichte prägen. Umgekehrt garantieren zwei Namen keine Unabhängigkeit: Beide können Arbeitgeber, Code, Testumgebung oder Interessen teilen.

Die belastbare Lösung ist deshalb eine sichtbare Prüfstruktur. Eine Person in zwei Rollen darf ein legitimer Zustand sein; er darf kein unsichtbarer Zustand sein.

Der Testboden ist vorhanden, sein Belegformat bleibt offen

Der Pilot verlangt mehr als Papier. Jede im Binding definierte Operation muss bei einem Testereignis automatisiert validiert werden. Der Test Report soll Umgebung, Szenario und logischen Weg von der Thing Description bis zur Kommunikation beschreiben. Mindestens ein Consumer und ein Exposer müssen die beschriebenen Operationen und Funktionen abdecken.

Lauffähige Implementierungen stehen damit tatsächlich vor der Empfehlung.

Zugleich hält der Entwurf fest, dass der genaue Inhalt des Test Reports noch nicht entschieden ist. Er verweist auf das seit Februar 2025 offene Issue 3. Ungeklärt ist also das Evidenzschema, nicht die Notwendigkeit von Tests.

Die offenen Punkte verändern die Aussagekraft: Gehören optionale Fehlerpfade zu „jeder Operation“? Dürfen beide Enden aus derselben Codebasis stammen? Wie werden gemeinsam genutzte Bibliotheken oder Test-Harnesses offengelegt? Bleiben Fehlläufe und Korrekturen erhalten? Was belegt semantische Übereinstimmung jenseits bloßen Nachrichtenaustauschs?

Bevor externe Einträge Current werden können, sollte der Text diese Fragen beantworten. Sonst definiert der erste akzeptierte Fall den Standard durch Präzedenz.

Ein Rollen- und Evidenzbeleg für jede Transition

Öffentliche Issues, Reviews, Pull Requests und Wartefristen sind bereits vorgesehen. Es braucht keine neue Instanz, sondern eine kompakte Verbindung dieser Artefakte mit der Zustandsentscheidung.

Der Beleg fixiert Binding-Version, Zielspezifikation, Hilfsdokumente und angewandte Registerdefinition. Beide Prüfrollen erscheinen getrennt, mit Person, einschlägiger Qualifikation und ausdrücklicher Angabe einer Doppelrolle. Relevante Bindungen zum Einreicher, Protokoll oder getesteten Implementierungen gehören in eine begrenzte Interessenerklärung, nicht in eine Personalakte.

Der Evidenzteil nennt Termine, Umgebungen, Consumer, Exposer, Abdeckung je Operation, gemeinsamen Code und ungetestete Pfade. Jeder Bericht behält Befunde, Vorbehalte und Änderungswünsche. Danach folgen Kommentarfrist, Einwände sowie die datierte und begründete Entscheidung des Verwalters.

Vier Nichtaussagen sollten neben Current stehen: keine W3C Recommendation, kein universeller Interoperabilitätsnachweis, keine Änderung des Ursprungsprotokolls und kein Patentversprechen für das Registerdokument.

Wird der Eintrag später Superseded oder Obsolete, bleibt der Beleg erhalten. Eine alte Zeile ohne Grund ihrer früheren Empfehlung ist nur eine halbe Historie.

Heng Lus Unterscheidung ist hier nützlich: Fachwissen liefert Urteil, laufender Code liefert Evidenz, der Verwalter übt ein begrenztes Mandat aus. Keines ersetzt die anderen.

Der Pilot ist der günstigste Zeitpunkt

Die Quellen belegen weder ein Scheitern einer Doppelrollenprüfung noch eine Vereinnahmung des Verfahrens oder einen mangelhaften Binding-Eintrag. Kein externer Antrag hat nachweislich Current erreicht. Die Charta ist weiterhin vorgeschlagen.

Eben deshalb lässt sich die Dokumentation jetzt ohne Krisenmodus ordnen. Sobald Werkzeuge und Beschaffung Current als Standardauswahl behandeln, wird die nachträgliche Rekonstruktion teuer.

Zwei Prüfungen können von zwei Personen oder von einer Person kommen. Das Register sollte diesen Unterschied bewahren, statt ihn in einer grünen Zelle verschwinden zu lassen.

Quellen

1. W3C-Hinweis zur Prüfung der vorgeschlagenen WoT-Charta
2. Vorgeschlagene Charta der Web of Things Working Group
3. Geltende Charta der Web of Things Working Group
4. Pilotentwurf des WoT Binding Registry
5. Fixierte Quelle des Registers
6. Issue 3: Inhalt des Test Reports
7. W3C Process: Registry Track
8. Heng Lu, The Multi-Stakeholder Mirage