Tweet

今回の主な内容 空白と言語識別を一気に読む 空白文字の取り扱い 妥当性を検証するXMLプロセッサがすべきこと xml:space属性の役割 xml:space属性の取り得る値 環境ごとに異なる行末の取り扱い 行末は#xAとなる 言語識別 言語の識別と、国や地域の識別

　　前回の「XMLの外部参照と非依存文書宣言」では、XML 1.0勧告の中で、XML宣言や文書型宣言を扱っている部分である「2.8 Prolog and Document Type Declaration」（2.8 前書き及び文書型宣言）と、XML宣言に含まれる非依存文書宣言に関する説明「2.9 Standalone Document Declaration」（2.9 非依存文書宣言）を読み切った。

　これら2つは多少関係がある話題だったが、今回解説する内容は、それらとは直接的にはつながりがない。今回扱うのは、以下の3つである。まず、「2.10 White Space Handling」（2.10 空白の取扱い）は、空白文字の扱いに関する規定を記述している部分である。空白文字の定義はすでに「2.3 Common Syntactic Constructs」（2.3 共通の構文構成子）で読んだ。今回は、空白文字の扱いについての解説だ。

　次は、「2.11 End-of-Line Handling」（2.11 行末の取扱い）である。行末は制御文字を使って示すことになるが、環境によって異なるコードが使用されており、何らかの規定を設けなければ異種環境間での相互運用性が維持できない性質のものである。

　最後は、「2.12 Language Identification」（2.12 言語識別）である。これは、XML文書のある部分に記述された文字列が、どのような言語（日本語であるとか英語であるとか）で記述されているかを示すために使用される。

　今回で、「2 Documents」のセクションも終わりである。あと一息なので、頑張って乗り切ろう。

■空白文字の取り扱い

