出典(authority):フリー百科事典『ウィキペディア(Wikipedia)』「2016/03/18 22:27:45」(JST)
拡張子 | .xml |
---|---|
MIME Type | application/xml |
UTI | public.xml |
開発者 | World Wide Web Consortium (W3C) |
初版 | 1998年 |
種別 | マークアップ言語 |
派生元 | Standard Generalized Markup Language (SGML) |
拡張 | XHTML、DocBook、RSS、ebXML、 ... |
国際標準 | 1.0 (Fifth Edition) 1.1 (Second Edition) |
テンプレートを表示 |
Extensible Markup Language(エクステンシブル マークアップ ランゲージ)は、個別の目的に応じたマークアップ言語作成のため、汎用的に使うことができる仕様、および仕様により策定される言語の名称である。一般的にXML(エックスエムエル)と略称で呼ばれる。JISによる訳語は「拡張可能なマーク付け言語」。
SGMLからの移行を目的として開発された。文法はSGMLの構文解析器と互換性を保つようにSGMLのサブセットに定められシンプルになり、機能はSGMLに無いものが追加されている。
XML の仕様は、World Wide Web Consortium (W3C) により策定・勧告されている。1998年2月に XML 1.0 が勧告された。2010年4月現在、XML 1.0 と XML 1.1 の2つのバージョンが勧告されている(#バージョン)。XMLは現在、広く普及している技術である。
ちなみに、「eXtensible Markup Language の略である」と書かれることがあるが、これは間違いであり、XはExの発音を表している[1]。
XMLは、個別の目的に応じたマークアップ言語群を創るために汎用的に使うことができる仕様である。 マークアップ言語とは、コンピュータ言語の一種で、文章の論理的な構造(段落など)や見栄え(フォントサイズなど)に関する指定を、文章とともにテキストファイルに記述するための言語である。 XMLは、拡張可能な言語の一つに分類されるが、その理由は、XMLを使うことで、使用者は自分たち自身で複数のタグを定義することができるからである。 XMLの文脈におけるタグとは、文書の断片に意味を付加するための印である。
XMLの最も重要な目的は、異なる情報システムの間で、特にインターネットを介して、構造化された文書や構造化されたデータの共有を、容易にすることである[2]。 XMLを使うと、文書を構造化して記述することもできるし、コンピュータのデータを直列化 (シリアライズ) することもできる。 データを直列化する用途でXMLを使う際には、XMLは、JavaScript Object Notation (JSON) やYAMLなどの、テキストを基にした他の直列化言語と比較衡量することができる[注 1]。
XMLで文書の論理的構造を規定する制約を追加することによって、XMLを適用したマークアップ言語を実装することができる。 XMLを適用したマークアップ言語は非常に多く存在している (#XMLの応用の節を参照)。 例えば、Extensible HyperText Markup Language (XHTML)[注 2]、DocBook、RSS、Mathematical Markup Language (MathML)、ebXML、Scalable Vector Graphics (SVG)、MusicXML などがある。 さらに、XMLはこのような適用マークアップ言語のための仕様記述言語、すなわちスキーマ言語として使うことができる。 XMLで記述するスキーマ言語としては、RELAX NG、 XML Schema などがある。
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など)を用いることも可能である[注 3]。
XMLだけでは最低限の書式しか決められていないため、XMLの力を引き出す各種の関連技術が別途標準化されている (#XMLの拡張および#XML文書をプログラムで処理する、#XML文書を視覚的に表示する、#XMLインフォメーションセットを参照)。 以下に挙げるものをはじめとして、現在も多くの関連技術の標準化作業が行われている。
XMLは現在、広く普及している技術であるが、その技術的な有用性などについて、肯定的に評価する人々が多い一方で、批判的に評価する人々も多い (#XMLに対する支持と批判を参照)。
XML文書の正当性の水準には、整形式XML文書と妥当なXML文書の、2つの水準がある。 なおXML文書に対して、整形式XML文書としての検査のみを行うXMLプロセサを非検証XMLプロセサといい、整形式XML文書としての検査に加えて妥当なXML文書としての検査を行うXMLプロセサを検証XMLプロセサという。
整形式XML文書が満たすべき構文の規則を説明する。
整形式XML文書としての条件が満たされることのみを考慮する場合 (スキーマ言語を使わずに手軽にXMLを使う場合) においても、XMLは、大量の文書やもしくは木構造として表現することができるデータを格納するための、一般的な枠組みとしての役割を果たすことができる。
XML文書は、要素 (element) と属性 (attribute) が複数集まって、構成されている。 要素は内部に子要素を含むことができる。 属性は要素に付随し、属性の内部に子要素を含むことはできない。 要素は開始タグと終了タグで内容を挟むことで表現する。 開始タグは「<要素名>」、終了タグは「</要素名>」で記述する。
一つの要素を記述するための基本的な構文を次に示す。
<要素名 属性="値">内容</要素名>
ここで、<要素名 属性="値"> をこの要素の開始タグといい、</要素名> を終了タグという。 「内容」は何らかのテキストである。
次に示す例は整形式XML文書である。
<書籍 出版日="2007-10-31">これは書籍です.... </書籍>
この例は、書籍という要素を一つもつXML文書である。 <書籍>
が書籍要素の開始タグであり、</書籍> が書籍要素の終了タグである。 「出版日="2007-10-31"」は書籍要素の属性である。 この属性の名前 (属性名) は「出版日」であり、この属性の値 (属性値) は "2007-10-31" である。 「これは書籍です.... 」は、書籍要素の内容である。
要素の内容を構成するテキストはまた、さらに任意の数の要素を含むことができる (なお、このように一つの要素内に文字列データと子要素が混在するものを、「混合内容」と呼ぶ[注 5])。 すなわち、一般的なXML文書は木構造をなす。 この点において、XMLはプログラミング言語LISPのS式と似ている。 S式でも木構造を記述する。 S式の木構造のおのおのの節は、自分自身のプロパティリストをもつことができる。
要素は内部に別の要素を含むことができる。 構造化したXML文書の例を示す。
<レシピ 名前="パン" 準備時間="5分" 調理時間="3時間">
<料理>基本的なパン</料理>
<材料 量='3' 単位='カップ'>小麦粉</材料>
<材料 量='0.25' 単位='オンス'>イースト</材料>
<材料 量='1.5' 単位='カップ' 状態="温かい">水</材料>
<材料 量="1" 単位="ティースプーン">食塩</材料>
<要領>
<手順>全ての材料を一緒にして混ぜます。</手順>
<手順>十分にこねます。</手順>
<手順>布で覆い、暖かい部屋で1時間そのままにしておきます。</手順>
<手順>もう一度こねます。</手順>
<手順>パン焼きの容器に入れます</手順>
<手順>布で覆い、暖かい部屋で1時間そのままにしておきます。</手順>
<手順>オーブンに入れて温度を180℃にして30分間焼きます。</手順>
</要領>
</レシピ>
要素の属性の値は、必ずシングルクォート (') かダブルクォート (") で括らなければならない。 そして要素内にある属性は、互いに属性名が異なっていなければならない。 XML文書では要素は正しく入れ子になっていなければならない。 要素は決してオーバーラップしていてはならない。
例えば、次の文書は整形式XML文書ではない。 なぜなら 書名
要素と 著者
要素がオーバーラップしているからである。
<!-- 正しくありません! 整形式XML文書ではありません! -->
<書籍目録> <書名>XML入門<著者>筒井<書名>続・XML入門<著者>小松</書名></著者></書名></著者> </書籍目録>
次の2つの文書は整形式XML文書である。
<!-- 正しい整形式XML文書です -->
<書籍目録> <書名>XML入門</書名> <著者>筒井</著者> <書名>続・XML入門</書名> <著者>小松</著者> </書籍目録>
<!-- もう一つの正しい整形式XML文書です -->
<書籍目録> <書名>XML入門</書名> <著者>筒井<書名>続・XML入門<著者>小松</著者></書名></著者> </書籍目録>
整形式XML文書においては、XML文書は正確に一つのルート要素 (文書要素; document element とも呼ばれる) をもたなければならない。 ルート要素とは、XML文書の要素の階層構造において最上位の要素のことをいう。 最上位の要素は一つでなければならない。 最上位の要素が複数ある文書は、整形式XML文書ではない。 整形式XML文書が一つのルート要素をもたなければならないという条件が意味することは、整形式XML文書のテキストは、ルート要素の開始タグと対応する終了タグの間に、収められなければならないということである。 ルート要素の開始タグと終了タグの間に収められたテキストは、任意の数の要素や文字列データを含むことができる。
ルート要素の前に、必要に応じて、XML宣言 (XML declaration) をおくことができる。 このXML宣言は、XMLのどのバージョンが使われているか (現時点ではバージョン1.0であることが多い) などを示す。 XML宣言では、XMLのバージョンの他に、文字符号化方式 (文字コード) の指定や、他のXML文書との依存関係についての指定を、行うこともできる。
XML宣言を含んだXML文書の例を示す。
<?xml version="1.0" encoding="UTF-8"?>
<書籍 出版日="2007-10-31">これは書籍です.... </書籍>
XML仕様では、XMLプロセサ (XMLパーサ、XML文書の構文解析器) が、Unicodeの文字符号化方式であるUTF-8およびUTF-16で記述されたXML文書を処理できることを、必須条件としている (UCS-4は必須条件ではない)。 XMLプロセサは、UTF-8およびUTF-16の他にも、いくつかの任意の文字符号化方式の文書を処理できるようにして良い。 例えば、UCS-4、EUC-JP、Shift_JIS、EBCDICなどの文字符号化方式の文書を処理できるXMLプロセサが、広く普及し、使われている。
コメントはXML文書の木構造のどこにでもおくことができる。 コメントは、"<!--" で始まり、"-->" で終わる。 なお、コメント内に "--" を含むことはできない。
コメントを含むXML文書の例を示す。
<書籍 出版日="2007-10-31">
<!-- これはコメントです.... -->
これは書籍です....
</書籍>
内容のない要素を空要素 (empty element) という。 XMLでは、空要素を表現するために特別な構文を使うことができる。 開始タグを書きその直後に終了タグを書くこともできるが、その代わりに空要素のタグを使うことができるのである。 空要素タグは開始タグと似ているが、閉じ括弧の直前にスラッシュをおく。
次の3つの例は、XMLでは同等である。
<foo></foo>
<foo/>
<foo />
空要素タグは属性を含むことができる。
<情報 著者="小松左京" 分類="サイエンスフィクション" 日付="2009-01-01"/>
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には、事前宣言された実体として次の表に示す5つの実体がある。
実体参照 | 実体 | 実体の説明 |
---|---|---|
& |
& | アンパサンド (ampersand) |
< |
< | 小なり (less than) |
> |
> | 大なり (greater than) |
' |
' | アポストロフィ (apostrophe) |
" |
" | クォーテーションマーク (quotation mark) |
「AT&T」の名前でアンパサンドを表現するために、事前宣言されたXMLの実体を使う例を示す。
<会社名称>AT&T</会社名称>
事前宣言された実体以外の実体を宣言する必要がある場合、XML文書の Document Type Definition (DTD、文書型定義) の内部で宣言する。
XML文書の内部に定義されたDTDを使って、置換文字列としての実体を宣言して、実体参照を使う例を次に示す。 宣言された実体は、一つの文字であっても良いし、テキストの断片であっても良いし、他の実体への参照を含むテキストであっても良い。
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE 例 [
<!ENTITY copy "©">
<!ENTITY copyright-notice "Copyright © 2007 平成新報社">
]>
<例>
©right-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&T</会社名称>
<会社名称>AT&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[
そしてCDATAセクションの内容が続き、次の記述が最初に出現したところでCDATAセクションは終わる。
]]>
CDATAセクションの内容の文字列は全て文字列データとして解釈され、マークアップや実体参照や文字参照として解釈されることはない。
次の例で「送信者」の開始タグと終了タグはマークアップとして解釈される。
<送信者>星新一</送信者>
しかし次のように記述した場合は、
<![CDATA[<送信者>星新一</送信者>]]>
次のように記述したものと同等に解釈される。
<送信者>星新一</送信者>
すなわち、「送信者」タグは「星新一」の文字列と同列に位置づけられ、いずれも文字列データとして解釈される。
文字参照 ð
が要素の内容で出現した場合は、一つのUnicode文字 00F0 ("ð") として解釈される。 しかしCDATAセクション内で出現した場合は、8つの文字からなる文字列として解釈される。 すなわち、アンパサンド、#マーク、文字x、数字0、数字0、文字F、数字0、セミコロンの8つの文字からなる文字列として解釈される。
整形式XML文書は、とりわけ、次に示す規則に適合しなければならない。
<私は空です/>
のように記述することができる。この例は <私は空です></私は空です>
と意味的に同等である。要素の名前ではアルファベットの大文字と小文字とが区別される。 例えば、次の例は整形式である。
<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文書の正当性を自動的に検査する例を示す。
irb> require "rexml/document" irb> include REXML irb> doc = Document.new(File.new("test.xml")).root
妥当なXML文書について詳しく説明する。
XMLでは、要素に名前を付けることができ、階層構造をとることができ、スキーマ言語 (Document Type Definition など) により用途に沿うように定義されたスキーマを使うことで要素と属性の意味を公開し説明することができる。 XMLのこうした特徴により、目的に応じたXMLに準拠したマークアップ言語を創るための、構文的な基礎が成り立っている。
スキーマは、制約の集合を記述することにより、XML文書の構文上の規則を単に補足するのみである。 スキーマは、多くの場合、要素と属性の名前を限定し、各要素が内容とするものの階層構造を規定し、属性の内容を規定する。 例えば、「誕生日」という名前の要素では、「月」という名前の一つの要素と「日」という名前の一つの要素をもつことができ、「月」要素と「日」要素のそれぞれは文字列データのみをもつことができる。
スキーマに定義された制約には、データ型の割り当てを含むことができる場合がある。 データ型を割り当てることにより、データ型が割り当てられた情報がどのように処理できるかを、規定することができる。 例えば、「月」要素の文字列データは、そのXML文書で採用したスキーマ言語の機能に準拠して、「1」から「12」までの数字のみが妥当であるという形で、定義することができる可能性がある。 ここでスキーマ言語の (データ型に関する) 機能とは、おそらく特定の方法で形式にしたがって記述しなければならないということだけでなく、別のデータ型の値であるかのように処理されることを未然に防ぐことを、意味する。
何らかのスキーマに準拠したXML文書は、整形式であるということに加えて、妥当 (valid) であるということができる。
XMLのスキーマは、XMLの文書型 (文書の種類、文書の論理的構造) を記述したものである。 多くの場合スキーマは、その文書の構造と内容に関する制約という形で表現される。 XMLのスキーマは、XML仕様で規定されている、整形式XML文書としての基本的な制約に加え、それ以上の制約をXML文書に課すことができる。 XMLのスキーマ言語は、標準規格のものもプロプライエタリなものも含めて、こうしたスキーマを表現するという目的のもと、数多く存在している。 いくつかのスキーマ言語では、スキーマ自身をXML文書として記述する。
スキーマ言語の記述能力はスキーマ言語ごとにさまざまである。 例えばスキーマ言語の一つである Document Type Definition (DTD) では、XML文書がとるべき構造の主な規則として、そのDTDに準拠したXML文書で使うことができる要素の名前、要素の内容モデル、要素で指定できる属性の名前、属性の値のデータ型を、記述することができる[5]。
なお、要素の内容モデルとは、要素の内容に出現可能な要素やデータとその順番、および要素の出現回数を規定したもののことをいう[6]。
Standard Generalized Markup Language (SGML) やXMLなどの汎用的なデータ記述言語が世に出る前は、ソフトウェア設計者は、複数のプログラムの間でデータの受け渡しをするために、自分自身でファイルフォーマットを定義するか、ちょっとしたコンピュータ言語を定義しなければならなかった。 このため受け渡しするデータの詳細な仕様やその他の文書を書かなければならなかったし、文書の書き手を別途に確保しなければならないこともあった。
XMLが一定の構造をもち厳密な構文解析の規則をもつことで、ソフトウェア設計者は構文解析を標準的なソフトウェアツール (妥当性検証器、バリデータ) に任せることができる。 そしてXMLには、用途に特有の言語を開発するための一般的な、データモデル指向の枠組みがある。 このためソフトウェア開発者は、比較的高水準の抽象度において、自分たちが扱うデータの規則の開発に専念するだけでよい。
XML文書をスキーマに照らして妥当性検証を行うための、十分にテストされたツールが、数多く存在している。 XML文書をスキーマに照らして妥当性検証を行うためのツールを、妥当性検証器 (バリデータ) という。 妥当性検証器は、スキーマに表現された制約にXML文書が準拠しているかについて、自動的に妥当性検証を行う。 妥当性検証器は、XMLプロセサ (XMLパーサ) に含まれていることもあれば、XMLプロセサとは別に提供されていることもある。
これまでに述べたスキーマの使い方とは別の使い方も存在する。 例えば、XMLエディタは、XML文書の編集を支援するためにスキーマを使うことができる。 こうしたXMLエディタでは、妥当な要素名や妥当な属性名を提示することなどができる。
XMLのための最も歴史の古いスキーマ言語は Document Type Definition (DTD、文書型定義) である。 DTDは、XMLの前身であるSGMLから引き継がれた。 DTDは XML 1.0 標準に含められているため、ほとんどあらゆるXMLプロセサがDTDを扱うことができる。 しかし2007年現在ではDTDを使うことは限定的な範囲にとどまっているようである。 その理由は次のとおりである。
DTDは、現在も多くの用途で使われている。 その理由は、一定の人々にとっては、DTDは他の新しいスキーマ言語よりも読みやすく書きやすいと、考えられているからである。
XML Schema は、World Wide Web Consortium (W3C) により開発された、DTDの後継となる新しいスキーマ言語である。 非公式には、XSDと呼ばれることもある。 XSDは、XML Schema のインスタンス (スキーマ) を意味する "XML Schema Definition" の頭字語である。
XML Schema は、XMLによるマークアップ言語のスキーマの記述能力において、DTDと比べて非常に強力である。 XML Schema は、豊富なデータ型を扱うことができるスキーマ言語である。 XML文書の論理的構造について、DTDより詳細な制約を記述することができる。 そしてDTDより詳細な妥当性検証の枠組みのもとで、妥当性検証が行われる。
XML Schema はまた、XML Schema によるスキーマ自体を、XMLに準拠した形式を使って記述する。 XML Schema のスキーマ自体がXMLに準拠することで、スキーマを編集したりスキーマに何らかの処理を行うために、普通のXMLツールを使うことができるようになる。
ただし、XML Schema の妥当性検証器を実装する作業には、単にXML文書を読むことができる能力よりも、非常に多くの知識と能力を必要とする。
XML Schema に対しては賛否両論がある。 XML Schema に対する批判の一部を示す。
RELAX NG は、人気のあるもう一つの新しいスキーマ言語である。 最初にOASIS (構造化情報標準促進協会) で仕様が策定された。 RELAX NG は、現在ではISO (国際標準化機構) の国際標準となっている。 ISOでは、文書スキーマ定義言語 (DSDL) の一部分を構成する仕様として位置づけられている。
RELAX NG のスキーマの記述方法は、2つの形式がある。 XMLに準拠した構文 (XML構文、xml syntax) と、XMLに準拠しない短縮構文 (compact syntax) である。 短縮構文は、読みやくすることとより書きやすくすることを目指している。 ただし、短縮構文で記述されたスキーマをXML構文のスキーマに変換する方法と、その逆の変換を行う方法は、しっかり定義されているので、ジェームズ・クラークが開発した Trang conversion tool を使えば、標準のXMLツールを使う利便を享受することができる。
RELAX NG は、XML Schema よりも簡潔なスキーマ定義と簡潔な妥当性検証の枠組みを、備えている。 そのため RELAX NG は、XML Schema と比べて、使いやすく、また RELAX NG の妥当性検証器を実装することも容易になっている。
RELAX NG もまた、データ型フレームワークプラグインを使う能力を備えている。 RELAX NG でスキーマを記述する人は、例えば、XML文書で XML Schema のデータ型の定義に適合させたいと考えるかもしれない。 そして RELAX NG では、データ型フレームワークプラグインを使うことにより可能となっている。
ISO 文書スキーマ定義言語 (DSDL; Document Schema Description Languages) 標準は、小規模なスキーマ言語の広範なセットを共に提供する。 DSDL を構成する複数の仕様のそれぞれが、特定の問題に対応するために特化されている。 DSDL は、 RELAX NG のXML構文と短縮構文、スキマトロン、データ型ライブラリ言語、文字レパートリ記述言語、文書スキーマ再命名言語、名前空間に基づく検証委譲言語 (NVDL) を、含んでいる。DSDLスキーマ言語群は、XML Schemas を支持するベンダの支援は2007年の時点ではまだ受けていない。 DSDLは、出版のための機能が欠如していることに対する、出版業界の一定の草の根の反応でもある。
いくつかのスキーマ言語では、特定のXML文書の構造を記述する能力に加えて、個々のXML文書をその特定のXML文書構造に適合するように変換する機能も、限定的ながら備えている。
DTDと XML Schema はこの変換機能を備えている。 DTDと XML Schema では、XML文書に属性の既定値を与えることができる。 RELAX NG とスキマトロンは、意図的にこの機能を外している。 例えば、XMLインフォメーションセットを正確に扱うことが、RELAX NG とスキマトロンの仕様策定時に変換機能を外した理由の一つである。
XML文書を視覚的に表示するための方法を説明する。
XML文書は、その文書の内容をどのように視覚的に表示するかという情報を、含んでいない。 Cascading Style Sheets (CSS) や Extensible Stylesheet Language (XSL) のようなXMLのためのスタイルシート言語を使うのでなければ、ほとんどのウェブブラウザは普通のXML文書を生のXMLテキストとして描画する。 いくつかのウェブブラウザは「ハンドル」をつけて表示する (例えば、余白に + と - の符号を表示する)。 ハンドルを使うことにより、XML文書構造の部分木を、マウスクリックで展開したり折りたたんだりすることができる。
CSSを使ってウェブブラウザでXML文書を描画するためには、XML文書は次のような要領でスタイルシートへの参照を含めなければならない (XMLの処理命令を使ってスタイルシートを使って描画する旨を指定している)。
<?xml-stylesheet type="text/css" href="myStyleSheet.css"?>
この方法は、HTML文書におけるスタイルシート指定の方法とは異なる。 HTML文書では <link/>
要素を使ってスタイルシートを指定する。
XML文書を視覚的に表示するために、Extensible Stylesheet Language (XSL、拡張可能なスタイルシート言語) を使うこともできる。 XSLを使う場合は、XML文書をXHTML/HTML文書の構造に変換するか、もしくはウェブブラウザで視覚的に表示することができる他の文書の構造に変換する。
クライアント側で XSL Transformations (XSLT) のスタイルシートを指定するためには、XML文書に次のようにXSLTスタイルシートへの参照を含めることが、必要である (XMLの処理命令を使って実現している)。
<?xml-stylesheet type="text/xsl" href="myTransform.xslt"?>
クライアント側のXSLTスタイルシート処理機能は、現在では多くのウェブブラウザが備えている。
別の方法として、このようなエンドユーザのウェブブラウザの能力に依存する方法を採らずに、サーバ側でXSLを使ってXML文書を視覚化可能な形式に変換する方法も、行われている。 エンドユーザは、「舞台の裏側で」何が行われているかを、意識する必要はない。 エンドユーザが目にするものは、よく整形され視覚化された文書だけである。
XMLを拡張する技術を説明する。
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種類の要素となる。
名前空間は、XMLの予約属性である xmlns
を使って宣言される。 xmlns
属性の属性値はIRI (Internationalized Resource Identifier) である必要があり、通常はURI (Uniform Resource Identifier) である。
例を示す。
xmlns="http://www.w3.org/1999/xhtml"
この例の "http://www.w3.org/1999/xhtml" を名前空間名という。 ここで注意すべきこととしては、名前空間の宣言で記述されたURIは、実際にインターネット上の住所として解釈されるわけではないということである(自由に考えよう、URIほど便利なものが必ずインターネットのアドレスをささなければいけないなどと、誰が決めたのか)。 例えば、http://www.w3.org/1999/xhtml自体には何のコードもない。 このURIの文書では、人間の読者に対してXHTMLについて簡単に説明しているだけである。 ("http://www.w3.org/1999/xhtml" のような) URIを名前空間の識別子として使うことで、("xhtml" のような) 単純な文字列を名前空間名として使うよりも、異なる名前空間が意図せずして同じ名前空間名を使ってしまう危険性を低減する。 名前空間の識別子は、ウェブの住所 (アドレス) の慣習にしたがう必要はない。
名前空間の宣言は、短い接頭辞を含むことができる。 この名前空間接頭辞を使うことで、異なるボキャブラリに由来する要素と属性を識別することができる。
名前空間接頭辞を使う例を示す。
xmlns:xhtml="http://www.w3.org/1999/xhtml"
XML名前空間を使ったXML文書の例を示す。
<?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>
このXML文書は、次の2つの名前空間のボキャブラリから構成されている。
なおこのXML文書は、あるXML文書をXHTML文書に変換するXSLTスタイルシートである。
XML名前空間を使う場合、そのXML名前空間のボキャブラリが定義されていることが必要であるわけではない。 しかしXML文書でXML名前空間を使う場合に、そのXML名前空間のボキャブラリを定義しておくことは、そのXML名前空間のURIのもとで正しい文書構造を定義しているスキーマに関連づけるために、行われることが多い。
プログラマやアプリケーションソフトウェアがXML文書を処理する手段としては、これまで次に示す3つの技法が伝統的に使われてきた。 なお、この節の説明で使うAPIとはアプリケーションプログラミングインタフェースのことをさす。
さらに、近年に開発され使われるようになった、XML文書を処理する技法を示す。
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文書に対して、視覚的に出力したり印刷出力できるよう変換処理を行うことができる。
Pull Parsing は、XML文書を、最初から順番に読み込み、Iterator パターン のデザインパターンを使って項目 (item) の一連の流れとして扱う、近年に徐々に普及してきた技法である[9][10]。 Pull Parsing の技法により、再帰下降パーサを実装することができる。 再帰下降パーサでは、パースを実行するプログラムは、パースの対象となるXML文書の構造と似ている。 そしてパースの中間結果を取得することができる。
パースの中間結果を、パースを実行するメソッド内の局所変数 (ローカル変数) として使うことができる。 あるいは、低水準のメソッドの引数として渡したり、高水準のメソッドへの戻り値として返すことができる。 Pull Parsing の技法を提供する実装としては次のものがある。
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とは対照的な手法である。 データバインディングの実現例を次に示す。
OpenOffice.org、AbiWord、およびアップルの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エディタが使えるようになっている。
XMLインフォメーションセット (XML Information Set、インフォセット、Infoset) は、XML文書の抽象的なデータモデルを「情報項目」 (information item) の集合を使って規定している。 World Wide Web Consortium (W3C) から、2001年10月24日にXMLインフォメーションセット仕様が勧告された。 XMLインフォメーションセットの仕様における定義は、整形式XML文書内の情報を参照する必要がある他の仕様において使われることが想定されている。
一つのXML文書には、そのXML文書が整形式でありかつXML名前空間の制約に準拠している場合、一つのXMLインフォメーションセットがある。 XMLインフォメーションセットを構成するためには、そのXML文書が妥当なXML文書であることは、必須要件ではない。
一つのXMLインフォメーションセットには、次に示す11種類の情報項目がある。
XMLインフォメーションセットの Second Edition (第2版) が2004年2月4日に勧告された。
インフォメーションセットへの追加情報すなわちインフォメーションセットに対する改変は、スキーマによる妥当性検証を行う際に、インフォメーションセットを改変することをいう。 例えば、インフォメーションセットに属性の既定値 (デフォルト値) を追加することなどがある。情報を追加されたインフォメーションセットは、スキーマ検証後インフォメーションセットあるいはPSVI (post-schema-validation infoset) と呼ばれる[13]。
インフォメーションセットへの追加情報については、賛否両論がある。 インフォメーションセットに情報を追加することに否定的な見解としては、インフォメーションセットへの追加情報はモジュール性を侵害し相互運用性の面での問題を引き起こす危険があるとする。 なぜなら、同じXML文書を扱う複数のアプリケーションソフトウェアは、受け取る情報が妥当性検証を行うかどうかに依存してしまうからである。 アプリケーションソフトウェアが、妥当性検証を行う場合に受け取る情報と、妥当性検証を行わない場合に受け取る情報が、異なってしまうのである[14]。
XML Schema は、XMLインフォメーションセットへの追加情報を扱うことができる。 RELAX NGは、インフォメーションセットへの追加情報を扱わない。 RELAX NG では、インフォメーションセットへの追加情報に否定的な立場をとっている。
デジタルメディアの出版を行ってきた人々は、1980年の後半—インターネットが広く使われるようになるより前の時期—には既に、動的に情報を視覚化するための技術として、汎用的なマークアップ言語である Standard Generalized Markup Language (SGML) が多くの用途に適していることを、理解していた[15][16]。 SGMLはいくつかの分野で普及していたが、仕様が複雑で処理系の開発が難しく、またSGML文書の処理が重いという欠点があった。1990年代半ばまでには、SGMLを実際に使っていた一定の人々は、新しく現れた World Wide Web (ウェブ) を経験した。 そうした人々は、ウェブが発展することにより直面するいくつかの問題に対して、SGMLが解決策を提供すると、強く考えるようになった。 Dan Connolly は、自分が1995年にWorld Wide Web Consortium (W3C) のスタッフになった時に、SGMLをW3Cのアクティビティの一覧に追加した。 このアクティビティの作業は、1996年の中頃にサン・マイクロシステムズのジョン・ボサックが、このアクティビティに関する宣言を起草しアクティビティの共同作業者を募ることで、始まった。 ボサックは、SGMLとウェブの双方を経験していた人々の小さなコミュニティと良好な関係を築いていた。 ボサックは、自分の作業においてマイクロソフトから支援を受けた。
XMLの仕様は、11人のメンバーからなるワーキンググループにより編集され[17]、だいたい150人から構成される Interest Group のメンバーから支援を受けて、作成された。 技術的な論議が Interest Group のメーリングリストで提起され、提起された論議は、合意形成により解決された。合意形成ができなかった場合は、ワーキンググループのメンバーの投票による多数により、解決された。 このアクティビティで行われた設計上の決定とその根拠の記録は、Michael Sperberg-McQueen が1997年12月4日に編集した[18]。 このアクティビティでは、ジェームズ・クラークが、技術リーダとして貢献した。 クラークの貢献として特筆されるのは、空要素 "<空/>" の導入と、この技術の名称 "Extensible Markup Language" (XML) の命名である。 この技術の名称として、他に提案され吟味されたものの一部を次に示す。
XML仕様のワーキンググループではジョン・ボサックが議長を務めた。 このワーキンググループではジェームズ・クラークが技術リーダを務めた。 ワーキンググループの共同エディタは、もともとはティム・ブレイと Michael Sperberg-McQueen であった。 このアクティビティのプロジェクトの途中で、ブレイはネットスケープ・コミュニケーションズとのコンサルティングの契約を結んだ。 このブレイとネットスケープの契約に対しては、マイクロソフトが強く抗議した。 ブレイは、エディタの役割を一時的に辞することを要請された。 このことに関して、ワーキンググループでは激しい議論が行われた。 この議論は、最終的にはマイクロソフトの Jean Paoli が第3の共同エディタに就くことで解決した。 なおXMLワーキンググループには、日本人としてはただ一人村田真がメンバーとして1997年に参加した。
XMLワーキンググループは、直接会って活動したことは数回しかなかった(最初の会議は1997年8月22日)。 XML仕様の設計は、電子メールと週に一度の電話会議の双方を有機的に活用することにより、成し遂げられた。 XML仕様の設計では、SGMLの欠点を解決すべく文法を簡素化した。 XML仕様における設計上のいくつかの大きな決定は、1996年の7月から11月までの間の12週間の真剣な作業のなかで行われた。 この12週間の作業の後 (1996年11月) に、XMLの最初のワーキングドラフトが公表された[19]。 その後も1997年をとおして設計作業は続けられ、XML 1.0 は、1998年2月10日にW3Cの勧告となった[20]。
XML 1.0 は、ワーキンググループが目標としていた次の目標を達成したと、評価する人々が多い。
技術者にとってはXMLはSGMLよりも習得しやすい技術であり、また処理系の開発が容易になったことで低い費用でXML技術を利用できるようになった。 現在ではXMLは広く普及している技術である。
XMLの前身であるSGMLと同様にXMLでも、いくつかの冗長な構文要素があり、要素記述子の繰り返しを仕様に含んでいる。 文書を短くすることは、XMLワーキンググループでは、XMLの構造において本質的な問題とは見なされなかった。
XMLは、ISO標準 Standard Generalized Markup Language (SGML) のサブセットである。 XMLのほとんどはSGMLから変更されずに採り入れられている。 XMLがSGMLから採り入れられている技術的な要素には次のものが含まれる。
XMLがSGMLから採り入れなかった技術要素としては、SGML宣言がある (XMLでは文書の文字符号化方式としてUTF-8とUTF-16を採用している)。
XMLの他の技術的起源としては、次の3つが挙げられる。
XML仕様の設計に関する議論のなかで開発された革新的な考え方には、次のものが含まれる。
2010年1月現在の時点では、XMLには2つのバージョンがある。
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 はどのようなものかということについての、いくつかの提案を含んでいる。 その内容は次のとおりである。
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つの特許についていくつかの大企業と話し合っていると述べた[23]。
XMLを使う人々や企業に在籍していない専門家たちは、Scientigoの主張に対して懐疑的で批判的な立場で反応した。 一定の人々は、Scientigoをパテント・トロールであると述べた。 ティム・ブレイは、この2つの特許がXMLを対象とするという主張は「ばかげている」と述べた[24]。
XMLに関係する多くの先行技術がSGMLを含めて存在している。
多くの論者がXMLに対してさまざまな批判を行ってきた。 こうした批判は、XMLの長所と潜在的な欠点に対する言及を含んでいる[25]。
先述したISOの標準群のほかに、XML関連では次の文書が発行されている。
[ヘルプ] |
アプリケーションソフトウェアからXML文書を読み書きするためのアプリケーションプログラミングインタフェース (API)
Category:XMLベースの技術
ウィクショナリーにXMLの項目があります。 |
|
|
||||||||||||||||||||||
|
Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable. It is defined by the W3C's XML 1.0 Specification[2] and by several other related specifications,[3] all of which are free open standards.[4]
The design goals of XML emphasize simplicity, generality and usability across the Internet.[5] It is a textual data format with strong support via Unicode for different human languages. Although the design of XML focuses on documents, it is widely used for the representation of arbitrary data structures[6] such as those used in web services.
Several schema systems exist to aid in the definition of XML-based languages, while many application programming interfaces (APIs) have been developed to aid the processing of XML data.
As of 2009[update], hundreds of document formats using XML syntax have been developed,[7] including RSS, Atom, SOAP, and XHTML. XML-based formats have become the default for many office-productivity tools, including Microsoft Office (Office Open XML), OpenOffice.org and LibreOffice (OpenDocument), and Apple's iWork. XML has also been employed as the base language for communication protocols, such as XMPP. Applications for the Microsoft .NET Framework use XML files for configuration. Apple has an implementation of a registry based on XML.[8]
XML has come into common use for the interchange of data over the Internet. IETF RFC 7303 gives rules for the construction of Internet Media Types for use when sending XML. It also defines the media types application/xml and text/xml, which say only that the data is in XML, and nothing about its semantics. The use of text/xml has been criticized as a potential source of encoding problems and it has been suggested that it should be deprecated.[9]
RFC 7303 also recommends that XML-based languages be given media types ending in +xml; for example image/svg+xml for SVG.
Further guidelines for the use of XML in a networked context may be found in RFC 3470, also known as IETF BCP 70, a document covering many aspects of designing and deploying an XML-based language.
The material in this section is based on the XML Specification. This is not an exhaustive list of all the constructs that appear in XML; it provides an introduction to the key constructs most often encountered in day-to-day use.
<
and end with a >
, or they begin with the character &
and end with a ;
. Strings of characters that are not markup are content. However, in a CDATA section, the delimiters <![CDATA[
and ]]>
are classified as markup, while the text between them is classified as content. In addition, whitespace before and after the outermost element is classified as markup.<
and ends with >
. Tags come in three flavors:
<section>
</section>
<line-break />
<Greeting>Hello, world.</Greeting>
. Another is <line-break />
.<img src="madonna.jpg" alt='Foligno Madonna, by Raphael' />
Another example would be
<step number="3">Connect A to B.</step>
where the name of the attribute is "number" and the value is "3".
<div class="inner greeting-box" >Hello!</div>
where the attribute "class" has both the value "inner greeting-box" and also indicates the two CSS class names "inner" and "greeting-box".
<?xml version="1.0" encoding="UTF-8"?>
XML documents consist entirely of characters from the Unicode repertoire. Except for a small number of specifically excluded control characters, any character defined by Unicode may appear within the content of an XML document.
XML includes facilities for identifying the encoding of the Unicode characters that make up the document, and for expressing characters that, for one reason or another, cannot be used directly.
Unicode code points in the following ranges are valid in XML 1.0 documents:[10]
XML 1.1[11] extends the set of allowed characters to include all the above, plus the remaining characters in the range U+0001–U+001F. At the same time, however, it restricts the use of C0 and C1 control characters other than U+0009 (Horizontal Tab), U+000A (Line Feed), U+000D (Carriage Return), and U+0085 (Next Line) by requiring them to be written in escaped form (for example U+0001 must be written as  or its equivalent). In the case of C1 characters, this restriction is a backwards incompatibility; it was introduced to allow common encoding errors to be detected.
The code point U+0000 (Null) is the only character that is not permitted in any XML 1.0 or 1.1 document.
The Unicode character set can be encoded into bytes for storage or transmission in a variety of different ways, called "encodings". Unicode itself defines encodings that cover the entire repertoire; well-known ones include UTF-8 and UTF-16.[12] There are many other text encodings that predate Unicode, such as ASCII and ISO/IEC 8859; their character repertoires in almost every case are subsets of the Unicode character set.
XML allows the use of any of the Unicode-defined encodings, and any other encodings whose characters also appear in Unicode. XML also provides a mechanism whereby an XML processor can reliably, without any prior knowledge, determine which encoding is being used.[13] Encodings other than UTF-8 and UTF-16 will not necessarily be recognized by every XML parser.
XML provides escape facilities for including characters which are problematic to include directly. For example:
 
) " "
 
) " "А
) "А"
A
) "A"There are five predefined entities:
<
represents "<">
represents ">"&
represents "&"'
represents '"
represents "All permitted Unicode characters may be represented with a numeric character reference. Consider the Chinese character "中", whose numeric code in Unicode is hexadecimal 4E2D, or decimal 20,013. A user whose keyboard offers no method for entering this character could still insert it in an XML document encoded either as 中
or 中
. Similarly, the string "I <3 Jörg
" could be encoded for inclusion in an XML document as "I <3 Jörg
".
"�
" is not permitted, however, because the null character is one of the control characters excluded from XML, even when using a numeric character reference.[15] An alternative encoding mechanism such as Base64 is needed to represent such characters.
Comments may appear anywhere in a document outside other markup. Comments cannot appear before the XML declaration. Comments start with "<!--
" and end with "-->
". For compatibility with SGML, the string "--
" (double-hyphen) is not allowed inside comments;[16] this means comments cannot be nested. The ampersand has no special significance within comments, so entity and character references are not recognized as such, and there is no way to represent characters outside the character set of the document encoding.
An example of a valid comment: "<!--no need to escape <code> & such in comments-->
"
This example contains Chinese text. Without proper rendering support, you may see question marks, boxes, or other symbols instead of Chinese characters. |
This example contains Cyrillic text. Without proper rendering support, you may see question marks or boxes, misplaced vowels or missing conjuncts instead of Cyrillic letters. |
XML 1.0 (Fifth Edition) and XML 1.1 support the direct use of almost any Unicode character in element names, attributes, comments, character data, and processing instructions (other than the ones that have special symbolic meaning in XML itself, such as the less-than sign, "<"). The following is a well-formed XML document including Chinese, Armenian and Cyrillic characters:
<?xml version="1.0" encoding="UTF-8"?>
<俄语 լեզու="ռուսերեն">данные</俄语>
The XML specification defines an XML document as a well-formed text – meaning that it satisfies a list of syntax rules provided in the specification. Some key points in the fairly lengthy list include:
<
and &
appear except when performing their markup-delineation roles!"#$%&'()*+,/;<=>?@[\]^`{|}~
, nor a space character, and cannot start with -
, .
, or a numeric digit.The definition of an XML document excludes texts that contain violations of well-formedness rules; they are simply not XML. An XML processor that encounters such a violation is required to report such errors and to cease normal processing. This policy, occasionally referred to as "draconian error handling," stands in notable contrast to the behavior of programs that process HTML, which are designed to produce a reasonable result even in the presence of severe markup errors.[17] XML's policy in this area has been criticized as a violation of Postel's law ("Be conservative in what you send; be liberal in what you accept").[18]
The XML specification defines a valid XML document as a well-formed XML document which also conforms to the rules of a Document Type Definition (DTD).
This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2015) |
In addition to being well-formed, an XML document may be valid. This means that it contains a reference to a Document Type Definition (DTD), and that its elements and attributes are declared in that DTD and follow the grammatical rules for them that the DTD specifies.
XML processors are classified as validating or non-validating depending on whether or not they check XML documents for validity. A processor that discovers a validity error must be able to report it, but may continue normal processing.
A DTD is an example of a schema or grammar. Since the initial publication of XML 1.0, there has been substantial work in the area of schema languages for XML. Such schema languages typically constrain the set of elements that may be used in a document, which attributes may be applied to them, the order in which they may appear, and the allowable parent/child relationships.
The oldest schema language for XML is the Document Type Definition (DTD), inherited from SGML.
DTDs have the following benefits:
DTDs have the following limitations:
Two peculiar features that distinguish DTDs from other schema types are the syntactic support for embedding a DTD within XML documents and for defining entities, which are arbitrary fragments of text and/or markup that the XML processor inserts in the DTD itself and in the XML document wherever they are referenced, like character escapes.
DTD technology is still used in many applications because of its ubiquity.
A newer schema language, described by the W3C as the successor of DTDs, is XML Schema, often referred to by the initialism for XML Schema instances, XSD (XML Schema Definition). XSDs are far more powerful than DTDs in describing XML languages. They use a rich datatyping system and allow for more detailed constraints on an XML document's logical structure. XSDs also use an XML-based format, which makes it possible to use ordinary XML tools to help process them.
xs:schema element that defines a schema:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
</xs:schema>
RELAX NG was initially specified by OASIS and is now also an ISO/IEC International Standard (as part of DSDL). RELAX NG schemas may be written in either an XML based syntax or a more compact non-XML syntax; the two syntaxes are isomorphic and James Clark's conversion tool - 'Trang', can convert between them without loss of information. RELAX NG has a simpler definition and validation framework than XML Schema, making it easier to use and implement. It also has the ability to use datatype framework plug-ins; a RELAX NG schema author, for example, can require values in an XML document to conform to definitions in XML Schema Datatypes.
Schematron is a language for making assertions about the presence or absence of patterns in an XML document. It typically uses XPath expressions.
The ISO DSDL (Document Schema Description Languages) standard brings together a comprehensive set of small schema languages, each targeted at specific problems. DSDL includes RELAX NG full and compact syntax, Schematron assertion language, and languages for defining datatypes, character repertoire constraints, renaming and entity expansion, and namespace-based routing of document fragments to different validators. DSDL schema languages do not have the vendor support of XML Schemas yet, and are to some extent a grassroots reaction of industrial publishers to the lack of utility of XML Schemas for publishing.
Some schema languages not only describe the structure of a particular XML format but also offer limited facilities to influence processing of individual XML files that conform to this format. DTDs and XSDs both have this ability; they can for instance provide the infoset augmentation facility and attribute defaults. RELAX NG and Schematron intentionally do not provide these.
A cluster of specifications closely related to XML have been developed, starting soon after the initial publication of XML 1.0. It is frequently the case that the term "XML" is used to refer to XML together with one or more of these other technologies which have come to be seen as part of the XML core.
xml:base
attribute, which may be used to set the base for resolution of relative URI references within the scope of a single XML element.xml:id
functions as an "ID attribute" in the sense used in a DTD.Some other specifications conceived as part of the "XML Core" have failed to find wide adoption, including XInclude, XLink, and XPointer.
The design goals of XML include, "It shall be easy to write programs which process XML documents."[5] Despite this, the XML specification contains almost no information about how programmers might go about doing such processing. The XML Infoset specification provides a vocabulary to refer to the constructs within an XML document, but also does not provide any guidance on how to access this information. A variety of APIs for accessing XML have been developed and used, and some have been standardized.
Existing APIs for XML processing tend to fall into these categories:
Stream-oriented facilities require less memory and, for certain tasks which are based on a linear traversal of an XML document, are faster and simpler than other alternatives. Tree-traversal and data-binding APIs typically require the use of much more memory, but are often found more convenient for use by programmers; some include declarative retrieval of document components via the use of XPath expressions.
XSLT is designed for declarative description of XML document transformations, and has been widely implemented both in server-side packages and Web browsers. XQuery overlaps XSLT in its functionality, but is designed more for searching of large XML databases.
Simple API for XML (SAX) is a lexical, event-driven interface in which a document is read serially and its contents are reported as callbacks to various methods on a handler object of the user's design. SAX is fast and efficient to implement, but difficult to use for extracting information at random from the XML, since it tends to burden the application author with keeping track of what part of the document is being processed. It is better suited to situations in which certain types of information are always handled the same way, no matter where they occur in the document.
Pull parsing[19] treats the document as a series of items which are read in sequence using the iterator design pattern. This allows for writing of recursive descent parsers in which the structure of the code performing the parsing mirrors the structure of the XML being parsed, and intermediate parsed results can be used and accessed as local variables within the methods performing the parsing, or passed down (as method parameters) into lower-level methods, or returned (as method return values) to higher-level methods. Examples of pull parsers include StAX in the Java programming language, XMLPullParser in Smalltalk, XMLReader in PHP, ElementTree.iterparse in Python, System.Xml.XmlReader in the .NET Framework, and the DOM traversal API (NodeIterator and TreeWalker).
A pull parser creates an iterator that sequentially visits the various elements, attributes, and data in an XML document. Code which uses this iterator can test the current item (to tell, for example, whether it is a start or end element, or text), and inspect its attributes (local name, namespace, values of XML attributes, value of text, etc.), and can also move the iterator to the next item. The code can thus extract information from the document as it traverses it. The recursive-descent approach tends to lend itself to keeping data as typed local variables in the code doing the parsing, while SAX, for instance, typically requires a parser to manually maintain intermediate data within a stack of elements which are parent elements of the element being parsed. Pull-parsing code can be more straightforward to understand and maintain than SAX parsing code.
The Document Object Model (DOM) is an interface-oriented application programming interface that allows for navigation of the entire document as if it were a tree of node objects representing the document's contents. A DOM document can be created by a parser, or can be generated manually by users (with limitations). Data types in DOM nodes are abstract; implementations provide their own programming language-specific bindings. DOM implementations tend to be memory intensive, as they generally require the entire document to be loaded into memory and constructed as a tree of objects before access is allowed.
Another form of XML processing API is XML data binding, where XML data are made available as a hierarchy of custom, strongly typed classes, in contrast to the generic objects created by a Document Object Model parser. This approach simplifies code development, and in many cases allows problems to be identified at compile time rather than run-time. Example data binding systems include the Java Architecture for XML Binding (JAXB) and XML Serialization in .NET.[20]
XML has appeared as a first-class data type in other languages. The ECMAScript for XML (E4X) extension to the ECMAScript/JavaScript language explicitly defines two specific objects (XML and XMLList) for JavaScript, which support XML document nodes and XML node lists as distinct objects and use a dot-notation specifying parent-child relationships.[21] E4X is supported by the Mozilla 2.5+ browsers (though now deprecated) and Adobe Actionscript, but has not been adopted more universally. Similar notations are used in Microsoft's LINQ implementation for Microsoft .NET 3.5 and above, and in Scala (which uses the Java VM). The open-source xmlsh application, which provides a Linux-like shell with special features for XML manipulation, similarly treats XML as a data type, using the <[ ]> notation.[22] The Resource Description Framework defines a data type rdf:XMLLiteral
to hold wrapped, canonical XML.[23] Facebook has produced extensions to the PHP and JavaScript languages which add XML to the core syntax in a similar fashion to E4X, namely XHP and JSX respectively.
XML is an application profile of SGML (ISO 8879).[24]
The versatility of SGML for dynamic information display was understood by early digital media publishers in the late 1980s prior to the rise of the Internet.[25][26] By the mid-1990s some practitioners of SGML had gained experience with the then-new World Wide Web, and believed that SGML offered solutions to some of the problems the Web was likely to face as it grew. Dan Connolly added SGML to the list of W3C's activities when he joined the staff in 1995; work began in mid-1996 when Sun Microsystems engineer Jon Bosak developed a charter and recruited collaborators. Bosak was well connected in the small community of people who had experience both in SGML and the Web.[27]
XML was compiled by a working group of eleven members,[28] supported by a (roughly) 150-member Interest Group. Technical debate took place on the Interest Group mailing list and issues were resolved by consensus or, when that failed, majority vote of the Working Group. A record of design decisions and their rationales was compiled by Michael Sperberg-McQueen on December 4, 1997.[29] James Clark served as Technical Lead of the Working Group, notably contributing the empty-element "<empty />" syntax and the name "XML". Other names that had been put forward for consideration included "MAGMA" (Minimal Architecture for Generalized Markup Applications), "SLIM" (Structured Language for Internet Markup) and "MGML" (Minimal Generalized Markup Language). The co-editors of the specification were originally Tim Bray and Michael Sperberg-McQueen. Halfway through the project Bray accepted a consulting engagement with Netscape, provoking vociferous protests from Microsoft. Bray was temporarily asked to resign the editorship. This led to intense dispute in the Working Group, eventually solved by the appointment of Microsoft's Jean Paoli as a third co-editor.
The XML Working Group never met face-to-face; the design was accomplished using a combination of email and weekly teleconferences. The major design decisions were reached in a short burst of intense work between August and November 1996,[30] when the first Working Draft of an XML specification was published.[31] Further design work continued through 1997, and XML 1.0 became a W3C Recommendation on February 10, 1998.
XML is a profile of an ISO standard SGML, and most of XML comes from SGML unchanged. From SGML comes the separation of logical and physical structures (elements and entities), the availability of grammar-based validation (DTDs), the separation of data and metadata (elements and attributes), mixed content, the separation of processing from representation (processing instructions), and the default angle-bracket syntax. Removed were the SGML declaration (XML has a fixed delimiter set and adopts Unicode as the document character set).
Other sources of technology for XML were the Text Encoding Initiative (TEI), which defined a profile of SGML for use as a "transfer syntax"; and HTML, in which elements were synchronous with their resource, document character sets were separate from resource encoding, the xml:lang attribute was invented, and (like HTTP) metadata accompanied the resource rather than being needed at the declaration of a link. The Extended Reference Concrete Syntax (ERCS) project of the SPREAD (Standardization Project Regarding East Asian Documents) project of the ISO-related China/Japan/Korea Document Processing expert group was the basis of XML 1.0's naming rules; SPREAD also introduced hexadecimal numeric character references and the concept of references to make available all Unicode characters. To support ERCS, XML and HTML better, the SGML standard IS 8879 was revised in 1996 and 1998 with WebSGML Adaptations. The XML header followed that of ISO HyTime.
Ideas that developed during discussion which were novel in XML included the algorithm for encoding detection and the encoding header, the processing instruction target, the xml:space attribute, and the new close delimiter for empty-element tags. The notion of well-formedness as opposed to validity (which enables parsing without a schema) was first formalized in XML, although it had been implemented successfully in the Electronic Book Technology "Dynatext" software;[32] the software from the University of Waterloo New Oxford English Dictionary Project; the RISP LISP SGML text processor at Uniscope, Tokyo; the US Army Missile Command IADS hypertext system; Mentor Graphics Context; Interleaf and Xerox Publishing System.
There are two current versions of XML. The first (XML 1.0) was initially defined in 1998. It has undergone minor revisions since then, without being given a new version number, and is currently in its fifth edition, as published on November 26, 2008. It is widely implemented and still recommended for general use.
The second (XML 1.1) was initially published on February 4, 2004, the same day as XML 1.0 Third Edition,[33] and is currently in its second edition, as published on August 16, 2006. It contains features (some contentious) that are intended to make XML easier to use in certain cases.[34] The main changes are to enable the use of line-ending characters used on EBCDIC platforms, and the use of scripts and characters absent from Unicode 3.2. XML 1.1 is not very widely implemented and is recommended for use only by those who need its unique features.[35]
Prior to its fifth edition release, XML 1.0 differed from XML 1.1 in having stricter requirements for characters available for use in element and attribute names and unique identifiers: in the first four editions of XML 1.0 the characters were exclusively enumerated using a specific version of the Unicode standard (Unicode 2.0 to Unicode 3.2.) The fifth edition substitutes the mechanism of XML 1.1, which is more future-proof but reduces redundancy. The approach taken in the fifth edition of XML 1.0 and in all editions of XML 1.1 is that only certain characters are forbidden in names, and everything else is allowed, in order to accommodate the use of suitable name characters in future versions of Unicode. In the fifth edition, XML names may contain characters in the Balinese, Cham, or Phoenician scripts among many others which have been added to Unicode since Unicode 3.2.[34]
Almost any Unicode code point can be used in the character data and attribute values of an XML 1.0 or 1.1 document, even if the character corresponding to the code point is not defined in the current version of Unicode. In character data and attribute values, XML 1.1 allows the use of more control characters than XML 1.0, but, for "robustness", most of the control characters introduced in XML 1.1 must be expressed as numeric character references (and #x7F through #x9F, which had been allowed in XML 1.0, are in XML 1.1 even required to be expressed as numeric character references[36]). Among the supported control characters in XML 1.1 are two line break codes that must be treated as whitespace. Whitespace characters are the only control codes that can be written directly.
There has been discussion of an XML 2.0, although no organization has announced plans for work on such a project. XML-SW (SW for skunkworks), written by one of the original developers of XML,[37] contains some proposals for what an XML 2.0 might look like: elimination of DTDs from syntax, integration of namespaces, XML Base and XML Information Set (infoset) into the base standard.
The World Wide Web Consortium also has an XML Binary Characterization Working Group doing preliminary research into use cases and properties for a binary encoding of the XML infoset. The working group is not chartered to produce any official standards. Since XML is by definition text-based, ITU-T and ISO are using the name Fast Infoset for their own binary infoset to avoid confusion (see ITU-T Rec. X.891 | ISO/IEC 24824-1).
XML and its extensions have regularly been criticized for verbosity and complexity.[38] Mapping the basic tree model of XML to type systems of programming languages or databases can be difficult, especially when XML is used for exchanging highly structured data between applications, which was not its primary design goal. Other criticisms attempt to refute the claim that XML is a self-describing language[39] (though the XML specification itself makes no such claim). JSON, YAML, and S-Expressions are frequently proposed as alternatives (see Comparison of data serialization formats);[40] which focus on representing highly structured data rather than documents, which may contain both highly structured and relatively unstructured content.
Wikimedia Commons has media related to XML. |
Wikibooks has a book on the topic of: Subject:XML |
|
|
|
|
関連記事 | 「X」 |
.