Resumen

  • La revisión del Comité Asesor del W3C sobre el estatuto propuesto del grupo Web of Things cierra el 31 de agosto de 2026 a las 23:59 UTC. Al corte de este artículo no había un resultado público.
  • La propuesta incorpora un WoT Binding Registry y proyecta las transiciones a Registry Draft, Candidate Registry y W3C Registry durante 2027.
  • El documento del registro sigue en fase piloto. Sus pocas vinculaciones del propio grupo no pueden salir aún de Initial; las contribuciones externas se abrirían después.
  • El paso a Current requiere una revisión desde el protocolo objetivo y otra desde la conformidad con WoT. El texto permite que una persona experta en ambos campos haga las dos revisiones en documentos separados.
  • Current significa que el custodio recomienda la vinculación para implementaciones nuevas y considera suficiente la experiencia práctica. No equivale a Recomendación W3C ni prueba interoperabilidad universal.
  • Un recibo de funciones y evidencia debería decir si intervinieron una o dos personas, qué examinó cada función, qué operaciones se probaron y por qué el custodio cambió el estado.

La consulta termina antes de que el registro empiece

Los estatutos anteriores trataban las vinculaciones de protocolos sobre todo como documentos. La nueva propuesta pretende mantener una lista estructurada y actualizable que pueda incorporar trabajos del W3C y de organizaciones externas. Eso cambia el objeto de gobernanza: ya no basta con publicar una nota; hay que decidir qué entrada puede recibir una recomendación operativa y cómo cambia con el tiempo.

El plazo del 31 de agosto no debe confundirse con aprobación. El estatuto vigente se prorrogó hasta el 16 de octubre, y la propuesta conserva marcadores pendientes para sus fechas definitivas. Registry Draft en el primer trimestre de 2027, Candidate Registry en el segundo y W3C Registry en el tercero son hitos previstos, no estados alcanzados.

El grupo sí dispone de un borrador concreto. Define campos, requisitos, responsabilidades y un ciclo de vida. También declara que aún no es un W3C Registry. Durante el piloto solo incluye unas pocas vinculaciones creadas por el grupo, todas limitadas a Initial. Las solicitudes externas llegarían cuando esa prueba termine.

Esta separación permite ensayar el procedimiento sin convertir el laboratorio en respaldo institucional. También deja a quienes revisan el estatuto una maquinaria visible, no una promesa abstracta.

Current puede convertirse en una instrucción

Los estados propuestos son Initial, Current, Superseded y Obsolete. Nada se borra: una versión nueva obtiene otra entrada y la anterior conserva su historia.

La palabra Current tiene un significado definido. El custodio recomienda esa vinculación para implementaciones nuevas y considera que acumula experiencia suficiente. Una biblioteca, un integrador o una compra técnica puede leer esa celda como atajo. Por tanto, el registro influye en decisiones aunque no sea el texto que define el protocolo.

El Proceso del W3C delimita esa influencia. Los registros documentan valores; no establecen requisitos de arquitectura o interoperabilidad. Esas obligaciones pertenecen a las especificaciones que usan el registro. Además, el informe de registro no está bajo la Política de Patentes del W3C y no se convierte en Recomendación por tener una entrada estable.

La propuesta conserva la autoridad de cada organización externa. Si una vinculación revela que MQTT, Modbus, BACnet, CoAP u otro protocolo necesita cambios, el grupo WoT debe acudir a su responsable. Registrar no es legislar sobre el protocolo ajeno.

De ahí la necesidad de explicar el alcance: qué demuestra Current y qué queda fuera.

Dos preguntas pueden tener una sola autora

La transición a Current contiene dos pruebas conceptuales. La primera pregunta si la vinculación representa con fidelidad la especificación de origen. La segunda pregunta si respeta Thing Description y permite que un Consumer interprete las operaciones declaradas.

El borrador dice que el custodio debería nombrar al menos dos revisores: alguien experto en el protocolo y alguien experto en WoT. A continuación permite que la misma persona cubra ambos papeles si domina los dos campos. La obligación que permanece es elaborar dos documentos de revisión separados.

La excepción puede ser sensata. En protocolos industriales especializados quizá existan pocas personas capaces de entender simultáneamente el estándar externo y la abstracción de Web of Things. Una segunda firma sin conocimiento nuevo solo añadiría demora.

