En defensa de YAML

 (opensource.posit.co)
1 puntos por GN⁺ 21 시간 전 | 1 comentarios | Compartir por WhatsApp
  • YAML 1.2 es un formato de serialización basado en sangría para archivos de configuración anidados escritos por personas, y hay que distinguirlo de las críticas a su inestabilidad derivadas de experiencias antiguas con PyYAML
  • Los formatos de archivos de configuración han ido cambiando para corregir las limitaciones de generaciones anteriores, como la estructura plana de INI, la verbosidad de XML y la falta de comentarios o cadenas multilínea en JSON
  • TOML es claro en estructuras poco profundas como pyproject.toml y Cargo.toml, pero en estructuras anidadas profundas aumenta la carga de lectura y edición por la repetición de rutas y los arreglos de tablas
  • El Core Schema de YAML 1.2 trata yes, no, on, off, y, n como cadenas y elimina los números sexagesimales y los timestamps como tipos centrales, reduciendo los viejos problemas de inferencia implícita de tipos
  • py-yaml12 es un parser y formateador de YAML 1.2 para Python que ofrece valores predeterminados seguros, 100% de cumplimiento con yaml-test-suite y rendimiento competitivo con la extensión C de PyYAML gracias a una implementación en Rust

El problema de fondo

  • En los últimos años, el ambiente alrededor de los formatos de configuración se ha movido hacia la idea de que YAML es malo y TOML es bueno, pero evaluar YAML requiere considerar su historia, los cambios en la especificación y el estado de las herramientas en 2026
  • Las críticas a YAML fueron razonables durante mucho tiempo e incluso usuarios cuidadosos sufrieron comportamientos inesperados, pero la especificación cambió y el ecosistema de herramientas se está poniendo al día
  • Las críticas actuales a YAML solo se entienden al ver también la genealogía de los formatos de configuración, donde se ha repetido el patrón de que el formato siguiente corrige los excesos del anterior

Breve historia de los formatos de configuración

  • Los archivos INI aparecieron a inicios de los años 80 junto con MS-DOS y las primeras versiones de Windows, como un formato plano, legible y editable por personas con pares clave-valor, secciones entre corchetes y comentarios con punto y coma
  • INI era suficiente para necesidades de la época como configuración de controladores, rutas de fuentes y ajustes de aplicaciones, pero tenía limitaciones estructurales: no podía anidarse más de un nivel y no existía una especificación oficial, por lo que cada parser implementaba su propio dialecto
  • XML fue adoptado ampliamente a finales de los 90 en el mundo del software empresarial, ofreciendo jerarquías arbitrarias, esquemas, namespaces, transformaciones y una estructura autodescriptiva, pero en la práctica los archivos de configuración se volvieron tan verbosos que resultaban difíciles de mantener a mano
  • JSON surgió como una respuesta más ligera a XML y, apoyado en la simplicidad de los literales de objetos de JavaScript, reemplazó a XML en las APIs web de finales de los 2000 y principios de los 2010, pero como formato de configuración tenía limitaciones como la falta de comentarios, de cadenas multilínea y la prohibición de comas finales
  • YAML apareció en 2001 y TOML en 2013 para cubrir el hueco que JSON dejó: YAML ofrecía sintaxis basada en sangría con anidamiento arbitrario, múltiples documentos, referencias y tipos personalizados; TOML apuntaba a ser un “INI estandarizado” con tipos explícitos y especificación formal
  • Cada nueva generación de formatos partió de los excesos de la anterior, y gran parte de los problemas actuales atribuidos a YAML son producto no tanto del diseño del formato como de versiones específicas de la especificación y de parsers atados a ellas

