Definición
XML es un formato para representar datos estructurados mediante etiquetas anidadas, con una apertura y un cierre por cada elemento.
Fue durante años el estándar de intercambio entre sistemas, y JSON lo ha desplazado en casi todo lo que es web moderna por ser mucho más compacto y directo de usar.
Sigue vivo, y no por inercia: en administración pública, facturación electrónica, banca, logística y sistemas de empresa es lo que hay, y con frecuencia es obligatorio por normativa.
XML frente a JSON
| XML | JSON | |
|---|---|---|
| Verbosidad | Alta: cada dato lleva apertura y cierre | Baja |
| Validación formal | Esquemas maduros y muy potentes | Existe, menos extendida |
| Atributos y metadatos | Sí, además del contenido | No, solo pares clave-valor |
| Firma digital dentro del documento | Estándar consolidado | Poco habitual |
| Uso hoy | Empresa, administración, facturación | APIs web, aplicaciones |
Las dos ventajas reales de XML explican dónde sobrevive: validación estricta mediante esquema y firma digital incorporada al propio documento. En facturación electrónica ambas son requisitos, no lujos.
Lo que hay que conocer
Esquema. Un fichero que define qué elementos son obligatorios, en qué orden y de qué tipo. Permite validar un documento antes de procesarlo y saber exactamente en qué línea falla. Es la mejor característica del formato.
Espacios de nombres. Prefijos que evitan colisiones cuando un documento mezcla vocabularios distintos. Son la causa habitual de que un procesador «no encuentre» un elemento que está claramente en el fichero: se busca por nombre, y hay que buscar por nombre y espacio de nombres.
Codificación declarada. El documento indica su propia codificación en la primera línea. Si la declaración no coincide con el contenido real, falla al abrirlo — y ese es probablemente el error más frecuente al generarlo.
Ejemplo práctico
En facturación electrónica española, el documento es XML, tiene un esquema oficial y va firmado digitalmente. No es opcional ni sustituible por otro formato.
Lo que aprendí trabajando con documentos así: la diferencia entre una integración que funciona y una que da problemas eternos es validar contra el esquema antes de enviar. Un documento que se envía sin validar produce un rechazo genérico del receptor, sin decir dónde está el fallo; validado en origen, sabes el elemento exacto y la línea.
Y hay una consecuencia específica de la firma que conviene entender: si el documento está firmado, no se puede tocar. Ni un espacio. Cualquier modificación posterior invalida la firma. Eso obliga a generar el documento completo y correcto antes de firmarlo, no a corregirlo después — que es el reflejo natural y aquí no vale.
El segundo aprendizaje, sobre generar XML: no se construye concatenando texto. Es la misma trampa que en SQL: un valor con un carácter especial —un ampersand en el nombre de una empresa, unas comillas en una dirección— rompe el documento o, peor, lo altera. Hay que usar la biblioteca del lenguaje, que escapa los valores correctamente.
Y una advertencia de seguridad concreta: procesar XML que llega de fuera tiene un riesgo propio. Los analizadores permiten, por defecto en algunas configuraciones, que un documento haga referencia a ficheros externos, y eso puede usarse para leer ficheros del servidor o para provocar una denegación de servicio. La medida es sencilla y hay que aplicarla siempre: desactivar el procesamiento de entidades externas en el analizador. Es una línea de configuración y evita una familia entera de ataques.
Errores comunes
- Generarlo concatenando texto sin escapar valores.
- Ignorar los espacios de nombres al buscar elementos.
- Codificación declarada que no coincide con el contenido.
- No validar contra el esquema antes de enviar.
- Modificar un documento ya firmado.
- Procesar XML externo sin desactivar las entidades externas.
- Elegir XML para una API nueva donde JSON sería mejor.
- No guardar el documento enviado tal cual, que es lo que acredita qué mandaste.
Cuándo usarlo
Cuando te lo imponen: facturación electrónica, integraciones con administración, sistemas antiguos de empresa, y formatos estándar del sector.
Para una API nueva o un intercambio entre sistemas propios, JSON casi siempre es mejor. La excepción real es cuando necesitas validación formal estricta o firma dentro del documento — y ahí XML sigue sin competencia.
