Résumé

  • La révision 21 du projet JSCalendar 2.0 ajoute une condition de couverture : si le progress global d’une Task est absent, au moins un participant doit avoir fourni une valeur avant que le défaut puisse devenir completed.
  • L’absence de relevé n’est ni un échec ni un travail en cours, mais elle n’est pas une preuve d’achèvement. Il faut conserver le dénominateur, les valeurs reçues, la version de règle et l’origine explicite ou dérivée du résultat.

Un tableau de pilotage peut afficher une tâche, dix participants et une colonne d’avancement entièrement vide. Personne n’a déclaré avoir fini. Personne n’a non plus signalé un échec. Pourtant, une règle formulée comme « toutes les valeurs présentes sont completed » peut ne trouver aucune contradiction et colorer la ligne en vert.

C’est cette frontière discrète que traite la révision 21 de JSCalendar 2.0: A JSON Representation of Calendar Data, enregistrée le 2 octobre 2026. Le changement porte sur le défaut calculé lorsqu’une Task ne contient pas de progress global explicite.

La révision 20, comme le RFC 8984, disait que le défaut était completed si la valeur de tous les participants était completed. La révision 21 exige désormais qu’au moins un participant possède effectivement une propriété progress et que tous les participants qui en possèdent une aient fourni completed.

Cette existence minimale évite une ambiguïté de l’ensemble vide. En logique formelle et dans certains moteurs de règles, une proposition universelle peut être vraie faute de contre-exemple. Les sources gelées ne prouvent pas qu’un logiciel déployé a réellement clôturé une tâche de cette manière. Elles prouvent une modification textuelle qui empêche désormais de transformer zéro observation en conclusion positive.

La règle ne dit pas que chaque personne inscrite doit répondre. Le progrès du Participant reste facultatif. Si deux personnes sur dix rendent une valeur et que ces deux valeurs sont completed, le défaut peut être completed, à condition qu’aucun progrès global explicite ne soit présent. Les huit silences ne deviennent pas automatiquement des refus. Seul le passage de zéro relevé à un achèvement est interdit.

Le dénominateur doit donc accompagner le résultat. « Deux rapporteurs sur deux ont terminé » et « deux participants sur dix ont rendu un relevé, tous deux terminé » satisfont le même prédicat, mais ne décrivent pas la même couverture. Une interface qui masque cette différence remplace l’information de contrôle par une couleur.

L’ordre des critères tranche les cas mixtes. Il y a completed si au moins une valeur existe et si toutes les valeurs présentes sont completed. Sinon, la présence d’un failed donne failed. En l’absence d’échec, une valeur in-process donne in-process. Si aucun critère ne correspond, notamment quand aucun relevé n’existe, le défaut est needs-action.

Ce n’est pas un vote. Un completed et un failed produisent failed ; un completed et un in-process produisent in-process. Les valeurs absentes ne sont inventées ni comme échec, ni comme travail en cours, ni comme achèvement. Elles restent absentes tandis que la règle évalue les observations réellement fournies.

Le calcul ne s’applique que si le progress global de la Task est omis. Une valeur globale explicite reste une assertion distincte. Deux états affichés completed peuvent donc avoir des provenances différentes : l’un a été écrit directement, l’autre déduit des participants. L’audit doit préserver cette provenance.

Une valeur de Participant est elle-même encadrée. Elle n’est définie qu’au sein d’une Task, exige une calendarAddress et suppose un participationStatus accepted. Ses valeurs de base sont in-process, completed et failed, avec la possibilité de valeurs enregistrées ou spécifiques à un fournisseur. Le niveau Task accepte aussi cancelled, qui n’est pas une valeur de base du progrès individuel.

percentComplete est un autre champ. Il représente un entier optionnel de zéro à cent ; il n’est pas la moyenne normative qui déciderait de la catégorie. Sans règle locale explicite et traçable, cent ne doit pas être converti silencieusement en completed et une absence ne doit pas devenir zéro.

Les standards antérieurs gardent les plans séparés. Le RFC 5545 distingue le STATUS d’un VTODO, son horodatage d’achèvement et l’état de participation d’un attendee. Le RFC 5546 distingue lui aussi l’état de l’objet contrôlé par l’organisateur du PARTSTAT annoncé dans l’échange. Une représentation JSON plus commode ne fusionne pas contribution individuelle et état global.

Le transport est encore autre chose. JMAP Calendars peut synchroniser l’objet et CalDAV dispose de règles d’autorité et de livraison. Une écriture API réussie, un message accepté ou une entrée IANA ne prouve pas qu’un produit exécute déjà la sémantique de la révision 21. Le document est un projet du groupe CALENDAR EXTENSIONS dans le flux IETF, destiné au niveau Proposed Standard et en AD Evaluation ; ce n’est pas encore un RFC.

Enfin, un statut de calendrier n’est pas un reçu du monde réel. Une contribution peut être marquée terminée sans livrable, un objet peut être synchronisé alors que le traitement externe a échoué, et une assertion globale peut être fausse. La nouvelle clause empêche seulement la fabrication d’un achèvement à partir d’aucun rapport.

Le Minimum Initial Specification de Lu Heng suggère la bonne taille de règle commune : assez déterministe pour empêcher l’absence de devenir réussite, sans centraliser le jugement final. Running-Code Primacy exige de nommer la révision, la requête et le chemin d’override réellement exécutés. Reality Layers interdit au symbole completed de devenir une preuve de performance qu’il n’a pas observée.

Le contrôle utile est un reçu d’agrégation : UID et version de la Task, valeur globale explicite, nombre de participants, nombre de rapporteurs, valeurs acceptées, extensions, ordre des prédicats, résultat, version de l’évaluateur et action en aval. Il doit dire asserted ou derived.

Une clause d’existence minuscule pose ainsi une règle institutionnelle : l’unanimité des preuves commence par au moins une preuve. Le silence peut exiger une relance ; il ne doit pas être promu en succès.

Sources