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つの種類がある。
| 列挙属性型 | ||||||
|