Pero dos documentos no prueban dos corroboraciones independientes. Una interpretación equivocada de versión, una suposición débil en las pruebas o un mismo punto ciego puede pasar por ambos análisis. Tampoco dos nombres garantizan independencia: pueden compartir empresa, código, banco de pruebas o incentivos.

La solución no es contar personas, sino publicar la forma de la revisión. Si una experta asumió dos funciones, el registro debe mostrarlo. Así el lector puede valorar competencia y concentración sin convertir ninguna de las dos en acusación.

Existe un piso de pruebas, pero falta cerrar su métrica

El borrador exige que cada operación de la vinculación se valide automáticamente en un evento de pruebas. El Test Report debe describir entorno, escenario y recorrido lógico desde una Thing Description hasta la comunicación. También debe incluir al menos un Consumer y un Exposer capaces de cubrir las funciones anunciadas.

No es una revisión puramente documental. El paso a Current depende de código en funcionamiento.

Sin embargo, el texto reconoce que el contenido exacto del informe todavía no está decidido y enlaza una issue abierta desde febrero de 2025. La incertidumbre está identificada: no se discute si debe haber evidencia, sino cómo debe quedar expresada.

El detalle importa. ¿Se prueban rutas de error opcionales? ¿Pueden contar dos extremos de una misma base de código? ¿Cómo se declara una biblioteca o arnés compartido? ¿Se preservan fallos y correcciones? ¿Qué separa un intercambio de mensajes de una correspondencia semántica completa?

Si esas respuestas llegan después de las primeras entradas externas, los primeros casos aceptados fijarán la práctica. Es preferible que el grupo defina el estándar probatorio antes de que el precedente lo defina por él.

Un recibo de funciones y evidencia

El piloto ya utiliza issues, revisiones, pull requests y plazos públicos. No necesita otra institución. Necesita reunir esos elementos en un registro de decisión estable.

Para cada paso a Current, el recibo debería fijar la versión de la vinculación, la especificación objetivo, los documentos auxiliares y la versión de las reglas aplicadas. Las dos funciones de revisión aparecerían por separado, con la persona que desempeñó cada una, su experiencia relevante y una declaración expresa cuando una sola persona haya cubierto ambas. Las afiliaciones o conflictos pertinentes deben ser visibles sin publicar datos privados innecesarios.

La evidencia debería enumerar fechas y entornos, Consumer y Exposer, cobertura operación por operación, código compartido y caminos no probados. Cada revisión conservaría conclusiones, reservas y cambios solicitados. Después vendrían el periodo de comentarios, las objeciones, la decisión fechada del custodio y sus razones.

El mismo recibo debe declarar cuatro límites. Current no es Recomendación W3C, no prueba interoperabilidad universal, no cambia el protocolo subyacente y no genera por sí solo compromisos de patente para el registro.

Cuando una entrada pase a Superseded u Obsolete, el recibo debe acompañarla. Si el diseño conserva la fila pero pierde la razón de la decisión, la inmutabilidad será solo aparente.

La separación de Heng Lu resulta útil aquí: quien revisa aporta pericia, las implementaciones aportan evidencia y el custodio ejerce un mandato acotado. Ninguna capa debe apropiarse de la autoridad de otra.

Resolverlo en el piloto cuesta menos

Las fuentes no demuestran que una revisión de doble función haya fallado ni que alguien haya capturado el proceso. Tampoco muestran una solicitud externa que ya sea Current. El estatuto sigue siendo una propuesta.

Precisamente por eso la decisión puede tomarse sin urgencia defensiva. Cuando herramientas y compradores comiencen a usar Current como valor por defecto, recuperar la procedencia será difícil. Ahora basta con hacer explícita la concentración.

El registro puede permitir que una persona haga dos trabajos rigurosos. Lo que no debería permitir es que la etiqueta final borre si hubo una o dos miradas humanas y qué evidencia sostuvo cada una.

Fuentes

  1. Aviso de revisión del estatuto WoT propuesto
  2. Estatuto propuesto del grupo Web of Things
  3. Estatuto vigente del grupo Web of Things
  4. Borrador piloto de WoT Binding Registry
  5. Fuente fijada del registro
  6. Issue 3: definición del contenido de Test Report
  7. Proceso W3C: Registry Track
  8. Heng Lu, The Multi-Stakeholder Mirage