Summary

  • RFC 2376 は text/xml と application/xml を登録したが、charset を省略した場合、前者は BOM や XML 宣言に反しても US-ASCII、後者は XML プロセサによる判定となった。
  • 登録名、受信ヘッダー、実際のオクテット、優先順位、アプリケーション上の意味は別の証拠である。RFC 7303 は後に二つの扱いをそろえ、古い暗黙値を取り除いた。

自分を説明する文書にも外枠があった

XML は、異なる機械やソフトウェアの間で構造を運ぶために作られた。文書先頭の encoding 宣言は内部ラベルとして働き、BOM は本文を読む前に重要なバイト表現を見分ける助けとなる。

しかし HTTP、メール、WebDAV を通る XML は単独ではない。MIME 形式の Content-Type が外側に付き、そこにも charset を書ける。受信側には、同じオクテットをどう文字にするかについて複数の主張が届いた。

1998年7月の RFC 2376 は Informational 文書として text/xml と application/xml を導入した。XML を SGML と同じ型で運べば、処理能力やパラメータに曖昧さが残る。専用の共通名を作る判断は必要だった。難所は、複数のラベルの順位である。

表示上の選択が解釈権を変えた

すべての XML エンティティは application/xml にできた。XML を知らないエージェントは、単なるファイルとして扱える。text/xml は既定でプレーンテキストとして見せる意図を示した。

その利便性は MIME の最上位型 text の規則を連れてきた。明示的な charset があれば、RFC 2376 は二つの型のどちらでも外部パラメータを権威とした。内部宣言が常に勝つわけではない。

省略時には差が決定的になる。application/xml では MIME ヘッダーが符号化情報を提供していない。XML 対応プロセサは BOM、冒頭のバイト配列、内部宣言を使えた。XML を知らない MIME エージェントは推測しない。

ところが text/xml では、省略が US-ASCII を意味した。HTTP 上でも同じで、本文が UTF-8 や UTF-16 であり、その旨を内部に明記していても変わらない。欠けた欄は「不明」ではなく、古い既定値を起動する命令だった。

仕様は矛盾を見える形にした

RFC 2376 の例は、UTF-16 の BOM と encoding="utf-16" を持つ本文に、text/xml だけを付けている。それでも規範上の解釈は US-ASCII だった。文書自身を信じると、配送契約には従わないことになる。

同じ手掛かりを application/xml が包めば、BOM から UTF-16 を決められた。BOM がなければ、初期バイトから候補を絞り、内部宣言を読める。一語違う外部型が、証拠の強さを変えた。

保存や変換でも影響は残る。中継装置が本文を変換して外部 charset だけを更新することがある。逆に保存時にヘッダーだけ失うこともある。本文を配送文脈から切り離すと、その本文を解読できた理由まで失われる。

自己記述は自分の順位を決められない

XML 1.0 も、外部情報との競合を内部宣言だけでは解決できないと認めている。優先順位は上位の配送プロトコルが定める。転送途中の変換を文書自身が知れない以上、合理的な分担だった。

同時に、これは統制の問題である。どの層が別の層を覆せるのか。値の欠落は無知なのか、既定値の指定なのか。RFC 2376 は MIME の歴史から答えを借りた。

2001年の RFC 3023 は RFC 2376 を置き換えたが、text/xml の US-ASCII 既定は残した。中継エージェントが変換する現実を踏まえ、外部 charset の理由を詳しく説明した。その後、実装慣行とテキスト型の規則がさらに変わった。

修復は無言の決定を消した

RFC 6657 は、新しい text/* 型が charset の振る舞いを明示するよう求めた。2014年の RFC 7303 は text/xml と application/xml を整合させ、最上位型の選択だけで符号化が変わる仕組みを終わらせた。

現在の順位は、まず BOM、BOM がなければ明示的な MIME charset、双方がなければ XML 自身の規則である。過去の混乱を避けるため、application/xml はなお推奨される。

+xml 接尾辞は別の境界も整えた。用途固有の型は XML 構文であることを汎用ツールへ知らせつつ、文書の目的を名前に残せる。XML として解析できることは、その語彙を理解し、安全に処理できることの証明ではない。

レジストリ行は実行記録ではない

現在の IANA レジストリは application/xml などを RFC 7303 に結び付ける。これは名前の調整を証明するが、個々の応答のヘッダー、オクテット、プロセサの判断、業務上の意味を証明しない。

Lu Heng の reality layers で見れば、登録型、受信ヘッダー、原本オクテット、BOM、内部宣言、復号結果、構文木、アプリケーション動作は別々の受領証だ。running-code primacy は現物と実装の観測を求める。minimum initial specification は RFC 2376 の価値も守る。狭い共通入口は有効だった。後継仕様が退けたのは、調整ではなく既定値に隠れた権力だった。