Convertir XML a YAML

El XML gasta buena parte de sus caracteres en decir dónde termina cada elemento. YAML lo dice con la sangría, así que el mismo documento sale bastante más corto y cada nivel de anidación es un salto visual en vez de un par de etiquetas que buscar con la vista. En un pom.xml de Maven o un web.config, esa es la diferencia entre desplazarte sin parar y leer de un tirón.

La estructura no cambia en nada. Cada elemento se convierte en una clave, sus hijos pasan a ser el mapa que hay debajo, y el texto se convierte en el valor. No se reordena ni se resume nada: lo que tienes delante es el mismo documento sin la puntuación, que es justo lo que necesitas cuando el objetivo es entender qué dice el archivo.

Los atributos llegan como claves con el prefijo @ delante, y un elemento que tiene atributos y texto a la vez guarda ese texto bajo una clave llamada #text. Las dos van entre comillas, porque YAML reserva el @ como indicador especial al principio de un valor sin marcar y el # abre un comentario.

Parece ruido añadido y en realidad es corrección. Si editas el archivo a mano, conserva esas comillas: quitarlas produce un YAML que no se puede leer o que, en el caso de #text, convierte silenciosamente el resto de la línea en un comentario y pierde el valor. Lo mismo pasa si cambias el nombre de una clave al reorganizar la salida.

Este es el motivo más sólido para hacer la conversión. Comparar dos versiones de un XML es incómodo porque un cambio a un solo nivel de profundidad aparece como varias líneas de etiquetas, y cualquier reformateo automático reescribe el archivo entero. Convertir las dos versiones a YAML y compararlas muestra los valores modificados en su propia línea, con la ruta de claves justo encima.

Hay un matiz que decide si esto funciona o no. Como un elemento repetido una vez se vuelve un mapa y repetido dos veces se vuelve una lista, una versión que añadió una segunda dependencia cambia la forma de esa rama entera y no solo su contenido, así que la comparación muestra el bloque completo como reescrito. No es que la conversión pierda información: es que la forma cambia de verdad, y saberlo de antemano evita leer una diferencia grande como un cambio grande.

Los prefijos se conservan como parte del nombre de la clave, así que un documento que usa soap: o xsi: produce claves con dos puntos dentro. El generador las escribe sin comillas y se leen bien con el mismo analizador. Las propias declaraciones del espacio de nombres sobreviven como atributos, así que un xmlns por defecto llega como una clave "@xmlns" entre comillas en la raíz.

Una clave sin comillas con dos puntos dentro es de las cosas que conviene ajustar a mano antes de que el archivo viaje a otro sitio. Si el YAML lo va a leer otra herramienta, ponle comillas tú mismo: no cuesta nada y evita un problema que solo aparece cuando otro analizador lee el archivo. Nada resuelve los prefijos a su URI real, así que dos documentos que usan prefijos distintos para el mismo espacio de nombres no se comparan bien entre sí.

Los valores que parecen números se interpretan como tal, tanto en el texto de un elemento como en un atributo. Una versión de Maven escrita 4.13.2 sigue siendo texto, porque tiene dos puntos y no puede ser un número, y lo mismo pasa con una dirección o una ruta. Pero un atributo de versión escrito 1.0 se convierte en 1, y un valor con ceros a la izquierda como 007 se convierte en 7.

En un config que solo se lee, el daño se limita a cómo se ve el valor, y aun así importa: una versión de esquema que aparece como 1 en vez de 1.0 en una revisión es algo que alguien va a cuestionar o, peor, copiar tal cual. Revisa una vez los valores con pinta de número en la salida. Si el YAML va a alguna parte que no sea un ojo humano, pon comillas a los que en realidad eran identificadores.

Un valor con saltos de línea dentro se escribe como bloque —una barra vertical con el texto sangrado debajo—, lo que lo mantiene legible en vez de convertirlo en una sola línea con los saltos escapados. Un valor largo de una sola línea se escribe tal cual, sin cortarlo. Las dos son la opción correcta cuando el objetivo es que alguien lo lea.

Un elemento vacío o autocerrado se convierte en una cadena vacía, escrita como un par de comillas. El XML no distingue entre un elemento vacío y uno que no contiene nada, así que no se pierde información, pero una cadena vacía es fácil de pasar por alto en un archivo largo: si estás revisando un config buscando valores sin definir, busca las comillas vacías en vez de fiarte de la vista.

El XML admite comentarios, el YAML admite comentarios, y ninguno de los tuyos sobrevive. El analizador los descarta al leer y el generador no tiene nada que volver a escribir. En un archivo de datos eso da igual; en un archivo de build es la pérdida más grande de todas, porque el comentario encima de una versión fijada suele ser el único registro que queda de por qué está fijada así.

La forma sensata de trabajar es tratar el YAML como una copia de lectura y conservar el XML como la fuente. Si el YAML va a convertirse de verdad en la fuente —una migración real a un chart de Helm o a Ansible— conviene programar el paso de copiar los comentarios a mano como parte del trabajo, antes de borrar el XML y perder el razonamiento con él.

Un config recién convertido todavía no es un values.yaml ni un conjunto de variables. Trae restos del XML —las claves @, las claves #text, una declaración de espacio de nombres en la raíz, y quizá una clave ?xml de la línea de declaración— que no significan nada para lo que sea que estés alimentando. Borrarlos es el primer paso.

El segundo es renombrar. Los nombres de elementos XML suelen ser largos porque tenían sentido con un esquema detrás, y un config en YAML normalmente quiere nombres más cortos y planos. Los dos pasos son manuales, y son la migración de verdad; la conversión solo te da un punto de partida legible en vez de una pared de etiquetas.

Conviene convertir cuando el objetivo es entender, revisar o comparar: el YAML es más corto, la estructura salta a la vista, y todo el proceso ocurre en tu navegador en el tiempo que tarda en soltarse el archivo. Es un buen hábito para cualquier config que te hayan pasado y tengas que entender antes de tocarlo.

No conviene convertir cuando el archivo lo valida un esquema, va firmado, o lo consume una herramienta que lee XML directamente. En ese caso el XML es el documento de verdad, y una copia en YAML es una segunda versión que acabará desincronizada de la primera. Léelo como YAML, cámbialo como XML.

Tanto la lectura del XML como la escritura del YAML son JavaScript que se ejecuta en esta página, así que un config con cadenas de conexión, claves de licencia o rutas internas no llega a ningún servidor. Puedes comprobarlo en la pestaña de red del navegador durante la conversión.

Los archivos de hasta 100 MB entran en el nivel gratuito sin coste, lo que cubre con margen incluso un manifiesto de Android o un web.config grande. No hay cuenta que crear ni cola de espera: el archivo se procesa en el momento en que lo sueltas.