拡張マークアップ言語( XML ) は、データの保存、送信、および再構築のためのマークアップ言語およびファイル形式です。XML は、人間が読みやすく機械が読みやすい形式でドキュメントをエンコードするための一連のルールを定義します。1998年のWorld Wide Web Consortiumの XML 1.0 仕様[ 2 ] [ 3 ]およびその他のいくつかの関連仕様[ 4 ] (これらはすべて無料のオープン標準です)が XML を定義しています。[ 5 ]
XML の設計目標は、インターネット全体でのシンプルさ、汎用性、使いやすさを重視しています。[ 6 ]これは、さまざまな人間の言語をUnicodeで強力にサポートするテキスト データ フォーマットです。XML の設計はドキュメントに焦点を当てていますが、この言語は、Web サービスで使用されるものなど、任意のデータ構造を表現するために広く使用されています。[ 7 ] [ 8 ]
XMLベースの言語の定義を支援するスキーマシステムはいくつか存在し、プログラマーはXMLデータの処理を支援するために多くのアプリケーションプログラミングインターフェース(API)を開発してきた。
XMLの主な目的はシリアル化、つまり任意のデータの保存、送信、再構築です。2つの異なるシステムが情報を交換するには、ファイル形式について合意する必要があります。XMLはこのプロセスを標準化します。したがって、XMLは情報を表現するための共通語に似ています。[ 9 ]
XMLはマークアップ言語として、情報をラベル付け、分類し、構造的に整理します。[ 10 ] XMLタグはデータ構造を表し、メタデータを含みます。タグの内側にあるのは、XML標準で規定された方法でエンコードされたデータです。[ 10 ]追加のXMLスキーマ(XSD)は、XMLの解釈と検証に必要なメタデータを定義します。(これは正規スキーマとも呼ばれます。)[ 11 ]基本的なXMLルールに準拠したXMLドキュメントは「整形式」であり、スキーマに準拠したドキュメントは「有効」です。[ 11 ]
IETF RFC 7303 (旧RFC 3023に取って代わるもの) は、 XML メッセージで使用するメディア タイプの構築に関するルールを提供します。この規格では、3 つのメディア タイプapplication/xml(text/xmlはエイリアス)、application/xml-external-parsed-entity(text/xml-external-parsed-entityはエイリアス)、が定義されています。これらは、内部の意味application/xml-dtdを公開せずに生の XML ファイルを送信するために使用されます。RFC 7303 ではさらに、XML ベースの言語には、たとえばSVGの場合のように、で終わるメディア タイプを与えることを推奨しています。+xmlimage/svg+xml
ネットワーク環境での XML の使用に関するさらなるガイドラインは、XML ベースの言語の設計と展開の多くの側面を網羅した文書であるRFC 3470 (IETF BCP 70 としても知られる) に記載されています。 [ 8 ]
XMLはインターネット上でのデータ交換に広く使われるようになりました。RSS 、Atom、Office Open XML、OpenDocument、SVG、COLLADA、XHTMLなど、XML構文を使用した数百ものドキュメント形式が開発されています[ 12 ] 。また、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規格に基づいた運用気象情報の表現である。[ 13 ]
このセクションの内容は、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」である例があります。別の例として、属性名が「number」で、値が「3」である例があります。XML属性は単一の値しか持つことができず、各属性は各要素に最大で1回しか出現できません。複数の値のリストが必要な一般的な状況では、XML自体が定義する形式を超えた何らかの形式で、リストを整形式XML属性[ i ]にエンコードする必要があります。通常、これはカンマまたはセミコロンで区切られたリスト、または個々の値にスペースが含まれていないことがわかっている場合は、スペースで区切られたリストを使用できます[ ii ]。区切り文字としてスペースを使用した例は次のとおりです。この場合、属性「class」は「inner greeting-box」という値を持つと同時に、「inner」と「greeting-box」という 2 つのCSSクラス名も示しています。<step number="3">Connect A to B.</step><div class="inner greeting-box">Welcome!</div><?xml version="1.0" encoding="UTF-8"?>で始まる場合があります。例としては、 があります。XML文書は、 Unicodeに規定された文字のみで構成されます。ごく少数の制御文字を除き、Unicodeで定義されている文字はすべてXML文書の内容に含めることができます。
XMLには、文書を構成するUnicode文字のエンコーディングを識別する機能や、何らかの理由で直接使用できない文字を表現する機能が含まれています。
XML 1.0 文書では、以下の範囲の Unicode コード ポイントが有効です: [ 14 ]
XML 1.1 では、許可される文字のセットが拡張され、上記のすべてに加えて、U+0001–U+001F の範囲の残りの文字が含まれるようになりました。[ 15 ]ただし、同時に、U+0009 (水平タブ)、U+000A (改行)、U+000D (キャリッジリターン)、U+0085 (次の行) 以外のC0 およびC1制御文字の使用は、エスケープ形式で記述する必要があるため制限されています (たとえば、U+0001は またはそれと同等の形式で記述する必要があります)。C1 文字の場合、この制限は後方互換性がありません。これは、一般的なエンコード エラーを検出できるようにするために導入されました。
コードポイントU+0000(ヌル)は、XML 1.1文書で許可されていない唯一の文字です。
Unicode文字セットは、さまざまな方法でバイトにエンコードして保存または送信することができ、これを「エンコーディング」と呼びます。Unicode自体は、文字レパートリー全体を網羅するエンコーディングを定義しています。よく知られているものには、UTF-8(XML標準ではBOMなしでの使用が推奨されています)とUTF-16があります。[ 16 ] ASCIIやさまざまなISO/IEC 8859など、Unicodeより前に存在したテキストエンコーディングは他にも多数あります。それらの文字レパートリーは、いずれの場合もUnicode文字セットのサブセットです。
XML では、Unicode で定義されているエンコーディングと、文字が Unicode にも含まれるその他のエンコーディングのいずれも使用できます。また、XML プロセッサが事前の知識なしに、どのエンコーディングが使用されているかを確実に判断できるメカニズムも提供されています。[ 17 ] UTF-8 および UTF-16 以外のエンコーディングは、すべての XML パーサーで認識されるとは限りません (場合によっては、標準で認識が義務付けられている UTF-16 でさえ認識されないことがあります)。
XMLには、直接含めると問題のある文字を含めるためのエスケープ機能があります。例:
  А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文書は整形式テキストであると定義されています。つまり、仕様で規定されている構文規則を満たす文書です。主なポイントは以下のとおりです。
