Resumen

  • La revisión 21 del borrador JSCalendar 2.0 añade una condición de cobertura: si una Task no declara su progress general, debe existir al menos un progreso de participante para que el valor predeterminado pueda ser completed.
  • Que nadie informe no significa fracaso ni trabajo en curso, pero tampoco prueba terminación. Hay que guardar el denominador, los valores recibidos, la versión de la regla y si el resultado fue declarado o derivado.

Una organización abre su panel y ve una tarea en verde. Debajo aparecen varios participantes, pero ninguna de sus celdas de avance contiene dato alguno. Nadie dijo que terminó. La aparente unanimidad nació precisamente porque no había una voz capaz de contradecirla.

La revisión 21 de JSCalendar 2.0: A JSON Representation of Calendar Data, registrada el 2 de octubre de 2026, corrige esa frontera en la definición del progreso predeterminado de una Task. El caso sólo se activa cuando falta un progress general explícito.

La revisión 20, como RFC 8984, decía que el valor era completed si todos los participantes tenían progreso completed. La revisión 21 agrega dos piezas: al menos un participante debe poseer la propiedad progress, y todos los participantes que sí la posean deben informar completed.

La diferencia evita que una proposición sobre un conjunto vacío produzca una conclusión positiva. En lógica formal y en ciertos lenguajes de consulta, «todos los valores cumplen» puede ser verdadero cuando no hay valores. No existe en el paquete de fuentes evidencia de que un cliente desplegado haya cometido ese error, de modo que no corresponde inventar una incidencia. Sí existe una corrección normativa de la ambigüedad.

Tampoco se exige que cada persona de la lista responda. El progreso del Participant es opcional. Si una Task tiene diez participantes y sólo dos informan, el valor puede derivarse como completed cuando ambos informes son completed. Los ocho silencios no vetan el resultado. Lo que ya no puede ocurrir es completar con cero informes aptos.

Por eso el denominador debe acompañar al color. «Dos de dos informantes terminaron» y «dos de diez participantes informaron y ambos terminaron» satisfacen la misma condición, pero exponen coberturas radicalmente distintas. El estado agregado sin cobertura oculta una decisión institucional detrás de una palabra técnica.

El orden de evaluación resuelve las mezclas. Primero se comprueba que exista al menos un valor y que todos los valores aportados sean completed. Si no, cualquier failed produce failed. Sin fallos, cualquier in-process produce in-process. Si nada coincide, incluido el caso sin informes, queda needs-action.

No hay voto mayoritario. completed junto con failed termina en failed; completed junto con in-process termina en in-process. Un campo ausente no se rellena como fracaso, proceso o finalización. Sigue ausente y sólo las observaciones presentes entran en los predicados.

Además, la derivación desaparece si existe progress general en la Task. Una autoridad puede escribir un estado explícito y ese valor no se recalcula desde los participantes. Dos pantallas pueden mostrar completed con procedencias diferentes: una asserted y otra derived. La auditoría debe distinguirlas.

Los informes individuales tienen condiciones. Sólo están definidos para un Participant dentro de una Task, requieren calendarAddress y exigen participationStatus accepted. Los valores base son in-process, completed y failed, además de extensiones registradas o de proveedor. cancelled existe en el nivel de Task, no como valor base del participante.

percentComplete no resuelve lo mismo. Es un entero opcional entre cero y cien. La especificación no lo convierte en promedio normativo ni ordena que cien implique completed. Cualquier transformación de porcentaje a categoría necesita una política local explícita y una huella de decisión.

Los antecedentes separan los planos. RFC 5545 distingue STATUS de VTODO, la hora de finalización y el estado de participación. RFC 5546 separa el estado del objeto del organizador y PARTSTAT del asistente. El modelo JSON no autoriza a fusionar contribución individual, tarea general y ejecución real.

JMAP Calendars o CalDAV pueden transportar y sincronizar el objeto, pero una escritura aceptada no demuestra que un producto ejecute la regla nueva. Tampoco una entrada de IANA convierte la revisión en comportamiento universal. El documento está en el grupo CALENDAR EXTENSIONS, flujo IETF, destinado a Proposed Standard y en AD Evaluation; todavía no es RFC.

Y un estado de calendario no es un recibo de resultado. Una persona puede marcar su parte como terminada sin entregar el archivo; una Task puede sincronizarse aunque falle un proceso externo; un valor general explícito puede ser incorrecto. La revisión 21 impide fabricar terminación a partir de silencio, no garantiza la verdad de los informes.

Minimum Initial Specification de Lu Heng propone la escala adecuada: una regla común mínima que impida que ausencia se vuelva éxito, mientras las decisiones con consecuencias permanecen locales. Running-Code Primacy pregunta qué versión, consulta, valor predeterminado y override se ejecutaron. Reality Layers impide que el símbolo completed adquiera autoridad sobre hechos que nunca observó.

El control práctico es un recibo de agregación: UID y version, progreso general explícito, participantes totales, informantes, valores aceptados, extensiones, orden de evaluación, resultado, versión del evaluador y acción posterior. Debe decir si el estado fue asserted o derived.

Una frase breve preserva una regla de gobierno: para hablar de evidencia unánime tiene que existir al menos una evidencia. El silencio puede exigir seguimiento; nunca merece ascenso automático a éxito.

Fuentes