Convertir TOML a XML

La versión interesante de esta conversión no es migrar una configuración. Es un paso de informe o de presentación: los datos de un proyecto viven en un manifiesto TOML porque es lo que eligieron Cargo, pip, Hugo y media cadena de herramientas actual, y el sistema que quiere esos datos lleva leyendo XML desde antes de que TOML existiera.

En España eso no es una excentricidad heredada, es la norma administrativa. La factura electrónica al sector público es XML con su esquema, los documentos del expediente electrónico tienen esquemas publicados, y un portal de proveedores con un XSD anexo al pliego es una situación corriente. Nadie al otro lado va a aceptar un `.toml`, y nadie va a cambiar el esquema por ti.

XML necesita exactamente una raíz y un documento TOML es una tabla con las claves que sea, así que se aplica una regla. Si el archivo tiene una sola clave de primer nivel, esa clave se convierte en la raíz, sea una tabla o un valor suelto: un archivo que sólo lleva una sección `[tool]` y sus subtablas se convierte en un documento `<tool>`. Si hay varias claves de primer nivel —lo habitual en un manifiesto con `[package]`, `[dependencies]` y un par de valores sueltos— todo queda envuelto en un `<root>` genérico.

Renombrar esa raíz es casi siempre la primera edición, y son dos cambios al principio y al final del archivo. Si la conversión se va a repetir, lo ordenado es tocar el TOML: anida el manifiesto entero bajo una sola tabla con el nombre que pide el esquema y el conversor producirá la raíz correcta siempre, sin ningún paso posterior.

Un bloque `[[bin]]` repetido tres veces es la forma que tiene TOML de escribir una lista de registros, y se convierte en tres elementos `<bin>` hermanos, cada uno con sus propios hijos. Así es exactamente como XML representa una lista, sin elemento envolvente y sin atributo de índice, y es el único punto de esta conversión donde no hay nada que decidir.

Un array de valores simples se comporta igual: `tags = ["a", "b"]` produce dos elementos `<tags>` con texto dentro, y no uno solo con los valores separados por comas. Que el esquema receptor quiera eso o prefiera un `<tags>` envolviendo hijos `<tag>` es de las cosas que un XSD te dice a la primera, y añadir el envoltorio con una transformación XSLT es una docena de líneas.

TOML es raro por tener cuatro tipos de fecha y hora en lugar de uno, y la conversión los mantiene separados en vez de aplastarlos contra un instante común. Convertir `launch = 2026-03-01T08:00:00Z`, `opens = 2026-03-01T08:00:00+02:00`, `seen = 2026-03-01T08:00:00`, `day = 2026-03-01` y `at = 08:00:00` produce, en ese orden, `<launch>2026-03-01T08:00:00.000Z</launch>`, `<opens>2026-03-01T08:00:00.000+02:00</opens>`, `<seen>2026-03-01T08:00:00.000</seen>`, `<day>2026-03-01</day>` y `<at>08:00:00.000</at>`.

Ése es el mapa con el que trabajar al leer o escribir el esquema: los tres primeros son léxicamente válidos como `xs:dateTime`, el cuarto es `xs:date` y el quinto es `xs:time`. Lo único que gana cada valor es una parte de milisegundos que no estaba en el manifiesto. Los tres tipos aceptan fracciones de segundo, así que la validación no se resiente; lo que sí se rompe es cualquier comparación contra un literal escrito en la forma corta, como una XSLT que pregunte por `= '08:00:00'`.

Un `2026-03-01T08:00:00+02:00` llega como `2026-03-01T08:00:00.000+02:00` y no como `06:00:00.000Z`. Es el comportamiento preferible para un documento que va a leer una persona, y significa que dos elementos con el mismo instante pueden llevar texto distinto. Una comparación de dos `xs:dateTime` en XSD o en XPath lo resuelve bien, porque la especificación define el orden después de normalizar; ordenar los elementos como cadenas, que es lo que hace un `xsl:sort` por defecto, no.

Los valores sin zona son los que conviene mirar antes de presentar nada. Una fecha y hora local de TOML dice que el reloj marcaba las ocho de la mañana en algún sitio, y el XML repite eso sin decir dónde; XSD lo llama zona horaria no especificada y, como el desfase podría ser cualquiera, una comparación de orden contra un valor con zona puede resultar indeterminada en vez de cierta o falsa. La hora suelta es la sorpresa más afilada: `at = 08:00:00` no tiene fecha, así que un elemento declarado `xs:dateTime` la rechaza y en el origen no hay nada con lo que completarla.

