要約

  • JSCalendar 2.0ドラフト第21版は小さく重要な条件を加えた。Task全体のprogressが明示されていない場合、既定値をcompletedにするには少なくとも一人の参加者が進捗を報告していなければならない。
  • 沈黙は失敗でも作業中でもない。しかし完了証拠でもない。報告者数、受け取った値、規則の版、集約が明示値か導出値かを残す必要がある。

プロジェクト表の進捗欄がすべて空だとする。誰も完了を報告していない。失敗も作業中も報告されていない。それでも「存在するすべての進捗値はcompletedだ」という判定が反例を見つけられず、行が緑になることがある。

2026年10月2日にIETF Datatrackerへ記録された JSCalendar 2.0: A JSON Representation of Calendar Data 第21版は、この空白を仕様の中で閉じる。対象はTaskに明示的な全体progressがないとき、参加者の状態から既定値をどう導くかという規則である。

第20版は、RFC 8984にもある表現を引き継ぎ、すべての参加者のprogress値がcompletedなら既定値をcompletedとしていた。第21版は存在条件を加える。少なくとも一人がprogressプロパティを持ち、そのプロパティを持つ参加者の全員がcompletedでなければならない。

空集合に対する全称命題は形式論理では真になり得る。実装者やクエリエンジンが「すべて完了」を、反対する値が一つもない状態として評価すれば、報告ゼロが完了になり得る。ただし凍結した資料に、実製品がそう動いた証拠や事故記録はない。ここで確認できるのは、旧文言にあった解釈余地を新しい文言が除いたことまでだ。

新規則は「名簿の全員が必ず報告する」という意味でもない。参加者のprogressは任意である。十人が登録され二人だけが報告した場合、その二人がともにcompletedでTask全体の明示値がなければ、既定値はcompletedになり得る。沈黙した八人は自動的な拒否票ではない。禁止されたのは、適格な報告が一件もない状態から完了を作ることだ。

だから分母を隠してはならない。「報告した二人のうち二人完了」と「登録された十人のうち二人だけが報告し、その二人が完了」は同じ既定値を返しても、管理上の意味は違う。前者は述語の結果、後者は観測範囲である。集約だけを示す画面は、運用判断に必要な情報を捨てている。

評価順序も決まっている。まず一件以上の参加者progressがあり、存在するすべての値がcompletedなら完了。そうでなければ、一件でもfailedがあれば失敗。failedがなく一件でもin-processなら作業中。どれにも当てはまらない場合、報告ゼロを含めてneeds-actionとなる。

混在時は多数決ではない。completedとfailedならfailed、completedとin-processならin-processになる。欠落値をfailed、in-process、completedのどれかに作り替えることもない。欠落は欠落のまま、実際に存在する報告だけが順序付きの条件に入る。

この導出が働くのはTask全体のprogressが省略された場合だけである。権限を持つ生成者が全体値を明示すれば、参加者からの既定導出はそれを上書きしない。同じcompletedでも、直接assertされた状態と規則からderivedされた状態がある。監査記録が最後の単語しか持たなければ、その来歴を復元できない。

参加者報告にも入口条件がある。第21版ではParticipantのprogressはTask内だけで定義され、設定時にはcalendarAddressが必要で、participationStatusはacceptedでなければならない。基本値はin-process、completed、failedで、IANA登録値やvendor-specific値も規則に従って利用できる。Task全体にはcancelledがあるが、参加者progressの基本値にはない。

percentCompleteは代用品ではない。別の任意プロパティで、0から100までの整数として定義される。より細かな表示には使えるが、分類状態を数値平均で求める規則ではない。別のローカル方針と記録がなければ、100を自動的にcompletedへ変えたり、未報告をゼロに変えたりすべきではない。

既存標準も境界を支える。RFC 5545はVTODOのSTATUS、完了時刻、参加者の参加状態を別に扱う。RFC 5546も、organizerが管理するobject stateと、スケジューリング交換でattendeeが示すPARTSTATを区別する。JSONモデルが扱いやすくても、個人の寄与とタスク全体は同じ事実ではない。

伝送はさらに別の層だ。JMAP Calendarsは日程データを同期でき、CalDAV schedulingには固有の権限と配送規則がある。API保存の成功、メッセージ受理、IANAレジストリ上の名称は、特定製品が第21版の集約を実行した証明ではない。現在の文書はCALENDAR EXTENSIONS Working GroupのIETF stream文書で、Proposed Standardを意図しAD Evaluation中だが、まだRFCではない。

カレンダー状態は現実の成果を証明しない。参加者が完了と記録しても成果物が届かないことはある。Taskの同期に成功しても外部ジョブは失敗し得る。明示された全体状態自体が誤っている場合もある。第21版が改善するのは、報告ゼロから完了を製造しない点であり、報告内容の真実性や履行を保証するものではない。

Lu HengのMinimum Initial Specificationが示す共通層は小さい。独立判断を奪わず、「観測なし」を「完了」にしない決定的条件だけを共有する。Running-Code Primacyは、実行されたdraft revision、query、default rule、override pathを問う。Reality Layersは、正しいcalendar aggregateが未観測の実績に権威を持つことを防ぐ。

必要なのはaggregate receiptである。Task UIDとversion、明示された全体progress、参加者総数、報告者数、受理した値、拡張値、評価順序、導出結果、evaluator version、下流動作を保存する。単にcompletedと書くのではなく、assertedかderivedかも示す。

短い存在条件が守る原則は明快だ。一致した証拠と呼ぶなら、少なくとも一件の証拠が要る。沈黙にはフォローアップが必要かもしれないが、便利な既定値で成功へ昇格させてはならない。

出典