テキスト

XML (標準)

拡張マークアップ言語
略語	テキスト
状態	公開済み、W3C勧告
開始年	1996年; 29年前 （1996年）
初版	1998年2月10日; 26年前 ( 1998-02-10 )
最新バージョン	1.1 (第2版) 2006年9月29日; 18年前 ( 2006-09-29 )
組織	ワールドワイドウェブコンソーシアム(W3C)
編集者	ティム・ブレイ、ジャン・パオリ、マイケル・スペルバーグ・マックイーン、イヴ・マラー、フランソワ・イェルジョ、ジョン・W・コーワン
基本基準	SGML
関連規格	W3C XMLスキーマ
ドメイン	シリアル化

拡張マークアップ言語（XML）は、任意のデータを保存、転送、再構築するためのマークアップ言語およびファイル形式です。 ^[2]人間が読みやすく、機械が読みやすい形式で文書をエンコードするための一連の規則を定義します。ワールドワイドウェブコンソーシアムの1998年のXML 1.0仕様^{[3] [4]}およびその他の関連仕様^[5]（すべて無料のオープンスタンダード）はXMLを定義しています。^[6]

XMLの設計目標は、インターネット全体でのシンプルさ、汎用性、使いやすさを重視しています。^[7] XMLは、さまざまな人間の言語をUnicodeで強力にサポートするテキストデータ形式です。XMLの設計はドキュメントに重点を置いていますが、この言語はWebサービスで使用されるものなど、任意のデータ構造の表現にも広く使用されています。^{[8 ]}

XMLベースの言語の定義を支援するためにいくつかのスキーマシステムが存在し、一方でプログラマーはXMLデータの処理を支援するために多くのアプリケーションプログラミングインターフェース（API）を開発してきました。 ^[10]

XMLの主な目的はシリアル化、つまり任意のデータの保存、転送、再構築です。2つの異なるシステム間で情報を交換するには、ファイル形式について合意する必要があります。XMLはこのプロセスを標準化します。したがって、XMLは情報を表現するための共通語に似ています。^{[11] : 1}

マークアップ言語として、XMLは情報をラベル付けし、分類し、構造的に整理します。^{[11] : 11} XMLタグはデータ構造を表し、メタデータを含みます。タグ内にあるのは、XML標準で指定された方法でエンコードされたデータです。^{[11] : 11}追加のXMLスキーマ（XSD）は、XMLを解釈および検証するために必要なメタデータを定義します。（これは、正規スキーマとも呼ばれます。）^{[11] : 135}基本的なXMLルールに準拠したXMLドキュメントは「整形式」であり、スキーマに準拠したXMLドキュメントは「有効」です。^{[11] : 135}

IETF RFC 7303 (旧 RFC 3023 に代わる) は、 XML メッセージで使用するメディア タイプの構築規則を提供します。 は、 application/xml(text/xmlエイリアス)、application/xml-external-parsed-entity(text/xml-external-parsed-entityエイリアス)、および の3 つのメディア タイプを定義します。これらは、内部セマンティクスapplication/xml-dtdを公開せずに生の XML ファイルを送信するために使用されます。RFC 7303 ではさらに、XML ベースの言語には、たとえばSVGの場合はで終わるメディア タイプを指定することを推奨しています。 +xmlimage/svg+xml

ネットワーク環境でのXMLの使用に関するさらなるガイドラインは、XMLベースの言語の設計と展開の多くの側面を網羅した文書であるRFC 3470（IETF BCP 70とも呼ばれる）に記載されています。^{[10] [9]}

XMLは、インターネット上でのデータ交換に一般的に使用されるようになりました。XML構文を使用する何百ものドキュメント形式が開発されており、^[12] RSS、Atom、Office Open XML、OpenDocument、SVG、COLLADA、XHTMLなどがあります。XMLは、 SOAPやXMPPなどの通信プロトコルの基本言語も提供します。これは、非同期JavaScriptおよびXML（AJAX）プログラミング技術で使用されるメッセージ交換形式の1つです。

Health Level 7、OpenTravel Alliance、FpML、MISMO、National Information Exchange Modelなどの多くの業界データ標準は、XML と XML スキーマ仕様の豊富な機能に基づいています。出版業界では、Darwin Information Typing Architecture がXML 業界データ標準です。XML は、さまざまな出版形式を支えるために広く使用されています。

XMLの応用例の一つは、 IWXXM標準に基づいた運用気象（OPMET）情報の転送である。^[13]

このセクションの資料は、 XML仕様に基づいています。これは、XML に出現するすべての構成要素を網羅したリストではなく、日常の使用で最も頻繁に遭遇する主要な構成要素の概要を示しています。

キャラクター

XML 文書は文字列です。(1.1) XML 文書には、Null を除くすべての有効なUnicode文字を使用できます (ただし、推奨されない文字もあります)。

プロセッサとアプリケーション

