XML

XMLは、個別の目的に応じたマークアップ言語を定めるための汎用的言語であり、「タグの入れ子」式の構文が拡張性を容易にするとして「extensible」を謳っている。

データ構造としては木構造になるため、巡回があるようなネットワーク構造を直接扱うことはできない（XLinkなどの提案がある）。

XMLの最も重要な目的は、異なる情報システムの間で構造化された文書や構造化されたデータの共有を容易にすることである^[2]。

Webページを記述するマークアップ言語であるHTMLは、XMLと文法がよく似ている。これはどちらもSGMLが元になっているためである。

HTMLが特定目的のための言語であるのに対し、XMLはHTMLのような特定目的のための言語を新たに定めるための仕組みであり、タグを定義する事でXMLベースのマークアップ言語を定義することができる。実際、HTMLと同等の機能をXMLによって定義したXHTMLが開発されている。

XMLで文書の論理的構造を規定する制約を追加することによって、XMLを適用したマークアップ言語を実装できる。XMLを適用したマークアップ言語は非常に多く存在している （#XMLの応用の節を参照）。例えば、Extensible HyperText Markup Language (XHTML)^{[注 1]}、DocBook、RSS、Mathematical Markup Language (MathML)、ebXML、Scalable Vector Graphics (SVG)、MusicXML などがある。さらにXMLは、そういった個別のXMLについての構文規則を示すためのスキーマ言語も用意している。スキーマ自体もXMLのXML Schemaの他、XMLではない記法でとても簡潔に大変わかりやすく書ける、Compact Syntaxも用意されているRELAX NGもある。

XMLは、同じく汎用的に使えるマークアップ言語である Standard Generalized Markup Language (SGML) の、簡素化されたサブセットとして、人間にとっても比較的判読しやすいように設計された （#歴史を参照）。XMLの仕様は、XMLワーキンググループなどにより設計が行われ、World Wide Web Consortium (W3C) により勧告 （策定） されている。XMLは無償で使えるオープン標準の技術である。XML仕様のW3C勧告ではXMLの文法とXMLプロセサ （XMLパーサ、XML文書の構文解析器） のための要件を定めている。1998年2月に XML 1.0 が勧告され、2004年2月に XML 1.1 が勧告された（#バージョン参照）。

XML文書の正当性の水準には、整形式XML文書と妥当なXML文書の、2つの水準がある （#整形式XML文書と妥当なXML文書を参照）。XML文書のマークアップ規則に従って記述されていることだけが問題とされる文脈で、スキーマ言語を使わずに、XML文書のマークアップ規則に従って記述された文書を、「整形式XML文書」 (well-formed XML document) という （#XMLの構文と整形式XML文書を参照）。さらに、XML文書をより厳密に構造化した文書やデータとして扱いたい場合は、XML文書の構造をスキーマ言語によって定義することができ、XMLプロセサでそのXML文書（XMLインスタンス）に対してその文書構造に従っていることを検証する（妥当性検証を行う）というように、XML技術を使うこともできる （#XML文書の論理的構造と妥当なXML文書を参照）。 XML文書に対して妥当性検証を行うことにより、従来アプリケーションソフトウェアで行ってきた、XML文書の構造の検査や、XML文書に含まれるデータに対するデータ型のチェックや値の範囲のチェックが、可能となる。スキーマ言語としては Document Type Definition (DTD、文書型定義)、W3C XML Schema、RELAX NG （文書スキーマ定義言語: DSDL）などがある。XML文書の構造がスキーマ言語によって定義され、XML文書の妥当性を検証するソフトウェアによって妥当性が検証されたXML文書のことを「妥当なXML文書」 (valid XML document) という。整形式XML文書は、妥当なXML文書である場合と、妥当なXML文書ではない場合とがある。スキーマ言語を採用して妥当性検証を行う方法でXMLを使うこともできるし、スキーマ言語を採用せず妥当性検証を行わないで手軽にXMLを使うこともできる。

XML勧告では、XMLプロセサがサポートすべき文字符号化方式（文字コード）としてUTF-8とUTF-16 (Unicode) を定めているため、英語以外の言語も扱いやすくなっている （#多言語環境で使うを参照）。また、UTF-8とUTF-16以外の文字コード（UCS-4、EUC-JP、Shift_JIS、EBCDICなど）を用いることも可能である^{[注 2]}。

XMLだけでは最低限の書式しか決められていないため、XMLの力を引き出す各種の関連技術が別途標準化されている （#XMLの拡張および#XML文書をプログラムで処理する、#XML文書を視覚的に表示する、#XML情報集合を参照）。 以下に挙げるものをはじめとして、現在も多くの関連技術の標準化作業が行われている。

• プログラムからXML文書を処理する方法として、Document Object Model (DOM) や Simple API for XML (SAX) などのアプリケーションプログラミングインタフェース (API) が標準化されている^{[注 3]}。

• XML文書のスタイルを指定する技術（スタイルシート）として Extensible Stylesheet Language (XSL) や Cascading Style Sheets (CSS) などがある。

• XML文書を非テキスト形式（バイナリ）で効率的に表現する方法として、World Wide Web Consortium (W3C) は Efficient XML Interchange (EXI) フォーマットを定義した。

XMLは現在、広く普及している技術であるが、その技術的な有用性などについて、肯定的に評価する人々が多い一方で、批判的に評価する人々も多い （#XMLに対する支持と批判を参照）。

