Prompt y alcance
Un equipo quiere redactar contratos de datos y configuraciones de grafos de conocimiento en YAML-LD mientras continúa atendiendo a los consumidores existentes de JSON-LD. Explica cómo verificarías la equivalencia semántica, manejarías los límites de las características de YAML, asegurarías el parseo y establecerías compuertas de adopción.
W3C YAML-LD 1.0 es actualmente un Working Draft. Define YAML-LD como convenciones sobre YAML que utilizan la sintaxis, semántica y API de JSON-LD, mientras restringe las características más ricas de YAML para que cada documento YAML-LD pueda representarse como JSON-LD. La pregunta evalúa la migración de formatos de datos y la interoperabilidad sin asumir que el borrador es un estándar final.
Qué evalúa el entrevistador
El entrevistador busca que separes la sintaxis superficial de YAML de la semántica de grafos de JSON-LD y que definas normalización, pruebas diferenciales, seguridad del parser y gobernanza de versiones. Una respuesta sólida establece que un Working Draft no es un compromiso de estabilidad y que la legibilidad por sí sola no demuestra el valor de adopción.
Preguntas aclaratorias antes de responder
- ¿Los consumidores leen YAML directamente o solo aceptan grafos RDF en JSON-LD?
- ¿Qué palabras clave de JSON-LD, contextos, documentos remotos y espacios de nombres se requieren?
- ¿Existen anclajes (anchors), alias, etiquetas personalizadas (custom tags) o tipos de marca de tiempo (timestamp)?
- ¿Cuáles son el límite de confianza del parser, los límites de recursos y la política remota de
@context? - ¿Qué ventana de compatibilidad, negociación de versiones, reversión (rollback) y aprobador final se requieren?
Marco de respuesta de 30 segundos
“Trataría a YAML-LD como un formato de entrada en estado de Working Draft y congelaría el subconjunto soportado y la versión de JSON-LD. Cada muestra pasaría por un parser seguro de YAML, validación de restricciones de YAML-LD, conversión a JSON-LD, normalización de conjuntos de datos RDF y comparación semántica; las características que no puedan representarse de forma equivalente serían rechazadas. Los contextos remotos utilizarían una lista de permitidos (allowlist) y una caché fijada, con límites en alias, profundidad, tamaño y otros accesos a recursos. El nuevo formato comenzaría en doble escritura de solo lectura o parseo en sombra (shadow parsing), expandiéndose solo después de que se aprueben las compuertas de semántica de grafos, errores, rendimiento y seguridad.”
Respuesta profunda paso a paso
1. Definir el contrato de entrada y salida
Incluye en el contrato el documento YAML-LD, el JSON-LD generado, el conjunto de datos RDF y la versión de la API del consumidor. Congela las palabras clave de JSON-LD soportadas, las fuentes de contexto, la codificación y las reglas numéricas; el YAML arbitrario no es YAML-LD. Registra las versiones de la especificación y de la suite de pruebas cada vez que cambie el borrador para que diferentes parsers no diverjan silenciosamente.
2. Restringir primero las características de YAML
El W3C señala que YAML es más expresivo que JSON, por lo que YAML-LD admite un subconjunto restringido que se asigna a JSON-LD. Rechaza o prohíbe explícitamente etiquetas personalizadas, tipos de marca de tiempo ambiguos, alias cíclicos y tipos específicos de la implementación; permite anclajes y alias solo cuando su estructura expandida y representación en JSON sean estables. Codifica estos límites como reglas de linting ejecutables en lugar de confiar en la memoria del autor.
3. Verificar la semántica del grafo, no la similitud de texto
Parsea YAML-LD de forma segura, conviértelo a JSON-LD, expande contextos y produce un conjunto de datos RDF. Compara los conjuntos de tripletas o cuádruplas con un algoritmo de normalización. El orden de las propiedades, la indentación de YAML y el orden de las claves de JSON no deben alterar el resultado; los identificadores de nodos, etiquetas de idioma, tipos y el orden de las listas requieren verificaciones explícitas. Conserva un reproductor mínimo para cada diferencia semántica en lugar de ocultarlo con una diferencia de cadenas (string diff).
yaml = safe_parse(input, aliases=false, max_depth=32, max_bytes=1048576)
yaml_ld = validate_yaml_ld_subset(yaml)
json_ld = to_json_ld(yaml_ld)
left = normalize_rdf(json_ld)
right = normalize_rdf(reference_json_ld)
assert left == right4. Diseñar límites de seguridad para el parser
Deshabilita capacidades arbitrarias de archivo, red y ejecución de código; permite @context remotos solo desde una lista de permitidos con versiones fijadas y límites de tamaño. Limita el tamaño del documento, la profundidad de anidamiento, la expansión de alias, el tiempo de parseo y la memoria, y registra las versiones del parser y los hashes de contexto. Devuelve errores estructurados con ubicaciones en caso de falla; nunca escribas datos no validados en un almacén de grafos o repositorio posterior.
5. Preservar a los consumidores existentes
Construye una matriz de compatibilidad para cada consumidor de JSON-LD, cubriendo resolución de contexto, tipos, etiquetas de idioma, listas, nulos y campos desconocidos. Inicialmente mantén JSON-LD como la salida canónica y usa YAML-LD solo como entrada del autor o una ruta en sombra; compara fallas de conversión, diferencias de grafos, latencia, aciertos en caché y uso de recursos. Las características no soportadas por los consumidores deben fallar en CI en lugar de degradarse silenciosamente en producción.
6. Establecer compuertas de adopción y reversión (rollback)
Define con anticipación la consistencia semántica, la tasa de aprobación de pruebas críticas (fixtures), los escaneos de seguridad, el p95 del parser, los límites de recursos y los umbrales de tasa de errores del consumidor. Pausa la expansión cuando cambie el Working Draft o la suite de pruebas, manteniendo el generador de JSON-LD anterior, la caché de contextos y la versión de entrada. Exige pruebas repetidas, simulacros de actualización, registros de auditoría y aprobación del propietario de los datos antes de la adopción; no describas un borrador como un estándar estable.
Ejemplo de respuesta de alta calidad
Trataría el Working Draft de YAML-LD 1.0 como un formato de entrada controlado y congelaría la versión de JSON-LD soportada, las palabras clave, los contextos y el subconjunto de YAML. La canalización utilizaría un parser seguro con límites en tamaño, profundidad, alias y acceso a la red; tras la validación, convertiría a JSON-LD, expandiría contextos, normalizaría un conjunto de datos RDF y compararía la semántica del grafo con la línea base existente de JSON-LD. El orden de las claves y la indentación no deben importar, mientras que los identificadores de nodos, tipos, etiquetas de idioma y orden de listas deben coincidir. Los contextos remotos usarían una lista de permitidos, caché fijada y auditoría de hashes. Inicialmente, JSON-LD seguiría siendo la salida canónica mientras YAML-LD se ejecuta en parseo en sombra, con compuertas para diferencias semánticas, errores de parseo, latencia p95, memoria y errores de los consumidores. Cualquier característica de YAML no representable, escaneo de seguridad fallido o regresión por actualización del borrador pausa la expansión y revierte al generador anterior. La aprobación final se basaría en una suite de pruebas versionada y la firma del propietario de los datos, no en tratar un Working Draft como un estándar final.
Errores comunes
- Tratar un YAML más corto o legible como prueba de interoperabilidad → la legibilidad no es equivalencia semántica de grafos → compara conjuntos de datos RDF normalizados.
- Usar directamente un deserializador genérico de YAML → puede aceptar tipos o alias fuera del subconjunto de YAML-LD → habilita el modo seguro y el linting de restricciones.
- Ejecutar únicamente un diff de texto → el orden de las claves y la indentación crean diferencias falsas → compara nodos, tipos, etiquetas de idioma, listas y cuádruplas.
- Permitir contextos remotos arbitrarios → los riesgos de cadena de suministro, disponibilidad y deriva quedan descontrolados → usa una lista de permitidos, caché, hashes y límites.
- Llamar estándar estable a un Working Draft → el borrador puede cambiar → versiona las pruebas, escalona el despliegue y mantén la salida de reversión.
Preguntas de seguimiento y respuestas
¿Por qué no conservar todas las características de YAML?
El objetivo es que un documento YAML-LD pueda representarse como JSON-LD. Los tipos, etiquetas o estructuras cíclicas sin mapeos estables rompen la interoperabilidad y deben rechazarse o posponerse para un perfil extendido.
¿Cómo determinas que dos documentos tienen la misma semántica?
Convierte y expande contextos, produce conjuntos de datos RDF normalizados y compara identificadores de nodos, predicados, objetos, tipos, etiquetas de idioma y orden de listas en lugar de texto sin procesar.
¿Por qué fijar y colocar en listas de permitidos los recursos remotos de @context?
Afectan el parseo e introducen riesgos de red, cadena de suministro y deriva de versiones. Las fuentes, versiones, hashes y tiempos de espera fijos hacen que los resultados sean reproducibles y reversibles.
¿Cuándo puede YAML-LD convertirse en la ruta de autoría principal?
Después de que la validación de restricciones, los diffs semánticos, los escaneos de seguridad, el rendimiento, la compatibilidad con consumidores y los simulacros de reversión se aprueben repetidamente, con la versión del borrador, la suite de pruebas y el responsable de cambios bloqueados.
¿Qué sucede si una actualización de la especificación genera una pequeña diferencia en el grafo?
Pausa la expansión, conserva un reproductor mínimo, la versión de la especificación y el hash del contexto, y determina si el cambio es intencionado. Continúa produciendo el JSON-LD anterior hasta que la política de compatibilidad y la aprobación del propietario de los datos estén completas.