Dos modelos definidos para necesidades diferentes
El estándar RFC 8259 define JSON mediante objetos, arreglos y valores que pueden ser texto, número, booleano o nulo. Un arreglo mantiene el orden de sus elementos; un objeto se define como una colección no ordenada de pares nombre–valor, aunque muchas implementaciones muestren el orden de inserción.
La recomendación XML 1.0 del W3C describe documentos formados por elementos, atributos, datos de caracteres, comentarios e instrucciones de procesamiento. El orden de los nodos forma parte del documento y un elemento puede mezclar texto con otros elementos. Estas capacidades explican por qué no existe una conversión universal y reversible entre XML y JSON.
Comparación práctica antes de transformar
| Aspecto | JSON | XML | Decisión al convertir |
|---|---|---|---|
| Listas | Arreglos explícitos | Elementos hermanos repetidos | Definir si uno y varios elementos siempre producirán un arreglo |
| Tipos | Número, booleano y nulo forman parte del modelo | El texto no adquiere tipo sin reglas adicionales | Evitar inferir tipos solo por la apariencia |
| Atributos | No existe una categoría equivalente | Son distintos de los elementos hijos | Elegir una convención como @id o un objeto separado |
| Namespaces | No tiene mecanismo incorporado | Identifican vocabularios mediante nombres calificados | Conservar prefijo y URI cuando sean relevantes |
| Contenido mixto | No representa directamente texto intercalado con nodos | Puede combinar texto y elementos en orden | Usar una estructura especial o aceptar pérdida de orden |
Un ejemplo sencillo ya necesita una convención
JSON posible: { "producto": { "@id": "7", "nombre": "Café" } }
El prefijo @ no pertenece a RFC 8259: es una decisión del conversor para distinguir un atributo de un elemento. Otra integración podría usar "atributos":{"id":"7"}. La salida solo es correcta si emisor y receptor comparten la misma convención.
Cero, uno y varios elementos repetidos
Supón que <pedido> puede contener cero, uno o varios elementos <item>. Algunos conversores producen un objeto cuando existe uno y un arreglo cuando existen varios. Esto obliga al consumidor a manejar dos tipos distintos. Para una API estable suele ser más predecible normalizar siempre item como arreglo, incluso cuando solo tenga una posición.
La ausencia también requiere una regla. Un elemento que no aparece, <nota/> y <nota></nota> pueden representar estados diferentes según el esquema. Convertir los tres automáticamente a null borraría esa diferencia.
Texto XML frente a tipos JSON
Sin un esquema o contrato, valores como 0012, false y 2026-08-19 son texto XML. Convertir 0012 a número elimina ceros; transformar cualquier texto false en booleano puede cambiar un código o etiqueta. Por esa razón, la herramienta XML a JSON de Nexo Útil conserva el contenido textual y deja la conversión de tipos para una etapa que conozca las reglas del destino.
Namespaces y nombres calificados
La especificación Namespaces in XML permite distinguir vocabularios que utilizan el mismo nombre local. factura:total y envio:total pueden tener significados diferentes. Conservar únicamente la palabra total crea una colisión. Una migración debe decidir si mantiene el prefijo, registra la URI asociada o transforma cada vocabulario mediante reglas propias.
Información que puede perderse
Comentarios, instrucciones de procesamiento, orden de contenido mixto, declaraciones de namespace y distinciones entre atributo y elemento no tienen equivalentes automáticos en JSON. Incluso los números JSON presentan límites de interoperabilidad: RFC 8259 advierte que la precisión disponible depende de la implementación. Identificadores extensos y decimales financieros suelen transportarse como texto o mediante una convención acordada.
Procedimiento reproducible para una integración
- Valida primero que el XML esté bien formado.
- Identifica atributos, namespaces, contenido mixto y elementos repetibles.
- Escribe la convención de salida antes de convertir una muestra.
- Prueba por separado los casos con cero, uno y varios elementos.
- Compara tipos, valores vacíos, orden y nombres con el contrato receptor.
- Guarda una prueba automatizada con la entrada y el JSON esperado.
El registro reproducible del conversor muestra un caso con atributos y elementos repetidos. Puedes usar el comparador de textos para enfrentar la salida obtenida con una respuesta esperada.
Cuál elegir
JSON suele encajar bien en APIs web centradas en objetos y arreglos. XML resulta apropiado cuando el estándar del sector ya lo exige, cuando importan namespaces, validación con esquemas, contenido documental mixto o compatibilidad con sistemas existentes. La mejor elección es la que conserva el significado requerido con reglas comprensibles para todos los participantes.