Los problemas que sustentaban el rechazo a YAML

  • Las críticas a YAML no eran inventadas: se basaban en experiencias reales que muchos programadores tuvieron durante años
  • El problema más famoso, el caso de Norway, viene de YAML 1.1, donde el escalar sin comillas NO se interpretaba como el booleano false, haciendo que no en una lista de códigos de países cambiara a un valor falso 
    countries:
  - dk
  - fi
  - is
  - no
  - se

    ["dk", "fi", "is", false, "se"]
  • La misma regla también se aplicaba a yes, on, off, y, n y muchas variantes de mayúsculas y minúsculas; además, asignaciones de puertos como 22:22 se interpretaban como enteros sexagesimales, números de versión como 10.23 como flotantes en vez de cadenas, y valores con apariencia de fecha como timestamps
  • En código de ciencia de datos y aprendizaje automático, nombres de variables naturales como n y y también podían interpretarse bajo las reglas implícitas de booleanos de YAML 1.1 no como claves de cadena, sino como claves False y True 
    {"variables": {"x": "features", False: "sample_size", True: "target"}}
  • La agresiva inferencia implícita de tipos de YAML 1.1 pretendía mejorar la legibilidad al leer true sin comillas como booleano, pero en archivos de configuración reales terminó aumentando la imprevisibilidad
  • Los archivos de configuración no suelen editarse con frecuencia y a menudo los modifica alguien distinto de quien los escribió originalmente, por lo que un parseo silenciosamente incorrecto puede propagarse por meses a través de todo un sistema; es uno de los peores contextos posibles para comportamientos inesperados
  • La complejidad de toda la especificación YAML también era una carga, y la especificación YAML 1.2.2 es un documento considerable con 10 capítulos y una estructura de secciones numeradas en cuatro niveles
  • Existen muchas formas de representar cadenas multilínea, y los anchors y aliases crean un sistema de referencias poderoso, pero para la mayoría de las tareas de configuración suponen un peso conceptual mayor del necesario
  • Los problemas de seguridad de la deserialización de objetos basada en tags, en particular la vulnerabilidad de yaml.load() en Python, se convirtieron en un vector de ataque bien conocido, y esas críticas eran válidas para YAML 1.1 y para el ecosistema de herramientas que lo rodeaba

Lo que TOML hace bien

  • TOML es un formato limpio, legible y no ambiguo en configuraciones planas o poco profundas
  • Su sintaxis resulta familiar para quien haya visto archivos INI, pero agrega tipos explícitos, una especificación formal y soporte para tablas anidadas mediante claves separadas por puntos
  • pyproject.toml y Cargo.toml suelen tener secciones bien definidas de uno o dos niveles de profundidad y contenido predecible, así que son casos donde TOML encaja bien
  • En TOML, las cadenas siempre van entre comillas, por lo que no nunca es ambiguo entre booleano y palabra; además, enteros, flotantes y fechas son tipos de primera clase, y los comentarios funcionan como se espera
  • La adopción de PEP 518 en el ecosistema de empaquetado de Python y el uso de Cargo en la comunidad de Rust respaldan que TOML es una buena elección para ese tipo de problema
  • La especificación de TOML es lo suficientemente corta como para que un programador competente pueda escribir un parser compatible en un fin de semana, lo que ha favorecido un ecosistema amplio, bien probado y consistente
  • TOML no tiene un problema equivalente a la fractura de versiones entre YAML 1.1 y 1.2: TOML 1.0 es TOML 1.0 en todas partes

Dónde TOML se vuelve pesado

  • Cuando un archivo de configuración necesita expresar profundidad, la estructura anidada de TOML depende de encabezados de sección separados por puntos ([servers.alpha]) o arreglos de tablas ([[products]]), y mientras más crece el anidamiento más difícil se vuelve de leer
  • Martin Vejnár, de PyTOML, al rechazar que su biblioteca se convirtiera en dependencia de pip, argumentó desde su propia experiencia que cuando el esquema de configuración se vuelve complejo la sintaxis de TOML se ve mal y resulta difícil de leer
  • En YAML, la sangría transmite la jerarquía de un vistazo; en TOML, en cambio, hay que repetir la ruta completa en cada encabezado de sección 
    services:
  web:
    image: nginx:latest
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
    resources:
      limits:
        memory: 512M
        cpu: "0.5"

    [services.web]
image = "nginx:latest"

[services.web.environment]
DB_HOST = "postgres"
DB_PORT = 5432

[services.web.resources.limits]
memory = "512M"
cpu = "0.5"
  • Quien lee TOML tiene que reconstruir mentalmente la estructura en árbol a partir de una sucesión de nombres calificados planos, y según mediciones de la documentación de StrictYAML, al expresar los mismos datos un archivo TOML usa alrededor de 50% más caracteres por la repetición de prefijos de ruta
  • Python demostró hace mucho que usar la sangría como estructura no es una debilidad sino una fortaleza, porque elimina una clase de errores donde la estructura visual y la estructura sintáctica no coinciden
  • YAML hereda esa ventaja de la estructura por sangría, pero TOML no la exige, de modo que la relación entre una clave y la tabla que la contiene no existe en la disposición física del archivo sino únicamente en los encabezados de sección
  • En archivos de configuración profundamente anidados, TOML es difícil de escanear y difícil de editar con confianza

