REC-xml-19980210
REC-xml-19980210
拡張可能マークアップ言語 (XML. Extensible Markup Language) は、SGMLのサブセットであり、この文書の中で完全に記述されている。その目的は、現在HTMLで可能な方法を以って一般性を有するSGMLをウェブ上で配信し、受信し、処理できるようにすることである。XMLは、実装の容易さと、SGMLとHTMLの双方との相互運用性とを目指して設計されている。
この文書は、W3C会員およびその他の利害関係者によって検討され、ディレクターによってW3C勧告として公布されているものである。この文書は安定的であって、参照資料として用いたり、他の文書からの規範的リファレンスとして引用してもよい。勧告作成におけるW3Cの役割は、仕様書に注意をひき、その広範な配備を推進することである。これはウェブの機能性と相互運用性を拡張するものである。
この文書は、広く用いられている既存の国際的なテキスト処理規格 (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) をWWW上での使用のためにサブセット化することにより作成された文法を規定する。これはW3CのXMLアクティビティの産物である。XMLアクティビティの詳細は、http://www.w3.org/XML で見ることができる。現行のW3C勧告およびその他の技術文書のリストは、http://www.w3.org/TR で見ることができる。
この仕様書はURIという用語を使っている。この用語は、[IETF RFC1738] や [IETF RFC1808] を置き換えるものと期待される進行中の作業 [Berners-Lee et al.] によって定義されている。
この仕様書内の既知のエラーの一覧は、http://www.w3.org/XML/xml-19980210-errata で入手可能である。
この文書(原文)のエラーは、xml-editor@w3.org までレポートいただきたい。
拡張可能マークアップ言語 (Extensible Markup Language) は、XMLと略称されるものであり、XML文書と呼ばれるデータオブジェクトのクラスを記述し、一部それを処理するコンピュータプログラムの挙動を記述するものである。XMLは、SGML (the Standard Generalized Markup Language [ISO 8879]) の応用プロファイルあるいは制限形態である。構造により、XML文書は適合的なSGML文書である。
XML文書は、実体 (entity) と呼ばれる記憶単位からなり、実体は解析され、または解析されないデータを包含する。解析されるデータはキャラクタからなり、キャラクタのうちのあるものはキャラクタデータを形成し、あるものはマークアップを構成する。マークアップは、文書の記憶レイアウトや論理的構造の記述をエンコードする。XMLは、記憶レイアウトや論理的構造に制約を課すための機構を提供する。
XMLプロセッサ (XML processor) と呼ばれるソフトウェアモジュールは、XML文書を読んでその内容と構造へのアクセスを提供するために使われる。 XMLプロセッサはアプリケーション (application) と呼ばれる他モジュールのためにその仕事をするものと考えられる。この仕様書は、XMLプロセッサの必須の挙動を、それがXMLデータをどのように読まなければならないか、またアプリケーションに提供しなければならない情報という観点で記述する。
XMLは、W3C (the World Wide Web Consortium) の賛助の下で1996年に構成されたXMLワーキンググループ(もともとは the SGML Editorial Review Board として知られていた)によって開発された。議長は Sun Microsystems の Jon Bosak が務め、これもまたW3Cによって組織された XML Special Interest Group(以前は the SGML Working Group として知られていた)の活発な参加を得た。XMLワーキンググループのメンバー表は付録に与えられている。Dan Connolly がワーキンググループのW3Cとの連絡役として働いた。
XMLについての設計目標は、こうである。
この仕様書は、関連する規格(キャラクタについては Unicode と ISO/IEC 10646、言語識別タグについては Internet RFC 1766、言語名コードについては ISO 636、国別コードについては ISO 3166)とともに、 XMLバージョン 1.0 を理解し、それを処理するコンピュータプログラムを構築するために必要なすべての情報を提供する。
このバージョンのXML仕様書は、すべてのテキストと法律上の注意とに手が付けられない限り、自由に配布してもよい。
XML文書を記述するために使われる用語は、この仕様書の本文に定義されている。以下のリストで定義されている用語は、それらの定義を構築したり、XMLプロセッサの行動を記述する際に使われるものである。
データオブジェクトは、それがこの仕様書において定義されているように整形式であれば、XML文書 (XML document) である。整形式のXML文書は、一定の踏み込んだ制約に沿えば、さらに妥当である場合がある。
各XML文書は、論理的構造と物理的構造との双方を有する。物理的には、文書は、実体 (entity) と呼ばれる記憶単位から構成される。実体は、他の実体を参照 (refer) して、それを文書に組み込んでもよい。文書は "root" または文書実体 (document entity) において開始する。論理的には、文書は、宣言や要素、注釈、キャラクタ参照、処理命令から構成される。これらのものはすべて明示的なマークアップによって文書内に示される。論理的構造および物理的構造は、"4.3.2 Well-Formed Parsed Entities" において記述されている通り、適切にネストされなくてはならない。
| 文書 | ||||
|
document 生成規則に合致するとは、
この結果として、非ルート要素Cそれぞれについて、 Cは、Pの内容の中にあるけれども、Pの内容の中にある他のどの要素の内容の中にもないといった他の要素Pが、文書内に1つある。PをCの親 (parent)といい、CはPの子 (chile)という。
解析される実体は、テキスト (text) すなわち一連の キャラクタからなる。これは、マークアップまたはキャラクタデータを表わす場合がある。 キャラクタ (character) は、ISO/IEC 10646 [ISO/IEC 10646] によって規定されている、テキストの基本単位である。合法なキャラクタは、タブ、キャリッジリターン、ラインフィードと、Unicodeおよび ISO/IEC 10646 の合法なグラフィックキャラクタである。[Unicode] の section 6.8 に定義されている "compatibility characters" の使用はしないように勧められる。
| キャラクタの範囲 | ||||||
|
キャラクタコードをビットパターンにエンコードするための機構は、実体ごとに異なっていてもよい。XMLプロセッサはすべて、10646 の UTF-8 と UFT-16 を受け付けなくてはならない。この2つのうちのどちらが使われているかを知らせ、あるいは他のエンコーディングを持ち込んで使用するための機構は、"4.3.3 実体内のキャラクタエンコーディング" において後述する。
この節は、文法規則において広く用いられている記号をいくつか定義する。
S (空白.white space)は、1個以上のスペース (#x20) キャラクタ、キャリッジリターン、ラインフィード、タブからなる。
| 空白 | ||||
|
便宜上、キャラクタは、文字 (letter)、数字 (digit)、その他のキャラクタに分類される。文字は、1個以上の組み合わせキャラクタ (combining character) が続く場合のあるアルファベット (alphabetic character) や音節基礎キャラクタ (syllabic base character)、あるいは表意キャラクタ (ideographic character) からなる。それぞれのクラスの具体的なキャラクタの定義は、"B. キャラクタクラス" に与えられている。
Name は、1つの文字または数個の句読点 (punctuation) キャラクタのうちの1つで始まり、文字、数字、ハイフン、アンダースコア、コロン、ピリオドが続いたトークンである。"xml" という文字列や、(('X'|'x') ('M'|'m') ('L'|'l')) に合致する任意の文字列で始まる名前は、この仕様書のこのバージョンまたは将来のバージョンにおける標準化のために予約される。
注意: XML名前内部のコロンキャラクタは、名前スペースを用いた実験のために予約される。コロンの意味は将来のある時点で標準化されるものと期待されており、その時点には実験的目的のためにコロンを使っている文書は更新される必要があるかもしれない。(XMLのために採用される名前スペース機構が、実際に名前スペース区切り子としてコロンを使うということの保証はない。) 実際上、このことは、作成者は名前スペースの実験の一部として以外にXML名前の中でコロンを使うべきではないが、XMLプロセッサはコロンを名前キャラクタとして受け付けるべきだということを意味する。
Nmtoken(名前トークン)は、名前キャラクタの任意の混合物である。
| 名前およびトークン | ||||||||||||||||||||
|
リテラルデータは、その文字列の区切り子として使われている引用符を含まない、引用符で括られた任意の文字列である。リテラルは、内部実体 (internal entity) の内容 (EntityValue)、属性の値 (AttValue)、外部識別子 (SystemLiteral) の内容を規定するために使われる。SystemLiteral はマークアップをスキャンせずに解析できることに注意すること。
| リテラル | ||||||||||||||||||||||||||||
|
テキストは、入り交じったキャラクタデータとマークアップからなる。 マークアップ (markup) は、 開始タグ (start-tag)、 終了タグ (end-tag)、 空要素タグ (empty-element tag)、 実体参照 (entity reference)、 キャラクタ参照 (character reference)、 注釈 (comment)、 CDATA 部 (CDATA section) 区切り子 (delimiter)、 文書型宣言 (document type declaration)、 処理命令 (processing instruction) という形を取る。
マークアップでないすべてのテキストは、文書のキャラクタデータ (character data) を構成する。
アンパサンドキャラクタ (&) と小なり不等号 (<) がリテラル形式で現れてよいのは、 マークアップ区切り子として使われるとき、または注釈、処理命令、CDATA 部の内部にあるときだけである。これらは内部実体宣言のリテラル実体値の内部でも合法である。"4.3.2 Well-Formed Parsed Entities" を見ること。それ以外の場所で必要であるならば、 数的キャラクタ参照 (numeric character references) か、それぞれ "&"、"<" という文字列を使ってエスケープされなければならない。大なり不等号 (>) は、">" という文字列を使って表わされてもよく、また、それが内容中の "]]>" という文字列の中で現れるとき、その文字列が CDATA 部の末尾をマークしていないときは、互換性のため、">" またはキャラクタ参照を使ってエスケープされなければならない。
要素の内容の中では、キャラクタデータとは、どのマークアップの開始区切り子も包含しない任意のキャラクタ文字列である。CDATA 部の中では、キャラクタデータとは、CDATA 部終了区切り子 "]]>" を含まない任意のキャラクタ文字列である。
属性値が単引用符と二重引用符の両方を包含できるようにするため、アポストロフィまたは単引用符キャラクタ (') は "'" と表わしてよく、二重引用符キャラクタ (") は """ と表わしてよい。
| キャラクタデータ | ||||
|
注釈 (comment) は、他のマークアップの外側ならば文書内のどこに現れてもよい。さらに、文法によって認められている場所ならば、文書型宣言の内部に現れてもよい。注釈は、文書のキャラクタデータの一部分ではない。XMLプロセッサは、アプリケーションがコメントのテキストを引きだすことを可能にしてもよいが、可能にする必要はない。互換性のため、"--" という文字列(ダブルハイフン)は、注釈の内部で発生してはならない。
| 注釈 | ||||
|
注釈の例
<!-- declarations for <head> & <body> -->
|
処理命令 (processing instruction, PI) は、文書がアプリケーションのための命令を包含できるようにする。
| 処理命令 | ||||||||
|
処理命令は、文書のキャラクタデータの一部ではないが、アプリケーションにそのまま渡されなくてはならない。処理命令は、命令が向けられている先のアプリケーションを識別するために使われるターゲット (PITarget) で始まる。"XML" や "xml" などのターゲット名は、この仕様書のこのバージョンまたは将来のバージョンにおける標準化のために予約されている。XML表記機構 (the XML Notation mechanism) は、PIターゲットの形式的宣言のために使ってもよい。
CDATA 部 (CDATA section) は、キャラクタデータが発生してよい場所ならばどこで発生してもよい。CDATA 部は、さもなくばマークアップとして認識されるキャラクタを包含するテキストのブロックをエスケープするために使われる。CDATA 部は "<![CDATA[" という文字列で始まり、"]]>" という文字列で終わる。
| CDATA 部 | ||||||||||||||||
|
CDATA 部の内部では、CDEnd 文字列だけがマークアップとして認識されるから、小なり不等号やアンパサンドはリテラル形式で発生してもよい。これらは "<" や "&" を使ってエスケープする必要はない(し、エスケープできない)。CDATA 部はネストできない。
CDATA 部の例。ここでは "<greeting>" や "</greeting>" はマークアップではなくキャラクタデータとして認識される。
<![CDATA[<greeting>Hello, world!</greeting>]]>
|
XML文書は、使われているXMLのバージョンを指定するXML宣言 (XML declaration) で始まってよく、また始まるべきである。たとえば、下記は完全なXML文書であり整形式であるが、妥当ではない。
<?xml version="1.0"?>
|
また、これもそうである。
<greeting>Hello, world!</greeting>
|
この仕様書のこのバージョンへの適合性を示すためには "1.0" というバージョン番号が使われるべきである。文書がこの仕様書のこのバージョンに適合しないならば、"1.0" という値を使うことはエラーである。この仕様書の今後のバージョンに "1.0" 以外の番号を与えることがXMLワーキンググループの意図ではあるが、この意図は、将来のバージョンのXMLを作成することや、作成されたとしても特定の番号づけスキームを使うことのコミットメントを示すものではない。将来のバージョンは排除されていないので、もし自動バージョン認識が必要になればそのの可能性を与える手段として、この構造が提供されている。プロセッサがサポートしないバージョンのラベルがついた文書を受け取った場合、プロセッサはエラーを発信してもよい。
XML文書におけるマークアップの機能は、その記憶や論理的構造を記述し、属性と値の対をその論理的構造に結びつけることである。XMLは、論理的構造の制約を定義し、定義済みの記憶単位の利用をサポートするため、文書型宣言という機構を提供する。 XML文書は、結び付けられた文書型宣言を有し、かつ文書が文書型宣言の中に表わされた制約に準拠すれば、妥当である。
文書型宣言は、文書内で最初の要素の前に現れなければならない。
| 前書き | ||||||||||||||||||||||||
|
XML文書型宣言は、文書のクラスに文法を提供するマークアップ宣言を包含し、またはそれを指し示す。この文法は文書型定義またはDTDとして知られている。文書型宣言は、外部サブセット(特殊な種類の外部実体)を指し示し、あるいは内部サブセットの中に直接にマークアップ宣言を包含することができ、その両方をすることもできる。文書のためのDTDは、両方のサブセットを一つにまとめたものからなる。
マークアップ宣言は、 要素型宣言 (element type declaration) か、 属性リスト宣言(attribute-list declaration)、 実体宣言(entity declaration)、 表記宣言(notation declaration) である。これらの宣言は、下記の整形式性制約および妥当性制約に記述されているように、全部または一部がパラメータ実体の内部に包含される。より完全な情報は "4. 物理的構造" を見ること。
| 文書型宣言 | ||||||||||||||||||
|
マークアップ宣言は、全部または一部がパラメータ実体の置換テキストからなる場合がある。この仕様書内の個別の中間生成規則(non-terminal. elementdecl や AttlistDecl など)を表わす後出の生成規則は、パラメータ実体がすべて取り込まれた後で宣言を記述する。
妥当性制約: ルート要素型
文書型宣言の中の Name は、ルート要素の要素型に合致しなければならない。
妥当性制約: 適切な宣言/PEのネスト
パラメータ実体置換テキストは、マークアップ宣言を用いて適切にネストされなければならない。すなわち、マークアップ宣言(上記の markupdecl)の最初のキャラクタと最後のキャラクタとの一方がパラメータ実体参照の置換テキストの中に包含されていれば、 両方とも同じ置換テキストに包含されていなければならない。
整形式性制約: 内部サブセット内のPE
内部DTDサブセットの中では、パラメータ実体参照は、マークアップ宣言の内部ではなく、マークアップ宣言が発生できる場所でしか発生できない。(これは、外部パラメータ実体の中で発生する参照や、外部サブセットには適用されない。)
内部サブセットのように、外部サブセットや、DTD内で参照されている外部パラメータ実体は、 中間生成規則記号 markupdecl によって認められた型の完全なマークアップ宣言に空白やパラメータ実体参照が混じったものの連なりで構成されていなければならない。しかしながら、外部サブセットまたは外部パラメータ実体の内容は、条件的セクション (conditional section) 構造を使うことにより、条件によって無視される場合がある。これは内部サブセットの中では認められない。
| 外部サブセット | ||||||||
]
|
外部サブセットや外部パラメータ実体は、その中ではマークアップ宣言の間だけでなくマークアップ宣言の内部ででもパラメータ実体参照が許されるという点でも、内部サブセットと異なる。
文書型宣言のあるXML文書の例
<?xml version="1.0"?>
|
文書のDTDのURIはシステム識別子 (system identifier) "hello.dtd" が与える。
この例のように、宣言はローカルに与えることもできる。
<?xml version="1.0" encoding="UTF-8" ?>
|
外部サブセットと内部サブセットの両方が使われていれば、内部サブセットが外部サブセットの前に発生したものとみなされる。このことは、内部サブセット内の実体宣言や属性宣言が、外部サブセット内のものに優先するという効果を有する。
マークアップ宣言は、XMLプロセッサからアプリケーションに渡されるときに、文書の内容に影響を及ぼすことができる。例は、属性デフォルトや実体の宣言である。スタンドアローン文書宣言はXML宣言の構成部分として現れてよいが、これは文書実体にとって外部的に見えるそうした宣言の有無を発信するものである。
| スタンドアローン文書宣言 | ||||||
|
スタンドアローン文書宣言の中では、"yes" という値は、XMLプロセッサからアプリケーションへ渡される情報に影響する文書実体にとって外部的なマークアップ宣言が (DTD外部サブセット内か、内部サブセットから参照される外部パラメータ実体内かのいずれかに)ないことを示す。"no" という値は、そうした外部マークアップ宣言があり、またはあるかもしれないことを示す。スタンドアローン文書宣言は外部宣言の存在を示すだけであることに注意すること。外部実体が内部的に宣言されるとき、そうした実体への参照が文書内に存在しても、文書のスタンドアローン状態を変化させない。
外部マークアップ宣言がなければ、スタンドアローン文書宣言は無意味である。外部マークアップ宣言があり、スタンドアローン文書宣言がなければ、"no" という値があるものとされる。
standalone="no" が当てはまるXML文書は、アルゴリズム的にスタンドアローン文書に変換できる。スタンドアローン文書は、いくつかのネットワーク配信アプリケーションにとって望ましい場合がある。
妥当性制約: スタンドアローン文書宣言
外部マークアップ宣言のどれかが、
amp, lt, gt, apos, quot 以外)への参照が文書内に現れる場合は、これらの実体
no" という値をもたなければならない。
スタンドアローン文書宣言をもつXML宣言の例
<?xml version="1.0" standalone='yes'?>
|
XML文書の編集において、マークアップを離して置いて読みやすくするために 「空白 (white space)」(スペース、タブ、改行.この仕様書内では中間生成規則 S によって示されている)を使うことが便利であることがよくある。そうした空白は大概、文書の配信版の中に組み込まれることは意図されていない。他方、たとえば詩歌やソースコードなどにおいては、配信版でも保存されるべき「重要な」空白が一般的である。
XMLプロセッサは、マークアップでない文書中のすべてのキャラクタを、つねにそのままアプリケーションへ渡さなければならない。妥当性を検証するXMLプロセッサは、これらのキャラクタのどれが要素内容内に現れている空白を構成するかもアプリケーションに知らせなくてはならない。
その要素の中で空白がアプリケーションによって保存されるべきとの意図を知らせるために、xml:space という名前の特殊な属性を要素に添付してもよい。妥当な文書では、他と同様に、この属性が使われるならば宣言されなければならない。宣言されるときには、取りうる値が "default" と "preserve" だけの 列挙された型 (enumerated type) として与えられなくてはならない。例.
<!ATTLIST poem xml:space (default|preserve) 'preserve'>
|
"default" という値は、アプリケーションのデフォルトの空白処理モードがこの要素にとって受付可能であることを知らせる。"preserve" という値は、アプリケーションが空白をすべて保存することの意図を示す。この宣言された意図は、xml:space 属性の他のインスタンスで上書きされない限り、それが指定されている要素の内容の内部にある要素すべてに適用されるものとみなされる。
どの文書のルート要素も、この属性の値が与えられるか、または属性がデフォルト値で宣言されるかしない限り、アプリケーション空白処理に関して何の意図も知らせなかったものとみなされる。
XML解析される実体は、編集の便宜上複数行に組織されたコンピュータファイルに保存されることがよくある。これらの行は、概して、キャリッジリターン (#xD) とラインフィード (#xA) のキャラクタの組み合わせによって分離される。
アプリケーションの仕事を単純化するため、 解析される外部実体、または解析される内部実体のリテラル実体値が、"#xD#xA" というリテラルな2キャラクタの列か、孤立したリテラルな #xD かを包含する場所ならばどこであっても、 XMLプロセッサはアプリケーションに #xA という単一のキャラクタを渡さなければならない。(この挙動は、解析前、入力時に改行すべてを #xA に標準化することにより、簡便に生み出すことができる。)
文書処理において、内容を書いている自然的または形式的言語を識別することが便利なことがよくある。XML文書内の任意の要素の内容や属性値で使われている言語を指定するために、xml:lang という名前の特殊な属性を文書に挿入してもよい。妥当な文書では、他と同様に、この属性が使われるのであれば 宣言されなければならない。属性の値は [IETF RFC 1766], "Tags for the Identification of Languages" で定義されている言語識別子である。
| 言語の識別 | ||||||||||||||||||||||||
|
Langcode は、以下のどれであってもよい。
i-"(または "i-")というプレフィックスで始まる。
x-" または "-X" というプレフィックスで始まらなければならない。
Subcode セグメントは何個あってもよい。もし最初のサブコードセグメントが存在し、その Subcode が2文字からなるのであれば、[ISO 3166], "Codes for the representation of names of countries" による国別コードでなくてはならない。最初のサブコードが3文字以上からなるならば、Langcode が "x-" または "X-" というプレフィックスで始まるのでない限り、 問題の言語を表わす IANA で登録されたサブコードでなければならない。
言語コードは小文字で、また国コードは(あれば)大文字で与えるのが慣例である。これらの値はXML文書内の他の名前と違って大文字小文字の区別がないことに注意すること。
例.
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
|
xml:lang で宣言されている意図は、その内容の内部にある他の要素上で xml:lang のインスタンスで上書きされない限り、 それが指定されている要素の属性および内容のすべてに適用されるものとみなされる。
xml:lang を表わす単純な宣言は、
xml:lang NMTOKEN #IMPLIED
|
というような形をとることになるが、もしそれが適切ならば特定のデフォルト値も与えられてよい。英語で解説や注釈がついたイギリスの学生向けフランス詩集では、xml:lang 属性はこのように宣言されることになるだろう。
<!ATTLIST poem xml:lang NMTOKEN 'fr'>
|
各XML文書は 1つ以上の要素 (element) を包含し、この要素の境界は開始タグ (start-tag) と 終了タグ (end-tag) によって、 あるいは空要素については空要素タグ (empty-element tag) によって区切られている。要素はそれぞれ、ときにその「一般的識別子 (generic identifier. GI)」と呼ばれる名前によって識別される型 (type) をもち、また1セットの属性指定をもつ場合もある。属性指定はそれぞれ1つの名前 (name) と1つの 値 (value) をもつ。
| 要素 | ||||||||||||||||
|
この仕様書は、要素型および属性の意味や使用法、(文法論を超えた)命名法を包含しない。ただし、(('X'|'x')('M'|'m')('L'|'l')) と合致するもので始まる名前は、この仕様書のこのバージョンまたは将来のバージョンにおける標準化のために予約される。
整形式性制約: 要素型の合致
要素の終了タグの Name は、開始タグの要素型と合致しなければならない。
妥当性制約: 要素の妥当性
要素は、Name が要素型と合致する elementdecl に合致する宣言があり、以下の1つが当てはまるならば、妥当である。
EMPTY に合致し、要素が内容をもたない。
children に合致し、 子要素の連なりが、子要素の各対の間に任意的な空白(中間生成規則 S に合致するキャラクタ)がある内容モデルの中の正規の表現によって生成された言語に属する。
Mixed に合致し、内容が、その型が内容モデル内の名前に合致するキャラクタデータと子要素とからなる。
どれかに合致し、どの子要素の型も宣言されている。
空でないXML要素の最初は開始タグ (start-tag) でマークされる。
| 開始タグ | ||||||||||||||||||||||||
|
開始タグおよび終了タグの Name は要素の型 (type) を与える。 Name-AttValue の対は、要素の属性指定 (attribute specification) という。 それぞれの対の Name は属性名 (attribute name) といい、 AttValue の内容(' または " 区切り子の間のテキスト)は属性値 (attribute value) という。
整形式性制約: 属性指定の一意性
同じ開始タグまたは空要素タグの中に2回以上現れてよい属性名はない。
妥当性制約: 属性値の型
属性は宣言されていなければならない。値は、その属性について宣言された型のものでなくてはならない。(属性型については、"3.3 属性リスト宣言" を見ること。)
整形式性制約: 外部実体参照の禁止
属性値は、外部実体への直接または間接の実体参照を包含することができない。
整形式性制約: 属性値内の < の禁止
("<" 以外の)属性値の中で直接または間接に参照されている実体の置換テキストは、< を包含してはならない。
開始タグの例
<termdef id="dt-dog" term="dog">
|
開始タグで始まる要素の最後は、開始タグで与えられた要素型をエコーする名前を包含している 終了タグ (end-tag) によってマークされなくてはならない。
| 終了タグ | ||||
|
終了タグの例
</termdef>
|
開始タグと終了タグの間のテキストは、要素の内容 (content) と呼ばれる。
| 要素の内容 | ||||
|
要素が空 (empty) であれば、要素は、開始タグの直後に終了タグを続けたもの、または空要素タグによって表現されなければならない。 空要素タグ (empty-element tag) は特別な形をとる。
| 空要素用のタグ | ||||||
|
空要素タグは、EMPTY というキーワードを使って定義されているか否かを問わず、内容をもたない任意の要素を表わすために使ってよい。相互運用性のため、EMPTY と宣言されている要素については空要素タグを使わなくてはならず、また空要素タグを使うことができるのはその要素についてのみである。
空要素の例
<IMG align="left"
|
XML文書の要素構造は、解析の目的のために、要素型宣言と属性リスト宣言を使って制約してもよい。要素型宣言は、要素の内容を制約するものである。
要素型宣言は、しばしば、どの要素型が要素の子として現れることができるかを制約する。ユーザの選択により、XMLプロセッサは、ある宣言が、宣言を与えられていない要素型に言及するときには警告を発行してもよいが、これはエラーではない。
要素型宣言 (element type declaration) は、このような形をとる。
| 要素型宣言 | ||||||||||
|
ここでは Name は、宣言されている要素型を与える。
妥当性制約: 要素型宣言の一意性
2度以上宣言してよい要素型はない。
要素型宣言の例
<!ELEMENT br EMPTY>
|
その要素型の要素が、 任意的に空白(中間生成規則 S に合致するキャラクタ)で分離された子要素だけを含まなくてはならない(キャラクタデータは含んではならない)とき、 その要素型は要素内容 (element content) をもつ。この場合、制約は、内容モデル、すなわち、子要素の許容される型とそれらが出現を許される順序とを支配する単純な文法を取り込む。文法は内容パーティクル (cp) に基づいて構築される。内容パーティクルは、名前および内容パーティクルの選択リスト、内容パーティクルの順列リストからなる。
| 要素内容モデル | ||||||||||||||||||||
|
ここでは各 Name は、子として現れてよい要素の型である。選択リスト内にある内容パーティクルは、文法中で選択リストが現れる位置の要素内容の中に現れてよい。順列リスト内に発生する内容パーティクルは各自、リスト内に与えられた順序で要素内容の中に現れなくてはならない。名前やリストに続いている任意的なキャラクタは、その要素やそのリスト内の内容パーティクルが、1回以上 (+)、0回以上 (*)、0回または1回 (?) 現れてよいか否かを支配する。そうした演算子が存在しないのは、要素や内容パーティクルがちょうど1回現れなくてはならないという意味である。この文法と意味はこの仕様書の生成規則で使われているものと同じである。
要素の内容は、順列、選択、繰り返し演算子に従って、内容の中の各要素を内容モデル内の要素型と照合し、内容モデルを通じてパスを追跡できる場合には、またできる場合にのみ、内容モデルに合致する。互換性のため、文書内の要素が内容モデル内の1つの要素型の1回の出現を超えて合致できるならば、エラーである。さらなる情報は、"E. 決定的内容モデル" を見ること。
妥当性制約: グループ/PEの適切なネスト
パラメータ実体置換テキストは、括弧で括られたグループを用いて適切にネストされなければならない。すなわち、choice、seq、Mixed 構造の中の左括弧または右括弧のどちらかが パラメータ実体の置換テキストに包含されるならば、両方とも同じ置換テキストに包含されなければならないのである。相互運用性のため、choice、seq、Mixed 構造の中にパラメータ実体参照が現れるならば、 その置換テキストは空であるべきではなく、また置換テキストの最初の非ブランクキャラクタも最後の非ブランクキャラクタもコネクタ(| または ,)であるべきではない。
要素内容モデルの例
<!ELEMENT spec (front, body, back?)>
|
その型の要素が、任意的に子要素が混じったキャラクタデータを包含してよいとき、要素型は混在内容 (mixed content) をもつ。この場合、子要素の型は制約されることがあるが、その順序や出現数は制約されない。
| 混在内容宣言 | ||||||||||||||||
|
ここでは Name は、子として現れてよい要素の型を与える。
妥当性制約: 型の重複の禁止
単一の混在内容宣言の中に同じ名前は2度以上現れてはならない。
混在内容宣言の例
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
|
属性 (attribute) は、名前-値の対を要素に結びつけるために使われる。属性指定が現れてよいのは、開始タグ、空要素タグの内部だけである。したがって、それらを認識するために使われる生成規則は "3.1 開始タグ、終了タグ、空要素タグ" にある。属性リスト宣言は、
属性リスト宣言 (attribute-list declaration) は、与えられた要素型と結び付けられる各属性の名前、データ型、(あれば)デフォルト値を指定する。
| 属性リスト宣言 | ||||||||
|
AttlistDecl 規則の Name は、要素の型である。ユーザの選択により、それ自身が宣言されていない要素型のために属性が宣言されれていれば、XMLプロセッサは警告を発行してもよいが、これはエラーではない。AttDef 規則の Name は属性の名前である。
与えられた要素型に2つ以上の AttlistDecl が与えられているとき、与えられたすべてのものの内容が併合される。与えられた要素型の同じ属性に2つ以上の定義が与えられているときは、最初の宣言が拘束的であり、後の宣言は無視される。相互運用性のため、DTDのライターは、与えられた要素型について最大で1つの属性リスト宣言を、与えられた属性名について最大で1つの属性定義を、各属性宣言には少なくとも1つの属性定義を与えることを選んでもよい。相互運用性のため、ユーザの選択で、XMLプロセッサは与えられた要素型について2つ以上の属性リスト宣言が与えられ、あるいは与えられて属性に2つ以上の属性定義が与えられているときに警告を発行してもよいが、 これはエラーではない。
XML属性型は3種類、文字列型、トークン型のセット、列挙型である。文字列型は、任意のリテラル文字列を値としてとってよい。トークン化型は、注記されているように、変動する辞書的および意味的制約をもつ。
| 属性型 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
妥当性制約: ID
ID 型の値は Name 生成規則に合致しなければならない。1つの名前がXML文書内に2回以上この型の値として現れてはならない。すなわち、ID値は、それをもつ要素を一意的に識別しなければならないのである。
妥当性制約: 1要素1ID
2つ以上のID属性を指定してよい要素型はない。
妥当性制約: ID属性デフォルト
ID属性は、#IMPLIED または #REQUIRED の宣言されたデフォルトをもたなければならない。
妥当性制約: IDREF
IDREF 型の値は Name 生成規則に合致しなければならず、IDREFS 型の値は Names に合致しなければならない。各 Name は、XML文書内のある要素上のID属性の値に合致しなければならない。すなわち、IDREF 値が何かのID属性の値に合致しなければならないのである。
妥当性制約: 実体名
ENTITY 型の値は Name 生成規則に合致しなければならず、ENTITIES 型の値は Names に合致しなければならない。それぞれの Name は、DTDに宣言されている解析されない実体の名前に合致しなければならない。
妥当性制約: 名前トークン
NMTOKEN 型の値は Nmtoken 生成規則に合しなければならず、NMTOKENS 型の値は Nmtokens に合致しなければならない。
列挙属性 (enumerated attribute) は、宣言の中で与えられた値のリストの1つをとることができる。列挙型には2つの種類がある。
| 列挙属性型 | ||||||||||||||||
|
NOTATION 属性は、関係づけられたシステム識別子および/またはパブリック識別子を用いてDTDで宣言され、 その属性が添付される要素を解釈するときに使われるべき 表記法 (notation) を識別する。
妥当性制約: 表記法属性
この型の値は、宣言に取り込まれている表記法の名前の1つに合致しなければならない。宣言内のすべての表記法名は宣言されなくてはならない。
妥当性制約: 列挙
この型の値は、宣言内の Nmtoken トークンの1つに合致しなければならない。
相互運用性のため、単一の要素型の列挙属性型の中で同じ Nmtoken は2度以上発生するべきではない。
属性宣言は、その属性の存在が必須であるか否か、必須でない場合には宣言された属性が文書内にないときにXMLプロセッサがどのように反応すべきかについての情報を与える。
| 属性デフォルト | ||||||||||||||||||||||||||||
|
属性宣言において、#REQUIRED はその属性がつねに与えられなければならないことを意味し、#IMPLIED はデフォルト値が与えられないことを意味する。 宣言が #REQUIRED でも #IMPLIED でもないならば、AttValue 値は宣言されたデフォルト (default) 値を包含する。#FIXED というキーワードは、属性がつねにデフォルト値をもたなくてはならないことを宣明する。デフォルト値が宣言されていれば、XMLプロセッサが省略された属性に遭遇したとき、プロセッサはその属性が宣言されたデフォルト値つきで存在するかのように動作することになる。
妥当性制約: 必須属性
デフォルト宣言が #REQUIRED というキーワードならば、属性リスト宣言内の型のすべての要素に属性が指定されなければならない。
妥当性制約: 属性デフォルトの合法性
宣言されたデフォルト値は、宣言された属性型の辞書的制約に沿わなければならない。
妥当性制約: 固定属性デフォルト
属性が #FIXED キーワードで宣言されたデフォルト値をもつならば、その属性の具体値(インスタンス)はデフォルト値に合致しなければならない。
属性リスト宣言の例
<!ATTLIST termdef
|
属性の値がアプリケーションに渡され、あるいは妥当性をチェックされる前に、XMLプロセッサは属性値を以下のように標準化しなければならない。
宣言された値が CDATA でなければ、XMLプロセッサは、先頭または末尾についているスペース (#x20) キャラクタを切り捨てて スペース (#x20) キャラクタの並びを単一のスペース (#x20) キャラクタで置き換えることにより標準化された属性値をさらに処理しなければならない。
宣言が読まれていない属性はすべて、妥当性を検証しないパーサにより、それが CDATA であるかのように扱われるべきである。
条件的セクション (conditional section) は、それらを支配するキーワードに基づいてDTDの論理的構造に取り込まれあるいは排除される文書型宣言外部サブセットの一部分である。
| 条件的セクション | ||||||||||||||||||||
|
内部および外部DTDサブセットのように、条件的セクションは、1つ以上の完全な宣言、注釈、処理命令、ネストされた条件的セクションに空白が混じったものを包含してよい。
条件的セクションのキーワードが INCLUDE であれば、条件的セクションの内容はDTDの一部である。条件的セクションのキーワードが IGNORE であれば、条件的セクションの内容は、論理的にはDTDの一部ではない。信頼できる解析のためには、ネストされた条件セクションを探知して最も外側の(無視される)条件的セクションの末尾が適切に探知されることを保証するため、無視される条件的セクションであっても内容が読まれなければならないことに注意すること。INCLUDE のキーワードがついた条件的セクションが IGNORE のキーワードがついたより大きな条件的セクションの内部で発生するならば、条件的セクションは外側のものも内側のものも両方とも無視される。
条件的セクションのキーワードがパラメータ実体参照であれば、パラメータ実体は、プロセッサがその条件的セクションを取り込むか無視するかを決定する前にその内容によって置換されなければならない。
例.
<!ENTITY % draft 'INCLUDE' >
|
XML文書は、1つまたは多数の記憶単位からなっていてもよい。これらは実体 (entity) と呼ばれる。実体はすべて内容 (content> を有し、(下記の通り文書実体と外部DTDサブセットを除き)すべて名前 (name) で識別される。XML文書はそれぞれ、文書実体 (document entity) と呼ばれる実体を1つ有する。この文書実体は、XMLプロセッサにとっての出発点として働くものであり、文書全体を包含してもよい。
実体は、解析されるものでも解析されないものでもよい。 解析される実体の内容はその置換テキストとして参照される。このテキストは文書の統合的部分とみなされる。
解析されない実体は、内容がテキストであってもなくてもよく、テキストであってもXMLでなくてよいリソースである。解析されない実体は各自、結び付けられた表記法 (notation) を有し、名前で識別される。XMLプロセッサが実体の識別子と表記法をアプリケーションに利用可能にするという要求を超えては、XMLは解析されない実体の内容に制約を課さない。
解析される実体は、実体参照を用いて、名前で呼び出される。解析されない実体は名前で呼び出されるが、この名前は ENTITY 属性または ENTITIES 属性の値の中で与えられる。
一般的実体 (general entity) は、文書内容の内部で使うための実体である。この仕様書では、あいまいさを導かないときには、一般的実体はときに実体という無限定の用語で呼ばれることがある。 パラメータ実体は、DTD内部で使うための解析される実体である。これら2タイプの実体は、異なる参照形式を使い、異なる文脈において認識される。それだけではなく、これらは異なる名前スペースを占める。同じ名前をもつパラメータ実体と一般的実体とは、2つの区別される実体である。
キャラクタ参照 (character reference) は、ISO/IEC 10646 キャラクタセットの特定のキャラクタ、たとえば利用可能な入力デバイスから直接にアクセスできないキャラクタを参照する。
| キャラクタ参照 | ||||||||||
|
整形式性制約: キャラクタの合法性
キャラクタ参照を使って参照されているキャラクタは Char を表わす生成規則に合致しなければならない。
&#x" で始まるならば、終端 ; までの数字および文字は ISO/IEC 10646 におけるキャラクタコードの16進表記を与える。単に "&#" で始まるならば、終端 ; までの数字はキャラクタコードの10進表記を与える。
実体参照 (entity reference) は、指名された実体 (named entity) の内容を参照する。 一般的解析される実体への参照は、区切り子としてアンパサンド (&) とセミコロン (;) を使う。 パラメータ実体参照 (parameter-entity reference) は、区切りとしてパーセント記号 (%) とセミコロン (;) を使う。
| 実体参照 | ||||||||||||||||||||||||||||||||||||||||||||||
|
整形式性制約: 実体の宣言
DTDのない文書や、パラメータ実体参照を包含しない内部DTDサブセットだけしかない文書、"standalone='yes'" の文書においては、 実体参照において与えられている Name が実体宣言の中のものと合致しなければならない。ただし、整形式文書は、以下の実体は宣言する必要はない。amp, lt, gt, apos, quot. パラメータ実体の宣言は、それに対する参照のどれよりも先行しなければならない。同様に、一般的実体の宣言は、属性リスト宣言内のデフォルト値で現れる、それに対するどの参照よりも先行しなければならない。実体が外部サブセットや外部パラメータ実体の中で宣言されていれば、妥当性を検証しないプロセッサはそれらの宣言を読んで処理することを義務づけられないことに注意すること。そうした文書については、実体は宣言されなくてはならないという規則は standalone='yes' である場合に限って整形式性制約となる。
妥当性制約: 実体の宣言
"standalone='no'" のある外部サブセットまたは外部パラメータ実体を有する文書においては、実体参照内で与えられる Name は 実体宣言の中のものと合致しなければならない。相互運用性のため、妥当な文書は、amp, lt, gt, apos, quot という実体を "4.6 定義済み実体" において規定される形式で宣言するべきである。パラメータ実体の宣言は、それに対する参照のどれにも先行しなければならない。同様に、一般的実体の宣言は、属性リスト宣言の中のデフォルト値の中に現れる、それに対する参照のどれにも先行しなければならない。
整形式性制約: 解析済み実体
実体参照は 解析されない実体の名前を包含してはならない。解析されない実体が参照されてもよいのは ENTITY 型または ENTITIES 型として宣言された属性値の中だけである。
整形式性制約: 再帰の禁止
解析される実体は、直接間接を問わずそれ自身への再帰的参照を包含してはならない。
整形式性制約: DTD内
パラメータ実体参照が現れてよいのはDTDの中だけである。
キャラクタ参照、実体参照の例
T ype <key>less-than</key> (<) to save options.
|
パラメータ実体参照の例
<!-- declare the parameter entity "ISOLat2"... -->
|
| 実体宣言 | ||||||||||||||||||||
|
Name は、実体参照の中の実体、 あるいは解析されない実体の場合には ENTITY 属性または ENTITIES 属性の値の中の実体を識別する。同じ実体が2回以上宣言されていれば、最初の宣言が拘束的である。ユーザの選択により、実体が複数回宣言されていればXMLプロセッサは警告を発行してもよい。
実体宣言が EntityValue であれば、宣言された実体は内部実体 (internal entity) と呼ばれる。分離した物理的記憶オブジェクトはなく、実体の内容は宣言の中で与えられる。リテラル実体値で表わされた実体やキャラクタ参照の中には、正しい置換テキストを生み出すことが要求される場合があるものがある。"4.5 内部実体置換テキストの構造" を見ること。
内部実体は解析される実体である。
内部実体宣言の例
<!ENTITY Pub-Status "This is a pre-release of the
|
実体は、内部的でなければ、外部実体 (external entity) であり、以下のように宣言される。
| 外部実体宣言 | ||||||||||||||
|
NDataDecl があれば、これは一般的な解析されない実体である。それ以外の場合は解析される実体である。
妥当性制約: 表記法の宣言
Name は表記法の宣言された名前に合致しなければならない。
SystemLiteral は実体のシステム識別子 (system identifier) と呼ばれる。これはURIであり、実体を引き出すために使われる場合がある。よくURIと一緒に使われるハッシュマーク (#) やフラグメント識別子は、形式的にはURIそのものではないことに注意すること。フラグメント識別子がシステム識別子の一部として与えられていれば、XMLプロセッサはエラーを発信してもよい。この仕様書の外部にある情報(例.特定のDTDによって定義されている特殊なXML要素型や、特定のアプリケーションの仕様によって定義されている処理命令)によって別段与えられているのでない限り、 相対URIは、実体宣言があるリソースの位置との相対比較である。したがって、URIは、文書実体、外部DTDサブセットを包含している実体、 あるいはその他の外部パラメータ実体との相対比較である。
XMLプロセッサは、UTF-8 を用いてURI内の非 ASCII キャラクタを1バイトまたはそれ以上のバイトとして表現し、これらのバイトをURIエスケープ機構を用いてエスケープすることにより (すなわち、各バイトを %HH に変形することにより。ここで HH はバイト値の16進表記である)扱うべきである。
システム識別子に加えて、外部識別子はパブリック識別子 (public identifier) を取り込んでもよい。実体の内容を引き出そうと試みるXMLプロセッサは、パブリック識別子を使って代替URIを生成しようとしてもよい。プロセッサがそのようにできないならば、システムリテラルで指定されているURIを使わなければならない。照合が試みられる前に、パブリック識別子の中の空白文字列はすべて単一のスペースキャラクタ (#x20) に標準化されなければならず、先頭および末尾の空白は除去されなければならない。
外部実体宣言の例
<!ENTITY open-hatch
|
解析される外部実体はそれぞれ、テキスト宣言 (text declaration) で始まる場合がある。
| テキスト宣言 | ||||
|
テキスト宣言は、解析される実体への参照によってではなく、リテラルに与えられなければならない。解析される外部実体の最初以外の位置に現れてよいテキスト宣言はない。
文書実体は、document という名前の生成規則に合致すれば、整形式である。一般的解析される外部実体は、extParsedEnt という名前の生成規則に合致すれば、整形式である。外部パラメータ実体は、extPE という名前の生成規則に合致すれば、整形式である。
| 整形式の解析される外部実体 | ||||||||
|
一般的な解析される内部実体は、その置換テキストが content という名前の生成規則に合致すれば、整形式である。内部パラメータ実体は、定義により、すべて整形式である。
実体における整形式性の結果は、XML文書内の論理的および物理的構造が適切にネストされているということである。どの開始タグ、終了タグ、空要素タグ、要素、注釈、処理命令、キャラクタ参照、実体参照も、ある実体の中で始まって他の実体の中で終わることはできない。
XML文書内の解析される外部実体は各自、キャラクタを表わすのに異なるエンコーディングを使ってもよい。XMLプロセッサはすべて UTF-8 または UTF-16 で書かれた実体を読むことができなければならない。
UTF-16 でエンコードされた実体は、ISO/IEC 10646 Annex E および Unicode Appendix B によって記述されているバイト順マーク (the Byte Order Mark. the ZERO WIDTH NO-BREAK SPACE charecter, #xFEFF) で始まらなければならない。これは、エンコーディング署名であって、XML文書のマークアップやキャラクタデータの一部分ではない。UTF-8 と UTF-16 でエンコードされた文書を区別するために、XMLプロセッサはこのキャラクタを使えなければならない。
XMLプロセッサは UTF-8 と UTF-16 エンコーディングで書かれた実体を読むことだけしか要求されないが、他のエンコーディングが世界中で使われていることが認識され、XMLプロセッサがそれらを使った実体を読むことが望ましい場合がある。UTF-8 または UTF-16 以外のエンコーディングで記録されている解析される実体は、エンコーディング宣言を包含するテキスト宣言 (text declaration) で始まらなければならない。
| エンコーディング宣言 | ||||||||||
|
文書実体において、エンコーディング宣言はXML宣言の一部である。EncName は使われているエンコーディングの名前である。
エンコーディング宣言においては、Unicode / ISO/IEC 10646 の様々なエンコーディングとを表わすためには "UTF-8", "UTF-16", "ISO-10646-UCS-2", "ISO-10646-UCS-4" という値が使われるべきであり、ISO 8850 の一部を表わすためには "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-9" という値が使われるべきであり、JIS X-0208-1997 の様々なエンコードされた形式を表わすためには "Shift-JIS", "Shift_JIS", "EUC-JP" という値が使われるべきである。XMLプロセッサは他のエンコーディングを認識してもよい。IANA (the Internet Assigned Numbers Authority) [IANA] で、単にリストされているにすぎないもの以外の(charset として)登録されているキャラクタエンコーディングは、その登録されている名前を使って参照されるべきである。これらの登録された名前は大文字小文字の区別がないものとして定義されており、照合をしようとするプロセッサは大文字小文字を区別しない方法で照合をするべきであることに注意すること。
外部転送プロトコル(例.HTTP、MIME)によって与えられる情報がない場合、 エンコーディング宣言を取り込んでいる実体がその宣言で指名されている以外のエンコーディングでXMLプロセッサに提示されること、 エンコーディング宣言が外部実体の最初以外で発生すること、 バイト順マークでもエンコーディング宣言でも始まらない実体が UTF-8 以外のエンコーディングを使うことは、エラーである。ASCII は UTF-8 のサブセットであるから、通常の ASCII 実体はエンコーディング宣言を厳密に要求されないことに注意すること。
XMLプロセッサが処理できないエンコーディングをもつ実体に遭遇したときは、致命的エラーである。
エンコーディング宣言の例
<?xml encoding='UTF-8'?>
|
下記の表は、どのキャラクタ参照、実体参照、解析されない実体の呼び出しが出現するか、またそれぞれの場合にXMLプロセッサの要求される挙動をまとめたものである。左端の列の見出しは認識文脈を記述する。
content に対応する。
AttValue に対応する。
Name として。ENTITY 型として宣言されている属性の値、またはENTITIES 型として宣言されている属性の値の中のスペースで区切られたトークンの1つとして出現する。
EntityValue に対応する。
EntityValue や AttValue の外にある参照として。
| 実体型 | キャラクタ | ||||
| パラメータ | 一般的内部 | 解析される一般的外部 | 解析されない | ||
| 内容の中の参照 | 認識されない | 取り込まれる | 妥当性を検証するならば取り込まれる | 禁止 | 取り込まれる |
| 属性値の中の参照 | 認識されない | リテラルに取り込まれる | 禁止 | 禁止 | 取り込まれる |
| 属性値として発生 | 認識されない | 禁止 | 禁止 | 通知する | 認識されない |
| 実体値の中の参照 | リテラルに取り込まれる | バイパスされる | バイパスされる | 禁止 | 取り込まれる |
| DTDの中の参照 | PEとして取り込まれる | 禁止 | 禁止 | 禁止 | 禁止 |
DTDの外部では % キャラクタは特別な意味をもたない。したがって、DTDの中でならばパラメータ実体参照となるはずのものが、内容の中ではマークアップとして認識されない。同様に、解析されない実体の名前は、それが適切に宣言された属性の値の中に現れる場合を除いて、認識されない。
実体は、参照が認識された場所において文書の一部であるかのように、参照そのものに代えてその置換テキストが引き出されて処理されるときに取り込まれる。置換テキストは キャラクタデータと(パラメータ実体を除く)マークアップの双方を包含してよい。これらは通常の方法で認識されなければならない。ただし、マークアップ区切り子をエスケープするために使われる実体(amp, lt, gt, apos, quot という実体)の置換テキストは、つねにデータとして扱われる。("AT&T;" という文字列は "AT&T;" に展開され、残ったアンパサンドは実体参照区切り子として認識されない。) キャラクタ参照は、示されたキャラクタが参照そのものの代わりに処理されるときに取り込まれる。
XMLプロセッサが解析される実体への参照を認識するとき、文書の妥当性を検証するため、プロセッサはその置換テキストを取り込まなければならない。実体が外部的であり、プロセッサがXML文書の妥当性検証を試みないならば、プロセッサはその実体の置換テキストを取り込んでもよいが、取り込む必要はない。妥当性を検証しないパーサが置換テキストを取り込まないならば、パーサ(解析器)は、実体を認識したが読まなかったことをアプリケーションに知らせなければならない。
この規則は、SGMLおよびXML実体機構により提供される、主にオーサリングにおけるモジュラ性をサポートするために設計された自動取り込みが、他のアプリケーションにとって、特に文書閲覧時には、必ずしも適切でないという認識に基づくものである。たとえば、ブラウザは、解析される外部実体参照に遭遇したとき、実体の存在の視覚的な指示を提供し、要求に応じてのみ表示のために引き出すことを選んでもかまわないのである。
以下は禁止され、致命的エラーを構成する。
EntityValue および AttValue の内部を除く、DTDの中でのキャラクタまたは一般的実体参照の出現。
実体参照が属性値の中に現れ、あるいはパラメータ実体参照がリテラル実体値の中に現れるとき、 参照それ自身に代えてその置換テキストが、参照が認識された箇所の文書の一部であるかのように処理される。ただし、置換テキスト内の単引用符および二重引用符キャラクタは、つねに普通のデータキャラクタとして扱われ、リテラルを終結しないことになる。たとえば、これは整形式である
<!ENTITY % YN '"Yes"' >
|
が、これは整形式でない。
<!ENTITY EndAttr "27'" >
|
解析されない実体の名前が、ENTITY 型や ENTITIES 型として宣言されている属性の値の中のトークンとして現れるとき、 妥当性を検証するプロセッサは、実体と、その結び付けられた表記法の両方について、システム識別子と (あれば)パブリック識別子とをアプリケーションに知らせなければならない。
実体宣言内のEntityValue の中に現れるとき、一般的実体はバイパスされてそのまま残される。
解析される外部実体と一緒のときには、パラメータ実体は妥当性を検証するならば取り込まれる必要があるにすぎない。パラメータ実体参照がDTDの中で認識されて取り込まれるとき、その置換テキストは、先頭に1つ、末尾に1つスペース (#x20) キャラクタを添付することにより拡大される。その意図は、パラメータ実体の置換テキストを、DTD内に整数個の文法的トークンを包含するように制約することである。
内部実体の扱いを論じるに際しては、実体値の2つの形態を区別することが有益である。 リテラル実体値 (literal entity value) は、現実に実体参照の中に存在している引用符で括られた文字列であり、中間生成規則 EntityValue に対応する。 置換テキスト (replacement text) は、キャラクタ参照やパラメータ実体参照を置き換えた後の実体内容である。
内部実体宣言 (EntityValue) の中で与えられているリテラル実体値は、キャラクタ、パラメータ実体、一般的実体参照を包含してよい。そうした参照はリテラル実体値の内部に完全に包含されなければならない。上述のように取り込まれる現実の置換テキストは、参照されているどのようなパラメータ実体の置換テキストも包含しなければならず、 リテラル実体値の中のどのキャラクタ参照についてもその代わりに、参照されているキャラクタを包含しなければならない。しかしながら、一般的実体参照はそのまま展開しないでおかなければならない。たとえば、以下の宣言が与えられているとすると
<!ENTITY % pub "Éditions Gallimard" >
|
"book" 実体の置換テキストは
La Peste: Albert Camus,
|
文書の内容や属性値の中に "&book;" という参照が現れていれば、一般的実体参照 "&rights;" は展開されたであろう。
これらの単純な規則は複雑な相互作用をもつ場合がある。難しい例についての詳細な議論は "D. 実体、キャラクタ参照の展開" を見ること。
実体参照もキャラクタ参照もともに、小なり不等号やアンパサンドその他の区切り子をエスケープ (escape) するために使うことができる。一般的実体のセット (amp, lt, gt, apos, quot) は、この目的のために指定されている。数的キャラクタ参照を使ってもよい。これは認識されたときに直ちに展開されるものであってキャラクタデータとして扱われなければならず、 そのため、"<"、"&" という数的キャラクタ参照を使って、キャラクタデータ内で発生するときの <、& をエスケープしてもよい。
XMLプロセッサはすべて、宣言されているか否かを問わず、これらの実体を認識しなければならない。相互運用性のため、妥当なXML文書は、他のものと同じように、使用前にこれらの実体を宣言するべきである。問題の実体が宣言されるならば、それらは下記に示したように、エスケープされている単一のキャラクタかそのキャラクタへのキャラクタ参照が置換テキストである内部実体として宣言されなければならない。
<!ENTITY lt "&#60;">
|
"lt" と "amp" との宣言の中の <、& キャラクタは、実体置換が整形式であることという要求に沿うために二重にエスケープされることに注意すること。
表記法 (notation) は、解析されない実体の書式、表記属性を生み出す要素の書式、処理命令がアドレスされるアプリケーションを、名前によって識別する。
表記法宣言 (notation declaration) は、実体や属性リスト宣言の中や属性指定の中で使うために、表記法に名前を与え、 XMLプロセッサやそのクライアントアプリケーションが与えられた表記で書かれたデータの処理ができるヘルパーアプリケーションの位置を決定できるようにしてよい表記法に外部識別子を与える。
| 表記法宣言 | ||||||||
|
XMLプロセッサは、アプリケーションに、属性値や属性宣言、実体宣言の中で宣言され、または参照されているどの表記法であってもその名前と外部識別子を与えなければならない。プロセッサは、さらに、外部識別子をシステム識別子やファイル名、その他、記述されている表記法で書かれたデータのためのプロセッサをアプリケーションが呼べるようにするために必要な情報へと解釈する。(しかしながら、XML文書が、XMLプロセッサやアプリケーションが走っているシステム上で利用可能でない、表記法特有のアプリケーションのための表記法を宣言または参照することは、エラーではない。)
文書実体 (document entity) は、実体樹のルート (root) であり、XMLプロセッサにとっての出発点である。この仕様書は、文書実体がXMLプロセッサによってどのように位置を決定されるかは規定しない。他の実体とは異なり、文書実体は名前をもたず、まったく識別なしにプロセッサの入力ストリーム上に現れてもおかしくないのである。
適合的なXMLプロセッサは、2つのクラスに分かれる。妥当性を検証するものと検証しないものとである。
妥当性を検証するプロセッサも検証しないプロセッサも同様に、 文書実体や、プロセッサが読むその他の解析される実体の内容の中にある、この仕様書の整形式性制約の違反を報告しなければならない。
妥当性を検証するプロセッサ (validating processor) は、DTDの中の宣言によって表わされた制約の違反と、この仕様書の中で与えられている妥当性制約を満たすことの失敗を報告しなければならない。これを達成するために、妥当性を検証するXMLプロセッサは、DTD全体と、文書内で参照されている解析される外部実体のすべてを読んで処理しなければならない。
妥当性を検証しないプロセッサは、整形式性について、内部DTDサブセット全体を含めた文書実体をチェックすることだけが要求される。 プロセッサは、妥当性について文書をチェックすることは要求されないが、 内部DTDサブセットの中や、プロセッサが読んだパラメータ実体の中で、プロセッサが読まないパラメータ実体への最初の参照までにあるあるすべての宣言を処理することが要求される。すなわち、プロセッサは、属性値を標準化し、内部実体の置換テキストを取り込み、デフォルトの属性値を補うために、 それらの宣言の中の情報を使わなければならない。プロセッサは、読まれないパラメータ実体への参照の後に遭遇した実体宣言や属性リスト宣言を処理してはならない。実体が上書き宣言を含んでいるかもしれないからである。
妥当性を検証するXMLプロセッサの挙動は、高度に予見可能である。プロセッサは、文書のすべての部分を読み、すべての整形式性違反および妥当性違反を報告しなければならない。妥当性を検証しないプロセッサでは更に不要であるが、妥当性を検証するプロセッサも、文書のうち文書実体以外の部分は読む必要がない。このことは、XMLプロセッサのユーザにとって重要な場合がある2つの影響をもつ。
異なるXMLプロセッサの間での相互運用において最大の信頼性を得るために、妥当性を検証しないプロセッサを使うアプリケーションは、そうしたプロセッサに要求されない挙動を信頼するべきではない。外部実体内で宣言されたデフォルト属性や内部実体の使用といった能力を要求するアプリケーションは、妥当性を検証するXMLプロセッサを使うべきである。
XMLの形式的文法は、この仕様書の中で、単純なEBNF (the Extended Backus-Naur Form) 表記法を使って与えられている。文法中の各規則は、次のような形式で、1つのシンボルを定義する。
symbol ::= expression
|
シンボルは、正規表現によって定義されていれば先頭文字を大文字にして書かれ、そうでない場合には先頭文字を小文字にして書かれている。リテラル文字列は、引用符で括られる。
規則の右辺の表現の内部では、1つ以上のキャラクタの文字列を照合するために、以下の表現が使われる。
#xN
N は16進法の整数であり、その表記は、符号なし2進数として解釈されたときにその正規的 (UCS-4) コード値が示されている値をもつ、ISO/IEC 10646 のキャラクタに合致する。#xN 形式内の先頭の0の数は重要ではない。対応するコード値の中の先頭の0の数は、使われているキャラクタエンコーディングによって支配されるのであり、XMLにとっては重要ではない。
[a-zA-Z], [#xN-#xN]
[^a-z], [^#xN-#xN]
[^abc], [^#xN#xN#xN]
"string"
'string'
A や B は、単純な表現を表わす。
表現)
表現 は、1つの単位として扱われ、このリストに記述されているように組み合わされる場合がある。
A?
A または無に合致する。任意的な A である。
A B
A に B が続いたものに合致する。
A | B
A または B に合致するが、2つともには合致しない。
A - B
A に合致するが B には合致しない任意の文字列と合致する。
A+
A の1回以上の出現と合致する。
A*
A の0回以上の出現と合致する。
/* ... */
[ wfc: ... ]
[ vc: ... ]
Unicode 規格に定義されている特性に従って、キャラクタは、基本キャラクタ (base character)(その他には、発音符なしのラテンアルファベットのアルファベットキャラクタが含まれる)、 表意キャラクタ (ideographic character)、組み合わせキャラクタ (combining character)(その他には、このクラスにはほとんどの発音符が含まれる)に分類される。これらのクラスは組み合わさって、文字のクラスを形成する。数字とエクステンダ (extender) も区別される。
| キャラクタ | ||||||||||||||||||||||||
|
ここで定義されているキャラクタクラスは、以下のようにして、Unicode キャラクタデータベースから引き出すことができる。
XMLは、妥当なXML文書は適合的なSGML文書でもあるべきだという点で、SGMLのサブセットであるように設計されている。SGMLの制約を超えてXMLが文書に課す追加的制約の詳細な比較は、[Clark] を見ること。
この付録には "4.4 XMLプロセッサの実体および参照の扱い" で規定されている実体およびキャラクタ参照の認識と展開の順序を解説する例がある。
DTDに
<!ENTITY example "<p>An ampersand (&#38;) may be escaped
|
という宣言があれば、XMLプロセッサは、プロセッサが実体宣言を解析するときにキャラクタ参照を認識し、実体 "example" の値として続いている文字列を保存する前に、キャラクタ参照を解釈することになる。
<p>An ampersand (&) may be escaped
|
文書の中にある "&example;" への参照は、テキストの再解析を生じさせることになる。この時、"p" 要素の開始タグと終了タグが認識されて、3つの参照が認識されて展開され、以下の内容(全データ.区切り子やマークアップはない)をもつ "p" 要素を帰結する。
An ampersand (&) may be escaped
|
もっと複雑な例で、規則とその効果を完全に解説する。以下の例においては、行番号は単なる参考のためのものである。
1 <?xml version='1.0'?>
|
これは、以下のものを生成する。
xx" は "%zz;" という値をもつシンボルテーブルに保存される。置換テキストは再スキャンされないから、パラメータ実体 "zz" への参照は認識されない。(また、"zz" はまだ宣言されていないから、もし認識されてもエラーである。)
<" は即時に展開され、パラメータ実体 "zz" は "<!ENTITY tricky "error-prone" >" 置換テキストとともに保存される。これは整形式の実体宣言である。
xx" への参照が認識され、"xx" の置換テキスト(すなわち "%zz;")が解析される。今度は "zz" への参照が認識されて、その置換テキスト ("<!ENTITY tricky "error-prone" >") が解析される。このとき、一般的実体 "tricky" が、"error-prone" という置換テキストつきで宣言されている。
tricky" への参照が認識され、展開されて、"test" 要素の完全な内容は、自己記述的(かつ非文法的)文字列 This sample shows a error-prone method. となる。
互換性のため、要素型宣言内の内容モデルは決定的であることが要求される。
SGMLは、決定的内容モデル(SGMLは「曖昧さがない」という)を要求する。SGMLシステムを使って組み上げられたXMLプロセッサは、非決定的内容モデルをエラーとしてフラグを立てる場合がある。
たとえば、((b, c) | (b, d)) という内容モデルは、最初の b が与えられても、b にどの要素が続くかを確認するために前を見ることなしには、 モデル内のどちらの b が照合されているのかを知ることができないから、非決定的である。この場合、b への2つの参照は、モデルを (b, (c | d)) にして、1つの参照へ圧縮できる。最初の b は今度は明らかに、内容モデルの中で単一の名前にのみ合致する。パーサは、何が続いているのかを確かめるために前を見る必要はない。c か d かのどちらかが受付可能ということになる。
もっと形式的に。たとえば、Aho, Sethi, Ullman [Aho/Ullman] の section 3.9 の algorithm 3.5 といった標準的なアルゴリズムを使って、内容モデルから定型のステートロボット (finite state automaton) を構築してもよい。そうしたアルゴリズムの多くでは、正規表現内の各ポジション(すなわち、正規表現についての文法樹における各葉節)についてフォローセットが構築される。どれかのポジションが、2つ以上のフォローイングポジションが同じ要素型名をつけられているフォローセットをもてば、内容モデルはエラーであって、それがエラーとして報告されてももよい。
多いながらもすべてではない非決定的内容モデルを、自動的に同等の決定的モデルに縮小することを可能にするアルゴリズムが存在する。Brüggemann-Klein 1991 [Brüggemann-Klein] を見ること。
XMLエンコーディング宣言は、各実体についての内部的ラベルとして機能し、どのキャラクタエンコーディングが利用されているかを示す。しかしながら、XMLプロセッサは、内部ラベルを読むことができる前に、明らかにどのキャラクタエンコーディングが使われているかを知らなくてはならない。これは、内部ラベルが示そうとしているものである。一般的な場合において、これは望みのない状態である。しかしながら、XMLにおいては完全に望みがないわけではない。XMLは、一般的な場合を2つの方法で制約するからである。各実装は、有限のセットのキャラクタエンコードだけしかサポートしないものと考えられ、 XMLエンコーディング宣言は、通常の場合において各実体の中で使われているキャラクタエンコーディングを自動検知することを実行可能にするために、場所および内容において制限を受ける。また、多くの場合では、XMLデータストリーム自身に加えて、その他の情報源も利用可能である。プロセッサに対してXML実体が表示される際に、何らかの関連する(外部的な)情報がついているかいないかにより、2つの場合は区別可能な場合がある。最初のケースを先に検討する。
UTF-8 または UTF-16 フォーマットで書かれていないXML実体はそれぞれ、XMLエンコーディング宣言ではじまらなければならず、その最初のキャラクタは '<?xml' でなくてはならないから、 適合的なプロセッサはどれであっても、入力から2または4オクテット後で、以下のケースのうちのどれが適用されるかを検知することができる。このリストを読むに際して、UCS-4 では '<' は "#x0000003C"、'?' は "#x0000003F" であり、UTF-16 データストリームの必須のバイト順マークは "xFEFF" であることを知ることが助けになるかもしれない。
00 00 00 3C: UCS-4, big-endian 機 (1234 の順)
3C 00 00 00: UCS-4, little-endian 機 (4321 の順)
00 00 3C 00: UCS-4, まれなオクテット順 (2143)
00 3C 00 00: UCS-4, まれなオクテット順 (3412)
FE FF: UTF-16, big-endian
FF FE: UTF-16, little-endian
00 3C 00 3F: UTF-16, big-endian, バイト順マークなし(よって厳密にはエラーである)
3C 00 3F 00: UTF-16, little-endian, バイト順マークなし(よって厳密にはエラーである)
3C 3F 78 6D: UTF-8, ISO 646, ASCII, ISO 8859 の一部, Shift-JIS, EUC, またはその他の7ビット、8ビット、もしくは ASCII キャラクタが通常の位置、幅、値をもつことを確保する混合エンコーディング。これらのどれが適用されるか探知するためには実際のエンコーディング宣言が読まれなければならないが、これらのエンコーディングはすべて ASCIIキャラクタについては同じビットパターンを使うので、エンコーディング宣言自体は信頼して読んでよい。
4C 6F A7 94: EBCDIC (一部の味付け。どのコードページが使われているかを判断するためには、完全なエンコーディング宣言を読まなければならない。)
この水準の自動検知は、XMLエンコーディング宣言を読み、キャラクタエンコーディング識別子を解析するのに充分である。これは、エンコーディングの各ファミリーの個別のメンバーを区別するために、なお必要である。(例.UTF-8 を 8859 から区別したり、8859 の各部分を互いに区別したり、使われている特定の EBCDIC コードページを区別するためなど)
エンコーディング宣言の内容は ASCIIキャラクタに制限されているから、プロセッサは、エンコーディングのどのファミリーが使われているかを探知してしまえば直ちに、エンコーディング全体を安んじて読むことができる。実際には、広く使われているキャラクタエンコーディングはすべて、上記のカテゴリーのうちのひとつに分けられるから、 XMLエンコーディング宣言は、オペレーティングシステムや転送プロトコルレベルの外部情報源が信頼できないときであっても、相当程度信頼できる、転送中のキャラクタエンコーディングのラベリングを可能にする。
いったん使われているキャラクタコードをプロセッサが検知すれば、各場合について分離している入力ルーチンを呼び出すことによろうが、入力された各キャラクタについて適切な変換関数を呼び出すことによろうが、適切にプロセッサは行動することができる。
任意の自己ラベリングシステムと同様、XMLエンコーディング宣言は、ソフトウェアが実体のキャラクタセットやエンコーディングを、エンコーディング宣言の更新なしに変更すれば、機能しないことになる。キャラクタエンコーディングルーチンの実装は、注意深く、実体をラベルするために使われる内部および外部の情報の正確さを保証するべきである。
ありうる2つ目のケースは、一部のファイルシステムやネットワークプロトコルにおけるように、XML実体にエンコーディング情報が同伴しているときに起こる。複数の情報源が利用可能であるとき、その相対的な優先順位や矛盾処理の好まれる方法は、XMLを配信するために使われるより高次のプロトコルの一部として指定されるべきである。たとえば、内部ラベルや、外部ヘッダ内の MIME 型ラベルの相対的優先順位についての規則は、text/xml や application/xml MIME 型を定義するRFC文書の一部であるべきである。しかしながら、相互運用性の利害関係においては、以下の規則が推奨される。
charset パラメータが、キャラクタエンコーディングの方法を決定する。その他すべての発見的教授法や情報源は、単なるエラー回復のためのものである。
この仕様書は、W3C XMLワーキンググループによって準備され、公表を同意されたものである。この仕様書についてのワーキンググループの賛成は、必ずしもワーキンググループのメンバー全員が賛成に票を投じたことを意味するわけではない。XMLワーキンググループの現在および以前のメンバーは、次の通りである。
Jon Bosak, Sun (座長); James Clark (技術主任); Tim Bray, Textuality and Netscape (XML共同編集者); Jean Paoli, Microsoft (XML共同編集者); C. M. Sperberg-McQueen, U. of Ill. (XML共同編集者); Dan Connolly, W3C (W3C連絡係); Paula Angerstein, Texcel; Steve DeRose, INSO; Dave Hollander, HP; Eliot Kimber, ISOGEN; Eve Maler, ArborText; Tom Magliery, NCSA; Murray Maloney, Muzmo and Grif; Makoto Murata, Fuji Xerox Information Systems; Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe, SoftQuad; John Tigue, DataChannel著作権 (C) 1998 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学), すべての権利が留保されている。W3Cの 免責 (liability), 商標 (trademark), 文書利用 (document use), ソフトウェア使用許諾 (software licensing) 規則が適用される。