Summary

  • A RFC 2376 registrou text/xml e application/xml, mas omitir charset produzia regimes opostos: US-ASCII para o primeiro, mesmo contra BOM ou declaração XML, e detecção pelo processador XML para o segundo.
  • Registro, cabeçalho recebido, octetos, regra do decodificador e significado aplicativo eram provas diferentes. A RFC 7303 depois alinhou os dois tipos e removeu o antigo padrão invisível.

Um documento autodescritivo dentro de outra moldura

O XML foi concebido para levar estrutura entre máquinas e programas distintos. Sua declaração interna podia nomear a codificação, e a marca de ordem de bytes ajudava a reconhecer formas importantes antes da leitura do conteúdo.

Na rede, porém, o documento vinha envolvido por HTTP, correio ou WebDAV. O Content-Type no estilo MIME também podia trazer charset. O receptor recebia mais de uma resposta para a pergunta sobre quais caracteres aqueles octetos representavam.

Publicada em julho de 1998 como documento Informational, a RFC 2376 criou text/xml e application/xml. Ela rejeitou o reaproveitamento dos tipos SGML porque processadores, recursos e parâmetros não eram equivalentes. O nome comum era útil; a disputa estava na precedência.

Uma escolha de apresentação mudou a autoridade

Toda entidade XML cabia em application/xml. Um agente sem suporte poderia tratá-la como arquivo opaco. text/xml indicava que mostrá-la como texto simples era um padrão aceitável.

Essa conveniência herdou as regras históricas do tipo superior text. Com charset explícito, a RFC 2376 dava autoridade ao envelope nos dois tipos. A declaração interna não tinha garantia de prevalecer.

Na ausência do parâmetro, os caminhos divergiam. Para application/xml, o cabeçalho não oferecia informação de codificação. Um processador XML podia observar BOM, padrão inicial dos bytes e declaração. Um agente MIME sem conhecimento de XML não deveria supor nada.

Para text/xml, ausência significava US-ASCII. Isso valia em HTTP e mesmo quando o corpo era UTF-8 ou UTF-16 e dizia isso claramente. Um campo vazio acionava uma ordem herdada; não preservava incerteza.

O exemplo obrigava a ver o conflito

A RFC mostrou uma entidade com BOM UTF-16 e encoding="utf-16", mas rotulada apenas como text/xml. O resultado normativo continuava US-ASCII. Acreditar no documento violava o contrato de entrega.

Os mesmos sinais sob application/xml recuperavam seu peso. Sem charset, o BOM podia identificar UTF-16; sem BOM, o processador examinava a assinatura inicial e a declaração. Uma palavra no tipo externo alterava quais provas valiam.

O efeito alcançava armazenamento e intermediários. Um gateway poderia transcodificar o corpo e atualizar só o cabeçalho. Um arquivo salvo poderia perder o cabeçalho que governara sua leitura. Ao separar bytes e contexto, o sistema perdia a razão pela qual aqueles bytes haviam produzido certos caracteres.

Autodescrição não define a própria hierarquia

O XML 1.0 reconheceu que, havendo informação externa, o protocolo de nível superior deveria estabelecer prioridade. A divisão fazia sentido porque transportes podiam transformar dados sem informar a declaração interna.

Mas ela transformou codificação em questão de controle: qual camada pode derrubar outra? A ausência comunica desconhecimento ou um valor padrão? A RFC 2376 respondeu com uma regra parcialmente herdada da história MIME.

A RFC 3023 a substituiu em 2001 e preservou o US-ASCII implícito de text/xml. Explicou melhor a utilidade do charset externo quando intermediários fazem transcodificação. Depois, a prática e as regras dos tipos textuais continuaram mudando.

O reparo retirou uma decisão silenciosa

A RFC 6657 passou a exigir que novos tipos textuais definissem sua política de charset. Em 2014, a RFC 7303 alinhou text/xml a application/xml: escolher o ramo text deixou de decidir a codificação sozinho.

A ordem moderna considera primeiro o BOM; sem ele, um charset MIME explícito; na ausência de ambos, as regras do próprio XML. application/xml permanece recomendado para evitar confusão histórica.

O sufixo +xml também separou sintaxe e finalidade. Um tipo específico pode permitir processamento XML genérico sem esconder o vocabulário da aplicação. Montar uma árvore não prova que o receptor entendeu o documento ou pode agir com segurança.

O registro não comprova execução

O registro atual da IANA aponta application/xml e tipos relacionados para a RFC 7303. Ele comprova coordenação de nomes, não o cabeçalho recebido, os bytes preservados, a decisão do parser ou o significado aceito.

As reality layers de Lu Heng mantêm distintos o tipo registrado, o cabeçalho capturado, os octetos, o BOM, a declaração, a sequência decodificada, a árvore e a ação. Running-code primacy exige observar objeto e software reais. Minimum initial specification permite reconhecer o mérito da RFC 2376: ela abriu uma via interoperável estreita; os sucessores removeram a autoridade escondida num padrão, não a coordenação.