Qué cambió en YAML 1.2

  • La especificación YAML 1.2 se publicó en 2009, y la revisión aclaratoria 1.2.2 se completó en octubre de 2021
  • En el Core Schema de YAML 1.2, solo true, false y True, False, TRUE, FALSE se reconocen como booleanos; yes, no, on, off, y, n son cadenas normales
  • Los literales numéricos sexagesimales que causaban el problema de 22:22 fueron eliminados por completo, y los timestamps ya no son un tipo central, de modo que en el Core Schema un 2026-05-05 sin comillas se interpreta como cadena y no como fecha autodetectada
  • JSON pasó a ser un subconjunto estricto y correcto de YAML 1.2, y cualquier documento JSON válido también se parsea igual como YAML
  • Las reglas de interpretación de tags son más estrictas y claras, y la propia especificación está redactada con mayor claridad y se mantiene públicamente en GitHub
  • El YAML que la gente ha venido criticando es YAML 1.1; la especificación que domina hoy es el YAML 1.2, más seguro y más predecible
  • El problema es que la experiencia real del usuario con YAML está mediada no por la especificación sino por el parser, y para la mayoría de usuarios de Python ese parser es PyYAML, que implementa YAML 1.1 y no ha cambiado su semántica central desde 2006

Panorama de parsers YAML en Python

  • PyYAML es la biblioteca YAML de facto en Python, envuelve la biblioteca C LibYAML por rendimiento y también ofrece una ruta alternativa en Python puro
  • PyYAML se descarga millones de veces cada semana y es dependencia de innumerables paquetes, pero implementa YAML 1.1, que es la raíz de experiencias en el ecosistema Python como “YAML parseó un código de país como booleano”
  • El repositorio de PyYAML tiene más de 200 issues abiertas y más de 100 pull requests abiertas; el proyecto sigue con mantenimiento pero avanza lentamente, y una gran transición de versión hacia la semántica de YAML 1.2 todavía no se concreta
  • ruamel.yaml ofrece soporte para YAML 1.2 y capacidades de edición round-trip que preservan comentarios, flow style y el orden de las claves, por lo que es una opción mucho más potente que PyYAML para conservar comentarios o hacer edición sensible al formato
  • ruamel.yaml es considerablemente más lento que la ruta rápida basada en C de PyYAML porque su modo round-trip predeterminado usa principalmente una implementación en Python puro, y además tiene un historial de empaquetado que ha complicado pipelines de despliegue debido a problemas de namespace packages y cadenas de dependencias
  • StrictYAML implementa un subconjunto deliberado de YAML, eliminando toda inferencia implícita de tipos, tags, anchors y flow style
  • StrictYAML está filosóficamente más cerca de TOML que de YAML completo: es un formato seguro y simple con sintaxis de sangría de YAML, pero es exclusivo de Python, no tiene implementación en otros lenguajes y tampoco busca cumplir la especificación
  • En este panorama faltaba una biblioteca que fuera rápida, completamente compatible con YAML 1.2 y fácil de usar como reemplazo de la interfaz básica de PyYAML