プロセッサはマークアップを分析し、構造化された情報をアプリケーションに渡します。仕様では、XML プロセッサが実行しなければならないことと実行してはならないことに関する要件を定めていますが、アプリケーションは仕様の範囲外です。プロセッサ(仕様ではこう呼ばれています) は、口語的にはXMLパーサーと呼ばれることがよくあります。

マークアップとコンテンツ

XML 文書を構成する文字は、マークアップとコンテンツに分けられ、簡単な構文規則を適用することで区別できます。一般に、マークアップを構成する文字列は、文字で始まっ<て で終わる>か、文字で始まっ&て で終わります;。マークアップではない文字列はコンテンツです。ただし、CDATAセクションでは、区切り文字<![CDATA[と は]]>マークアップとして分類され、それらの間のテキストはコンテンツとして分類されます。さらに、最も外側の要素の前後の空白もマークアップとして分類されます。

タグ

タグはで始まり<で終わるマークアップ構造です>。タグには次の 3 つの種類があります。

• 開始タグ、例: <section>;
• 終了タグ、例: </section>;
• 空要素タグ、例: <line-break />。

要素

要素は、開始タグで始まり、対応する終了タグで終わるか、または空要素タグのみで構成される論理的なドキュメント コンポーネントです。開始タグと終了タグの間にある文字は、要素のコンテンツであり、子要素と呼ばれる他の要素を含むマークアップを含むことができます。例としては、 があります<greeting>Hello, world!</greeting>。また、 もあります<line-break />。

属性

属性は、開始タグまたは空要素タグ内に存在する名前と値のペアで構成されるマークアップ構造です。 の例は<img src="madonna.jpg" alt="Madonna" />、属性の名前が「src」と「alt」で、その値はそれぞれ「madonna.jpg」と「Madonna」です。 もう 1 つの例は<step number="3">Connect A to B.</step>、属性の名前が「number」で、その値が「3」です。 XML 属性は 1 つの値しか持てず、各属性は各要素に最大 1 回出現できます。 複数の値のリストが必要な一般的な状況では、リストを XML 自体が定義する形式を超えた形式を使用して整形式の XML 属性^[i]にエンコードする必要があります。 通常、これはカンマまたはセミコロンで区切られたリストですが、個々の値にスペースが含まれていないことがわかっている場合は^[ii] 、スペースで区切られたリストを使用できます。<div class="inner greeting-box">Welcome!</div>の例は、属性「class」に値「inner greeting-box」があり、2 つのCSSクラス名「inner」と「greeting-box」も示しています。

XML宣言

XML ドキュメントは、そのドキュメント自体に関する情報を記述するXML 宣言で始まる場合があります。例は次のとおりです<?xml version="1.0" encoding="UTF-8"?>。

XML ドキュメントは、 Unicodeレパートリーの文字のみで構成されています。特に除外されている少数の制御文字を除き、Unicode で定義されているすべての文字が XML ドキュメントのコンテンツ内に表示される可能性があります。

XML には、ドキュメントを構成する Unicode 文字のエンコードを識別したり、何らかの理由で直接使用できない文字を表現したりする 機能が含まれています。

XML 1.0文書では、以下の範囲のUnicodeコードポイントが有効です。^[14]

• U+0009 (水平タブ)、U+000A (改行)、U+000D (復帰): これらはXML 1.0 で受け入れられる唯一のC0制御です。
• U+0020–U+D7FF、U+E000–U+FFFD: これにより、BMP内の一部の非文字が除外されます(すべてのサロゲート、U+FFFE、および U+FFFF は禁止されています)。
• U+10000～U+10FFFF: 非文字を含む補助プレーン内のすべてのコード ポイントが含まれます。

XML 1.1 では、上記の文字すべてに加えて、U+0001～U+001F の範囲の残りの文字も使用できるように文字セットが拡張されています。^[15]ただし同時に、U+0009 (水平タブ)、U+000A (改行)、U+000D (復帰)、U+0085 (次行) 以外の C0 およびC1制御文字の使用が制限され、エスケープ形式で記述する必要があります (たとえば、U+0001 はまたはそれに相当する文字として記述する必要があります)。C1 文字の場合、この制限は下位互換性の問題であり、一般的なエンコード エラーを検出できるようにするために導入されました。

コード ポイントU+0000 (Null) は、XML 1.1 ドキュメントで許可されない唯一の文字です。

Unicode 文字セットは、さまざまな方法でバイトにエンコードして保存または転送できます。これらの方法は「エンコーディング」と呼ばれます。Unicode 自体は、レパートリー全体をカバーするエンコーディングを定義しています。よく知られているエンコーディングには、 UTF-8 (XML 標準ではBOMなしの使用が推奨されています) やUTF-16などがあります。^{[16] Unicode より前のテキストエンコーディングは、} ASCIIやさまざまなISO/IEC 8859など、数多くあります。これらの文字レパートリーは、いずれの場合も Unicode 文字セットのサブセットです。

