¿Qué es XML? No está muerto: se esconde dentro de archivos que usas a diario

A XML se le describe habitualmente como obsoleto, lo cual es extraño si se piensa que hoy casi seguro abriste varios archivos XML sin darte cuenta. Perdió la discusión sobre enviar datos entre programas — JSON ganó eso con claridad. Conservó todo lo demás.

Qué es

XML significa Extensible Markup Language. Se parece a HTML con una diferencia crucial: en HTML las etiquetas están fijadas de antemano, mientras que en XML las inventas tú.

<book>
  <title>Viaje al Oeste</title>
  <year>1592</year>
</book>

Nada define <book> por adelantado. El formato aporta la gramática — etiquetas, anidamiento, atributos — y tú aportas el vocabulario que tus datos necesitan.

Dónde ya lo usas

• Documentos de Word, Excel y PowerPoint. Un .docx es un zip lleno de XML; el texto, el formato y la estructura son archivos XML dentro.
• Ebooks. Un EPUB usa XML para su manifiesto, su lomo y su índice.
• SVG. Los gráficos vectoriales son XML. Abre cualquier logo SVG en un editor de texto y estarás leyendo XML.
• Sitemaps. El archivo que cada web da a los buscadores es XML.
• Feeds RSS y de pódcast. Todos los pódcast del planeta se distribuyen como feeds XML.
• Documentos oficiales y de empresa. La facturación electrónica es XML obligatorio en muchos países.
• Diseños de apps Android y muchísima configuración en general.

No es una lista de reliquias. Es donde XML resultó ser lo correcto.

Lo único que JSON no puede hacer

Considera una frase con énfasis dentro: el veloz zorro marrón, donde solo «veloz» va en cursiva. En XML es natural:

<p>el <em>veloz</em> zorro marrón</p>

Texto y marcado se entrelazan — lo que XML llama contenido mixto. El elemento contiene algo de texto, luego un elemento, luego más texto.

JSON no tiene forma de expresar esto. Sus valores son una cadena, un número, una lista o un objeto; no existe el concepto de «texto con cosas incrustadas en puntos concretos». Representar esa frase en JSON exige inventar una convención — un array de fragmentos, cada uno etiquetado con su estilo — y luego todos deben aceptar tu invento.

Los documentos están hechos de contenido mixto. Casi toda frase de un documento real lleva algo marcado dentro. Por eso los procesadores de texto, los ebooks y las maquetaciones son XML, y por eso seguirán siéndolo.

Los datos no son así. Un precio es un número, un nombre una cadena, un pedido tiene una lista de líneas. JSON encaja perfecto y XML solo añade puntuación.

Qué más tiene XML

• Atributos. <book id="42">: metadatos pegados al elemento en vez de dentro de él.
• Comentarios. <!-- así -->. JSON no tiene ninguno, lo que molesta de verdad en archivos de configuración.
• Esquemas. Un documento aparte puede especificar exactamente qué elementos se permiten, en qué orden y con qué tipos, y un archivo puede validarse automáticamente contra él. Por eso los sectores regulados usan XML: un gobierno publica un esquema y la ley puede remitirse a él.
• Espacios de nombres. Vocabularios de distintas fuentes se combinan en un archivo sin que choquen los nombres.
• Transformación. XSLT convierte una estructura XML en otra, o en HTML, como transformación declarada en vez de programa.

Las reglas, y la que lo rompe todo

• Exactamente un elemento raíz que contiene todo lo demás.
• Toda etiqueta debe cerrarse. <br> no vale; <br/> sí.
• Distingue mayúsculas. <Book> y <book> son elementos distintos.
• Los valores de atributo van entrecomillados.
• Anidamiento correcto. Las etiquetas cierran en orden inverso al de apertura.

Y luego la que causa más XML roto que todas las demás juntas: el ampersand.

Hay cinco caracteres reservados, y & es el peligroso porque aparece constantemente en las URL. Una dirección con parámetros lleva & entre ellos, y pegada en bruto dentro de XML invalida el archivo de inmediato. Debe escribirse &.

Esa es la causa habitual de que un validador rechace un sitemap o un feed RSS: un único ampersand sin escapar en un enlace. Los otros cuatro son <, >, " y ', escritos <, >, " y '.

Para un bloque lleno de esos caracteres, <![CDATA[ ... ]]> marca una región que el analizador debe tomar literalmente: la forma estándar de meter HTML dentro de un feed RSS.

Codificación

A diferencia de CSV, XML resuelve bien el problema de la codificación. La primera línea la declara:

<?xml version="1.0" encoding="UTF-8"?>

El archivo dice lo que es, nadie tiene que adivinar, y el contenido chino o japonés sobrevive al moverse entre sistemas. Una cosa pequeña que elimina toda una categoría de fallos.

Por qué la verbosidad a veces es el objetivo

XML es verboso. Para una API invocada mil veces por segundo eso es puro desperdicio, y JSON es la respuesta correcta.

Para un documento que debe leerse dentro de treinta años, validarse contra un estándar publicado e interpretarse igual por dos organizaciones que nunca han hablado, la verbosidad está trabajando. El archivo se describe a sí mismo, el esquema define qué es legal, y nada depende de un supuesto compartido que nadie escribió.

Esa es la división que conviene recordar: JSON para datos en movimiento, XML para documentos que deben durar.

Referencia rápida

• Lenguaje de marcado donde defines tus propias etiquetas
• Dentro de DOCX, XLSX, EPUB, SVG, sitemaps y feeds RSS
• Puede representar contenido mixto — texto con marcado dentro — y JSON no
• Tiene atributos, comentarios, espacios de nombres, esquemas y XSLT
• Un elemento raíz, toda etiqueta cerrada, distingue mayúsculas, atributos entrecomillados
• Un & sin escapar rompe el archivo — escribe &, sobre todo en URL
• Declara su propia codificación en la primera línea
• JSON para datos en movimiento; XML para documentos que deben durar