Convertir NDJSON a XML

Los dos formatos están en extremos opuestos de la misma cuestión. NDJSON se diseñó para que ninguna línea dependa de otra: se puede partir por donde sea, reanudar tras un fallo y procesar sin cargarlo entero. Un documento XML es lo contrario: no es válido hasta que llega la etiqueta de cierre de la raíz, así que es una unidad indivisible desde el primer byte hasta el último.

Eso es lo que hay que planificar, más que los nombres de las etiquetas. Convertir un volcado grande produce un único documento que hay que transmitir, analizar y aceptar entero, y un fallo en cualquier punto invalida todo. Si el sistema receptor tiene un límite de tamaño de mensaje o una política de reintentos, partir el origen en lotes antes de convertir es la diferencia entre un envío que se reanuda y uno que empieza de cero.

La forma es fija porque la forma de la entrada es fija. Un archivo delimitado por saltos de línea es siempre una lista, y una lista no tiene nombre propio, así que el documento es un elemento root que contiene un elemento item por registro. Cada campo se convierte en un elemento hijo con el nombre de su clave, y un objeto anidado se convierte en elementos anidados debajo.

No hay opción para cambiar esos dos nombres durante la conversión, y tampoco habría forma sensata de adivinarlos: nada dentro de un NDJSON dice si los registros son pedidos, expedientes o mediciones. La salida es deliberadamente el documento correcto más simple, lo que convierte el renombrado posterior en un buscar y reemplazar previsible en lugar de en un desenredo.

Esta es la parte que hay que leer si tus datos están en español, y es la que sorprende a todo el mundo. El escritor solo admite letras sin acento, cifras, guion bajo, punto y guion en un nombre de elemento; todo lo demás lo sustituye por un guion bajo. Así que una clave llamada año sale como a_o, razón_social sale como raz_n_social, descripción sale como descripci_n y nº_factura sale como n__factura.

Conviene subrayar dos cosas. La primera es que XML sí permitiría esas letras en un nombre de elemento: la restricción es de nuestro escritor, que se queda del lado conservador. La segunda es que el cambio es silencioso y solo afecta a los nombres, no a los valores: el contenido de descripción viaja intacto en UTF-8 dentro de una etiqueta que ha dejado de llamarse como se llamaba. Si el destino valida contra un esquema, ahí es donde aparece el rechazo. Renombra las claves del NDJSON antes de convertir, o corrige las etiquetas después, pero no des por hecho que han llegado tal cual.

Casi cualquier entrada de XML nombra su elemento de registro en un esquema: un documento de pedidos que contiene elementos de pedido, un lote que contiene transacciones. Los dos nombres genéricos son marcadores de posición, y sustituirlos es un trabajo de dos líneas en cualquier editor: una aparición de root en cada extremo e item en cada frontera de registro.

Hacerlo antes del primer envío y no después de un rechazo se paga solo. Un sistema que valida contra un esquema rechaza el documento entero por el nombre del elemento y normalmente lo informa de una manera que no lo dice con claridad. Si los envíos van a ser periódicos, el renombrado pertenece al script que mueve el archivo y no a la memoria de una persona.

Merece la pena decir qué no hace esta página, porque muchas búsquedas llegan aquí desde ese sitio. Facturae en España, el suministro de libros de registro a la Agencia Tributaria o un CFDI mexicano son esquemas concretos, con espacios de nombres, orden de elementos obligatorio y, en varios casos, una firma electrónica encima. Lo que sale de aquí es XML bien formado y genérico, no ninguno de esos documentos.

Sirve, eso sí, como paso intermedio honesto: convertir la exportación a XML plano y transformarla después con una hoja XSLT o con el propio generador del esquema es un camino habitual y perfectamente razonable. Lo que no funciona es renombrar la raíz y esperar que la validación pase, porque estos esquemas comprueban bastante más que los nombres.

Una lista en XML ha sido siempre la misma etiqueta escrita varias veces, así que un registro con tres etiquetas produce tres elementos seguidos con ese nombre. Sin numerar, sin unir y sin ninguna decisión tomada por ti: la estructura llega intacta.