　空白文字の定義は、すでに、「2.3 Common Syntactic Constructs」（2.3 共通の構文構成子）に記述されている。“[3] S ::= (#x20 | #x9 | #xD | #xA)+”というのが、EBNF的な空白文字の定義である（EBNFの詳細については、第2回「XML勧告読解に必須のEBNF」を参照）。ここで解説するのは空白文字の定義ではなく、空白文字の扱われ方である。それを意図的に指定するための属性が1つ定義されている。

　では本文を読み始めよう。

　まず、読みやすさのために挿入される空白文字は、文書の意味のある一部ではないことを示している。例えば、要素の内容を字下げして記述するXML文書は多いが、字下げに使われた空白文字は、文書のデータの一部ではない、ということである。しかし、それだけが空白文字の使い方ではなく、意味のある空白、例えば詩やソースコードにおける空白がこれに当たる、と例も示している。

　poetry（詩）で使われる空白が保持されねばならないというのは、字下げに使われる空白文字も詩を構成する芸術的な表現の一部と考えられるためだろう。表現のために作者が入れた空白文字は重要な意味があり、決して取り除いてはならないものである。

　ソースコードにおける空白にも同じような意図がある。ソースコードの意図を分かりやすく表現するために挿入された空白文字は意味があり、取り除いてはいけない。世の中には、字下げによってブロック構造を表現するプログラム言語（TransputerというCPUのためのプログラム言語、Occamがそうだったような記憶がある）もあり、そのような場合には空白文字を変更することは致命的なプログラムの破壊につながる。

　以上は、これから始まる規定の前振りとなる説明文である。

　いよいよ、空白文字の扱いに関する規定に入っていく。ここでは“空白文字”ではなく“文字”と記述されているが、当然これには空白文字が含まれる。「空白文字であろうと、（マーク付け以外の）すべての文字は変更せずに応用プログラムに渡されなければならない」。マーク付け以外の、というのは、逆にいえば、マーク付けの内部の空白文字は渡さなくてもよいということを示す。例えば、

<element attribute="value">

という開始タグが記述されているとき、elementとattributeの間の空白文字は、応用プログラムに渡されない。そこに書かれた空白文字が空白なのか改行なのかタブなのか、あるいは何個の空白文字が入っていたか、応用プログラムが知ることはない。

■妥当性を検証するXMLプロセッサがすべきこと

　次は、妥当性を検証するXMLプロセッサに関する規定である。「妥当性を検証するXMLプロセサは、これらの文字の中でどの文字が要素内容に出現する空白を構成するかを応用プログラム側に伝えなければならない（must）」としている。ここは少し分かりにくいところである。すべての空白文字を応用プログラムに渡さねばならない、というのは必須要件である。ともかくそれは渡されるのである。それに加えて、妥当性を検証するXMLプロセッサを使う場合、どの文字が「要素内容に出現する空白」であるかを応用プログラムに伝えなければならない。

　しかし、「要素内容に出現する空白」とは何だろうか？ 要素内容という言葉の定義は「3.2.1 Element Content」（3.2.1 要素内容）に出てくることになり、まだ先である。しかし分からないままでは読み通せないので、簡単に説明して先に進むことにしよう。要素内容の定義は、「ある型の要素が必ず子要素だけを含み（文字データを含まない）、それらの間には空白（非終端記号Sにマッチする文字）だけしか現れないとき、その要素型は要素内容を持つという」ということである。つまり、要素内容には、文字データは含まれず、要素だけを子に持つ。ただ、空白文字だけは含むことを許されているわけである。別のいい方をすれば、要素内容であるということは混合内容ではない、ということだ。混合内容は、文字データが子として出現することを許すものである。

　これをまとめると、「要素内容に出現する空白」とは、文字データが出現することがDTDによって禁止されている要素の内容に出現する空白文字」といえる。そして、どの文字がこの条件に合致した文字であるかを、XMLプロセッサは応用プログラムに伝えなければならない、というのである。当然のことながら、混合内容に出現した空白と、要素内容に出現する空白は違うものだと認識して、それを伝える必要が発生する。応用プログラムから見ると、混合内容に出現した空白は意味のあるものとして受け付けるべきだが、要素内容に出現した空白は読み飛ばすべきものといえる。

■xml:space属性の役割

　さて、次の段落からは、別の話題に変わる。今度は、xml:space属性に関する話題である。

　これもまた分かりにくい文章である。前の文章で既に、「文書内のマーク付け以外のすべての文字を、変更せずにそのまま渡さなければならない」と力強く断言したばかりである。それにも関わらず、ここで「空白を保存することが望ましい、という意図」などという言葉が出てくるのはなぜだろうか。

　ここで注意すべきことは、「意図（intention）」という表現である。これは、XMLプロセッサや応用プログラムの動作に対する規定を示している言葉ではない。あくまで、XML文書の作成者の考えたことを示す手段、と理解すべきだろう。結局のところ、xml:space属性の有無によって、XMLプロセッサの動作が変わることはない、ということになるのである。

　続いての文章は、xml:space属性を使う場合は、DTDの属性リスト宣言にこの属性も書いておけ、という意味である。xml:spaceという名前は一見名前空間を使用しているように見える。xmlが接頭辞ということである。しかし、名前空間を併用しないXML1.0で利用する場合は、“xml:space”がひと続きの、1つの属性名であることに注意が必要である。名前空間使用時には、xmlという接頭辞が宣言しなくても、暗黙的に名前空間URIのhttp://www.w3.org/XML/1998/namespaceに関連付けられるため、この属性はこの名前空間URIに属するspaceという名前の属性ということになる。しかし、この名前空間URIに別の接頭辞を与えてspace属性を記述することはできない。

　そして、宣言するときは、取り得る値を“default”か“preserve”のいずれか、または両方に限る列挙型でなければならない。ここで述べられた2つの文字列だけが正しい値として指定可能ということである。

　その次は、この属性を属性リスト宣言で記述した例である。

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

<!-- -->
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

　最初の例は、poem要素に付加されるxml:space属性について記述している。取り得る値は“default”か“preserve”のどちらか一方であり、省略時のデフォルト値はpreserveであることを示している。2番目の例は、pre要素に付加されるxml:space属性について記述しているが、こちらは選択の余地がなく、preserveのみが指定されている。この例では、defaultを記述することは間違いとなる。

■xml:space属性の取り得る値

　さて、次はdefaultとpreserveという値の持つ意味についての説明である。

　まず、「応用プログラムのデフォルトの空白処理モードがその要素に適用できる」という“default”について。ここで重要なことは、XMLプロセッサの空白処理モードではなく、もし応用プログラムが独自の空白文字処理機能を持っているなら、それを使うということである。例えば、応用プログラムが空白文字を増減してきれいにページに収まるように書式整形する機能があるなら、それを使ってよい。

　次に、「応用プログラムがすべての空白を保存する」という“preserve”は、応用プログラムが空白文字を勝手に変えてはならない。応用プログラムが、空白文字を増減してきれいにページに収まるように書式整形する機能があるとしても、それを使ってはならないということだ。

　余談だが、少し前に記述された例の要素名がpoemとpreであるというのは、何となくこの属性の使い道を暗示させる。poemつまり詩は、空白文字を意味のあるものとして保存する必要があるかもしれない。つまり、どちらの空白処理モードを使うかを明示的に属性で示す価値がある。一方、preの方はHTMLのpre要素を連想させる。HTMLのpre要素は、記述された空白文字をそのままWebブラウザ上に表示するタグだ。そのため、常に空白文字はそのまま扱われる必要があり、値を自由に指定する選択の余地を与える意味はないといえる。

　xml:space属性による指定は、子孫要素にも伝播する。そして、子孫要素側でxml:space属性を記述することで、その要素とその子孫には違う指定を適用することができる、ことも説明されている。

　次は、xml:space属性とルート要素との関連性についての規定である。ルート要素は親要素が存在しないため、上位の指定がないという点で特殊である。そのため、特に規定が必要とされるわけである。

　ちょっと長いので分解して読んでみよう。まず、「この属性の値を指定するか、またはこの属性のデフォルト値が宣言されている場合」というのは、ルート要素にxml:space属性に関する情報が指定されている場合、ということを意味する。属性の値を指定する方法は、XML文書上に明示する方法と、属性のデフォルト値をDTDに書き込む方法の2つがあるが、そのような指定がなされていない場合について話が続く。指定がなされていない場合、「いかなる意図も示さない」。つまり、defaultでもpreserveでもない状態になっている、ということである。そのことから考えると、実は、空白の扱いは、以下の3つのケースがあることになる。

• 示されていない
• default
• preserve

　preserve以外はどういう動作をさせれば適切なのか分かりにくい。しかし、すでに見たように、XMLプロセッサの動作としては、この指定に影響を受けることはない。応用プログラム側が、この指定の違いによって動作を変えたい場合だけ、この違いを意識するとよいだろう。その際、「示されていない」というあいまいな状態が好ましくなければ、DTDによってルート要素にxml:space属性の記述を必須としたり、デフォルト値を持つ属性として追加しておくことも可能だろう。もちろん、DTD以外のスキーマ言語で指定しておいてもよい。

■環境ごとに異なる行末の取り扱い

　行末を示すコードは、環境によって違う。例えば、UNIX系OSの世界では改行コード（#xA）を使うが、Macintoshの世界では復帰コード（#xD）を使う。Windowsの世界では復帰と改行（#xD;#xA）という2文字のシーケンスで示す。このような違いを無視して、XML文書における行末を示すコードを無理やり統一しようとすれば、非常に大きな使い勝手の悪さを招く。かといって、ここに挙げたすべてを有効な行末として受け入れるように応用プログラムを記述するのも面倒な作業である。

　以下に、そのあたりに関する規定が記述されている。

　解析対象実体というのは、XMLの構文で記述された実体であり、XML文書などを指す。これを複数の行に分けて記述するのは、よく行われる普通のことである。

　ここで述べられていることは、すでに述べたOS環境などによる行末を示すコードの相違の説明である。とはいえ、ここには1つだけ問題がある。「普通は」という限定が付いているが、これがどこからどこまでを含むのかは明示されていない。実際、メインフレームなどでは異なる改行コードが使用されていて、「復帰（#xD）コードおよび改行（#xA）コードの何らかの組み合わせ」では収まらない事例があり、これがXML 1.0から1.1への改版の1つの原動力となっている（XML 1.1は、2003年7月現在、策定中）。とはいえ、XML 1.0勧告の世界では、行末はここで示された範囲内で使うのが基本である。

　なお、ISO 10646（Unicode）の#x80〜#x9fの範囲は制御文字であり、これはXML 1.0勧告で使用できる文字の範囲に含まれる（EBNFの[2] Charの定義を参照）。メインフレームの改行コードに当たる#x85はこの範囲に含まれるので、XML文書に書き込んでよいように思えるが、たとえ書き込んだとしても、XML 1.0勧告準拠のXMLプロセッサはこれを行末として処理することはない。

■行末は#xAとなる

　次は、応用プログラムに渡す行末情報についての規定である。

　「XXした場合と同一の文字を」という表現が少し奇異に見える。何かの処理を強制したいなら、「XXせよ」と書くのが最も単純だが、そのような表現を行っていない。その理由は、手段を強制しないことにある。応用プログラムに渡る結果が同じなら、さまざまに処理方法を工夫して、より利便性の高いXMLプロセッサを開発すべきなのである。そのためには、ここで記述されたのとは異なる手順で、同じ結果を実現したいかもしれない。そのような実装もOKであるという意図を示すために、「XXした場合と同一の文字を」という表現になっているのである。

　では具体的にどんな処理なのか。説明されているのは、文書実体、外部解析対象実体に対して、解析を行う前に以下の処理をせよ、ということである。

• 連続する2文字#xD #xA→#xA
• #xAを後ろに伴わない#xD→#xA

　これにより、すべての行末は#xAで表現されるようになる。その結果、その後のプログラムの処理が簡単になる。ある文字が#xAであるか否か、というシンプルな判定で、行末かどうかを判定できるようになる。

　このことから分かるとおり、XMLでは、環境ごとの行末の相違を明示的に意識して扱うことはできない。例えば、行末が#xAである場合と、#xDである場合で処理を分ける応用プログラムを作成する、といったことはできない。

　ここでは、言語識別のために付加することができるxml:lang属性について記述されている。ある文章が日本語で書かれているか、英語で書かれているかで重要な違いが生じる場合がある。例えば、日本語の文章に英語の単語が挿入されている場合に、その単語が日本語の規則に沿ってレイアウトされるか、英語の規則に沿ってレイアウトされるか、その相違によって、ページに配置される文字の位置が変わる場合があり得る。このような問題は広く一般的に出現し得るので、XMLのようなごく基本的なマーク付け言語の仕様の中で定義を与える価値がある。

　では本文を読んでいこう。

　文書処理とは、もちろんコンピュータで電子的な文書を処理することをいう。ここでいう文書は、必ずしもXMLで扱うすべての文書とは一致しないものである。自然言語というのは、日本語や英語など、だれかが定義することなく自然発生的に人間が使っている言語である。形式言語というのは、筆者の知識の範囲を外れるので辞書を引いたところ、「生成文法が対象とする、数学的な文法規則により生成される抽象的言語」と記述されていた。そういえば、昔、『ゲーデル、エッシャー、バッハ―あるいは不思議の環 』（1985年、白揚社）という数学の本をかじったときに出てきた言葉のような気もするが、そういう数学的な言語と思えばよいだろうか。形式言語も、一種の言語といえるだろうが、自然言語とは異なる性格のものといえるだろう。そして、これらの言語の中のどれを用いて記述されているかを明示することは役に立つとしている。実際、同じ文字の並びが別の言語では異なる意味を持つことがあるので、これは役に立つと思って間違いないだろう。

　「この属性の値は、言語識別のためのタグ [IETF RFC 1766]、またはIETF標準化トラックの後継規定で定義される言語識別コードとする」は、JIS版では [IETF RFC 1766]ではなく、[IETF RFC 3066]と記述されている（次の仕様抜粋を参照）。これは、RFC 1766の新版としてRFC 3066が出てきたことに対応したものである。これらは同じ仕様の旧版と新版に当たる。つまり、RFC 1766の「IETF標準化トラックの後継規定」がRFC 3066ということになる。この2つは、どちらも“Tags for the Identification of Languages”という名前を持っているだけでなく、RFC 3066には“Obsoletes: 1766”という記述が含まれている。これがRFC 1766の新しい版であることを示している。そして、さらに将来RFC 3066の後継規定が生まれるかもしれない。この規定は、それも視野に入れた記述となっている。

■言語の識別と、国や地域の識別

　次の疑問は、RFC 1766やRFC 3066がいったい何をするものであるか、である。それが次の「Note」（備考）で説明されている。

　ここでは更にISO 639やISO 3166という別の規格の名前が登場している。ISO 639は“Code for the representation of names of languages”と呼ばれるもので、アルファベット2文字で言語を識別する名前を規定している。日本語なら“ja”、英語なら“en”である。

　一方のISO 3166は“Codes for the representation of names of countries and their subdivisions”と呼ばれるもので、アルファベット2文字で国や地域を識別する名前を規定している。日本なら“JP”、米国なら“US”である。さらにもう1つ記述されているのは、IANA-LANGCODESというものだが、これは何だろうか。インターネットの各種名前などの登録機関であるIANA（Internet Assigned Numbers Authority）に登録されている言語の名前であるが、これは容易に見ることができる。試しに、en-scouseという言語名のファイルを見てみると、“English Liverpudlian dialect known as 'Scouse'”に対応する名前だと分かった。これは英語のリバプール訛りであるらしい。果たして、これが独立した名前を与えて定義を与えるだけの価値があるものか筆者には分からないが、少なくとも、XML 1.0勧告の正しい仕様にのっとって、ある要素の示す文章が「リバプール訛り」であることを示すことはできる、ということだ。

　ここは、ほかの仕様と重複した定義が削除されたものである。次は具体例である。

<p xml:lang="en">
  The quick brown fox jumps over the lazy dog.
</p>
<p xml:lang="en-GB">
  What colour is it?
</p>
<p xml:lang="en-US">
  What color is it?
</p>
<sp who="Faust" desc='leise' xml:lang="de">
  <l>Habe nun, ach! Philosophie,</l>
  <l>Juristerei, und Medizin</l>
  <l>und leider auch Theologie</l>
  <l>durchaus studiert mit heißem Bemüh'n.</l>
</sp>

　最初の“xml:lang="en"”は英語（en）の指定である。“xml:lang="en-GB"”は、英国（GB）の英語（en）の指定である。3番目の“xml:lang="en-US"”は米国（US）の英語（en）である。4番目の“xml:lang="de"”はドイツ語（de）であることを示している。

　次に記述されているのは、xml:space属性と同じ子孫要素への指定の波及についてである。

　xml:space属性と同様なので、特に説明は必要ないだろう。これは、

<p lang="en">This is a <strong>pen</strong>.</p>

というようなXHTML文書の一部を思い浮かべれば妥当な仕様であることが分かるだろう。もし、xml:lang属性の効果が子孫要素に波及しないとすれば、strong要素にもxml:lang属性を付けなければならない。しかし、同じ文章中なのに、何回も指定しなければならないのはあまりに煩雑すぎる。

　次は、DTDによるこの属性の宣言の例である。

xml:lang NMTOKEN #IMPLIED

<!ATTLIST poem   xml:lang NMTOKEN 'fr'>
<!ATTLIST gloss  xml:lang NMTOKEN 'en'>
<!ATTLIST note   xml:lang NMTOKEN 'en'>

　ここでは、以下のような指定を宣言している。

• poem要素のxml:lang属性の値はフランス語(fr)
• gloss要素のxml:lang属性の値は英語(en)
• note要素のxml:lang属性の値は英語(en)

　このような定義を与えておけば、XML文書中でいちいち言語を指定することなく、要素ごとに適切な言語指定が行われることになる。

　さて、今回はこれで終わりである。これでXML 1.0勧告の中の「2 Documents」（2. 文書）のセクションを読み終えることができた。かなり泥臭い話も含まれていて大変だったと思うが、それもこれで終わりである。次回からは、「3. Logical Structures」（3. 論理構造）に入っていくことになる。こちらはXML文書の論理構造を扱うことになるので、少しはきれいな世界を見られるはずである。ぜひ、こちらも読んでいこう。

連載　やさしく読む「XML 1.0勧告」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）