第5回 「整形式」のXML文書と文字の定義
XML 1.0は、1998年にW3Cから勧告として公開された。当然中身は英語で、しかもEBNFと呼ばれる式によって重要な部分が記述してある。この連載では、XML 1.0を深く理解するための、そのXML 1.0勧告の最新版「Extensible Markup Language (XML) 1.0 (Second Edition)」をだれでも分かるように、やさしく読み解きながら解説していくことを目指している。（編集局）
川俣 晶
株式会社ピーデー
2003/1/7
■整形式のXML文書
今回の主な内容 整形式のXML文書生成規則の登場親と子の定義XMLで定める「文字」とは？構文構成子 |
今回は、XML 1.0勧告の第2章に当たる「2. 文書（Documents）」を読み取っていく。いよいよXMLで頻繁に出てくる「整形式のXML文書」について述べられている個所に入る。
2.1 Well-Formed XML Documents（整形式のXML文書）は、以下のように記述されている。
|
[Definition: A textual object is a well-formed XML document if:]
|
ここには、「整形式のXML文書」と呼ばれるテキストオブジェクトの条件が記されている。まず、（1）全体としてdocumentというラベル付けされた生成規則にマッチする、と書かれている。この生成規則は後で説明するが、重要なことは「全体として」という言葉である。前後に独自の情報を追加されたものは、部分としてはマッチしても、全体としてこの生成規則にマッチしないので、整形式のXML文書とは見なせない。この定義により、最初の1文字がどのような文字になるかが厳密に決まるので、XML 1.0勧告のAppendicesのF Autodetection of Character Encodings (Non-Normative)にあるエンコーディングの自動判定が実現できることになる。
次に、（2）この仕様に記述されたすべての整形式制約に従う、とある。これは実質的な意味での整形式の条件を述べているわけではないので、特にコメントは不要だろう。
（3）文書内で直接的または間接的に参照される個々の解析対象実体が整形式である。とはつまり、文書の内部だけが条件に従っているだけでは不十分で、参照されている解析対象実体も整形式の条件を満たしていなければ、整形式のXML文書とは見なせない、ということだ。しかし、属性にURIを記述してほかのリソースを参照する方法の場合、参照先が正しい整形式のXML文書になっていなくてもこの条件には引っ掛からない。解析対象実体として参照する場合だけの問題である。
上記の説明に続いて、いよいよEBNFで記述された生成規則の登場である。下記が、documentというラベル付けされた生成規則そのものだ。整形式のXML文書とは、すなわちこれにマッチする、ということである。
[1] |
document |
::= |
prolog
element
Misc* |
先頭に付いている[1]というのは、個々の生成規則に付けられた番号である。最初の1個なので、1という値になっている。XMLについて議論する場合には、生成規則の何番と示せば確実に同じものを指摘することができるが、生成規則内では番号ではなく、名前を使って参照する。上記の場合、documentという名前（ラベル）が付けられた生成規則であるとされる。
この規則では、まずprologという生成規則があり、次にelementという生成規則があり、最後に0個以上のMiscという生成規則が繰り返されることを示している。なお、prologはXML宣言などを生成する規則、elementは要素を生成する規則、Miscはコメントや処理命令、空白文字などを生成する規則である。これにより、XML宣言などがルート要素より手前でなければならないことや、ルート要素が終了タグで終わった後には、コメント、処理命令、空白文字しか書けないことが示されている。
|
Matching the document production implies that:
|
次は、生成規則documentにマッチするということを、別の表現で説明している。まず、（1）1つ以上の要素を含んでいる、ことが挙げられる。elementという生成規則が省略可能とは記述されていないので、少なくとも1つの要素が出現することは必須である。
次に（2）ルート、あるいは文書要素と呼ばれるたった1つの要素が存在する、としている。これも、生成規則から見れば明白である。要素を記述する生成規則は繰り返し可能ではないので、1つしか書けない。もちろん、その要素の子要素としていくつでも要素を記述することはできるが、トップレベルに記述できる要素は1つだけである。
この要素は、ほかの要素の内容に出現することはない。そのほかの要素は、開始タグが別の要素の内容にあれば、終了タグも同じ要素の内容に含まれる。さらに、単純にいい直した説明が続いている。つまり開始タグと終了タグで区切られた要素は、正しくお互いがネスト（入れ子）していなければならない、ということである。もっとも、ネストしていなければならないという意図を、生成規則documentだけで表現しているわけではなく、むしろ生成規則elementとそこから参照される生成規則が表現していると考えた方が分かりやすいかもしれない。
|
[Definition:
As a consequence of this, for each non-root element |
続いての説明では、親（parent）と子（child）という用語の定義である。同じような話が繰り返されているようにも思えるが、これは独立した定義を与えるために明示する必要があって記述されているものである。
親と子の具体的な内容はこうなる。ルート要素ではない要素Cがあり、要素Cを内容とするような別の要素Pが文書内に存在する。さらに要素Cは、要素Pのそれ以外の要素の内容には含まれない。ここでCやPは具体的な要素の名前ではなく、仮に与えられた一般的な要素を示すための名前である。そして次が重要な定義だが、こういう場合に、PをCの親（parent）といい、CをPの子（child）という、とされている。これが、この仕様での親子の定義である。
次は2.2 Characters（文字）である。下記は、XMLにおける文字の定義を、英語で表したものだ。
|
[Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data.] [Definition: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. The versions of these standards cited in A.1 Normative References were current at the time this document was prepared. New characters may be added to these standards by amendments or new editions. Consequently, XML processors must accept any character in the range specified for Char. The use of "compatibility characters", as defined in section 6.8 of [Unicode] (see also D21 in section 3.6 of [Unicode3]), is discouraged.] |
解析対象実体は、テキストを含む。テキストは、文字の並びである。それは、マーク付けまたは文字データを表現する。
続いて、文字はテキストの最小単位で、ISO/IEC 10646で示される、とある。JIS版のXML仕様書では、ここはISO/IEC 10646ではなくJIS X 0221-1:2001と記述されているが、基本的には同じものである。国際規格であるISO/IEC 10646を国内で規格として翻訳して認めたものがJIS X 0221(JIS X 0221-1:2001)に当たる。それから、ISO/IEC 10646-2000も参照せよとしているが、厳密にいうとISO/IEC 10646で参照しているものと、ISO/IEC 10646-2000で参照しているものは異なる。A.1 Normative Referencesを見ると分かるとおり、前者はISO/IEC 10646の1993年版で、後者は2000年版を意味している。XML 1.0勧告は、2000年版ができる前に成立しているので、基本的には1993年版を参照しているが、運用する際には2000年版を意識する必要もある。
説明は続く。使用できる文字は、タブ、復帰（carriage return）、改行（line feed）、UnicodeとISO/IEC 10646の正当な文字であるとしている。しかし、このような説明よりも、後で出てくる定義を見る方が明快で分かりやすいだろう。これらの標準の具体的な詳細はすでに述べたようにA.1 Normative Referencesで記述されているが、あらためて、この仕様が用意された時点のものと説明している。そして、補遺や新版によって新しい文字が標準に追加されるかもしれない、としている。そのため、XMLプロセサはCharで指定された範囲のどんな文字も受け付けなければならない、と続けている。
この部分は、使用できる文字の枠組みはCharという名前の生成規則で規定されて動かないものの、その中にはまだ何も文字が割り当てられていないコードが多数あり、それらは今後文字が割り当てられるかもしれないことを示している。それらの文字が未来のある時点で割り当てられたとしても、XMLプロセッサはそれを処理できねばならない。この要求を実現する最も簡単な方法は、すべての文字をISO/IEC 10646の番号を使って処理することである。理屈の上では、すべての文字を各国固有のコード体系に分散して変換してから処理する方法も考えられるが、未来に割り当てられる未知の文字まで含めて正しく処理するのは難しいだろう。結局のところ、XMLを使う場合には、ISO/IEC 10646と永遠に一緒に生きる覚悟が必要である。最後に、Unicodeのsection 6.8に定義された互換文字“compatibility characters”の利用は好ましくないとしている。例えば、全角英数字や、半角カタカナがこれに当たる。
さて、文字のEBNFによる定義は以下のようになっている。
[2] |
Char |
::= |
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] |
/* any Unicode character, excluding the surrogate blocks,
FFFE, and FFFF. */ |
当たり前のことも一応書いておくと、#x9はタブ。#xAは改行（line feed）、#xDは復帰（carriage return）である。[#x20-#xD7FF]と[#xE000-#xFFFD]の間の空いた領域は、サロゲートペアを表現するために使われ、[#x10000-#x10FFFF]の範囲の文字を間接的に表現するために使われる。#xFFFDと#x10000の間も空いているが、ここは特別な領域として文字が割り当てられないと決まっている範囲である。コメントで述べているのは、要するに、それと同じことを別の表現で述べているだけである。
|
The mechanism for encoding character code points into bit patterns may vary from entity to entity. All XML processors must accept the UTF-8 and UTF-16 encodings of 10646; the mechanisms for signaling which of the two is in use, or for bringing other encodings into play, are discussed later, in 4.3.3 Character Encoding in Entities. |
続く説明では、文字符号の位置を示すメカニズムは実体ごとに異なっていてもよいとしている。つまり、ある実体がシフトJISで記述されていて、別の実体がUTF-8で記述されていても構わない。さらに、すべてのXMLプロセサは、UTF-8とUTF16を受け付けなければならない。この文章は、裏を返せばこの2つ以外はXMLプロセッサが扱えなくてもよいことを示している。つまり、シフトJISで記述したXML文書を扱えないXML対応ソフトがあると考えてよい。実際、そのようなソフトにはしばしば遭遇することがある。問題は、UTF-8とUTF-16のどちらがよりベターかということだが、それに対する答えはXML 1.0勧告には含まれない。インターネット全体の技術体系からいけば、UTF-8の方がベターであろう。次はこの2つ、あるいはほかの符号化方式を示すメカニズムに関する議論は、後で4.3.3 Character Encoding in Entitiesで行われると記述されている。つまり、詳細についてはそちらを読む必要がある。
■構文構成子次は、2.3 Common Syntactic Constructs（構文構成子）である。順に読んでいこう。
|
This section defines some symbols used widely in the grammar. |
この節では、文法内で使用されるいくつかのシンボルを定義している。
|
S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs. |
最初に解説されるのは、Sである。これは、空白（white space）を示すシンボルだ。1つかそれ以上の空白文字、改行、復帰、タブを含む。以下の定義を見れば一目瞭然だろう。
[3] |
S |
::= |
(#x20 | #x9 | #xD | #xA)+ |
空白の次は、文字の分類である。
|
Characters are classified for convenience as letters, digits, or other characters. A letter consists of an alphabetic or syllabic base character or an ideographic character. Full definitions of the specific characters in each class are given in B Character Classes. |
文字は、便宜上、字（letters）、数字（digits）、そのほかの文字（other characters）というクラスに分類される。字はアルファベット、音節文字である基底文字。漢字のような文字とする。それぞれのクラスのすべての定義は、B Character Classesによって与えられている。B Character Classesには、詳細な文字のリストが掲載されている。このように文字をクラス分けするのは、名前に使用できる文字を分かりやすくするためといえる。この後、名前に関する説明が続くことになる。
|
[Definition: A Name
is a token beginning with a letter or one of a few punctuation
characters, and continuing with letters, digits, hyphens, underscores,
colons, or full stops, together known as name characters.] Names
beginning with the string " |
次は名前（Name）である。名前は要素など多くのものに与えられるので、ある意味でXMLで最も重要な役割を持つといえるかもしれない。定義として、Nameとは、「字」またはいくつかの区切り文字の1つで始まり、その後に、字（letters）、数字、ハイフン、下線、コロン記号、ピリオド記号のいずれかが続く。これらの文字は名前文字（name characters）という名前でも知られる。大文字小文字を問わずXMLで始まる名前は予約されていると書かれている。例えば、Extensible Music Languageのような言語を作っていて、要素名の先頭はxmという文字を付けると決めて、xmliveのような名前を使おうとすると、この制限に引っ掛かってしまう。しかし、この仕様書自身で定義されるxml:lang属性のような名前は予約された権利を行使したもので、問題ない。
|
Note: The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character. |
ここでは補足説明として、XML名前空間の勧告について記述されている。名前空間ではコロン文字を含む名前に特別な意味を割り当てている。そのため、名前空間を記述する目的以外では、コロン記号を使うべきではないとしている。しかし、XMLプロセッサは、コロンを名前文字として受け付けなければならない。もちろん、名前空間対応のXMLプロセッサは、コロン記号を名前空間の区切り文字として理解すべきであって、この文章が意味を持つのは、名前空間に対応せず、このXML1.0勧告にのみ準拠する場合だけである。
次はNmtokenの説明なのだが、続きは次回に請うご期待である。
 |
連載 やさしく読む「XML 1.0勧告」 |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
