Resumen

  • La issue 566 de W3C Strategy abrió el 4 de agosto una renovación del grupo existente, marcó el 15 de octubre como final esperado del refinamiento y dijo que no había cambios sustantivos.
  • También calificó de agresivamente optimista la primera carta: el objetivo ahora es CR en el cuarto trimestre de 2026 o el primero de 2027 y después mantenimiento, una intención que aún debía aclararse en el texto.
  • La carta vigente proyectaba CR en marzo, Proposed Recommendation en junio y Recommendation en septiembre de 2026. La página pública mantiene los documentos en Working Draft; eso no demuestra fracaso técnico.
  • El commit fijo f00f3b8 conserva cinco plazos [Q1–4 YYYY], una instrucción Choose one, un Web [spec name], un cronograma FooML/BarML y opciones operativas sin cerrar.
  • Antes de la revisión del Advisory Committee, un recibo ligado al commit elegido debería declarar el destino de cada documento, su hito, el dueño del mantenimiento y la resolución de cada token de plantilla.

Una renovación puede conservar la materia y cambiar el horizonte

La etiqueta “sin cambios sustantivos” puede describir honestamente el objeto técnico. El grupo sigue trabajando en un protocolo que separa aplicaciones, identidad y almacenamiento, y mantiene las mismas cinco especificaciones normativas. No aparece una transferencia a otro organismo ni una misión nueva.

El horizonte de madurez sí cambia. La carta activa, válida del 9 de septiembre de 2024 al 8 de septiembre de 2026, proyectó el protocolo central en CR para el 10 de marzo de 2026, en Proposed Recommendation para el 9 de junio y en Recommendation para el 8 de septiembre. Para avanzar más allá de CR esperaba dos implementaciones independientes e interoperables de cada función, verificadas con pruebas abiertas.

La historia pública de cartas conserva ese instrumento por separado. La lista de publicaciones LWS todavía agrupa los documentos bajo Working Drafts y el protocolo 1.0 muestra esa madurez. La comparación prueba que el calendario antiguo ya no describe el estado público. No explica las causas, la adopción ni la calidad de las implementaciones.

Por eso la nueva ruta de CR y mantenimiento no es un detalle editorial. Define qué umbral se espera alcanzar y qué autoridad queda después. Puede no ser una modificación sustantiva del ámbito, pero sí debe figurar como una decisión clara en el instrumento sucesor.

Lo que quedó dentro del molde

El repositorio nació con un commit producido por el charter assistant el 3 de agosto. Dos días después, otro commit retiró LDP Next de coordinación. Hubo, por tanto, una edición concreta; el historial corto no autoriza a inferir abandono.

El estado verificable está en el archivo inmutable de f00f3b8, no sólo en la versión renderizada y mutable. Allí las fechas de inicio y cierre son instrucciones entre corchetes. La asignación de 0,1 FTE figura como tarea. Para las teleconferencias se ofrece una opción temática u “otra cosa”; el canal de trabajo pide elegir lista, GitHub issues o ambos.

La sección de entregables conserva la instrucción Choose one. Un ramal define la fecha esperada como llegada a Recommendation u otro estado estable. El otro dice que el grupo publicará Candidate Recommendation Snapshots y no intentará llevar sus documentos a Recommendation. Ninguno aparece convertido en una cláusula única.

Las cinco especificaciones tienen [Q1–4 YYYY] como fecha. Un entregable tentativo aún se llama Web [spec name]; la línea de tiempo habla de requisitos y primeros borradores de FooML y BarML. Los criterios de éxito indican quitar una cláusula si no se va a REC y considerar otra si no se va a REC.

La presencia de esos rastros no revela qué se ha resuelto en conversaciones no públicas. Sí permite afirmar que ese commit todavía no expresa por sí solo una salida de madurez coherente.

El plazo abierto limita la conclusión

El Proceso del W3C da tres vías antes del final del refinamiento: iniciar la revisión del Advisory Committee, abandonar la propuesta o extender la fase. Una carta recoge entregables, hitos disponibles, mecanismos de reunión y comunicación. La adopción posterior es una W3C Decision; si se aprueba, llega una Call for Participation.

El 15 de octubre no había llegado. Nada demuestra que el commit del 5 de agosto vaya a revisión sin cambios. Tampoco que todo TODO visible equivalga a una decisión no tomada. Hablar de una violación sería excesivo; tratar el borrador como autoridad vigente también.

Un recibo con cinco filas y un registro de residuos

La versión que llegue a revisión debería venir acompañada por un recibo público. Primero, commit exacto, estado del refinamiento y fechas de vigencia. Después, una fila por cada documento: madurez actual, destino elegido, trimestre estimado o razón atribuida para no estimarlo y criterio de éxito aplicable.

Si el destino es CR más mantenimiento, el recibo debe decir si habrá nuevos Snapshots, qué cambios admite la fase y quién decide cada publicación. Eso convierte “mantenimiento” en una superficie de autoridad, no en un término intuitivo.

Un segundo registro cerraría los restos del molde: entregable ficticio, FooML/BarML, FTE, frecuencia de reuniones y canal público. Cada elemento tendría estado y responsable. La nota final separaría ámbito técnico sin cambios de calendario, destino y operación revisados.

Ese diseño no impone Recommendation ni entrega el poder del W3C al público. Sólo deja claro qué texto exacto se pide revisar.

Fuentes