XMLでは、Unicodeで定義されたエンコーディングと、Unicodeにも表示される文字を持つ他のエンコーディングを使用できます。XMLには、XMLプロセッサが事前の知識なしに、どのエンコーディングが使用されているかを確実に判断できるメカニズムも用意されています。^[17] UTF-8とUTF-16以外のエンコーディングは、すべてのXMLパーサーで認識されるとは限りません（標準ではUTF-16も認識するように義務付けられているにもかかわらず、場合によってはUTF-16さえも認識されないことがあります）。

XML には、直接含めることが困難な文字を含めるためのエスケープ機能が用意されています。例:

• 「<」と「&」の文字は重要な構文マーカーであり、CDATAセクション外のコンテンツには決して現れません。XMLエンティティ値で「<」を使用することは許可されていますが、推奨されません。^[18]
• 一部の文字エンコーディングは、Unicode のサブセットのみをサポートします。たとえば、XML ドキュメントを ASCII でエンコードすることは可能ですが、ASCII には「é」などの Unicode 文字のコード ポイントがありません。
• 著者のマシンでは文字を入力できない可能性があります。
• 一部の文字には、改行禁止スペース( )「 」とスペース( )「 」、キリル文字の大文字 A ( )「А」とラテン文字の大文字 A ( )「A」など、他の文字と視覚的に区別できないグリフがあります。  АA

定義済みのエンティティは5 つあります。

• <「<」を表します。
• >">" を表します。
• &「&」を表します。
• '「'」を表します。
• "' " ' を表します。

許可されているすべての Unicode 文字は、数値文字参照で表すことができます。Unicode での数値コードは 16 進数で 4E2D、10 進数で 20,013 である中国語の文字「中」を考えてみましょう。キーボードにこの文字を入力する方法がないユーザーでも、 または としてエンコードされた XML 文書にこの文字を挿入できます中。中同様に、文字列「I <3 Jörg」は、 としてエンコードされ、XML 文書に含めることができますI <3 Jörg。

�数値文字参照を使用する場合でも、ヌル文字はXMLから除外される制御文字の1つであるため、許可されません。 ^{[19]このような文字を表すには、} Base64などの代替エンコードメカニズムが必要です。

コメントは、他のマークアップ以外の文書内のどこにでも記述できます。コメントは、XML宣言の前に記述することはできません。コメントは で始まり<!--、 で終わります。SGML-->との互換性のため、コメント内では文字列 "--" (二重ハイフン) は使用できません。^[20]これは、コメントをネストできないことを意味します。コメント内ではアンパサンドには特別な意味がないため、エンティティ参照と文字参照はそのようなものとして認識されず、文書エンコーディングの文字セット外の文字を表す方法はありません。

有効なコメントの例: <!--no need to escape <code> & such in comments-->

この例にはアルメニア語のテキストが含まれています。適切なレンダリング サポートがない場合、アルメニア語の文字の代わりに疑問符、ボックス、またはその他の記号が表示されることがあります。

XML 1.0 (第 5 版) および XML 1.1 では、要素名、属性、コメント、文字データ、および処理命令でほぼすべてのUnicode文字を直接使用できます (小なり記号 "<" など、XML 自体で特別な記号の意味を持つ文字は除きます)。以下は、中国語、アルメニア語、およびキリル文字を含む整形式の XML ドキュメントです。

<?xml version="1.0" encoding="UTF-8"?> 
<俄语ଥথւ = " ༸ւཥր᥶" > данные </俄语> 

XML 仕様では、XML ドキュメントは整形式のテキストとして定義されています。つまり、仕様で規定されている構文規則のリストを満たすテキストです。かなり長いリストの重要なポイントは次のとおりです。

• ドキュメントには、適切にエンコードされた有効な Unicode 文字のみが含まれています。
• や などの特殊な構文文字は<、&マークアップの描写の役割を果たすとき以外は表示されません。
• 要素を区切る開始タグ、終了タグ、および空要素タグは、欠落したり重複したりすることなく、正しくネストされています。
• タグ名は大文字と小文字が区別され、開始タグと終了タグは完全に一致する必要があります。
• タグ名には、文字!"#$%&'()*+,/;<=>?@[\]^`{|}~やスペース文字を含めることはできず、また「-」、「.」、または数字で始まることもできません。
• 単一のルート要素には他のすべての要素が含まれます。

XML 文書の定義では、整形式規則に違反するテキストは除外されています。つまり、そのようなテキストは XML ではないということです。このような違反に遭遇した XML プロセッサは、そのようなエラーを報告し、通常の処理を停止する必要があります。このポリシーは、時には「厳格なエラー処理」とも呼ばれ、深刻なマークアップ エラーがあっても妥当な結果を生成するように設計されたHTML を処理するプログラムの動作とは対照的です。 ^{[21]この分野における XML のポリシーは}、ポステルの法則(「送信するものは保守的、受信するものは寛大」)に違反していると批判されています。^[22]

XML仕様では、有効なXML文書を、文書型定義（DTD）の規則にも準拠した整形式のXML文書として定義しています。^{[23] [24]}