Presentación de py-yaml12

  • py-yaml12 es un parser y formateador de YAML 1.2 para Python, implementado en Rust para ofrecer velocidad y precisión
  • py-yaml12 está construido sobre el crate de YAML para Rust saphyr y ofrece una API pequeña y enfocada con parse_yaml(), read_yaml() para carga, y format_yaml(), write_yaml() para serialización

  • Simplicidad

    • En la mayoría de los casos de uso, está diseñado para trabajar de inicio a fin solo con tipos básicos integrados de Python como dict, list, int, float, str, None
    • En la ruta común no hay clases especiales de documento ni tipos de nodo personalizados, y como YAML 1.2 es un superconjunto de JSON, todo JSON válido se parsea igual
    • py-yaml12 alcanza 100% de cumplimiento en yaml-test-suite, una colección comunitaria de pruebas de conformidad y casos límite
    • En una lista regions, el valor no se convierte silenciosamente en False con el comportamiento YAML 1.1 de PyYAML, pero con el comportamiento YAML 1.2 de py-yaml12 se conserva como la cadena "no", como exige la especificación
    • La API de archivos también es directa: si se escribe un diccionario de Python al disco y luego se vuelve a leer, se obtiene el mismo objeto en un round-trip sin pérdida
    • Para funciones avanzadas de YAML como valores etiquetados, ofrece un tipo envoltorio Yaml, pero para tareas comunes de configuración es opcional

  • Seguridad

    • Los valores predeterminados de py-yaml12 no solo mejoran la usabilidad sino también la seguridad; el enfoque opuesto en PyYAML trata tags como si fueran comandos, con el riesgo de ejecutar código arbitrario de Python con solo leer un archivo YAML
    • Si se lee con yaml.load(f, Loader=yaml.Loader) un archivo YAML que aliasa el namespace de tags Python object-apply de PyYAML, el código Python se ejecuta antes de devolver un diccionario aparentemente normal
    • En el ejemplo, el resultado del parseo parece ser {'debug': False, 'retries': 3}, pero antes de eso la variable de entorno YAML_PAYLOAD_RAN queda establecida en '1', de modo que al ver solo el resultado no se nota que hubo ejecución
    • py-yaml12 no ejecuta tags que no se hayan elegido explícitamente y los mantiene como datos; los tags no procesados se devuelven como un envoltorio Yaml que contiene el valor y el tag

  • Velocidad

    • Los benchmarks de py-yaml12 comparan rendimiento de lectura y escritura en archivos desde kilobytes hasta megabytes frente a la ruta predeterminada en Python puro de PyYAML, CSafeLoader y CSafeDumper basados en LibYAML, y ruamel.yaml
    • Como su lógica central de parseo y formateo está implementada en Rust compilado y no en Python interpretado, py-yaml12 ofrece un rendimiento competitivo con la extensión C de PyYAML manteniendo al mismo tiempo el cumplimiento completo con YAML 1.2
    • Actualmente no hay muchas opciones en bibliotecas de Python que ofrezcan a la vez cumplimiento total con YAML 1.2 y rendimiento del nivel de la extensión C de PyYAML

Conclusión

  • El debate habitual entre YAML y TOML se parece más a una discusión contra una forma del formato que ya no existe; las críticas eran reales, pero pertenecen en buena medida al plano histórico
  • A menudo, las críticas a YAML apuntan al YAML 1.1 experimentado a través de PyYAML, no a la especificación ni a una implementación correcta de YAML 1.2
  • TOML sigue siendo una buena opción para configuraciones superficiales y planas, y pyproject.toml encaja muy bien en ese papel, pero la afirmación de que YAML es intrínsecamente inseguro o impredecible no se sostiene frente a un parser compatible con YAML 1.2
  • La pregunta importante no es cuál formato es mejor en abstracto, sino qué formato y qué herramienta se ajustan mejor a una tarea específica
  • Para archivos de configuración complejos, anidados y escritos por personas, YAML 1.2 con un parser moderno es una respuesta fuerte, y los formatos siguen mejorando a medida que una generación corrige las asperezas de la anterior
  • En Python, se puede comprobar una experiencia moderna y conforme a la especificación de YAML con pip install py-yaml12
  • En el entorno de R, r-yaml12 ofrece las mismas ventajas: cumplimiento completo con YAML 1.2, rendimiento basado en Rust y valores predeterminados seguros, igual que el paquete de Python

Lecturas relacionadas