XML文書ではどのUnicodeの文字も （XMLで特別な意味をもつ、開き山括弧 "<" のような文字を除いて）、要素名として、属性名として、コメント内容として、文字データとして、処理命令 （後述） として、直接に使うことができる。このため、漢字とキリル文字を共に含む次の文書も、整形式XML文書である。

<?xml version="1.0" encoding="UTF-8"?>
<俄語>Данные</俄語>

XML文書 （あるいはSGML文書、HTMLウェブページを含む） において、文書型宣言 （DOCTYPE宣言、Document Type Declaration） は、その文書を特定の Document Type Definition(DTD、文書型定義) のスキーマと関連づけることを記述するものである。なお、Document Type Definition (DTD、文書型定義)は、XMLで使うことができるスキーマ言語の一つである。文書型宣言は、その文書が特定のスキーマに準拠していることを宣言する。

XML文書では文書型宣言を記述してもよいし、記述しなくてもよい。DTDをスキーマ言語として妥当性検証を行うことを想定しているのであれば、文書型宣言の記述は必須となるであろう。DTDで妥当性検証を行わない場合でも、後述する実体参照などを文書中で使うのであれば、文書型宣言において文書中で使う実体を宣言することができる。

文書型宣言は、その文書が特定のスキーマに準拠していること （妥当なXML文書であること） を、保証しているわけではない。文書型宣言に記されたスキーマに準拠しているかどうかを判断するには、検証XMLプロセサでその文書を検証する必要がある。

文書型宣言の一般的な構文は次のとおりである。

<!DOCTYPE ルート要素名 [SYSTEM もしくは PUBLIC 公開識別子] 外部サブセット参照 [
 <!-- 随意に内部サブセットを記述する -->
]>

ここで外部サブセットとは、そのXML文書のDTDを構成する （要素の型の宣言、後述する実体の宣言などの） 宣言群のうち、別ファイルに記述された宣言群のことである。また内部サブセットとは、そのXML文書のDTDを構成する宣言群のうち、文書型宣言内に直接記述された宣言群のことである^[3]。

XHTML 1.0 Strict に準拠したXML文書での文書型宣言は、次のとおりである。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XML文書においては、ルート要素がその文書の最初の要素である （例えば、XHTMLではルート要素は html である）。SYSTEM キーワードと PUBLIC キーワードは、その文書型 （文書の構造） の種類を指定する。一般に広く知られていないDTDを使う場合は、SYSTEM キーワードを使う。一般に広く知られているDTDを使う場合 （XHTMLなど） は、PUBLIC キーワードを使う。

• SYSTEM キーワードを使う際は、その後に続けて、その文書が準拠するDTDのファイルのURIを、外部サブセット参照として記述する。
• PUBLIC キーワードを使う際は、その後に続けて、その文書が準拠するDTDの公開識別子 (public identifier) を指定しなければならない （例えば XHTML 1.0 の公開識別子は、"-//W3C//DTD XHTML 1.0 Strict//EN" である）。公開識別子を記述した後に続けて、SYSTEM キーワードを使う場合と同様に、その文書が準拠するDTDのファイルのURIを、外部サブセット参照として記述する。

内部サブセットは必要に応じて記述する。 内部サブセットとして、DTDの一部分もしくはDTDの全体を記述することができる。 なお、内部サブセットとしてDTDの全体を記述する場合は、SYSTEMキーワード・PUBLICキーワード・外部サブセット参照は、いずれも記述しない。

実体参照 (entity reference) は、実体を表現するプレースホルダである。

XMLにおける実体 (entity) とは、SGMLにおける実体と同じように、名前の付けられたデータの本体である。具体的には、ファイルもしくは置換文字列のように、何らかの形でXML文書の一部となるデータを格納しているもののことである^[4]。置換文字列を使う事例としては、次のような場合がある。

• キーボードから簡単には入力できない文字をXML文書中に表現したい場合。
• 決まった単語の並びがXML文書中に何度も出現する場合。

実体参照の構成は、まず最初にアンパサンド ("&") があり、その後に実体の名前が続き、セミコロン (";") で終わる。

XMLには、事前宣言された実体として次の表に示す5つの実体がある。

「AT&T」の名前でアンパサンドを表現するために、事前宣言されたXMLの実体を使う例を示す。

<会社名称>AT&amp;T</会社名称>

事前宣言された実体以外の実体を宣言する必要がある場合、XML文書の Document Type Definition （DTD、文書型定義） の内部で宣言する。

XML文書の内部に定義されたDTDを使って、置換文字列としての実体を宣言して、実体参照を使う例を次に示す。宣言された実体は、一つの文字であっても良いし、テキストの断片であっても良いし、他の実体への参照を含むテキストであっても良い。

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE 例 [
    <!ENTITY copy "©">
    <!ENTITY copyright-notice "Copyright © 2007 平成新報社">
]>
<例>
    &copyright-notice;
</例>

XMLに準拠したブラウザを使うと、先のXML文書は次のように表示される。

     Copyright © 2007 平成新報社

ファイルの実体を参照するXML文書の例を示す。

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE 文章 [
    <!ENTITY tsutsui-yasutaka SYSTEM "another-file.xml">
]>
<文章>
 <文>星新一はSF作家である。</文>
 <文>小松左京はSF作家である。</文>
 &tsutsui-yasutaka;