XML ドキュメントは、整形式であることに加えて、有効である場合もあります。つまり、ドキュメントに文書型定義(DTD) への参照が含まれており、その要素と属性がその DTD で宣言され、DTD で指定されている文法規則に従っているということです。

XML プロセッサは、XML ドキュメントの妥当性をチェックするかどうかによって、妥当性検証型と非妥当性検証型に分類されます。妥当性エラーを発見したプロセッサは、それを報告できる必要がありますが、通常の処理を続行できます。

DTD はスキーマまたは文法の一例です。XML 1.0 が最初に公開されて以来、XML のスキーマ言語の分野では多大な作業が行われてきました。このようなスキーマ言語は通常、文書で使用できる要素のセット、それらに適用できる属性、それらの出現順序、および許容される親子関係を制約します。

XML の最も古いスキーマ言語は、SGML から継承されたドキュメント型定義(DTD) です。

DTD には次のような利点があります。

• DTD のサポートは、XML 1.0 標準に含まれているため、広く普及しています。
• DTD は要素ベースのスキーマ言語に比べて簡潔であり、結果として 1 つの画面に多くの情報が表示されます。
• DTD を使用すると、文字を公開するための標準的なパブリック エンティティ セットを宣言できます。
• DTD は、名前空間で使用されるタイプではなくドキュメント タイプを定義するため、ドキュメントのすべての制約が 1 つのコレクションにグループ化されます。

DTD には次の制限があります。

• XML の新しい機能、最も重要な名前空間は明示的にサポートされていません。
• 表現力が不足しています。XML DTD は SGML DTD よりも単純で、通常の文法では表現できない特定の構造があります。DTD は基本的なデータ型のみをサポートします。
• 読みやすさに欠けます。DTD 設計者は通常、パラメータ エンティティ (基本的にはテキストマクロとして動作します) を多用します。これにより、複雑な文法の定義が容易になりますが、明瞭さが犠牲になります。
• これらは、 SGMLから継承された正規表現構文に基づく構文を使用してスキーマを記述します。SAX などの一般的な XML API は、構文の構造化された表現をアプリケーションに提供しようとしないため、要素ベースの構文よりもプログラマーにとってアクセスしにくい場合があります。

DTD を他のスキーマ タイプと区別する 2 つの独特な機能は、XML ドキュメント内に DTD を埋め込むための構文サポートと、エンティティを定義することです。エンティティとは、文字エスケープのように、XML プロセッサが DTD 自体と XML ドキュメント内の参照される場所に挿入する任意のテキストまたはマークアップのフラグメントです。

DTD テクノロジは広く普及しているため、今でも多くのアプリケーションで使用されています。

W3C によって DTD の後継として説明されている新しいスキーマ言語は、XML スキーマです。これは、XML スキーマ インスタンスの頭文字である XSD (XML スキーマ定義)でよく呼ばれます。XSD は、XML 言語の記述において DTD よりもはるかに強力です。XSD は、豊富なデータ型システムを使用し、XML ドキュメントの論理構造に対してより詳細な制約を可能にします。また、XSD は XML ベースの形式を使用するため、通常の XML ツールを使用して処理できます。

スキーマを定義する xs:schema 要素:

<?xml version="1.0" encoding="UTF-8" ?> 
<xs:schema xmlns:xs= "http://www.w3.org/2001/XMLSchema" ></xs:schema> 

RELAX NG (Regular Language for XML Next Generation) は、当初OASISによって仕様が定められ、現在は標準となっています (パート 2: ISO/IEC 19757 – DSDLの正規文法ベースの検証)。RELAX NG スキーマは、XML ベースの構文でも、よりコンパクトな非 XML 構文でも記述できます。この 2 つの構文は同型であり、 James Clarkの変換ツールである Trang を使用すると、情報を失わずに変換できます。RELAX NG は、XML スキーマよりも定義と検証のフレームワークが簡単なので、使用と実装が簡単です。また、データ型フレームワークプラグインを使用することもできます。たとえば、RELAX NG スキーマ作成者は、XML ドキュメント内の値が XML スキーマ データ型の定義に準拠することを要求できます。

Schematron は、XML ドキュメント内のパターンの有無をアサーションするための言語です。通常はXPath式を使用します。Schematron は現在、標準となっています (パート 3: ISO/IEC 19757 – DSDLのルールベースの検証)。

DSDL (ドキュメント スキーマ定義言語) は、複数のパートから成る ISO/IEC 標準 (ISO/IEC 19757) であり、それぞれが特定の問題を対象とした一連の小さなスキーマ言語をまとめたものです。DSDL には、RELAX NG の完全構文とコンパクト構文、Schematronアサーション言語、およびデータ型、文字レパートリー制約、名前の変更とエンティティ拡張、および異なる検証者へのドキュメント フラグメントの名前空間ベースのルーティングを定義する言語が含まれます。DSDL スキーマ言語は、まだ XML スキーマのベンダー サポートを受けていません。これは、出版における XML スキーマの有用性の欠如に対する、業界の出版社の草の根的な反応であると言えます。

