Respostas:
A diferença entre text / xml e application / xml é a codificação de caracteres padrão se o parâmetro charset for omitido:
Text / xml e application / xml se comportam de maneira diferente quando o parâmetro charset não é especificado explicitamente. Se o conjunto de caracteres padrão (por exemplo, US-ASCII) para text / xml for inconveniente por algum motivo (por exemplo, servidores web ruins), o application / xml fornecerá uma alternativa (consulte "Parâmetros opcionais" do registro do aplicativo / xml na Seção 3.2).
Para texto / xml :
Em conformidade com [RFC2046], se uma entidade de texto / xml for recebida com o parâmetro charset omitido, os processadores MIME e XML devem DEVE usar o valor de charset padrão "us-ascii" [ASCII]. Nos casos em que a entidade XML MIME é transmitida via HTTP, o valor padrão do conjunto de caracteres ainda é "us-ascii".
Para application / xml :
Se uma entidade application / xml for recebida onde o parâmetro charset for omitido, nenhuma informação será fornecida sobre o charset pelo cabeçalho MIME Content-Type. Processadores XML em conformidade DEVEM seguir os requisitos na seção 4.3.3 do [XML] que abordam diretamente essa contingência. No entanto, processadores MIME que não são XML não devem assumir um conjunto de caracteres padrão se o parâmetro conjunto de caracteres for omitido de uma entidade application / xml.
Portanto, se o parâmetro charset for omitido, a codificação de caracteres de texto / xml será US-ASCII, enquanto que com application / xml, a codificação de caracteres poderá ser especificada no próprio documento.
Agora, uma regra prática na internet é: "Seja rigoroso com a saída, mas seja tolerante com a entrada". Isso significa garantir que você cumpra os padrões o máximo possível ao fornecer dados pela Internet. Mas crie alguns mecanismos para ignorar falhas ou adivinhar ao receber e interpretar dados pela Internet.
Assim, no seu caso, basta escolher um dos dois tipos (eu recomendo application / xml ) e certifique-se de especificar o caractere usado codificação correctamente (eu recomendo usar a respectiva codificação de caracteres padrão para jogar seguro, por isso, em caso de aplicação / xml uso UTF-8 ou UTF-16).
Como regra geral, a aposta mais segura para fazer com que seu documento seja tratado adequadamente por todos os servidores da web, proxies e navegadores de clientes é provavelmente o seguinte:
Em termos da especificação RFC 3023 , que alguns navegadores não conseguem implementar adequadamente, a principal diferença nos tipos de conteúdo está na maneira como os clientes devem tratar a codificação de caracteres, da seguinte maneira:
Para application / xml, application / xml-dtd, application / xml-external-parsed-entity ou qualquer um dos subtipos de application / xml, como application / atom + xml, application / rss + xml ou application / rdf + xml , a codificação de caracteres é determinada nesta ordem:
Para text / xml, text / xml-external-parsed-entity, ou um subtipo como text / foo + xml, o atributo de codificação da declaração XML no documento é ignorado e a codificação de caracteres é:
A maioria dos analisadores não implementa as especificações; eles ignoram o HTTP Context-Type e apenas usam a codificação no documento. Com tantos documentos mal formados por aí, é improvável que isso mude tão cedo.
ambos estão bem.
text / xxx significa que, caso o programa não entenda xxx, faz sentido exibir o arquivo para o usuário como texto sem formatação. application / xxx significa que não faz sentido mostrá-lo.
Observe que esses tipos de conteúdo foram originalmente definidos para anexo de email antes de serem usados posteriormente no mundo da Web.
text / xml é para documentos que seriam significativos para um ser humano se apresentados como texto sem processamento adicional, application / xml é para todo o resto
Toda entidade XML é adequada para uso com o tipo de mídia application / xml sem modificação. Mas isso não explora o fato de que o XML pode ser tratado como texto sem formatação em muitos casos. Os agentes de usuário MIME (e agentes de usuário da web) que não possuem suporte explícito para application / xml o tratarão como application / octet-stream, por exemplo, oferecendo salvá-lo em um arquivo.
Para indicar que uma entidade XML deve ser tratada como texto sem formatação por padrão, use o tipo de mídia text / xml. Isso restringe a codificação usada na entidade XML àquelas compatíveis com os requisitos para os tipos de mídia de texto, conforme descrito em [RFC-2045] e [RFC-2046], por exemplo, UTF-8, mas não UTF-16 (exceto para HTTP).
text/htmljá existe há muito tempo e era um pouco tarde para mudar isso.
Outras respostas aqui abordam a questão geral sobre o que é apropriado Content-Typepara uma resposta XML e concluem (como Qual é a diferença entre text / xml vs application / xml para resposta de serviço da web ) que são text/xmle application/xmlsão permitidos. No entanto, ninguém aborda se há regras específicas para os sitemaps .
Resposta: não há. A especificação do sitemap é https://www.sitemaps.org e, usando as site:pesquisas do Google, você pode confirmar que não contém as palavras ou frases mime , tipo mimético , tipo de conteúdo , aplicativo / xml ou texto / xml em qualquer lugar. Em outras palavras, é totalmente silencioso o tópico sobre o que Content-Typedeve ser usado para veicular mapas de site.
Na ausência de comentários nas especificações do mapa do site que abordem diretamente essa questão, podemos assumir com segurança que as mesmas regras se aplicam ao escolher Content-Typequalquer outro documento XML - ou seja, pode ser um text/xmlou outro application/xml.
text/htmle o tipo XHTML MIME preferidoapplication/xhtml+xml.