</文章>

なお、別ファイル another-file.xml には次の内容が記されていることとする。

 <文>筒井康隆はSF作家である。</文>

XMLに準拠したブラウザでこのXML文書を表示すると、次のようになる。

星新一はSF作家である。小松左京はSF作家である。筒井康隆はSF作家である。

文字参照 (character reference) は、文字をXML文書内でコード番号を指定して記述する記法である。文字参照は、実体参照と似ているが、実体参照では名前を使うのに対し、文字参照ではその部分で始めに "#" 文字を記述し続けて数字を記述する。

文字参照で使う数字は、符号化文字集合の国際規格である ISO/IEC 10646 (およびUnicode) のコード番号である。文字参照で使うことができる数字は、十進数であるか "x" を前につけた十六進数である。文字参照は、実体参照とは異なり、事前宣言されているわけでもなく、XML文書のDTD内部で宣言されているわけでもない。文字参照は、簡単には符号化できない文字を表現するために使われることが多い。例えば、欧州のコンピュータ上で作成するXML文書でアラビア語の文字を使う場合などである。「AT&T」の例の内のアンパサンドは、この場合に似ているともいえる。十進数の38と十六進数の26は、共に ISO/IEC 10646 の "&" 文字のコード番号である。つまり「AT&T」はXML文書では次のように記述することができる。

<会社名称>AT&#38;T</会社名称>
<会社名称>AT&#x26;T</会社名称>

処理命令 (processing instruction) は、XML文書の構成要素であり、XML文書を扱うソフトウェアに対する何らかの処理を行う命令を、記述する内容が、処理命令である。

次に処理命令の構文を示す。

<?処理命令ターゲット 処理内容?>

処理命令は ?> の文字列を除き任意の処理内容を記述することができる。処理命令には、処理内容として擬似属性 (pseudo attribute) を記述することがある。擬似属性は、記述のしかたが属性名と属性値のペアに似ている。しかしXMLプロセサは擬似属性を、属性として解釈せず、処理命令の処理内容として解釈する。

擬似属性を使った処理命令の例を次に示す。 これはXML文書にカスケーディングスタイルシート (CSS) と関連づけるという処理命令である。

<?xml-stylesheet type="text/css" href="monobook.css"?>

あるXML文書内に記述された特定の処理命令について、その処理命令をプログラマーが意図したとおりの処理を実行させるためには、そのXML文書を処理するアプリケーションソフトウェア側がその処理命令に対応する必要がある。

XML文書 （およびSGML文書） においてCDATAセクションとは、文字列データのみで構成されておりマークアップされたデータは含まれていないと、XMLプロセサが解釈するようマークされた、要素の内容を構成する文字列データの一部である。CDATAセクションは、文字列データを表現するための単なる代替構文である。 CDATAセクションとして宣言された文字列データと、"<" と "&" を "<" と "&" で表現する通常の構文で記述した文字列データとの間に、意味的な違いはない。

<![CDATA[

]]>

<送信者>星新一</送信者>

<![CDATA[<送信者>星新一</送信者>]]>

<送信者>星新一</送信者>

整形式XML文書は、とりわけ、次に示す規則に適合しなければならない。