一部のスキーマ言語は、特定の XML 形式の構造を記述するだけでなく、この形式に準拠する個々の XML ファイルの処理に影響を与える限定的な機能も提供します。DTD と XSD はどちらもこの機能を備えており、たとえば、情報セット拡張機能や属性のデフォルトを提供できます。RELAX NG と Schematron は意図的にこれらを提供していません。

XML 1.0 の最初の公開後すぐに、XML に密接に関連する一連の仕様が開発されました。多くの場合、「XML」という用語は、XML コアの一部と見なされるようになった他の 1 つ以上のテクノロジとともに XML を指すために使用されます。

• XML 名前空間を使用すると、名前の衝突が発生することなく、同じドキュメントに異なる語彙から取得した XML 要素と属性を含めることができます。XML 名前空間は XML 仕様自体の一部ではありませんが、事実上すべての XML ソフトウェアは XML 名前空間もサポートしています。
• XML ベースは、xml:base単一の XML 要素の範囲内で相対 URI 参照を解決するためのベースを設定するために使用できる属性を定義します。
• XML 情報セットまたは XML Infoset は、情報項目の観点から見た XML ドキュメントの抽象データ モデルです。Infoset は、XML 言語の仕様でよく使用され、これらの言語で許可される XML 構造の制約を記述するのに便利です。
• XSL (Extensible Stylesheet Language) は、XML ドキュメントを変換およびレンダリングするために使用される言語ファミリであり、次の 3 つの部分に分かれています。
• XSLT (XSL 変換) は、XML ドキュメントを他の XML ドキュメントまたは HTML、プレーン テキスト、XSL-FO などの他の形式に変換するための XML 言語です。XSLT は XPath と非常に密接に結合されており、入力 XML ドキュメントのコンポーネント (主に要素と属性) をアドレス指定するために使用されます。
• XSL-FO (XSL Formatting Objects) は、XML ドキュメントをレンダリングするための XML 言語であり、PDF の生成によく使用されます。
• XPath (XML パス言語) は、XML ドキュメントのコンポーネント (要素、属性など) をアドレス指定するための非 XML 言語です。XPath は、他のコア XML 仕様や、XML エンコードされたデータにアクセスするためのプログラミング ライブラリで広く使用されています。
• XQuery (XML Query) は、XPath と XML スキーマに深く根ざした XML クエリ言語です。XML にアクセスし、操作し、返すメソッドを提供し、主にXML データベースのクエリ言語として考えられています。
• XML 署名は、 XML コンテンツにデジタル署名を作成するための構文と処理規則を定義します。
• XML 暗号化は、 XML コンテンツを暗号化するための構文と処理ルールを定義します。
• XML モデル (パート 11: ISO/IEC 19757のスキーマ関連付け- DSDL ) は、任意の XML ドキュメントを上記のいずれかのスキーマ タイプに関連付ける手段を定義します。

「XML Core」の一部として考案された他のいくつかの仕様（ XInclude、XLink、XPointerなど）は、広く採用されませんでした。

XML の設計目標には、「XML 文書を処理するプログラムを簡単に作成できること」が含まれています。^[7]それにもかかわらず、XML 仕様には、プログラマーがそのような処理をどのように行うかについての情報がほとんど含まれていません。XML Infoset仕様は、XML 文書内の構成要素を参照するための語彙を提供しますが、この情報にアクセスする方法についてのガイダンスは提供していません。XML にアクセスするためのさまざまなAPI が開発され、使用されており、いくつかは標準化されています。

XML 処理用の既存の API は、次のカテゴリに分類される傾向があります。

• SAXやStAXなどのプログラミング言語からアクセス可能なストリーム指向 API 。
• DOMなどのプログラミング言語からアクセス可能なツリートラバーサル API 。
• XML データ バインディングは、XML ドキュメントとプログラミング言語オブジェクト間の自動変換を提供します。
• XSLTやXQueryなどの宣言型変換言語。
• LINQやScalaなどの汎用プログラミング言語への構文拡張。

ストリーム指向の機能では、必要なメモリが少なく、XML ドキュメントの線形トラバーサルに基づく特定のタスクでは、他の代替手段よりも高速でシンプルです。ツリー トラバーサル API とデータ バインディング API は通常、より多くのメモリを必要としますが、プログラマーにとってはより便利であることがよくあります。一部の API には、XPath 式を使用したドキュメント コンポーネントの宣言的な取得が含まれます。

XSLT は、XML ドキュメント変換の宣言的記述用に設計されており、サーバー側パッケージと Web ブラウザーの両方で広く実装されています。XQuery は機能的に XSLT と重複していますが、大規模なXML データベースの検索用に設計されています。

Simple API for XML (SAX) は、ドキュメントがシリアルに読み取られ、その内容がユーザーが設計したハンドラー オブジェクトのさまざまなメソッドへのコールバックとして報告される、語彙ベースのイベント駆動型API です。SA​​X は実装が高速かつ効率的ですが、ドキュメントのどの部分が処理されているかを追跡する負担がアプリケーション作成者に発生する傾向があるため、XML からランダムに情報を抽出するのには使いにくいです。ドキュメント内のどこに出現しても、特定の種類の情報が常に同じように処理される状況に適しています。

