text/xml

XML MIME 型

[22] XML MIME (type) は、多くの XML 関連仕様で XML として扱われるMIME型です。 text/xmlapplication/xml の他、 +xml で終わるMIME型が該当します。

仕様書

[48] はじめ RFC 2376 で定義されていましたが、改訂され RFC 3023 となりました。 RFC 3023 への改訂は、長らく素案状態で放置されていましたが、 2014年にようやく RFC 7303 となりました。

XML の MIME 型の選択

[65] XML に関係する MIME型は、色々ありすぎます。 どれを使うべきか迷うこともあります。

[108] 特に他の制約がない場合 (例えば特定の Web API仕様書で限定されていたりしない場合) には、次のように決めると良いでしょう。

XML DTD の場合
application/xml-dtd
SVG など、特別な MIME型がある文書の場合
その特別な MIME型 (image/svg+xml) など
それ以外の文書の場合
text/xml

XML MIME 型

[23] XML MIME (type) は、

です >>46

[16] XML型 (XML type) は、次のものです >>15

[17] この両者の定義は同等です。

[33] なお、 RFC 3023 は「XML MIME型」あるいは「XML媒体型」 という用語は規定していません。 その題名こそ「XML Media Types」ではありますが、本文中では「XML Media Types」 という用語が登場せず、附属書で「XML MIME Types」が節題として使われているのみです。

[24] RFC 3023 の「XML Media Types」と題した章では XML MIME実体のためのMIME型として text/xml, application/xml, text/xml-external-parsed-entityapplication/xml-external-parsed-entityapplication/xml-dtd の5つを定義していました >>57

[34] RFC 4287 (Atom 1.0) は「XML media types」を RFC 3023 から引用していますが、 >>33 のような状況なので規定の意味するところが曖昧になっています。

If the value of "type" is an XML media type [RFC3023] or ends with "+xml" or "/xml" (case insensitive)

のような記述がわざわざあるので、これを定義とみなすなら、Web Applications 1.0>>23 の定義よりはやや広いことになります。