• 空要素ではない要素は開始タグと終了タグの両方によって境界が定められる。
• 空要素は空要素タグ （自分自身で開始タグと終了タグの2つの機能を兼ねるタグ） で記述することができる。例えば <私は空です/> のように記述することができる。この例は <私は空です></私は空です> と意味的に同等である。
• 属性値は全てシングルクォート (') かダブルクォート (") のいずれかで括る。シングルクォートで始められた属性値はシングルクォートで終わり、ダブルクォートで始められた属性値はダブルクォートで終わる。
• タグは入れ子の構造をとることができる。ただしタグがオーバーラップしてはならない。ルート要素ではない要素のおのおのは、必ず別の要素に含まれる。
• XML文書は宣言された文字符号化方式 （文字コード） にしたがって記述される。文字符号化方式は、XML文書がHTTPを介して転送される場合に "Content-Type" ヘッダをつけるように暗黙的にXML文書の外部で指定しても良いし、XML文書の内部で文書の先頭のXML宣言内で宣言しても良い。このような宣言がない場合、Unicodeの文字符号化方式が使われていると仮定される。XML文書の最初のバイトをみて、UTF-16のバイト順マークと合致すればUTF-16であると仮定する。合致しない場合はUTF-8であると仮定する。

要素の名前ではアルファベットの大文字と小文字とが区別される。例えば、次の例は整形式である。

<Abc> ... </Abc>

しかし次の例は整形式ではない。

<ABC> ... </abc>

XML文書のスキーマを設計する際に、XMLの要素の名前を注意深く選択すると、そのスキーマに準拠したXML文書のデータの意味を、第三者に伝えるために有効であろう。XMLの要素の名前を注意深く選択することにより、そのスキーマに準拠したXML文書は、人間にとって読みやすいものとなる。

XMLの要素と属性の名前を、体が名を表すように注意深く選択決定することで、人間がXML文書を読む際に、要素と属性の意味を、外部の説明文書を参照することなく、よりよく理解できるようになる利点が生まれる。ただしこのような作業を行うことは、XML文書の冗長性が増えることでもある。

人によっては、XML文書を書く際の労力が増えることを、好まない場合がある。またファイルサイズも大きくなることになる。ただし圧縮技術をXML文書に適用してファイルサイズを小さくすることは可能である。

整形式XML文書を正確に書くためには、ここまで述べたことよりずっと多くの規則にしたがう必要がある。例えば、XML名前空間を使うことや、XMLでの「名前」として使うことができる正確な文字集合を使って、XML文書を書くことなどである。とはいえ、ここまで述べた整形式文書に関する概略を理解しておけば、多くのXML文書を読み理解しあるいは多くのXML文書を書くために必要な基礎は、身についたといえる。

XML文書の正当性を自動的に検査するための方法を説明する。

あるXML文書が、整形式XML文書としての条件のみを満たした文書であるか、それとも妥当なXML文書としての条件をも満たした文書であるかを、判別することは、比較的容易である。というのも、整形式XML文書であるための規則と、XMLの妥当性検証のしくみについては、XML文書を扱うツールの移植性を考慮して設計されているからである。つまりこの設計方針は、XML文書を扱うツールであれば、どのようなXML文書でも扱うことができるということである。

独立したツールを使い、XML文書の正当性を自動的に検査する例を示す。

• XML文書を扱えるウェブブラウザで、例えば Mozilla Firefox や Internet Explorer などで、XML文書をロードする。
• xmlwf のようなツールを使う （XMLプロセサの実装の一つである Expat に通常は同梱されている）。
• 何らかのプログラミング言語を使って文書を構文解析する。例えばプログラミング言語Rubyでは次のようになる。

irb> require "rexml/document"
irb> include REXML
irb> doc = Document.new(File.new("test.xml")).root

XMLのための最も歴史の古いスキーマ言語は Document Type Definition (DTD、文書型定義) である。DTDは、XMLの前身であるSGMLから引き継がれた。DTDは XML 1.0 標準に含められているため、ほとんどあらゆるXMLプロセサがDTDを扱うことができる。しかし2007年現在ではDTDを使うことは限定的な範囲にとどまっているようである。その理由は次のとおりである。

• DTDではXMLで新しく開発された機能を使うことができない。特にXML名前空間を扱えないことが厳しい。
• DTDは表現力が乏しい。DTDではいくつかの形式的な視点からXML文書を扱うことができない。
• DTDによるスキーマはXMLではない独自の構文で記述する。この構文は、XMLの前身であるSGMLから引き継いでいるという、経緯がある。XML 1.0 の制定当時はDTD以外のスキーマ言語は存在しなかった。

DTDは現在も多くの用途で使われている。その理由は、一定の人々にとってはDTDは他の新しいスキーマ言語よりも読みやすく書きやすいと考えられているからである。

いくつかのスキーマ言語では、特定のXML文書の構造を記述する能力に加えて、個々のXML文書をその特定のXML文書構造に適合するように変換する機能も、限定的ながら備えている。

DTDとXML Schemaはこの変換機能を備えている。 DTDと XML Schema では、XML文書に属性の既定値を与えることができる。RELAX NGとスキマトロンは、意図的にこの機能を外している。 例えば、XML情報集合を正確に扱うことが、RELAX NGとスキマトロンの仕様策定時に変換機能を外した理由の一つである。

XML文書はさまざまなMIMEタイプで配布することができる。RFC 3023 は、"application/xml" および "text/xml" のMIMEタイプを定義する。 "application/xml" と "text/xml" のMIMEタイプは、そのデータがXML文書の形式をとっているということのみを述べているだけであり、そのXML文書の論理的構造については何も述べていない。 "text/xml" を使うことに対しては、符号化に関する問題が生じる可能性があるとの批判があり、現在では非推奨とされている^[7]。RFC 3023 では、加えて、XML文書を "application/" で始まり、"+xml" で終わるMIMEタイプで配布することを勧めている。例えば、AtomのXMLデータに対しては、"application/atom+xml" のMIMEタイプで配布するのである。

XML名前空間 (Namespaces in XML) は、一つXML文書内で、異なる複数のボキャブラリ（スキーマ）に由来する要素と属性を、名前の衝突を発生させることなく、含めることができるようにするための仕様である。World Wide Web Consortium (W3C) から、1999年1月14日に Namespaces in XML 1.0 が勧告された。XML文書に異なる複数のボキャブラリに由来する要素と属性を含める場合、ボキャブラリのそれぞれに名前空間をわりあてることにより、要素名の衝突と属性名の衝突の問題を、解決することができる。

一つの名前空間において定義された要素の名前は、一意でなければならない。

顧客への参照と注文された商品への参照を含む簡単なXML文書の例を考える。顧客要素と商品要素は、ともに「識別番号」という名前の子要素をもつことがあるだろう。識別番号要素への参照は、顧客要素の子要素の識別番号要素も商品要素の子要素の識別番号要素も同じ要素名をもつので、あいまいである。しかし2つのボキャブラリを区別する2つの名前空間のもとで識別番号要素を使う場合、顧客要素の子要素の識別番号要素と商品要素の子要素の識別番号要素は意味的に明確に異なる2種類の要素となる。

xmlns="http://www.w3.org/1999/xhtml"

xmlns:xhtml="http://www.w3.org/1999/xhtml"

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns="http://www.w3.org/1999/xhtml">
 <xsl:template match="/社員名簿">
  <html>
   <head>
    <title>XML文書をXHTML文書に変換する例</title>
   </head>
   <body>
    <h1>社員名簿</h1>
    <ul> 
     <xsl:apply-templates select="社員">
      <xsl:sort select="姓"/>
     </xsl:apply-templates>
    </ul>
   </body>
  </html>        
 </xsl:template>
 <xsl:template match="社員">
  <li>
   <xsl:value-of select="姓"/> <xsl:value-of select="名"/>
  </li>        
 </xsl:template>
</xsl:stylesheet>

Simple API for XML (SAX) は、字句解析を行いイベント駆動で処理を行う API である。SAXを使うとXML文書は文書の最初から順次読み込まれ、その内容はプログラマが実装したハンドラオブジェクトの様々なメソッドへのコールバックとして報告される。SAXを使ったXML文書処理は高速であり、少ないコンピュータ資源を効率的に使って非常にサイズの大きいXML文書を処理することが可能である。

SAXを使うことに伴う問題は、XML文書に対してランダムアクセスを行って情報を取り出すことが難しいことである。そのため、SAXを使うに際し、プログラマはXML文書のどの部分が現在処理対象となっているか把握する為の機構を実装しなければならない。

SAXは、処理対象となるXML文書中のある種類の情報がどの部分に出現するかに依らず、常に同じように処理されると保証できる場合に用いるのが望ましい。

Document Object Model (DOM) は、インタフェース指向のAPIであり、XML文書のおのおのの部分を表現する節オブジェクトの集まりからなる木構造であるかのように、XML文書全体に対してナビゲーションを行うことを想定している。DOMでは、XML文書に対してランダムアクセスを行って情報を取り出すことが、簡単にできる。

DOMにおけるXML文書全体に相当する Document オブジェクトは、XML文書をXMLプロセサが処理することにより生成することもできるし、プログラマがプログラミングすることによって生成することもできる。DOMにおける Node (節) のさまざまな型のデータ型は、DOM仕様においては抽象的にインタフェースとして定義されている。Node のデータ型の実装は、プログラミング言語に固有の言語バインディングを提供する。 DOMの実装は、サイズの大きいXML文書を扱う場合はたくさんのメモリを使う。なぜならDOMの実装は、一般的にはXML文書全体からオブジェクトの木構造を構築してメモリにロード（展開）し、その後にDOMを介した処理をできるようにしているからである。

Javaでは、標準ライブラリを構成するいくつかのパッケージでDOMが実装されており、Javaのプログラマは標準ライブラリのDOMを使うことができる。DOMの仕様は、World Wide Web Consortium (W3C) で策定されているため、DOMで中核をなす Node やDocument などのインタフェースや、直列化 (出力) などの機能を提供するためのインタフェースはパッケージ org.w3c.dom.* に収められている。 ^[8]

Extensible Stylesheet Language (XSL) 技術におけるフィルタは、XML文書に対して、視覚的に出力したり印刷出力できるよう変換処理を行うことができる。

XSL Formatting Objects (XSL-FO)

XSL Formatting Objects (XSL-FO) は、World Wide Web Consortium (W3C) が策定した、XMLに準拠した宣言的なページ整形 (組版) 言語である。XSL-FO処理系を使うと、XSL-FO文書を他の非XML形式 (PDFなど) に変換出力することができる。

XSL Transformations (XSLT)

XSL Transformations (XSLT)は、W3Cが策定した、XMLに準拠した宣言的な文書変換言語である。XSLT処理系を使うと、XSLTスタイルシートを指示書として、XML文書として表現されたあるデータの木構造を、別の木構造に変換することができる。変換後の文書として、XML (例えば、XSL-FO文書やXHTML文書など)、HTML、プレーンテキストなどの形式にすることができる。またXSLT処理系によってはこの他の形式に変換できるものもある。

XQuery

XQueryは、W3Cが策定した、XML文書に対する、問い合わせ、構築、変換を行うための、コンピュータ言語 (問い合わせ言語) である。

XML Path Language (XPath)

XML Path Language (XPath) は、W3Cが策定した、XML文書中のデータを取得するための、DOMに似たノードの集まりからなる木構造をデータモデルとするパス式言語である。XSLTおよびXQueryの技術はXPathを使って実現されている。XPathの実装はまた、便利な関数ライブラリを含んでおり使うことができる。

Pull Parsing は、XML文書を、最初から順番に読み込み、Iterator パターン のデザインパターンを使って項目 (item) の一連の流れとして扱う、近年に徐々に普及してきた技法である^[9][10]。 Pull Parsing の技法により、再帰下降パーサを実装することができる。 再帰下降パーサでは、パースを実行するプログラムは、パースの対象となるXML文書の構造と似ている。 そしてパースの中間結果を取得することができる。

パースの中間結果を、パースを実行するメソッド内の局所変数 (ローカル変数) として使うことができる。 あるいは、低水準のメソッドの引数として渡したり、高水準のメソッドへの戻り値として返すことができる。 Pull Parsing の技法を提供する実装としては次のものがある。

• Streaming API for XML (StAX) - Java
• SimpleXML - PHP
• System.Xml.XmlReader - .NET Framework

例えば、JavaのStAXフレームワークでは、本質的な「反復子」 (イテレータ) を作成して使うことができる。

Pull Parsing で作成される「反復子」はXML文書中のさまざまな要素、属性、データを順番に訪れる。 「反復子」を使うプログラムは、処理中に現在の項目 (例えば、要素の開始、要素の終了、テキスト) を調べ、その特性 (例えば、要素の名前、名前空間、属性値、テキスト内容) を調査する。 そして反復子に「次の」項目へ移動するよう指示することもできる。 プログラムは、このようにXML文書を走査するようにして、文書から情報を取り出すことができる。

Pull Parsing の技法の特筆すべき長所は、XML文書をパースするDOMの技法と比べて非常に高速であり、メモリ使用が非常に少ないことである。 もう一つの長所は、再帰下降の手法は、パースを実行するプログラム内で、データを型づけされた変数として保持することに適していることである。 SAXでは、例えば、プログラマが自分で処理中の要素の祖先となる要素群を格納するスタック内に中間データを保持するコードをプログラミングする必要があることが多い。 これに対し、Pull Parsing の技法を使ってXML文書を処理するプログラムは、SAXを使うプログラムよりも、非常に単純で理解し易く保守が容易になることが多い。

XML文書を処理するもう一つのAPIは、XMLデータバインディングであり、XMLデータバインディングを使うと、XML文書を、その文書型に対応した、強く型づけされたプログラミング言語データ構造 (プログラムのソースコード) を、生成することができる。インタフェース指向のDOMとは対照的な手法である。データバインディングの実現例を次に示す。

• Relaxer^[11]
• Java Architecture for XML Binding (JAXB)^[12]

OpenOffice.org、AbiWord、およびAppleのiWorkなどのアプリケーションソフトウェアのネイティブファイルフォーマットは、XMLである。

従前、オフィススイートには各ソフトの特有のバイナリ形式としてデータが保存されていた。しかしながらこれでは互換性が低く、様々な情報をデータベースとして利用するオフィススイートでは不都合が生じていた。 そのため、データの標準化を進めて互換性を高めるため、各オフィススイートはXML形式でデータを出力する機能や、そもそも標準保存形式をXMLベースとするものが増えてきた。

OpenOffice.orgはXMLベースの保存形式を当初より標準としていた（英語版バージョン1.0は2002年5月1日リリース）。また、OpenOffice.orgに限らず、どのオフィススイートでも利用できるOpenDocument形式が国際標準化機構（ISO）によって標準規格として認定されている。

もう一つのオフィススイート用の保存形式である Office Open XML も、ISOにより標準規格として認定されている。

マイクロソフトの Microsoft Office では Microsoft Office XP のバージョンからXML形式への対応を始め、Microsoft Office 2003 で独自の定義の XML Schema がサポートされるに至った。 Microsoft Office 2007 ではデフォルトの保存方式がXMLとなった（Office Open XML）。Microsoft Office 2007 のいくつかの機能では、XMLファイルを利用者が指定したスキーマ (ただしDTDではない) に沿って編集することができるようになっている。 またマイクロソフトは、Microsoft Office 2003 のためのファイルフォーマット互換性キットを公開している。 この互換性キットを使うことにより、以前のバージョンの Microsoft Office で作成された文書をXMLに準拠した新しいフォーマットで保存することができる。

エディタについては現在、多くのXMLエディタが使えるようになっている。

情報集合への追加情報すなわち情報集合に対する改変は、スキーマによる妥当性検証を行う際に、情報集合を改変することをいう。 例えば、情報集合に属性の既定値 (デフォルト値) を追加することなどがある。情報を追加された情報集合は、スキーマ検証後情報集合あるいはPSVI (post-schema-validation infoset) と呼ばれる^[15]。

情報集合への追加情報については、賛否両論がある。 情報集合に情報を追加することに否定的な見解としては、情報集合への追加情報はモジュール性を侵害し相互運用性の面での問題を引き起こす危険があるとする。 なぜなら、同じXML文書を扱う複数のアプリケーションソフトウェアは、受け取る情報が妥当性検証を行うかどうかに依存してしまうからである。 アプリケーションソフトウェアが、妥当性検証を行う場合に受け取る情報と、妥当性検証を行わない場合に受け取る情報が、異なってしまうのである^[16]。

XML Schema は、XML情報集合への追加情報を扱うことができる。 RELAX NGは、情報集合への追加情報を扱わない。 RELAX NG では、情報集合への追加情報に否定的な立場をとっている。

XMLは、ISO標準 Standard Generalized Markup Language (SGML) のサブセットである。 XMLのほとんどはSGMLから変更されずに採り入れられている。 XMLがSGMLから採り入れられている技術的な要素には次のものが含まれる。

• 論理的な構造と物理的な構造を分離する (要素と実体)
• 文法に基づいた妥当性検証 (Document Type Definition (DTD、文書型定義))
• データとメタデータを分離する (要素と属性)
• 混合内容 (mixed content、要素の内容として子要素と文字列データが混在する内容モデル)
• 表現から処理を分離する (処理命令; processing instruction)
• 山括弧の構文

XMLがSGMLから採り入れなかった技術要素としては、SGML宣言がある (XMLでは文書の文字符号化方式としてUTF-8とUTF-16を採用している)。

XMLの他の技術的起源としては、次の3つが挙げられる。

Text Encoding Initiative (TEI)

Text Encoding Initiative (TEI、en:Text Encoding Initiative) は、「転送構文」として使うためのSGMLのプロファイルを定義している。

HyperText Markup Language (HTML)

HyperText Markup Language (HTML) では、文書の文字符号化集合はリソースの文字符号化方式と分離されている。

Extended Reference Concrete Syntax (ERCS)

Extended Reference Concrete Syntax (ERCS) から、XML 1.0 の命名規則が採用された。ERCSは、十六進数の文字参照を導入しており、全てのUnicodeの文字を使うことができるようにするために参照の概念を導入している。

XML仕様の設計に関する議論のなかで開発された革新的な考え方には、次のものが含まれる。

• XML文書の文字符号化方式 (文字コード) の決定のアルゴリズムと、XML宣言における文字符号化方式の指定
• 処理命令のターゲット
• xml:space 属性
• 空要素のタグのための新しい要素終了区切り

2010年1月現在の時点では、XMLには2つのバージョンがある。

XML 1.0

XML 1.0 が最初に策定されたのは1998年2月10日であった。1998年の策定後、数度の改訂 (修正) を経ている。この数度の改訂については新しいバージョン番号は割り当てられていない。現在の時点では、Fifth Edition（第5版）が最新版である。XML 1.0 Fifth Edition は、2008年11月26日にW3Cから公開された。XML 1.0 は、多くの処理系が実装され、現在においても一般的な用途に対しては採用が勧められるとされている。日本ではJIS X 4159:2005としてJIS規格化されている^[23]。

XML 1.1

XML 1.1 が最初に策定されたのは2004年2月4日であり、XML 1.0 Third Edition が公開された日と同じ日であった。現在の時点では、Second Edition (第2版) が最新版である。XML 1.1 Second Edition は、2006年8月16日にW3Cから公開された。XML 1.1 にはいくつかの機能が追加されている。XML 1.1 で追加された機能については議論の対象となっている。XML 1.1 で追加された機能は、XML をいくつかの状況で使い易くすることを目指している^[24]。XML 1.1 で追加された主な機能は次のとおりである。

• EBCDIC プラットフォームで使われている行終端文字を使えるようにする。
• Unicode 2.0 の文字集合に含まれない文字を使えるようにする。

XML 1.1 を実装している XML の処理系は、あまり多くない。XML 1.1 は、XML 1.1 特有の機能を必要とする状況においてのみ、採用を勧められるとされている^[25]。

XML 1.0 と XML 1.1 は、要素名と属性名に使うことができる文字集合において異なっている。XML 1.0 では、 Unicode 2.0 で定義された文字集合のみ要素名および属性名として使うことができる。Unicode 2.0 の文字集合には、世界で使われているほとんどの文字が含まれている。しかし Unicode 2.0 の文字集合には Unicode 2.0 より新しいバージョンで追加された文字は含まれていない。こうした Unicode の新しいバージョンで追加された文字としては、モンゴル語、クメール語 (カンボジア語)、アムハラ語、ビルマ語などの文字が、含まれる。

XML 1.1 においては、ほとんどのUnicode文字をXML文書の文字列データや属性値として使うことができる。また Unicode の現在のバージョンで定義されていない文字でさえ、使うことができる。 XML 1.1 の方式では、いくつかの文字については使うことができないが、その他の全ての文字は使うことができる。 一方で XML 1.0 では、仕様で明示的に規定された文字集合のみを、XML文書の文字列データや属性値として使うことができる。 このため XML 1.0 では、Unicode の新しいバージョンで追加される文字を扱うことはできない。

XML文書の文字列データや属性値について、XML 1.1 では XML 1.0 より多くの制御文字を使うことができる。 しかし「堅牢性」の観点から、XML 1.1 で使えるようになった制御文字の多くは、文字参照としてXML文書内に記述しなければならない。 XML 1.1 で使えるようになった制御文字には、2つの改行コードが含まれる。 この2つの改行コードは、XML 1.1 の処理系では空白記号として扱われる。 制御文字のうちこの空白記号として扱われる制御文字のみが、XML 1.1 で文字参照を使わずに直接にXML文書に記述することができる。

現在、XML 2.0 に関する議論が行われている。 XML-SW (SW は、skunk works スカンクワークスの意味) が、XMLの最初の設計者の一人によって書かれた。 XML-SW には、XML 2.0 はどのようなものかということについての、いくつかの提案を含んでいる。 その内容は次のとおりである。

• Document Type Definition (DTD、文書型定義) をXMLの構文から排除する。
• XML名前空間、XML Base およびXML情報集合 (情報集合) をXML仕様に統合する。

World Wide Web Consortium (W3C) では、XML Binary Characterization (XMLバイナリ表現) のワーキンググループが活動しており、同ワーキンググループでは、XML情報集合をバイナリ形式に符号化するために、ユースケースと特性を調査する予備研究を行っている。 このワーキンググループは、公的な標準を制定することが認可されているわけではない。 XMLは定義上明確にテキストに基づいているため、ITU-TとISOは、それぞれが定めるバイナリインフォメーションセットに対して、混乱を避けるために Fast Infoset の名前を使っている (参照: ITU-T Rec. X.891 | ISO/IEC 24824-1)。

2005年の10月に、Scientigoという小さな企業が、XMLの使用に対して同企業の2つの特許 U.S. Patent 5,842,213 と U.S. Patent 6,393,426 の対象になるという主張を、公的に表明した。 この2つの特許は、「特定の『階層構造ではない』統合されていない中立的な形式での、[データの]モデリングと格納と転送」を対象としている。 特許申請によると、この2つの特許は1997年と1999年に出願された。 Scientigoの最高経営責任者 (CEO) である Doyal Bryant は、この2つの特許を「金銭に換える」という願望を述べたが、同社は「世界を敵にするつもりはない」と言明した。 Bryant は、Scientigoは自社の2つの特許についていくつかの大企業と話し合っていると述べた^[26]。

XMLを使う人々や企業に在籍していない専門家たちは、Scientigoの主張に対して懐疑的で批判的な立場で反応した。 一定の人々は、Scientigoをパテント・トロールであると述べた。 ティム・ブレイは、この2つの特許がXMLを対象とするという主張は「ばかげている」と述べた^[27]。

XMLに関係する多くの先行技術がSGMLを含めて存在している。

• XMLはテキストに基づいた技術である。
• XMLはUnicodeの文字集合を扱える。Unicodeを採用したことにより、どのような自然言語の書き言葉であってもほとんどの情報を通信の対象にできる。
• XMLは汎用的にコンピュータ科学のデータ構造を表現できる。例えば、レコード（構造体）、リスト、木構造などを表現できる。
• XMLの自己文書化という形式は、構造とフィールド名とともに値も記述できる。
• XMLの厳密な構文と構文解析の要件があるため、XMLプロセサ (XMLパーサ) のアルゴリズムは非常に簡潔で効率よく一貫性のあるものとなる。
• XMLは文書データベースおよび文書処理のための技術として、スタンドアロン環境においてもネットワーク環境においても、非常によく活用されている。
• XMLは国際標準に基づいている。
• XMLでは、RELAX NG やスキマトロンのようなスキーマ言語を使うことで妥当性検証を行える。こうした妥当性検証の機構は次のことを容易にする。
  • 有効な単体テスト
  • 有効な防火壁 (ファイアウォール)
  • 有効な受け入れテスト
  • 契約に基づく有効な仕様
  • 有効なソフトウェア構築
• XMLの階層構造は、(全てではないが) ほとんどの種類の文書の表現に向いている。
• XMLはプレーンテキストとして表現される。プレーンテキストは、他のプロプライエタリな文書形式と比べて制限が少ない。
• XMLはプラットフォーム独立である。このため技術の移り変わりによる影響に比較的強い。
• XML文書は、スキーマが変更されても、前方互換性と後方互換性を保持することは、比較的容易である。
• XMLの前身であるSGMLは、1986年から使われつづけている。そのため大量に蓄積された経験やソフトウェアを活用できる。
• 整形式XML文書の要素の断片もまた、整形式のXML文書である。

• XML文書の構文は、同じ情報を表すバイナリ表現と比べて、冗長でサイズが大きい^[29][30]。
• XML文書は冗長であり、記憶装置、転送、処理のコストの面で、効率的な運用に悪い影響を与える可能性がある^{[30][31][注 5]}。
• XML文書の構文は、他の「テキストに基づく」データ転送形式と比べて冗長である^[32][33]。
• XMLはその前身であるSGMLよりも簡素化されたとはいえ、その処理は決して軽くはなく、インターネット上のプロトコルなど速度と軽さが要求される分野では、採用が見送られることがしばしばある^{[注 6]}。
• XMLが表現形式として採用している階層型モデルは、関係モデルやオブジェクト指向グラフと比べると制限が大きい^{[注 7][34]}。
• オーバーラップする (階層構造ではない) 節 (ノード) の関連を表現するには、余分な努力が必要である^[35]。
• XML名前空間を使うことには問題がともなう。名前空間を正しく扱うXMLプロセサを実装することは、難しい作業になる可能性がある^[36]。
• XMLは、「自己文書化」として表現されることが多い。しかしこの表現では、重大なあいまいさがあることを考慮していない^{[37][注 8]}。
• XML文書における内容と属性の区別は、一定の人々にとっては不自然に感じられる。XMLのデータ構造の設計を難しくする要因となっている^[38]。

• スキーマ言語
  • Document Type Definition(DTD、文書型定義)
  • XML Schema
  • Regular Language description for XML (RELAX)
  • TREX
  • 文書スキーマ定義言語 (DSDL: Document Schema Definition Languages)
    • RELAX NG
    • スキマトロン
• スタイルシート
  • Extensible Stylesheet Language (XSL)
    • XSL Formatting Objects (XSL-FO)
    • XSL Transformations (XSLT)
  • Cascading Style Sheets (CSS)
  • Document Style Semantics and Specification Language (DSSSL)
• XML Path Language (XPath)
• XML Linking Language (XLink)
• XQuery
• Jaql

• World Wide Web Consortium (W3C) - 標準化団体の一つ。
• OASIS - 標準化団体の一つ。
• Apache XML - Apacheソフトウェア財団のプロジェクト。
• Apache XML Graphics - Apacheソフトウェア財団のもう一つのプロジェクト。

• Abstract Syntax Notation One (ASN.1) - 電気通信やコンピュータネットワークでのデータ構造の表現・エンコード・転送・デコードを記述する記法
• JavaScript Object Notation (JSON) - JavaScriptにおけるオブジェクトの表記法をベースとした軽量なデータ記述言語
• YAML - 構造化データやオブジェクトを文字列に直列化（シリアライズ）するためのデータ形式
• Broadcast Markup Language - XMLベースのデータ放送向け記述言語