プル解析は、イテレータ設計パターンを使用して、文書を順番に読み取られる一連の項目として扱います。これにより、解析を実行するコードの構造が解析対象のXMLの構造を反映し、中間解析結果を解析を実行する関数内でローカル変数として使用およびアクセスしたり、低レベル関数に渡したり（関数パラメータとして）、高レベル関数に返したり（関数戻り値として）できる再帰下降パーサーを記述できます。^{[25]プルパーサーの例には、} PerlのData::Edit::Xml 、Javaプログラミング言語のStAX 、 SmalltalkのXMLPullParser、 PHPのXMLReader 、 PythonのElementTree.iterparse 、RedのSmartXML、 .NET FrameworkのSystem.Xml.XmlReader 、DOMトラバーサルAPI（NodeIteratorおよびTreeWalker）などがあります。

プル パーサーは、XML ドキュメント内のさまざまな要素、属性、およびデータを順番に参照する反復子を作成します。この反復子を使用するコードは、現在の項目をテストし (たとえば、開始タグか終了タグか、またはテキストかを判断する)、その属性 (ローカル名、名前空間、XML 属性の値、テキストの値など) を検査し、反復子を次の項目に移動することもできます。このように、コードはドキュメントをトラバースしながら情報を抽出できます。再帰下降アプローチは、解析を実行するコード内でデータを型付きローカル変数として保持するのに適していますが、たとえば SAX では通常、解析対象の要素の親要素である要素のスタック内で中間データをパーサーが手動で管理する必要があります。プル解析コードは、SAX 解析コードよりも理解しやすく、管理しやすい場合があります。

ドキュメントオブジェクト モデル(DOM) は、ドキュメント全体を、ドキュメントの内容を表すノード オブジェクトのツリーであるかのようにナビゲートできるインターフェイスです。DOM ドキュメントはパーサーによって作成することも、ユーザーが手動で生成することもできます (制限あり)。DOM ノードのデータ型は抽象的です。実装では、独自のプログラミング言語固有のバインディングが提供されます。DOM 実装は、通常、ドキュメント全体をメモリにロードし、アクセスを許可する前にオブジェクトのツリーとして構築する必要があるため、 メモリを大量に消費する傾向があります。

XML データ バインディングは、XML ドキュメントを扱うアプリケーションの開発を簡素化する手法です。DOM パーサーによって作成された汎用オブジェクトを使用するのではなく、XML ドキュメントを厳密に型指定されたオブジェクトの階層にマッピングします。結果として得られるコードは、多くの場合、読みやすく保守しやすく、実行時ではなくコンパイル時に問題を特定するのに役立ちます。XML データ バインディングは、ドキュメント構造がわかっていて、アプリケーションの作成時に固定されているアプリケーションに特に適しています。XML データの厳密に型指定された表現を作成することで、開発者は、オートコンプリート、コード リファクタリング、コード強調表示などの機能を備えた最新の統合開発環境 (IDE) を活用できます。これにより、正確で効率的なコードを簡単に作成でき、エラーやバグのリスクを軽減できます。データ バインディング システムの例としては、Java Architecture for XML Binding (JAXB)、. NET Frameworkの XML シリアル化、^{[26] 、} gSOAPの XML シリアル化などがあります。

XML は他の言語でも第一級のデータ型として登場しています。ECMAScript /JavaScript 言語のECMAScript for XML ( E4X) 拡張では、JavaScript 用に 2 つの特定のオブジェクト (XML と XMLList) が明示的に定義されています。これらのオブジェクトは、XML ドキュメント ノードと XML ノード リストを別個のオブジェクトとしてサポートし、親子関係を指定するドット表記を使用します。^[27] E4X は、 Mozilla 2.5+ ブラウザー (現在は非推奨) と Adob​​e Actionscriptでサポートされていますが、広く採用されていません。同様の表記法が、Microsoft .NET 3.5 以降向けの Microsoft LINQ実装や、 Java VM を使用するScalaでも使用されています。XML 操作用の特別な機能を備えた Linux 風のシェルを提供するオープンソースのxmlshアプリケーションでも、同様に <[ ]> 表記法を使用して XML をデータ型として扱います。 [ 28 ^{] [29]} Facebookは、E4Xと同様の方法でコア構文にXMLを追加するPHP言語とJavaScript言語の拡張機能、それぞれXHPとJSXを作成しました。 rdf:XMLLiteral

XMLはSGML （ISO 8879）のアプリケーションプロファイルです。^[30]

