The difference between text/xml and application/xml is the default character encoding if the charset parameter is omitted:
Text/xml and application/xml behave differently when the charset
parameter is not explicitly specified. If the default charset (i.e.,
US-ASCII) for text/xml is inconvenient for some reason (e.g., bad web
servers), application/xml provides an alternative (see "Optional
parameters" of application/xml registration in Section 3.2).
For text/xml:
Conformant with [RFC2046], if a text/xml entity is received with
the charset parameter omitted, MIME processors and XML processors
MUST use the default charset value of "us-ascii"[ASCII]. In cases
where the XML MIME entity is transmitted via HTTP, the default
charset value is still "us-ascii".
For application/xml:
If an application/xml entity is received where the charset
parameter is omitted, no information is being provided about the
charset by the MIME Content-Type header. Conforming XML
processors MUST follow the requirements in section 4.3.3 of [XML]
that directly address this contingency. However, MIME processors
that are not XML processors SHOULD NOT assume a default charset if
the charset parameter is omitted from an application/xml entity.
So if the charset parameter is omitted, the character encoding of text/xml is US-ASCII while with application/xml the character encoding can be specified in the document itself.
Now a rule of thumb on the internet is: “Be strict with the output but be tolerant with the input.” That means make sure to meet the standards as much as possible when delivering data over the internet. But build in some mechanisms to overlook faults or to guess when receiving and interpreting data over the internet.
So in your case just pick one of the two types (I recommend application/xml) and make sure to specify the used character encoding properly (I recommend to use the respective default character encoding to play safe, so in case of application/xml use UTF-8 or UTF-16).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…