[114] ISO/IEC 19757-4:2006 は「XML media type (i.e., application/xml, text/xml, or */*+xml)」と定義ではなく補足説明のような形で「XML media type」 を記述しています。

[35] HTML Standard (旧 Web Applications 1.0HTML5) は「XML MIME Types」を >>23 のように正確に定義しています。

MIME 型 application/xml, text/xml

[64] application/xmltext/xml は、 XML 文書実体MIME型です。

[86] RFC 3023 まではどちらが良いともされていなかったようですが、 RFC 7303 では application/xml を使うべきとされています >>87

[66] 以前から宗教上の理由により application/xml を好む人もいました。

[88] text/*charset 引数が省略された場合の既定値については色々な混乱がありました。 RFC 7303 は従来の定義を破棄して新たな (より現実的な) 規定となっています。これが text/xml を使うべきでない理由 >>87 とされています。

[109] ただしこの text/* に関する混乱とは、 IETF仕様書の理論上の規定が現実の運用と乖離していたことによるものでしたが、 UTF-8 への統一が進んだ現在では、ほとんど IETF のメンツだけの問題となっています。 テキストファイルには text/* を使う方がむしろ適切だとして、 text/xml を好ましいと考える人もいます。


[6] XML を利用したマーク付け言語によっては、 text/xmlapplication/xml のどちらを使うべきか限定していることがあります。

[9] WebDAV における XMLapplication/xml を使うべきであり、 text/xml非推奨です >>8。しかしどちらも対応しなければなりません >>8

[7] oEmbedtext/xml を使うことを要求しています。

[56] OOXML応用に特化した MIME型が無い時は text/xml を使うことを要求しています >>63

[63] ECMA-376 Second Edition, Part 1, 15.2.4

If no explicit MIME type exists for a specific XML format, text/xml shall be used. Consumers who read a value of text/xml should determine the contents by the root namespace of the contents of the part.

*/*+xml 構造化構文接尾辞 (MIME)

[30] 構造化構文接尾辞 xml は、 XML 文書実体を表しています。 すなわち、 +xml で終わる MIME型は、 XML を基にした形式であることを表しています。 この構造化構文接尾辞RFC 3023 で導入され、現在は RFC 7303 >>103 で定義されています。

[95] 例えば XHTMLMIME型application/xhtml+xmlSVGMIME型image/svg+xml です。

[90] XML を基にした形式に新しく MIME型を用意するときは、 +xml で終わる名前とするべきです。 ただし、一般の XML としての処理が何か不都合な場合はこの限りではありません。 >>89

[101] 特に、素片識別子として XPointer Frameworkelement() XPointer scheme を使うのが不適切な場合は、 +xml で終わるべきではありません >>46

[91] 応用は、 +xml で終わる MIME型なら XML文書であるとみなして XML の処理を実行できます >>89

[94] +xml で終わる MIME型の登録について RFC 7303RFC 6838 (MIME型の登録手続き) を参照しています >>89。しかし RFC 6838RFC 3023 (RFC 7303) を参照するだけで、実質的な規定を含んでいません >>93。 本来の意図は不明ですが、 RFC 7303 の記述によると、 IANA 登録時に XML ベースの形式は +xml を使うよう Media Reviewer が注意するべきである、 XML MIME実体を表すMIME型のみが +xml で終わる形で登録して良い、となっています >>89

[11] +xml で終わるMIME型の例:

RFC 3023 を参照しない XML MIME 型

[32] +xml で終わる MIME型は普通 RFC 3023 を引用していますが、 中にはそうでないものもあります。

+xml で終わらない XML の MIME 型

[31] RFC 3023 以前に使われ始めた MIME型や独自に決められたMIME型は、+xml が最後についていません。これらは定義上、「XML MIME型」ではありません。

[98] 更に RFC 7303 は、 XML としての一般的な処理が好ましくない場合は +xml で終わらない MIME型を使うべきであるとしています。

[99] +xml で終わらない XMLMIME型としては次のものが知られています。

[44] >>43 には >>31 も含む XML 文書MIME型の一覧があります。

[77] XHTMLRSS が誤って text/html, text/plain, application/octet-stream のような他のMIME型で送信されることもあります。 MIME Sniffing はそのような誤ったMIME型の一部を訂正するアルゴリズムを規定しています。

[78] 歴史的には text/html を場合によって XML (XHTML) として処理する利用者エージェントも存在しましたが、現在では正しくないと考えられています。 RSS として処理する場合は現在も残っています。

文書実体以外の MIME 型

[76] XML 関連の MIME型としては他に次のものがあります。

引数

[58] text/xml には次の引数があります。

[67] application/xml には次の引数があります。

[68] */*+xml 構造化構文接尾辞共通の引数はありません。

charset 引数

[25] text/xmlapplication/xml を含む多くの XML MIME型charset 引数を定義しており、 RFC 3023/RFC 7303 の規定によるとされています。詳しくは charset の項をご覧ください。

[110] */*+xml MIME型は、一貫性のため、 charset 引数を定義するべきです >>89

[92] UTF-8UTF-16 しか使わないような場合には、 charset 引数は必要ありません >>89

[97] +xml で終わらない XMLMIME型IANA に登録する場合、 charset 引数を定義するべきです >>96。 その定義は RFC 7303 を参照するべきです >>96

[100] 処理モデルはXMLにおける文字コードを参照してください。


[111] RFC 3023 時代には、 MIMEtext/* に関する規定に従い、 charset 引数が省略された場合には US-ASCII と解釈することになっていました。しかしこの MIME の規定はまったく現実に即しておらず、 RFC 3023 の規定も完全に無視されていました。

[112] 現在となっては Web文字コードUTF-8 に収束しており、 charset 引数は指定しなくても問題とはなりません。 (指定しても構いませんが。)

素片識別子

[26] 多くの XML MIME型では素片識別子RFC 3023XPointer の定義によるとされています。詳しくは素片識別子の項をご覧ください。

性質

[12] XML MIME型の性質を表す語として次のものがあります。

関連

[113] SGML MIME型も参照。

歴史

RFC 2376

[50] RFC 2376text/xmlapplication/xml を定義していました。 application/xml はどんな XML実体 (文書実体外部部分集合実体外部解析対象実体外部引数実体) にも使うことができ、 text/xmltext/* の制約を (MIME で使うときは) 受けるとsらえていました >>49

[52] どちらにも charset 引数があり、 省略可能であるものの強く推奨 >>49 されていました。 しかしその値域はなぜか明記されていませんでした。

[53] UTF-8UTF-16 が特に推奨されていますが、 MIME では text/xmlUTF-16 を使えないことになっていました >>49

[55] HTTP から MIME へ変換する場合には、 UTF-16 なら text/xml から application/xml に変更しなければならないとされていました >>49

[54] text/xml における既定値MIME でも HTTP でも us-ascii で、 application/xml では既定値を仮定するべきではないとされていました >>49。 なぜか仮定することを禁止はされていませんでした。

[51] 特定のXML応用MIME型が必要なら RFC 2376 を基にするべきである >>49 とは述べているものの、 そのための特別な仕組みは用意されていませんでした。

RFC 3023

[72] 第2世代である RFC 3023 では、新規に多くの MIME型が追加され、 既存のMIME型の意味も狭く変更されました。

[73] text/xmlapplication/xml文書実体のための MIME型とされ、 文書実体としても外部解析対象実体としても使える場合を除き、 文書実体以外の実体に使うことは禁止されました >>57

[74] 外部部分集合実体外部解析対象実体には新たに text/xml-external-parsed-entityapplication/xml-external-parsed-entityapplication/xml-dtd が追加されました >>57

詳細はそれぞれの項を参照。

[75] 特定のXML応用MIME型が必要なら RFC 3023 を基にするべきとの規定 (>>51) は引き続き存在し、 特に charset 引数RFC 3023 と同じ形で使うことが推奨されていました >>57

[80] 対象がより限定されたのを除けば、 text/xmlapplication/xmlcharset の定義は RFC 2376 とほぼ同様でした。

[82] RFC 3023 は更に、構造化構文接尾辞 +xml を定義していました。 XML ベースの書式の MIME型はこの構造化構文接尾辞を使うべきであること、 XML 以外のMIME型をこの構造化構文接尾辞IANA に登録してはならないこと、 RFC 3023 を参照した形の charset 引数を定義するべきことなどを規定していました。

[83] +xml は最初の構造化構文接尾辞で、 当時は「構造化構文接尾辞」という概念もまだありませんでした。 その後 RFC 6839 によって構造化構文接尾辞が定義された時に、 RFC 3023 に基づき素片識別子の解釈を補って IANA に登録されています >>84

RFC 7303

[104] RFC 7303RFC 3023 の13年ぶりの改訂版です。 改訂作業は比較的早くから行われていましたが、半ば放置された状態で10年以上経過し、 2014年にようやく RFC として出版されました。

[105] この改訂では文字コードの判定方法が、 RFC 3023 当時の RFC に基づく政治的に正しい方法に替えて、 より現実に合わせた形に改められています。

XMLにおける文字コードの項も参照してください。

[106] また素片識別子が実質未定義だった状態から、 XPointer を参照する形に改められています。

素片識別子の項も参照してください。

関連

[79] SGML には text/sgmlapplication/sgml が用意されています。理論上は XML文書SGML文書とみなせるはずですが、 実際には XMLSGMLMIME型で送信されることはなさそうです。

メモ

[59] なんの説明もなしに、「XML 文書 = 拡張子 .xml = MIME text/xml」のように説明している香具師はアホです。

[60] XML 文書一般に使える媒体型は、 text/xml のほかに application/xml があります。そして後者が一般形です。ですから、どちらを使えば良いのかわからない人は application/xml を使うほうが安全です。 (text/xml の方が適切なことはほとんどありません。)

[69] 名前空間のある XML 文書には MIME 媒体型は無力だとかで、 XML 文書はすべからく */*+xml ではなく application/xml を使うべき、みたいな風潮があることに悪寒を感じます。

[70] 確かに名前空間を使うと XHTML と SVG の混ざった文書が作れます。だけど、それは XHTML が主の文書がなくなることも、 SVG が主の文書がなくなることも意味しない。依然 application/xhtml+xmlimage/svg+xml の区別の意義は存在するはずです。どっちとも判断しがたい、文章と図が半々に混在した文書なら、そのときはじめて application/xml の出番でしょう。だってそれは単なる XHTML とも単なる SVG とも違った使われ方を求めているんだから。

[71] 確かに媒体型の仕組みで伝え得る情報は不十分です。 CC/PP とか、他の仕組みも必要なのは事実。だけどそれは媒体型をないがしろにしてもいいことは意味しません。媒体型の支配する世界にいる限りは。

[27] >>1-2 でもまあ、共通の処理モデルが RFC 3023 とかで定義されていない以上、 仕方がない気もするわな。 RFC 3023 って実際実装側にとって有意義なことほとんど書いてないじゃん。

[21] Bug 155730 &#8211; Mozilla doesn't handle files served as */*+xml as XML files (2007-02-10 14:34:20 +09:00 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=155730>

[36] draft-murata-kohn-lilley-xml-03 - XML Media Types ( 版) <http://tools.ietf.org/html/draft-murata-kohn-lilley-xml>

[37] Web Applications 1.0 r6661 Make the */*+xml handling be fallback handling, rather than overriding any registered handlers for specific XML types. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=6660&to=6661>

[38] W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures ( ( 版)) <http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#web-representation>

[39] XBL 2.0 ( ( 版)) <http://dev.w3.org/2006/xbl2/Overview.html#xml-mime-type>

[40] draft-ietf-appsawg-xml-mediatypes-01 - XML Media Types ( ( 版)) <http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-01>

[41] RFC 6839 - Additional Media Type Structured Syntax Suffixes ( ( 版)) <http://tools.ietf.org/html/rfc6839#section-4.1>

[42] XML Binding Language (XBL) 2.0 ( ( 版)) <http://www.w3.org/TR/2007/CR-xbl-20070316/#xml-mime>

[45] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) <http://tools.ietf.org/html/rfc7252#page-93>

[47] Index of /2006/02/son-of-3023 ( 版) <http://www.w3.org/2006/02/son-of-3023/>

[85] Re: [apps-discuss] Last Call: <draft-ietf-appsawg-xml-mediatypes-09.txt> (XML Media Types) to Proposed Standard ( (Paul Grosso 著, 版)) <http://lists.w3.org/Archives/Public/public-xml-core-wg/2014Mar/0003.html>

[107] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( ( 版)) <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1420348_2538929491>

[10] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1420348_2538929491>

Office documents that conform to this specification but are not contained in a package should use the MIME type text/xml.

[13] 155730 – (*/*+xml) Mozilla doesn't handle files served as */*+xml as XML files ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=155730>