SGML の動的な情報表示の汎用性は、インターネットが台頭する前の 1980 年代後半に、初期のデジタル メディア パブリッシャーによって理解されていました。^{[31] [32]} 1990 年代半ばまでに、SGML の実践者の中には、当時新しいWorld Wide Webの経験を積んだ人もおり、SGML は Web が成長するにつれて直面する可能性のあるいくつかの問題に対する解決策を提供すると考えていました。Dan Connolly は1995 年にスタッフに加わったときに、SGML を W3C の活動リストに追加しました。作業は、 Sun Microsystems のエンジニアJon Bosak が憲章を作成し、協力者を募集した1996 年半ばに開始されました。Bosak は、SGML と Web の両方の経験を持つ人々の小さなコミュニティで広い人脈を持っていました。^[33]

XMLは11人のメンバーからなるワーキンググループによってまとめられ、^[34]約150人のメンバーからなるInterest Groupによってサポートされた。技術的な議論はInterest Groupのメーリングリストで行われ、問題は合意によって解決されるか、合意に至らなかった場合はワーキンググループの多数決によって解決された。設計上の決定とその根拠の記録は、1997年12月4日にMichael Sperberg-McQueenによってまとめられた。 ^[35] James Clarkはワーキンググループの技術リーダーを務め、特に空要素<empty />構文と「XML」という名前に貢献した。検討対象として提案された他の名前には、「MAGMA」（Minimal Architecture for Generalized Markup Applications）、「SLIM」（Structured Language for Internet Markup）、「MGML」（Minimal Generalized Markup Language）などがあった。当初、仕様の共同編集者はTim BrayとMichael Sperberg-McQueenだった。プロジェクトの途中で、BrayはNetscapeとのコンサルタント契約を引き受け、Microsoftから激しい抗議を受けた。ブレイは一時的に編集者を辞任するよう求められた。このためワーキンググループ内で激しい論争が起こり、最終的にはマイクロソフトのジャン・パオリが3人目の共同編集者に任命されることにより解決した。

XMLワーキンググループは、主に電子メールと毎週の電話会議を通じてコミュニケーションをとっていました。主要な設計上の決定は、1996年8月から11月にかけての短期間の集中的な作業で下され、^[36] XML仕様の最初のワーキングドラフトが公開されました。^[37]さらなる設計作業は1997年まで続けられ、1998年2月10日にXML 1.0はW3C勧告となりました。

XML は ISO 標準である SGML のプロファイルであり、XML の大部分は SGML から変更されていません。SGML からは、論理構造と物理構造 (要素とエンティティ) の分離、文法ベースの検証 (DTD) の利用可能性、データとメタデータ (要素と属性) の分離、混合コンテンツ、処理と表現 (処理命令) の分離、およびデフォルトの山括弧構文がもたらされています。SGML 宣言は削除されたため、XML には固定の区切り文字セットがあり、ドキュメントの文字セットとしてUnicodeが採用されています。

XML の技術のその他のソースとしては、SGML のプロファイルを「転送構文」として定義したTEI (Text Encoding Initiative) とHTMLがあります。ISO 関連の中国/日本/韓国文書処理専門家グループの SPREAD (東アジア文書に関する標準化プロジェクト) プロジェクトの ERCS (拡張参照具象構文) プロジェクトは、XML 1.0 の命名規則の基礎となりました。SPREAD では、16 進数値文字参照と参照の概念も導入され、すべての Unicode 文字が使用できるようになりました。ERCS、XML、HTML をより適切にサポートするために、SGML 標準 IS 8879 は 1996 年と 1998 年に WebSGML 適応で改訂されました。

議論中に生まれた、XML に新しいアイデアには、エンコード検出アルゴリズムとエンコード ヘッダー、処理命令ターゲット、xml:space 属性、および空要素タグの新しい終了区切り文字などがありました。妥当性 (スキーマなしでの解析を可能にする) ではなく整形式性の概念は、XML で初めて形式化されましたが、電子ブック テクノロジの「Dynatext」ソフトウェア、^[38]ウォータールー大学の新オックスフォード英語辞典プロジェクトのソフトウェア、東京の Uniscope の RISP LISP SGML テキスト プロセッサ、米国陸軍ミサイル司令部の IADS ハイパーテキスト システム、Mentor Graphics Context、Interleaf および Xerox Publishing System で実装され、成功していました。

最初の XML (XML 1.0) は 1998 年に最初に定義されました。それ以降、新しいバージョン番号が付与されることなく、マイナーな改訂が行われてきましたが、現在は 2008 年 11 月 26 日に公開された第 5 版です。広く実装されており、今でも一般的な使用が推奨されています。

2番目のXML 1.1は、2004年2月4日にXML 1.0第3版と同じ日に最初に公開され、^[39]現在は第2版として2006年8月16日に公開されています。この第2版には、特定のケースでXMLを使いやすくするための機能（一部は議論の余地あり）が含まれています。^{[40]主な変更点は、} EBCDICプラットフォームで使用される行末文字の使用と、Unicode 3.2にないスクリプトと文字の使用を可能にすることです。XML 1.1はあまり広く実装されておらず、特定の機能を必要とするユーザーのみに使用することをお勧めします。^[41]

