Кратко

  • В редакции 21 проекта JSCalendar 2.0 появилось условие покрытия: если общий progress Task не задан явно, для значения completed нужен хотя бы один отчёт участника.
  • Молчание не означает ни failure, ни work in progress, но и не служит доказательством завершения. Аудит должен хранить знаменатель, значения, версию правила и происхождение результата — asserted или derived.

В панели управления может появиться зелёная строка, хотя колонка прогресса пуста у всех участников. Никто не сообщил о завершении. Но правило «все имеющиеся значения равны completed» не встречает возражения и превращает пустоту в единогласие.

Редакция 21 JSCalendar 2.0: A JSON Representation of Calendar Data, отмеченная Datatracker 2 октября 2026 года, закрывает именно эту границу. Речь идёт о состоянии по умолчанию, когда у Task отсутствует явный общий progress.

Редакция 20, как и RFC 8984, говорила: completed, если progress всех участников completed. Редакция 21 добавляет существование наблюдения: хотя бы у одного участника должно быть свойство progress, и у всех участников с таким свойством значение должно быть completed.

Это устраняет двусмысленность пустого множества. В формальной логике и некоторых запросах фраза «все элементы удовлетворяют условию» бывает истинной при отсутствии элементов. Источники не показывают, что реальный продукт допускал такую ошибку, поэтому статья не объявляет инцидент. Она фиксирует нормативное уточнение, не позволяющее получить положительный итог из нуля сообщений.

Уточнение не требует ответа каждого указанного участника. Participant progress остаётся необязательным. Если из десяти человек ответили двое и оба указали completed, результат по умолчанию может быть completed. Восемь молчащих не становятся автоматическим запретом. Запрещён только итог completed при нуле пригодных отчётов.

Поэтому знаменатель входит в управленческую запись. «Два из двух сообщивших завершили» и «из десяти участников сообщили двое, оба завершили» удовлетворяют одному предикату, но отражают разное покрытие. Один агрегированный цвет стирает различие.

Порядок проверки определён. Наличие хотя бы одного значения и только completed даёт completed. Иначе любой failed даёт failed. При отсутствии failed хотя бы один in-process даёт in-process. Если ничто не сработало, включая ноль отчётов, результат — needs-action.

Это не голосование. completed вместе с failed превращается в failed; completed вместе с in-process — в in-process. Пропуски не выдумываются как failure, работа или завершение. Они остаются пропусками.

Вывод применяется только при отсутствии общего Task progress. Явно записанное значение является отдельным утверждением. Два одинаковых completed могут быть прямой assertion и результатом derivation. Если сохранить лишь слово, путь решения потерян.

У Participant progress есть собственные условия: он определён только внутри Task, требует calendarAddress и participationStatus accepted. Базовые значения — in-process, completed и failed; допустимы зарегистрированные и vendor-specific расширения. cancelled есть на уровне Task, но не в базовом наборе участника.

percentComplete тоже отдельный показатель. Это необязательное целое от нуля до ста, не нормативное среднее для категории. Превращение ста в completed или пропуска в ноль допустимо лишь по явной локальной политике с записью преобразования.

RFC 5545 разделяет STATUS VTODO, время завершения и статус участия. RFC 5546 различает состояние объекта организатора и PARTSTAT участника. Удобная JSON-модель не объединяет личный вклад и общую задачу.

JMAP Calendars и CalDAV добавляют транспорт, синхронизацию и полномочия. Успешная запись API или имя в реестре IANA не доказывают исполнение редакции 21 конкретным продуктом. Это документ Working Group CALENDAR EXTENSIONS в потоке IETF, предназначенный для Proposed Standard и находящийся на AD Evaluation; пока не RFC.

Календарное состояние не является квитанцией реального результата. Участник может отметить вклад завершённым без поставки; объект может синхронизироваться при сбое внешней работы. Новое условие не создаёт истину, а только запрещает создавать завершение из молчания.

Minimum Initial Specification Лу Хэна задаёт минимальное общее правило: хотя бы одно наблюдение до успеха. Running-Code Primacy требует назвать реально работавшие редакцию, запрос и override. Reality Layers не позволяет календарному символу доказывать исполнение, которого он не наблюдал.

Нужна квитанция агрегации: UID и version Task, явное общее значение, число участников и сообщивших, принятые значения, расширения, порядок предикатов, результат, версия evaluator и последующее действие. Она должна различать asserted и derived.

Короткое условие существования защищает большой принцип: единогласное свидетельство начинается хотя бы с одного свидетельства. Молчание требует уточнения, а не автоматического успеха.

Источники