TOML permite que una clave sea casi cualquier cosa si va entrecomillada: `"informe 2024"`, `"line-length"`, `"x:y"`. Los nombres de elemento XML no pueden empezar por un dígito ni contener un espacio ni, sin un espacio de nombres declarado, dos puntos. El escritor reescribe en lugar de rechazar: todo lo que quede fuera de letras, dígitos, guion bajo, guion y punto se convierte en guion bajo, y un nombre que empieza por algo que no es letra ni guion bajo gana uno delante.

Así que `"informe 2024"` da `<informe_2024>`, `"a b"` da `<a_b>` y `"x:y"` da `<x_y>`. Este último es el que hay que vigilar: una clave escrita con dos puntos porque alguien pensaba en un prefijo de espacio de nombres pierde los dos puntos y se convierte en un nombre corriente, que no es lo que espera el esquema. Los guiones y los puntos sobreviven intactos, de modo que `line-length` o un nombre con puntos dentro de una clave entrecomillada pasan sin tocarse.

Por defecto cada clave del TOML se convierte en un elemento hijo, y casi todos los esquemas quieren al menos algunos valores como atributos. El convenio que sigue el escritor es una arroba al principio del nombre: dentro de una tabla, `"@id" = 42` produce `id="42"` en ese elemento en lugar de un hijo `<id>`. TOML admite la clave porque va entrecomillada.

El texto propio del elemento, junto a sus atributos, se escribe con la clave `"#text"` de la misma manera. Conocer las dos convierte un trabajo de dos pasadas en uno: dar forma al TOML con un puñado de arrobas es más rápido y más repetible que convertir y luego mover valores a atributos con una XSLT. Los valores de atributo se escapan para ampersand, ángulos y comillas dobles, así que una versión o una URL caben ahí sin riesgo.

No se escribe declaración XML, así que el documento empieza directamente en el elemento raíz. Tampoco se declara ningún espacio de nombres, no se referencia ninguna ubicación de esquema y no aparece ninguna instrucción de procesamiento. La salida va sangrada con dos espacios por nivel y termina en un salto de línea, y el texto y los atributos se escapan para `&`, `<`, `>` y `"`.

La mayoría de los analizadores aceptan un documento sin declaración y dan por supuesto UTF-8; el que exija una necesita una línea pegada arriba. Y hay un caso silencioso más: un array vacío como `tags = []` no produce elemento alguno, sólo una línea en blanco donde habría ido. Es defendible, porque no hay nada que repetir, y aun así sorprenderá a un esquema que declare ese elemento con `minOccurs="1"`.

Los dos formatos admiten comentarios y ni el lector ni el escritor los trasladan, así que toda línea que explicaba por qué una dependencia está fijada o por qué un ajuste tiene un valor raro desaparece del XML. En un manifiesto eso no es una pérdida menor: los comentarios suelen ser el único registro que existe de una decisión.

Trata el XML como un artefacto generado y no como una copia. Vuelve a generarlo cada vez que cambie el manifiesto, en lugar de editarlo y confiar en que los dos se mantengan al paso, y no lo guardes en el repositorio salvo que el procedimiento de presentación exija una copia versionada; y aun entonces, un paso de generación dentro de la compilación es mucho más seguro que un archivo que alguien tiene que acordarse de actualizar.

Todo lo anterior es un motivo por el que el primer intento no va a validar: la raíz tendrá el nombre equivocado, una hora suelta no satisfará un elemento declarado `xs:dateTime`, algunos valores serán hijos donde el esquema quiere atributos y una lista opcional puede faltar del todo. Encontrarlo entero en una pasada es mucho más rápido que encontrarlo en cuatro correos de rechazo.

`xmllint --schema contrato.xsd salida.xml --noout` te da la lista completa de quejas con números de línea y está en casi cualquier equipo. Recórrelas dando forma al TOML y no editando el XML, para que la siguiente pasada parta de un sitio mejor. Si el esquema es de verdad complejo —espacios de nombres anidados, grupos de sustitución, contenido mixto— esta conversión es la entrada de una XSLT y no el documento final, y asumirlo desde el principio ahorra una discusión más adelante.

En esta pestaña, con JavaScript corriente. No se descarga ningún motor, no se sube nada, no hay cuenta ni cupo diario, y el panel de red durante una conversión es la forma de comprobarlo, mejor que esta frase.

El límite gratuito es de 100 MB, que ningún manifiesto rozará jamás: estos archivos se miden en kilobytes. Lo que sí cambia de tamaño es la salida, porque XML repite cada nombre dos veces, una al abrir y otra al cerrar, y añade sangría: cuenta con un documento dos o tres veces mayor que el manifiesto del que salió. Es el coste ordinario del formato y desaparece en cualquier transporte que comprima.