Es el argumento más fuerte a favor del XML frente a los destinos tabulares para este mismo archivo. Convertir estos registros a CSV obliga a elegir entre columnas numeradas, una cadena concatenada o filas de más, y las tres pierden algo. Un pedido con cinco líneas de detalle o un evento con una lista de reglas aplicadas se convierte a XML sin ninguna concesión, que suele ser la razón por la que el sistema receptor eligió XML.

La reconciliación que hacen las conversiones tabulares no ocurre aquí, y tampoco hace falta. Cada elemento item lleva exactamente los campos que tenía su línea, así que un archivo de eventos mezclados produce elementos item de varias formas dentro de un mismo documento, lo cual es XML válido y suele ser inválido contra un esquema.

Un esquema que declara una secuencia fija de hijos rechaza el primer registro al que le falte uno. Cuando ese sea el caso, o filtras el origen a un solo tipo de registro antes de convertir, o añades los elementos que faltan como elementos vacíos; y conviene saber que un elemento vacío y un elemento declarado como anulable no son lo mismo para un validador estricto. Cuál de los dos quiere la entrada es una pregunta para su documentación, y responderla una vez ahorra un ciclo de rechazos.

Los ampersands, los signos de mayor y menor y las comillas dobles se escapan dentro de los valores, que es lo que evita que la descripción de un producto o un mensaje de registro con marcado dentro cierre el documento antes de tiempo. El apóstrofo no se escapa, cosa que es correcta en el contenido de un elemento y conviene tener presente si vas a mover esos valores a un atributo por tu cuenta.

Todo lo demás se escribe tal cual en UTF-8, incluidos los acentos, las eñes y cualquier alfabeto no latino: los valores no sufren la restricción que sí sufren los nombres. Un nulo de JSON se convierte en un elemento vacío, con la etiqueta presente y nada entre sus dos mitades. Hay esquemas que quieren en su lugar un atributo de nulidad y otros que quieren el elemento ausente; distinguirlos es una edición programada sobre la salida, porque el origen solo tiene una manera de decir que no hay nada.

El documento empieza directamente por el elemento raíz. XML 1.0 hace opcional la línea de declaración y la codificación es UTF-8, que es la que se asume por defecto, así que el archivo es correcto sin ella.

Aun así, hay entradas antiguas que la exigen y algunas herramientas de escritorio que se comportan mejor cuando está. Es una línea que se añade a mano al principio, y si el envío va a repetirse conviene que la añada el mismo script que hace el renombrado, en lugar de recordarlo cada vez.

Cada nombre de campo aparece dos veces por registro —en la etiqueta de apertura y en la de cierre— donde NDJSON lo escribe una. Añade la sangría y un documento de valores cortos con nombres de campo largos acaba pesando entre dos y tres veces lo que pesaba el archivo de partida.

En una entrega por SFTP eso da igual. En una cola de mensajes con límite de tamaño decide cuántos registros caben en un lote. La respuesta casi siempre es comprimir en lugar de reestructurar: este XML es extremadamente repetitivo, se comprime muy bien, y la mayoría de entradas que limitan el tamaño del mensaje aceptan una carga comprimida.

Primero que esté bien formado: cualquier editor de XML o un analizador de línea de comandos confirma en un segundo que el documento se interpreta, y debería. Después la validación contra esquema, y cuenta con que el primer intento falle por los nombres de elemento, por un espacio de nombres que falta en la raíz o por el orden, porque las secuencias de un XSD están ordenadas y las claves de un JSON no.

En cuanto un documento pasa, el trabajo queda definido: partir el origen en lotes del tamaño que acepte la entrada, convertir cada uno y aplicar los mismos renombrados y los mismos atributos de raíz. Hacer el primero a mano y leer con calma la salida del validador es lo que convierte los siguientes en mecánica.

La conversión se ejecuta en esta pestaña: el archivo se analiza línea a línea y el documento lo escribe un escritor pequeño dentro de la página. No se sube nada, no hay cuenta ni cola, y el tope gratuito es de 100 MB por archivo, con la memoria del navegador como límite práctico porque el documento se monta entero.

Los datos que acaban en esta ruta rara vez son triviales. Las entregas a organismos, a bancos, a aseguradoras y a sistemas de socios son justo los archivos que llevan una cláusula de confidencialidad detrás, y pasarlos por un servicio web desconocido sería una cesión que nadie autorizó. Aquí no hay ninguna cesión, y se comprueba mirando la pestaña de red mientras se convierte.