JSON vs XML

Orígenes: un lenguaje de marcado frente a un formato de datos

El ancestro de XML es SGML, y su objetivo de diseño era marcar documentos: prosa que mezcla párrafos, énfasis y estructura. Por eso XML, solo de los dos, soporta contenido mixto —texto con marcado en línea como <title>Learning <em>XML</em></title>— y por eso creció con atributos, referencias a entidades y un modelo de procesamiento pesado. JSON se extrajo de los literales de objeto de JavaScript hacia 2001 con un único propósito: mover datos estructurados entre programas con la mínima gramática posible. En JSON no hay contenido mixto, ni maquinaria de entidades, ni árbol de documento —objetos, arrays y cuatro tipos escalares son todo el universo—.

Sintaxis: el impuesto de etiquetas, los atributos y el array que falta

Cada elemento XML abre y cierra, así que un valor simple cuesta dos etiquetas: <price>19.99</price>. XML ofrece una grafía alternativa —<price currency="EUR">19.99</price>— y la elección atributo-o-elemento lleva dos décadas generando debate sin respuesta universal. JSON tiene exactamente una grafía para un par clave/valor y una para una lista. Lo crucial: JSON tiene arrays nativos; XML no tiene ningún tipo array. Una lista se expresa repitiendo un elemento, lo que significa que toda herramienta de JSON a XML debe ponerse de acuerdo en una convención para nombrar y envolver los elementos repetidos.

Esquemas y espacios de nombres: donde XML todavía se gana la vida

XSD es la ventaja silenciosa de XML en las empresas: un lenguaje de esquemas maduro, con tipos derivados, restricciones de cardinalidad, facetas de patrón y dos décadas de herramientas capaces de validar un documento e informar con precisión de qué elemento rompió qué regla. JSON Schema persigue el mismo objetivo con otra forma —es expresivo, soporta lógica condicional y se ha vuelto el lenguaje de contratos de facto para las APIs modernas—, pero su larga historia de borradores hace que las herramientas varíen más en lo que aceptan. Ambos ecosistemas pueden ser estrictos; el de XML simplemente es más viejo.

Los espacios de nombres son la otra característica duradera de XML. Una página XHTML puede incrustar SVG y MathML sin colisiones de claves porque cada vocabulario lleva su propio URI. JSON no tiene mecanismo equivalente —las colisiones de nombres se evitan por convención, o con diseños por capas como JSON-LD que adjuntan el contexto de forma explícita—.

Tamaño, streaming y cuándo elegir cuál

Para los mismos datos, las cargas XML suelen ser más grandes: solo las etiquetas de cierre duplican aproximadamente el marcado de los elementos, y los estilos cargados de atributos añaden más. Ambos formatos comprimen bien con gzip —la redundancia de XML es muy compresible—, pero el sobrecoste base rara vez se cierra del todo. En streaming, el ecosistema de parsers de XML llega más lejos: los parsers push SAX y StAX se diseñaron para documentos demasiado grandes para la memoria, y todas las plataformas traen uno. Los parsers de JSON en streaming existen y son excelentes, pero el procesado del documento completo sigue siendo lo habitual por defecto.

Elige JSON para cualquier cosa que se intercambien un par de programas: APIs web y móviles, logs estructurados, cargas de servicio a servicio. Elige XML cuando una especificación lo obliga —pilas SOAP, cadenas de publicación, formatos Office, muchos estándares sanitarios y financieros— o cuando necesitas validación XSD y espacios de nombres en la transmisión. La recomendación se invierte con claridad: el JSON que se cuela en una cadena de documentos suele querer ser XML, y una API de era SOAP que expone JSON limpio es una victoria de migración, no una traición.