XML a JSON: as decisões que todo conversor deve tomar

A ambigüidade que nenhum conversor pode evitar

Considere `<items><item>x</item></items>`. O `item` deve ser uma string ou uma lista de uma? O XML não diz, e a diferença importa no momento em que você escreve o código nele: um consumidor espera sempre uma quebra de matriz em uma resposta de elemento único e um consumidor espera que um objeto seja quebrado quando um segundo item chegar. Conversores maduros permitem forçar matrizes para elementos de lista conhecidos, em vez de adivinhar silenciosamente, porque a estimativa é correta com frequência suficiente para atingir a produção.

Os atributos precisam de uma convenção de nomenclatura

JSON não possui atributos, portanto, um atributo deve se tornar uma chave irmã ou um objeto aninhado. A convenção amplamente usada prefixa nomes de atributos com `@` — `<image src="a.png"/>` torna-se `{"@src": "a.png"}` — enquanto o texto do elemento entra em uma chave reservada como `#text` quando um elemento tem atributos e conteúdo. Qualquer que seja a convenção usada pelo conversor, ela deve ser aplicada de forma consistente, porque o XML meio convertido é pior que o XML não convertido.

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

Espaços para nome

Documentos com namespace — serviços SOAP, mapas de sites, formatos Office — qualificam os nomes dos elementos como `ns:element`. JSON não tem equivalente, então um conversor descarta o prefixo, mantém-no como parte da chave ou reorganiza o documento em torno do URI do namespace. Descartá-lo é comum e ocasionalmente desastroso quando dois namespaces usam o mesmo nome local. Se o seu documento usa namespaces, verifique se há colisões na saída antes de confiar nela e prefira manter o prefixo na chave.

Onde esta conversão é realmente usada

• Feeds RSS e Atom – ler um feed em JavaScript é muito mais fácil após a conversão.
• SOAP e APIs legadas — transformando uma resposta em algo que um cliente moderno pode consumir.
• Sitemaps e arquivos de configuração — inspecionando a estrutura sem um editor que entenda esquemas.
• Migrações de dados — mover registros de um sistema da era XML para um sistema baseado na JSON.

A fidelidade de ida e volta é um mito. A conversão de XML para JSON e vice-versa raramente retorna o documento original byte por byte, porque a ordem de declaração, espaços em branco, comentários e CDATA não sobrevivem. Converta quando precisar consumir os dados em outro lugar, não como estratégia de backup.

Valide primeiro e depois converta

Os analisadores XML são rigorosos em relação a tags não fechadas e entidades inválidas, e as mensagens de erro geralmente são precisas. Corrija o documento antes de converter — uma entrada bem formada é a única maneira de obter uma estrutura JSON que vale a pena manter. A conversão então é executada localmente no navegador, o que é importante quando o XML é uma exportação do cliente ou uma resposta de serviço interno, e continua funcionando offline.