1 comentarios

 
GN⁺ 21 시간 전
Opiniones en Lobste.rs

  • La explicación de que YAML surgió para cubrir las carencias de JSON suena rara. Según recuerdo, YAML salió de la comunidad de Perl, y podría ser contemporáneo de JSON o incluso más antiguo
    Buscando la historia real, un texto interesante de Ingy dot Net, uno de los creadores de YAML, sitúa su origen entre noviembre de 1999 y enero de 2001
    Además, según este artículo sobre la historia de JSON, una forma primitiva de JSON apareció en abril de 2001, cuando se usaban iframes ocultos y etiquetas <script> para enviar mensajes del servidor al cliente, y recién en 2002, cuando Douglas Crockford publicó json.org, se convirtió en un formato independiente
    Así que YAML fue un poco anterior a JSON, o, siendo generosos, ambos se desarrollaron más o menos al mismo tiempo. No es exacto decir que surgió como reacción a JSON o para llenar sus vacíos; en realidad, YAML fue una reacción a XML. JSON también nació por una razón práctica, la de meter datos directamente dentro de etiquetas <script>, pero es difícil negar que se volvió popular al posicionarse como una alternativa más simple que XML
    El texto en sí también da la impresión de haber sido escrito por un LLM, y el proyecto que presenta también parece vibecoded

    • Es correcto decir que YAML originalmente fue una reacción y una alternativa a XML
    • Yo también percibí olor a LLM en la parte donde critica la complejidad de YAML y luego elogia la nueva especificación de YAML. Critica que la especificación 1.2.2 sea larga a 4 niveles de profundidad, pero después dice que 1.2.2 sigue siendo grande aunque mucho menos compleja que 1.1
      Cada frase por separado suena razonable, pero en conjunto resulta confuso. También es raro que defienda a TOML diciendo que es un lenguaje con especificación, pero critique a YAML por tener una especificación compleja. Casi da la impresión de que YAML originalmente no tenía especificación y TOML sí
    • Para añadir una cosa más a esa historia, Crockford originalmente estaba trabajando con Data-E, un subconjunto de E, y Data-E solo expresaba datos simples. Los autores de E dejaron de impulsar su propio lenguaje y pasaron a intentar volver capability-safe a ECMAScript, y como resultado varias ideas de E, como WeakMap, terminaron entrando a ECMAScript
      JSON es, en la práctica, algo muy cercano a Data-E con estilo ECMAScript. Si ves la página archivada de Data-E, también se nota que ellos estaban reaccionando frente a XML
    • Si uno reinterpretara el artículo con buena fe, podría decirse que no hablaba del desarrollo de YAML en sí, sino de que la adopción de YAML fue una reacción a las limitaciones de JSON. En lo personal, yo también conocí YAML solo después de que JSON ya estuviera ampliamente difundido. Aun así, no hay datos que respalden esa percepción

  • Si usas tablas inline, el ejemplo “malo” de TOML quedaría así

    [services.web]
image = "nginx:latest"

environment = {
  DB_HOST = "postgres",
  DB_PORT = 5432,
}