[14] RFC 6546 - Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS ( 版) <https://tools.ietf.org/html/rfc6546>

As RID documents are XML,

the RID media type is 'text/xml'; i.e., the 'Content-type' Request

and Response headers MUST be 'text/xml'.

[18] XProc 2.0: An XML Pipeline Language () <https://www.w3.org/TR/2016/NOTE-xproc20-20160721/#introduction>

The media type for pipeline documents is application/xml. Often, pipeline documents are identified by the extension .xpl.

[19] Let [MIMESNIFF] define MIME-related concepts (domenic著, ) <https://github.com/whatwg/html/commit/0d08aea0733e5ad21f15f626b64d413a8c447083>

[20] XPath and XQuery Functions and Operators 3.1 () <https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#func-unparsed-text>

if the media type of the resource is text/xml or application/xml (see [RFC 2376]), or if it matches the conventions text/*+xml or application/*+xml (see [RFC 7303] and/or its successors), then the encoding is recognized as specified in [Extensible Markup Language (XML) 1.0 (Fifth Edition)]

[115] RFC 5689 - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) () <https://tools.ietf.org/html/rfc5689#section-3>

The Content-Type

request header MUST be set appropriately for an XML body (e.g., set

to "text/xml" or "application/xml").

[116] Editorial: use HTML/XML MIME type terms (annevk著, ) <https://github.com/whatwg/xhr/commit/daa0baea431703640e1d35fde8db8cd5050f578b>

[117] Use "XML MIME type" · Issue #160 · whatwg/xhr () <https://github.com/whatwg/xhr/issues/160>

[118] Editorial: use HTML/XML MIME type terms by annevk · Pull Request #171 · whatwg/xhr () <https://github.com/whatwg/xhr/pull/171>

[119] Define a new MIME type model, parser, and serializer (annevk著, ) <https://github.com/whatwg/mimesniff/commit/cc81ec48288944562c4554069da1d74a71e199fb>

[120] Multimodal Architecture and Interfaces () <https://www.w3.org/TR/2012/REC-mmi-arch-20121025/>

The Content-Type header field of the HTTP/POST request has to be set according to the lifecycle event format, e.g. “text/xml”.