<やなどの特殊構文文字は、&マークアップの区切りとしての役割を果たす場合を除いては表示されません。!"#$%&'()*+,/;<=>?@[\]^`{|}~XML 文書の定義では、整形式規則に違反するテキストは除外されます。それらは単に XML ではないからです。このような違反に遭遇した XML プロセッサは、そのようなエラーを報告し、通常の処理を停止する必要があります。[ 21 ] [ 22 ]この方針は、「厳格なエラー処理」と呼ばれることもあり、深刻なマークアップエラーがあっても妥当な結果を生成するように設計されているHTML を処理するプログラムの動作とは著しく対照的です。 [ 23 ]この分野における XML の方針は、ポステルの法則(「送信するものには保守的、受け入れるものには寛容であれ」)に違反しているとして批判されています。[ 24 ]
XML仕様では、有効なXML文書は、文書型定義(DTD)の規則にも準拠した整形式のXML文書であると定義されています。 [ 25 ]
XML文書は、形式が整っていることに加えて、有効である必要もあります。有効であるとは、文書型定義(DTD)への参照を含み、その要素と属性がそのDTDで宣言され、DTDで規定されている文法規則に従っていることを意味します。
XMLプロセッサは、 XMLドキュメントの有効性をチェックするかどうかに応じて、検証型または非検証型に分類されます。 [ 26 ]有効性エラーを発見したプロセッサは、それを報告できなければなりませんが、通常の処理を継続することができます。
DTDはスキーマまたは文法の一例です。XML 1.0が最初に公開されて以来、XMLのスキーマ言語の分野では多くの研究が行われてきました。このようなスキーマ言語は通常、文書内で使用できる要素のセット、それらに適用できる属性、要素の出現順序、および許容される親子関係を制約します。
XMLの最も古いスキーマ言語は、SGMLから継承された文書型定義(DTD)である。
DTDには以下の利点があります。
DTDには以下の制限があります。
DTDを他のスキーマタイプと区別する2つの特徴は、XMLドキュメント内にDTDを埋め込むための構文サポートと、エンティティを定義するための機能です。エンティティとは、XMLプロセッサがDTD自体と、参照されているXMLドキュメント内の任意の場所に挿入する、文字エスケープのような任意のテキストまたはマークアップの断片です。
DTD技術は、その普及度の高さから、現在でも多くの用途で利用されている。
W3CがDTDの後継と位置づける新しいスキーマ言語として、XMLスキーマ(XML Schema)があります。これは、XMLスキーマインスタンスの頭文字をとってXSD(XML Schema Definition)と呼ばれることもあります。XSDは、XML言語を記述する上でDTDよりもはるかに強力です。豊富なデータ型システムを採用し、XMLドキュメントの論理構造に対してより詳細な制約を課すことができます。また、XSDはXMLベースのフォーマットを使用するため、通常のXMLツールを使って処理することが可能です。
xs:スキーマを定義するスキーマ要素:
<?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 Schema よりも定義と検証のフレームワークがシンプルなので、使いやすく実装も容易です。また、データ型フレームワークのプラグインを使用する機能も備えています。たとえば、RELAX NG スキーマの作成者は、XML ドキュメントの値が XML Schema データ型の定義に準拠するように要求できます。
Schematronは、XMLドキュメント内のパターンの有無についてアサーションを行うための言語です。通常はXPath式を使用します。Schematronは現在、標準規格(パート3:ISO/IEC 19757のルールベース検証– DSDL )となっています。
DSDL (Document Schema Definition Languages) は、複数のパートからなる 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:base、単一のXML要素の範囲内で相対URI参照の解決の基準を設定するために使用できる属性を定義します。「XMLコア」の一部として考案された他の仕様の中には、 XInclude、XLink、XPointerなど、広く採用されなかったものもある。
XML の設計目標には、「XML 文書を処理するプログラムを簡単に作成できるようにする」というものがあります。[ 6 ]それにもかかわらず、XML 仕様には、プログラマがそのような処理をどのように行うかについての情報はほとんどありません。XML Infoset仕様は、XML 文書内の構造を参照するための語彙を提供しますが、この情報にアクセスする方法についてのガイダンスは提供しません。XML にアクセスするためのさまざまなAPI が開発され、使用されており、その一部は標準化されています。
XML処理のための既存のAPIは、概ね以下のカテゴリに分類されます。
ストリーム指向の機能はメモリ使用量が少なく、XMLドキュメントを線形に走査する特定のタスクにおいては、他の方法よりも高速かつシンプルです。ツリー走査やデータバインディングAPIは通常、より多くのメモリを必要としますが、プログラマにとっては使いやすい場合が多く、XPath式を用いてドキュメントコンポーネントを宣言的に取得できるものもあります。
XSLTはXML文書の変換を宣言的に記述するために設計されており、サーバーサイドパッケージとWebブラウザの両方で広く実装されています。XQueryは機能的にXSLTと重複する部分がありますが、大規模なXMLデータベースの検索をより目的として設計されています。
Simple API for XML (SAX) は、レキシカルなイベント駆動型API であり、ドキュメントを順次読み込み、その内容をユーザーが設計したハンドラーオブジェクトの各種メソッドへのコールバックとして返します。SAXは実装が高速かつ効率的ですが、ドキュメントのどの部分が処理されているかをアプリケーション開発者が常に把握する必要があるため、XML からランダムに情報を抽出する用途には適していません。SAX は、ドキュメント内のどこに出現しても、特定の種類の情報が常に同じ方法で処理されるような状況に最適です。
プル解析では、ドキュメントをイテレータ設計パターンを使用して順番に読み取られる一連の項目として扱います。これにより、解析を実行するコードの構造が解析対象の XML の構造を反映した再帰下降パーサーを記述でき、解析を実行する関数内で中間解析結果をローカル変数として使用およびアクセスしたり、下位レベルの関数に (関数パラメータとして) 渡したり、上位レベルの関数に (関数の戻り値として) 返したりできます。[ 27 ]プルパーサーの例としてはData::Edit::Xml、Perlの、Javaプログラミング言語のStAX 、 Smalltalkの XMLPullParser、 PHPの XMLReader 、Pythonの、 Redの SmartXML 、.NET Frameworkの、DOM トラバーサル API (および) などがあります。ElementTree.iterparseSystem.Xml.XmlReaderNodeIteratorTreeWalker
プルパーサーは、XML ドキュメント内のさまざまな要素、属性、およびデータを順次走査するイテレータを作成します。このイテレータを使用するコードは、現在の項目をテストし(たとえば、開始タグか終了タグか、またはテキストかを判断するため)、その属性(ローカル名、名前空間、XML 属性の値、テキストの値など)を検査し、イテレータを次の項目に移動することもできます。このように、コードはドキュメントを走査しながら情報を抽出できます。再帰下降アプローチは、解析を行うコード内でデータを型付きローカル変数として保持するのに適していますが、たとえば SAX では、解析対象要素の親要素である要素のスタック内に中間データを手動で保持する必要があります。プル解析コードは、SAX 解析コードよりも理解しやすく、保守しやすい場合があります。
ドキュメントオブジェクトモデル(DOM)は、ドキュメントの内容を表すノードオブジェクトのツリーとしてドキュメント全体をナビゲートできるインターフェースです。DOMドキュメントはパーサーによって作成することも、ユーザーが手動で生成することもできます(ただし制限があります)。DOMノードのデータ型は抽象型であり、実装はそれぞれ独自のプログラミング言語固有のバインディングを提供します。DOMの実装は、一般的にドキュメント全体をメモリにロードしてオブジェクトのツリーとして構築してからアクセスする必要があるため、メモリを大量に消費する傾向があります。
XML データ バインディングは、XML ドキュメントを扱う必要のあるアプリケーションの開発を簡素化する手法です。これは、DOM パーサーによって作成される汎用オブジェクトを使用するのではなく、XML ドキュメントを厳密に型付けされたオブジェクトの階層にマッピングします。結果として得られるコードは、多くの場合、読みやすく保守しやすく、実行時ではなくコンパイル時に問題を特定するのに役立ちます。XML データ バインディングは、アプリケーションの作成時にドキュメント構造が既知で固定されているアプリケーションに特に適しています。XML データの厳密に型付けされた表現を作成することで、開発者は、オートコンプリート、コード リファクタリング、コード ハイライトなどの機能を提供する最新の統合開発環境 (IDE) を活用できます。これにより、正しく効率的なコードを簡単に記述でき、エラーやバグのリスクを軽減できます。データ バインディング システムの例としては、Java Architecture for XML Binding (JAXB)、. NET Frameworkの XML シリアル化[ 28 ]、gSOAPの XML シリアル化などがあります。
XML は他の言語で第一級データ型として登場しています。ECMAScript / JavaScript 言語のECMAScript for XML (E4X) 拡張機能は、JavaScript 用に 2 つの特定のオブジェクト (XML と XMLList) を明示的に定義しており、これらは XML ドキュメント ノードと XML ノード リストを別々のオブジェクトとしてサポートし、ドット表記を使用して親子関係を指定します。[ 29 ] E4X はMozilla 2.5 以降のブラウザ (現在は非推奨) と Adobe Actionscriptでサポートされていますが、広く採用されていません。同様の表記は、Microsoft .NET 3.5 以降のMicrosoft のLINQ実装とScala (Java VM を使用) で使用されています。XML 操作のための特別な機能を備えた Linux ライクなシェルを提供するオープンソースの xmlsh アプリケーションも同様に <[ ]> 表記を使用して XML をデータ型として扱います。[ 30 ]リソース記述フレームワークは、ラップされた正規の XMLを保持するデータ型を定義しています。[ 31 ] Facebookは、E4Xと同様の方法でコア構文にXMLを追加するPHPおよびJavaScript言語の拡張機能、すなわちそれぞれXHPおよびJSXを作成しました。rdf:XMLLiteral
XMLはSGML(ISO 8879)のアプリケーションプロファイルです。 [ 32 ]
SGML の動的な情報表示における汎用性は、インターネットの台頭以前の 1980 年代後半に、初期のデジタル メディア出版社によって理解されていました。[ 22 ] [ 33 ] 1990 年代半ばまでに、SGML の実践者の中には、当時新しかったワールド ワイド ウェブで経験を積んだ人もおり、SGML はウェブが成長するにつれて直面するであろういくつかの問題に対する解決策を提供すると考えていました。ダン コノリーは1995 年にスタッフに加わったときに、SGML を W3C の活動リストに追加しました。作業は 1996 年半ばに、サン マイクロシステムズのエンジニアであるジョン ボサックが憲章を作成し、協力者を募集したときに始まりました。ボサックは、SGML とウェブの両方の経験を持つ人々の小さなコミュニティで人脈が広くありました。[ 34 ]
XML は、11 人のメンバーからなるワーキンググループによってコンパイルされ、約 150 人のメンバーからなるインタレスト グループがサポートしました。 [ 35 ]技術的な議論はインタレスト グループのメーリング リストで行われ、問題は合意によって解決され、合意に至らない場合はワーキング グループの多数決によって解決されました。設計上の決定とその根拠の記録は、1997 年 12 月 4 日にMichael Sperberg-McQueenによってコンパイルされました。 [ 36 ] James Clark はワーキング グループのテクニカル リードを務め、特に空要素構文と「XML」という名前に貢献しました。検討のために提案された他の名前には、「MAGMA」(Minimal Architecture for Generalized Markup Applications)、「SLIM」(Structured Language for Internet Markup)、「MGML」(Minimal Generalized Markup Language)などがありました。[ 37 ]仕様の共同編集者は、当初はTim BrayとMichael Sperberg-McQueenでした。プロジェクトの途中で Bray がNetscapeのコンサルタント契約を受け入れたため、Microsoft から激しい抗議を受けました。ブレイは一時的に編集長を辞任するよう求められた。これによりワーキンググループ内で激しい論争が起こり、最終的にはマイクロソフトのジャン・パオリが3人目の共同編集者として任命されることで解決した。[ 38 ]<empty />
XMLワーキンググループは主に電子メールと毎週の電話会議を通じてコミュニケーションを取りました。主要な設計上の決定は、1996年8月から11月にかけての短期間の集中的な作業で達成され、[ 39 ] XML仕様の最初のワーキングドラフトが公開されました。[ 40 ] 1997年を通して設計作業が続けられ、XML 1.0は1998年2月10日にW3C勧告となりました。
XMLはISO規格であるSGMLのプロファイルであり、XMLの大部分はSGMLをそのまま引き継いでいます。SGMLからは、論理構造と物理構造(要素とエンティティ)の分離、文法に基づく検証(DTD)の利用可能性、データとメタデータ(要素と属性)の分離、混合コンテンツ、処理と表現(処理命令)の分離、およびデフォルトの山括弧構文が引き継がれています。SGML宣言は削除されたため、XMLは固定の区切り文字セットを持ち、文書文字セットとしてUnicodeを採用しています。
XMLの技術源としては、転送構文としてSGMLのプロファイルを定義したTEI (Text Encoding Initiative)やHTMLなどがある。ISO関連の中国・日本・韓国文書処理専門家グループのSPREAD(Standardization Project Regarding East Asian Documents)プロジェクトのERCS(Extended Reference Concrete Syntax)プロジェクトは、XML 1.0の命名規則の基礎となった。SPREADはまた、16進数値文字参照と参照の概念を導入し、すべてのUnicode文字を利用できるようにした。ERCS、XML、HTMLをより良くサポートするために、SGML標準IS 8879は1996年と1998年にWebSGML適応版で改訂された。
XML の議論の中で生まれた斬新なアイデアには、エンコード検出アルゴリズムとエンコード ヘッダー、処理命令ターゲット、xml:space 属性、および空要素タグの新しい閉じ区切り文字などがありました。スキーマなしで解析を可能にする妥当性とは対照的に、整形式性の概念は、電子書籍技術「Dynatext」ソフトウェア[ 41 ]、ウォータールー大学新オックスフォード英語辞典プロジェクトのソフトウェア、東京の Uniscope の RISP LISP SGML テキスト プロセッサ、米国陸軍ミサイル司令部 IADS ハイパーテキスト システム、Mentor Graphics Context、Interleaf および Xerox Publishing System で既に成功裏に実装されていましたが、XML で初めて形式化されました。
最初のXML(XML 1.0)は1998年に初めて定義されました。その後、バージョン番号は変更されずに小規模な改訂が繰り返され、現在は2008年11月26日に発行された第5版となっています。広く普及しており、現在でも一般的に使用することが推奨されています。
2番目のXML (XML 1.1)は、XML 1.0第3版と同じ2004年2月4日に最初に公開され[ 42 ]、現在は2006年8月16日に公開された第2版となっています。XML 1.1には、特定のケースでXMLをより使いやすくすることを目的とした機能(一部は議論の余地がある)が含まれています[ 43 ] 。主な変更点は、 EBCDICプラットフォームで使用される行末文字の使用と、Unicode 3.2にないスクリプトと文字の使用を可能にすることです。XML 1.1はあまり広く実装されておらず、その特定の機能を必要とする人にのみ使用が推奨されています[ 44 ]。
XML 1.0 は、第 5 版のリリース以前は、要素名、属性名、および一意の識別子に使用できる文字の要件が XML 1.1 より厳格であった点で XML 1.0 と異なっていました。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 に追加されたバリ文字、チャム文字、フェニキア文字など、多くの文字を含めることができます。[ 43 ]
XML 1.0/1.1 文書の文字データと属性値では、対応する文字が現在の Unicode バージョンで定義されていなくても、ほぼすべての Unicode コード ポイントを使用できます。文字データと属性値では、XML 1.1 は XML 1.0 よりも多くの制御文字の使用を許可していますが、「堅牢性」のために、XML 1.1 で導入されたほとんどの制御文字は数値文字参照として表現する必要があります (XML 1.0 で許可されていた #x7F から #x9F は、XML 1.1 では数値文字参照として表現することが必須となっています[ 43 ] )。XML 1.1 でサポートされている制御文字の中には、空白文字として扱う必要がある 2 つの改行コードがあり、これらは直接書き込むことができる唯一の制御コードです。
XML 2.0 については議論されているが、そのようなプロジェクトに取り組む計画を発表した組織はない。XMLのオリジナル開発者の 1 人が書いたXML-SW (SW はskunkworksの略) [ 45 ]には、構文から DTD を排除することや、 XML 名前空間、XML ベース、XML 情報セットを基本標準に統合することなど、XML 2.0 がどのようなものになるかについての提案がいくつか含まれている。
2012年、James Clark(XMLワーキンググループのテクニカルリード)とJohn Cowan(XML 1.1仕様の編集者)はW3C内にMicroXMLコミュニティグループを設立し、XMLを大幅に縮小したサブセットの仕様であるMicroXMLを公開しました。[ 46 ] MicroXMLは、文書型宣言やCDATAセクションなど、完全なXMLの多くの機能を削除することで、はるかにシンプルなコア構文を提供し、[ 21 ]名前空間の接頭辞と競合する名前を許可しないことで、XML名前空間の有効性を保証します。
テキスト形式のXMLは冗長であるため、XMLをコンパクトに表現するための様々なバイナリ形式が提案されてきました。ASN.1をベースとしたFast Infosetは、2005年にITU-Tによって国際標準として発行され、その後ISOによっても承認されました。AgileDeltaが開発したバイナリXML形式であるEfficient XML Interchange(EXI)は、2011年にW3C勧告として採用され、2014年に第2版が発行されました。
XMLとその拡張機能は、冗長性、複雑さ、重複性について度々批判されてきた。[ 47 ]
XMLの基本的なツリーモデルをプログラミング言語やデータベースの型システムにマッピングすることは、特にXMLがアプリケーション間で高度に構造化されたデータを交換するために使用されている場合(これはXMLの主な設計目標ではなかった)、困難になることがあります。しかし、 XMLデータバインディングシステムを使用すると、アプリケーションは使用するプログラミング言語でデータのデータ構造を表すオブジェクトからXMLデータに直接アクセスできます。これにより、 DOMやSAXを使用してXML自体の直接表現からデータを取得するのではなく、型安全性が確保されます。これは、ドキュメントのXMLスキーマXSDの要素と、メモリに表現されるクラスのメンバーとの間のマッピングを自動的に作成することによって実現されます。
他の批判では、XMLが自己記述言語であるという主張を否定しようとしている[ 48 ](ただし、XML仕様自体はそのような主張はしていない)。
JSON、YAML、S式は、構造化データと比較的非構造化されたコンテンツの両方を含む可能性のあるドキュメントではなく、構造化データの表現に焦点を当てた、よりシンプルな代替手段としてよく提案されています(データシリアル化フォーマットの比較を参照)[ 49 ] 。しかし、W3C標準化されたXMLスキーマ仕様は、よりシンプルなシリアル化フォーマットと比較して、より幅広い構造化XSDデータ型を提供し、XML名前空間を通じてモジュール性と再利用性を提供します。
{{cite journal}}: CS1メンテナンス: DOIは2025年7月現在非アクティブです(リンク){{cite journal}}: CS1メンテナンス: DOIは2025年7月現在非アクティブです(リンク)