resources.limits = {
  memory = "512M",
  cpu = "0.5",
}

    Se ve bastante bien y, si se trata de contar caracteres, hasta parece más corto que el ejemplo en YAML

  • Puede que quede fuera del alcance dado que el objetivo del artículo es defender YAML, pero me habría gustado que también hablara de TOML 1.1 y de las nuevas funciones de tablas inline. Resuelven tres cosas que no me gustaban de JSON: nombres de claves sin comillas, comentarios como cadenas y soporte para comas finales

    • Puede ser válido decir que “las críticas a YAML ahora atacan una forma problemática que ya no existe”, pero luego ponerse a refutar una versión vieja de TOML se siente un poco raro
      Python 3.15 soporta TOML 1.1, y la adopción de TOML 1.1 parece mucho mejor que la de YAML 1.2. Actualizar un parser de TOML 1.0 a 1.1 probablemente sea casi trivial, pero subir de YAML 1.1 a 1.2 no parece serlo. Ni siquiera encuentro bien la lista de cambios en yaml.org; solo veo dos especificaciones enormes
      Cosas como el “Norway Problem” son para mí apenas una nota al pie menor entre las razones por las que no me gusta YAML; lo que realmente no me gusta es que es difícil de editar, usa espacios significativos y, en general, es bastante complejo

  • Creo que YAML, JSON y TOML tienen cada uno su propio espacio. El hueco que durante mucho tiempo sentí que estaba vacío lo llenó https://kdl.dev/
    JSON = intercambio de datos anidados arbitrariamente
    YAML = formato contenedor poco profundo para guardar cadenas multilínea
    TOML = archivo de configuración casi plano
    KDL = expresar como datos un DSL estilo Ruby

    • En proyectos nuevos donde hace falta configuración, yo también ya me establecí con KDL. Porque elimina bastante sintaxis de delimitadores no relacionada y muchas reglas de indentación
    • KDL está realmente muy bien. Sigo buscando oportunidades para usarlo. Hay casos, como en XML, donde tener atributos y nodos hijo al mismo tiempo hace que el marcado sea mucho más legible, y me gusta que ofrezca esa opción con una sintaxis ligera
    • En cuanto vi el ejemplo pensé “esto se parece a SDLang”, y no era coincidencia. Qué bueno que me diste a conocer KDL

  • No me gusta YAML por cosas como el Norway problem. YAML 1.2 lo redujo un poco, pero por las cadenas sin comillas, cadenas como "", "Null", "true", "FALSE" siguen siendo problemáticas, y hace falta un codificador que entienda YAML. Tampoco me gusta su complejidad general, pero la verdadera razón por la que odio YAML es esta

    tab characters must not be used in indentation
    Cuando la indentación tiene significado, está bien prohibir mezclar tabulaciones y espacios o usarlos de forma inconsistente. El enfoque de Python 3 se ve bastante bien
    Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
    Pero YAML parece ser el único formato de archivo que permite o exige indentación y aun así no soporta tanto tabulaciones como espacios
    Se podría decir que Make no soporta espacios, pero .RECIPEPREFIX puede configurarse con un valor que no sea una tabulación. Incluso se puede ver que en Make la tabulación no es indentación, sino una marca que usa Make

    • No puedo encontrarlo ahora, pero recuerdo haber leído una cita en la que Guido van Rossum decía que, si volviera a hacer Python desde cero, una de las cosas que sin falta cambiaría sería la prohibición del carácter de tabulación real en la indentación
      PEP-8 también recomienda fuertemente no usar tabulaciones para indentar

      Tabs should be used solely to remain consistent with code that is already indented with tabs.
      -- https://peps.python.org/pep-0008/#tabs-or-spaces

    • Como referencia, la especificación de NestedText también dice esto

      Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.

  • Creo que la lógica de “YAML no es malo, lo malo era YAML 1.1, pero la mayoría son parsers 1.1” no funciona tanto como el texto quisiera
    Me gusta YAML cuando se usa con moderación, y también me alegra que estén apareciendo nuevos parsers de alto rendimiento para YAML 1.2, pero si la versión “mala” sigue siendo la que usa la mayoría, creo que preferiría usar otra cosa. Si no puedo controlar qué parser se va a usar y por eso no puedo confiar en que mi YAML vaya a interpretarse correctamente, entonces YAML en su conjunto sigue estando en un estado “malo”
    Todos deberían migrar a 1.2, pero hasta entonces me parece razonable tratar YAML con cautela

  • La frase “el debate YAML vs TOML suele ser un debate que ataca un formato que ya no existe en una forma problemática, y las quejas son reales pero históricas” me hace querer gritar frente a GitHub Actions y Kubernetes

  • La defensa es sólida. Aun así, en documentos muy simples TOML es más legible, y es más fácil lograr que la gente use TOML que YAML
    Por desgracia, cambiar la percepción pública de los desarrolladores sobre una herramienta tiene una inercia muy larga. La gente lee cierta historia, toma una decisión y luego se pasa a otra herramienta que no cometió errores públicos

    • Eso deja de ser cierto cuando la organización, incluyendo arreglos, pasa de 2 niveles. A partir de ese punto, la indentación hace que la estructura sea mucho más fácil de entender

  • Ojalá que el parser YAML incluido en el intérprete de Ruby soportara YAML 1.2.2
    Pero no sé bien cómo cambiar la versión nueva como predeterminada sin romper el ecosistema

  • Sería bueno que los formatos de archivos de configuración pudieran especificar un esquema estandarizado. Así, un editor podría ver un archivo de configuración arbitrario y avisar sobre claves con errores tipográficos o tipos incompatibles
    También debería poder documentar para qué sirve una clave con pistas al pasar el cursor y ofrecer autocompletado de claves válidas fácilmente. Mejor aún si soportara aserciones o contratos simples para detectar valores inválidos. Por ejemplo, que la clave "color" deba coincidir con /#[a-fA-F0-9]{6}/
    Idealmente, esto también debería permitir generar automáticamente estructuras de datos para archivos de configuración

    • Eso es simplemente describir XML tal cual
      Hay varios formatos de especificación de validación como XSD o Relax NG, y yo estoy más familiarizado con los XML DTD, así que no puedo hablar mucho de los demás
    • En archivos JSON es bastante común usar una propiedad $schema en la clave de nivel superior para referenciar un archivo JSON Schema que define el esquema correcto. En esencia, es un XSD para JSON. Los buenos editores normalmente pueden usar eso como base para dar autocompletado y subrayados rojos
      Lo bueno es que TOML y YAML son más o menos JSON con una sintaxis distinta, así que normalmente también se pueden usar archivos de JSON Schema