Zusammenfassung

  • Revision 21 des JSCalendar-2.0-Entwurfs ergänzt eine Abdeckungsbedingung: Fehlt der ausdrückliche Gesamtwert progress, muss mindestens ein Teilnehmer Fortschritt gemeldet haben, bevor completed abgeleitet werden kann.
  • Schweigen ist weder Fehlschlag noch laufende Arbeit, aber auch kein Abschlussbeleg. Nenner, Werte, Regelversion und Herkunft als assertion oder derivation gehören in den Prüfpfad.

Eine Statuszeile kann grün werden, obwohl ihre Fortschrittsspalte vollständig leer ist. Die Regel fragt, ob alle vorhandenen Werte completed sind. Kein Wert widerspricht. Aus fehlenden Beobachtungen entsteht scheinbare Einstimmigkeit.

Revision 21 von JSCalendar 2.0: A JSON Representation of Calendar Data, am 2. Oktober 2026 im IETF Datatracker erfasst, schließt genau diese Lücke. Sie betrifft den Standardwert einer Task, wenn kein ausdrücklicher Gesamt-progress gesetzt ist.

Revision 20 und RFC 8984 formulierten completed, wenn die Fortschrittswerte aller Teilnehmer completed sind. Revision 21 fordert zusätzlich mindestens eine tatsächlich vorhandene Participant-progress-Eigenschaft; alle Teilnehmer mit dieser Eigenschaft müssen completed melden.

Die Ergänzung verhindert eine leere All-Aussage. In formaler Logik und manchen Abfragen kann „alle Elemente erfüllen die Bedingung“ bei null Elementen wahr sein. Das Quellenpaket belegt keine reale Fehlfunktion eines Kalenderprodukts. Es belegt eine Textänderung, die null Beobachtungen nicht mehr als positives Ergebnis zulässt.

Nicht jeder gelistete Teilnehmer muss melden. Participant progress bleibt optional. Bei zehn Teilnehmern und zwei Meldungen kann der Standard completed sein, wenn beide Meldenden completed angeben. Die acht Schweigenden sind kein automatisches Veto. Verboten ist nur die Ableitung aus genau null qualifizierten Meldungen.

Damit wird der Nenner zum Kontrollwert. „Zwei von zwei Meldenden fertig“ und „zwei von zehn Teilnehmern meldeten, beide fertig“ erfüllen denselben Prädikatstest, haben aber andere Evidenzabdeckung. Ein Dashboard, das nur completed zeigt, versteckt diesen Unterschied.

Die Reihenfolge ist fest. Mindestens ein Wert und ausschließlich completed ergibt completed. Andernfalls führt jedes failed zu failed. Gibt es kein failed, aber ein in-process, lautet das Ergebnis in-process. Passt nichts, insbesondere bei null Meldungen, gilt needs-action.

Es ist keine Mehrheitswahl. completed plus failed wird failed; completed plus in-process wird in-process. Fehlende Werte werden nicht zu failure, work in progress oder completion erfunden. Sie bleiben fehlend.

Die Ableitung greift nur bei fehlendem Task-Gesamtwert. Ein expliziter Wert ist eine eigene Aussage. Zwei Anzeigen mit completed können daher verschiedene Provenienz haben: direkt asserted oder aus Teilnehmerwerten derived. Die Speicherung nur des Endworts zerstört diese Information.

Auch Participant progress hat Voraussetzungen. Er ist nur innerhalb einer Task definiert, verlangt calendarAddress und einen participationStatus accepted. Basiswerte sind in-process, completed und failed, ergänzt um registrierte oder herstellerspezifische Werte. cancelled gehört zum Task-Vokabular, nicht zu den Basiswerten des Teilnehmers.

percentComplete ist getrennt. Die optionale Zahl von null bis hundert ist weder normativer Durchschnitt noch automatische Kategorie. Eine Umwandlung von 100 in completed oder von missing in null Prozent braucht eine ausdrückliche lokale Regel.

RFC 5545 trennt VTODO STATUS, Abschlusszeitpunkt und Teilnehmerstatus. RFC 5546 unterscheidet Objektstatus des Organisators und PARTSTAT des Attendees. JSON-Komfort hebt die Grenze zwischen individuellem Beitrag und Gesamtaufgabe nicht auf.

JMAP Calendars und CalDAV fügen Transport, Synchronisation und Autorität hinzu. Ein erfolgreicher API-Schreibvorgang oder IANA-Eintrag beweist nicht, dass Revision 21 in einem Produkt läuft. Das Dokument ist ein CALENDAR-EXTENSIONS-Working-Group-Draft im IETF-Stream, für Proposed Standard vorgesehen und in AD Evaluation; es ist noch kein RFC.

Ein Kalenderstatus ist zudem kein Wirkungsbeleg. Ein Beitrag kann als fertig markiert sein, obwohl die Lieferung fehlt; ein Objekt kann synchronisiert werden, während der externe Job scheitert. Revision 21 verhindert Abschluss ohne Meldung, garantiert aber nicht die Wahrheit vorhandener Meldungen.

Lu Hengs Minimum Initial Specification setzt die gemeinsame Regel richtig klein: keine Erfolgsableitung ohne Beobachtung. Running-Code Primacy fragt nach tatsächlich ausgeführter Revision, Abfrage und Override. Reality Layers verhindert, dass ein gültiger Kalenderwert als Nachweis realer Erfüllung gilt.

Ein Aggregationsbeleg sollte Task UID und version, expliziten Gesamtwert, Teilnehmerzahl, Meldendenzahl, Werte, Erweiterungen, Prüfreihenfolge, Ergebnis, Evaluator-Version und Folgeaktion enthalten. Er muss asserted und derived unterscheiden.

Die kurze Existenzklausel schützt ein institutionelles Prinzip: Einstimmige Evidenz beginnt mit wenigstens einer Evidenz. Schweigen kann Nachfassen verlangen, aber keinen automatischen Erfolg.

Quellen