第 5 版がリリースされる前、XML 1.0 は、要素名や属性名、一意の識別子に使用できる文字の要件が XML 1.1 と異なっていました。XML 1.0 の最初の 4 つの版では、文字はUnicode標準の特定のバージョン (Unicode 2.0 から Unicode 3.2) を使用してのみ列挙されていました。第 5 版では、将来性は高くなりますが冗長性は低減する XML 1.1 のメカニズムが採用されています。XML 1.0 の第 5 版と XML 1.1 のすべての版で採用されているアプローチは、名前で禁止されるのは特定の文字のみで、それ以外は将来の Unicode バージョンで適切な名前文字に対応できるようにするというものです。第 5 版では、XML 名に、バリ文字、チャム文字、フェニキア文字など、Unicode 3.2 以降に Unicode に追加された多くの文字を含めることができます。^[40]

ほぼすべての Unicode コード ポイントは、コード ポイントに対応する文字が現在のバージョンの Unicode で定義されていない場合でも、XML 1.0/1.1 ドキュメントの文字データと属性値で使用できます。文字データと属性値では、XML 1.1 では XML 1.0 よりも多くの制御文字を使用できますが、「堅牢性」のために、XML 1.1 で導入された制御文字のほとんどは数値文字参照として表現する必要があります (XML 1.0 で許可されていた #x7F から #x9F も、XML 1.1 では数値文字参照として表現する必要があります^[40] )。XML 1.1 でサポートされている制御文字の中には、空白文字として扱う必要がある 2 つの改行コードがあり、これらは直接記述できる唯一の制御コードです。

XML 2.0 についての議論はあったが、そのようなプロジェクトに取り組む計画を発表した組織はない。XMLのオリジナルの開発者の 1 人が書いたXML-SW ( skunkworksの略称) ^[42]には、構文から DTD を削除することや、XML 名前空間、XML ベース、XML 情報セットを基本標準に統合することなど、XML 2.0 の外観に関するいくつかの提案が含まれている。

2012年、ジェームズ・クラーク（XMLワーキンググループの技術リーダー）とジョン・コーワン（XML 1.1仕様の編集者）はW3C内にMicroXMLコミュニティグループを結成し、XMLの大幅に縮小されたサブセットの仕様を公開しました。^[43]

World Wide Web Consortium には、XML 情報セットのバイナリ エンコーディングの使用例とプロパティに関する予備調査を行う XML バイナリ特性ワーキング グループもあります。このワーキング グループは、公式の標準を作成する権限を持っていません。XML は定義上テキスト ベースであるため、ITU-T と ISO は混乱を避けるために、独自のバイナリ形式 (ITU-T Rec. X.891 および ISO/IEC 24824-1) にFast Infosetという名前を使用しています。

XMLとその拡張機能は、冗長性、複雑さ、冗長性について常に批判されてきました。^[44]

XML の基本ツリー モデルをプログラミング言語またはデータベースの型システムにマッピングすることは、特に XML がアプリケーション間で高度に構造化されたデータを交換するために使用される場合 (これが XML の主な設計目標ではなかった) は困難です。ただし、XML データ バインディングシステムを使用すると、 DOMまたはSAX を使用して XML 自体の直接表現からデータを取得するのではなく、使用するプログラミング言語でデータのデータ構造を表すオブジェクトからアプリケーションが XML データに直接アクセスできるため、型の安全性が保証されます。これは、ドキュメントの XML スキーマXSDの要素とメモリ内で表されるクラスのメンバーと の間のマッピングを自動的に作成することによって実現されます。

他の批判は、XMLが自己記述型言語であるという主張を反駁しようとするものである^[45]（ただし、XML仕様自体はそのような主張をしていない）。

JSON、YAML、S式は、よりシンプルな代替手段として頻繁に提案されています（データシリアル化形式の比較を参照）^[46]。これらは、ドキュメントではなく、高度に構造化されたデータの表現に重点を置いています。ドキュメントには、高度に構造化されたコンテンツと比較的非構造化されたコンテンツの両方が含まれる場合があります。ただし、W3C標準化のXMLスキーマ仕様は、よりシンプルなシリアル化形式と比較して、より幅広い構造化XSDデータ型を提供し、 XML名前空間を通じてモジュール性と再利用性を提供します。

• AIDX
• XML マークアップ言語のリスト
• XML スキーマの種類の一覧
• 拡張可能なプログラミング
• データシリアル化形式の比較
• バイナリ XML
• EBML
• WBXML
• XML プロトコル

Wikimedia Commons にはXMLに関連するメディアがあります。

Wikibooks には、 Subject:XMLに関する書籍があります。

• 公式ウェブサイト、ワールドワイドウェブコンソーシアム（W3C）
• XML 1.0 仕様
• 拡張参照具象構文の回顧録 2019-11-18 にRick JelliffeによってWayback Machineにアーカイブされました
• XML、Java、そしてWebの未来（1997年）Jon Bosak著
• 公式（W3C）マークアップ検証サービス
• XML FAQ は元々 W3C の XML SIG 向けに Peter Flynn が作成したものです。