TEIガイドラインP5

記述的マークアップ TEI: 記述的マークアップ¶

記述的マークアップは，文書を区分するために使われる． paraや\end{list}のよう なマークアップは，文書のある特定部分を示すもので，例えば「ここ から先は段落である」「ここで直近のリストが終わる」という ことを示している． 一方，手続き的マークアップの場合は，文書中の特定カ所でど のような処理を施すかが示されている． 例えば，「ここを，パラメータ42, b, xで段落処理をする」 「左マージンを2クワタ左へ，右マージンを2クワタ右へ，1行飛ばして 下へ移動し，新しく左マージンへ移動」などである． XMLでは，文書中に特定の処理を施す命令と，それを示すマー クアップは，別のものとされる．

一般に，文書に処理を施すためのマークアップや記述は，当該 文書とは別のデータに置かれる． その典型例は，スタイルシートである． スタイルシートは，時に，単なる表示以上の指定をすることが ある． ⁴

記述的マークアップは，同じ文書が，必要とされる部分を対象 に，多様に処理されることがある． 例えば，内容分析プログラムでは，アノテートされたテキスト 中の脚注は全て無視されるが，書式付けプログラムでは，それ らは集められ，章末にまとめられる． あるファイルの同じ部分データに異なる処理が施されることは可能である． 例えば，あるプログラムでは，人物や場所の名前を文書中から 抽出し，索引やデータベースを作ることもあるし，また，別の プログラムでは，同じ文書に対して，違うスタイルシートを使 うことで，異なる印字で，人物や場所の名前を印刷することも ある．

文書型TEI: 文書型¶

XMLの2つ目の特徴は，文書型である． 文書には，型があるとされている． 型とは，計算機で扱うデータの種類のようなものである． 文書型は，構成要素と構造から定義される． 例えば，「レポート」とは，「題目」「著者」「要旨」それと 一連の「段落」から構成されていると考えられる． 題目がないものは，この定義からすると，レポートとはいえな い． また，一連の段落の後に要旨がくるものは，例えレポートのよ うな体裁を繕っていても，ひとにとっては，それはレポートと はいえないだろう．

文書の型が既に知られているのであれば，パーサというソフトウェア は，その文書型の定義が与えられていれば，それに相応しい文 書であるかを確認することが出来る． パーサは，特定の要素のみが当該文書中に存在しているのか，それらは適切に関連づけられているか，正しく並べられているのかなどを確認することになる． より重要なのは，同じ文書型の異なる文書を，同じように処理することができることである． ソフトウェアは，文書型の情報から得られる知識を使い，より「知的な」振る舞いをするように作ることが出来る．

データ独立TEI: データ独立¶

XMLが開発された基本デザインは，ある目的で符号化された文書を，ハードウェアやソフトウェア環境に依存せずに，不足なく，他に渡すことが出来ることを保証することにある． これまでの説明にあった2つの特徴は，抽象レベルで，この要求を満たすためものである． XMLの3つ目の特徴は，文書をマークアップする文字列レベルのものである． XML文書は，どのような言語や書記システムで書かれていても，同じ符号化文字で書かれている(つまり，ある書記システムを担う図形文字を指示するバイナリデータを表現するしくみである)． ⁵ この符号化方式は，国際規格で定義されている． ⁶ 通称ユニコードと呼ばれているこの世界的な文字集合は，メーカーの団体であ るユニコードコンソーシアムが策定している． ⁷ このユニコードは，世界中の古今の書記システムを網羅する，多くの記号を表示するための規格である．

現在ある計算機システムの殆どが，ユニコードをサポートしている． ユニコードに対応していない計算機システムに対して，XMLは，数字を使い，間接的に1つの文字を指示する手法を用意している．これは，文字参照と呼ばれている手法で，詳しくは 文字参照のところで解説する．

要素TEI: 要素¶

XMLにおける，構造の構成要素をしめす専門用語を「要素」 という． 異なる種類の要素には，異なる名前が与えられている． 但し，XMLには，要素間の関連を示す仕組みしかなく，要素の 意味を表現する手段はない． 例えば，要素blortは，要素 farbleの中に出現することができる (または，できない)とか，要素 blortetteを子要素として持つ(また は，持てない)とかを表現できる． XMLは，ソフトウェアから独立していることから，テキスト要 素の意味には，全く関与しない． どのような要素名を付けるのか，それにどのような意味を期待 するのか，ということは，XMLの語彙を決めるユーザーの手 に委ねられている． ここに，本ガイドラインのような文書の主たる目的がある． ある要素の種類を示す名前を，専門用語で「共通識別子（GI)」 という．

内容モデルの例 TEI: 内容モデルの例¶

要素は空である，つまり，内容がないこともある． 要素は，要素を含まない文字列のみを内容として持つこともある． 但し，多くの場合，要素は，別の要素を埋め込んで(含んで)いる．

整形式XML文書には，様々な処理を施すことができる． 例えば，索引を作るソフトウェアでは，詩の中にある見出しや， 最初の行や単語のリストを作るために，必要な要素を抽出する ことができる． また，簡単な書式付けソフトウェアでは，連の間に空間を挿入 したり，各連の最初の行をインデントしたり，連番号を付加したりするこ とができる． 詩の中の異なる部分に，異なる字体を割り振ることもできる． また，分析ソフトウェアでは，句読点記号を，連や韻律の単位 関連づけることができるだろう． ¹¹ この様なソフトウェアを使うと，例えば，詩の編集者による連や行の違いに関心のある研究者にとっては， タグを操作することで，それを容易に知ることができるだろう． もちろん，そのようなテキストは，ある計算機から別の計算 機へと移送することも可能であり，タグを処理できるソフト ウェア(または人)であれば，ワープロで作られたデータを移 植する際には必要となる変形や変換処理を施す必要なく扱 うことができる．

名前空間は，名前が所属するグループを表記する手段を提供する が，その名前付与規則を確認する手段を提供するものではない． 整形式だけが，文書のマークアップの利便性を上げるものではな い． 例えば，電子作品集を作る際に，計算機システムが，どのように 連や行，見出しが共起しているのかを確認してくれると，便利で ある． もし，この時のシステムが，連には要素 stanzaをタグ付けし， 決して要素 cantoや Stanzaを付加しないのであれば， より便利なものとなるだろう． このように，ある規則に従って作られているかを検証された文書 を，妥当な文書と呼んでいる． このような妥当性を検証できることも，XMLの利点のひとつであ る． この様な検証には，形式的に書かれた規則が必要である． XMLの場合，この様な形式的な規則は，スキーマと呼ば れる，付加的な文書で定義される． ¹²

XML文書の検証 TEI: XML文書の検証¶

スキーマのデザインは，緩やかに規定することも，細かく規定するこ ともできる． このバランスを考えると，以下にあるような簡単な規則と，現実にあるテ キストを処理するという複雑さ間で，身動きが取れなくなるにち がいない． とりわけ，既に存在するテキストに対して規則を当てはめるとき， そのようになる． スキーマのデザインを決める人が，はるか昔のテキストに隠された元々 の意図や意味がはっきりとは解らないまま，その構造にある規則 を決めることは，とても難しい作業となる． 一方，例えば，データベースに入れることを前提に，ある規格に則っ て作られた新しいテキストがある場合には，その規則を厳密に決 めるほど，よりその効果は発揮されることになる． また，既存のテキストにマークを付加する場合においても，想定されるテキストについて厳密な規則を定義すれば，それを検証する際に，有効な手段となる． 小さなプロジェクトでは，スキーマに対して，多くの人が参加する大規模なプロジェクトとは異なるスタンスと取ることになるだろう． いずれにせよ，重要なことは，スキーマはテキストを解釈した結 果から得られるものである． 全てのテキストで絶対的に正しい，単一のスキーマなど存在しな い． 但し，ある特定の分析向けに，あるスキーマを優先的に使うこと は便利である．

XMLは，文書構造を統一したいと思うところで，広く使われてい る． 例えば，技術文書を書く時に，節の上下関係を，適切に入れ子の 関係にしておくことは，極めて重要であり，また，相互参照を適 切に処理することも大切である． この様な場合に，文書は，既定の規則に従っているかが確認され る，原材料とみなされる． 但し，厳密に統制される必要のない要素に対しては，単純な規則で済ませることも出来る． このような規則を明確に規定することで，研究者は，電子テキス トにタグ付けし，検証する作業を軽減させることができる． また，それは同時に，研究者には，符号化されるテキストが持つ構 造や，重要な特徴についての解釈を明確にすることも求められてくる．

スキーマの例TEI: スキーマの例¶

スキーマは，様々な方法で記述される． よく使われるのは，文書型定義(DTD)という，XMLがSGMLから引き 継いた方法である． また，W3Cで策定されたXML Schemaという言語もある( http://www.w3.org/XML/Schema)． また，OASISという団体で開発され，現在はISO規格になっている RELAX NGという言語もある． ¹³. 本章も含めて，本ガイドラインでは，RELAX NGの簡易表記を使っ て例を紹介する． 但し，本ガイドラインで規定された内容は，どのスキーマ言語か らも独立したものになっている． ¹⁴ 以下では，RELAX NGの簡易表記を使うことになるが，別のスキー マ言語を使っても，表現できることに注意して欲しい．

RELAX NGを使ったスキーマの書き方には，これ以外の表現方法も 可能であることに注意して欲しい． ¹⁵ ここでは，ガイドライン全体で使われる表現方法として，この ような書き方を採用している．

RELAX NGスキーマでは，可能な文書構造を，パタン を使い規定してゆく． RELAX NGスキーマでは，複数のパタンを定義してゆく． パタンは，入力される文書がマッチするテンプレートの役割を果 たすものである． パタンの意味は，他のパタンを参照することで定義されている． または，既定の基本概念を参照することでも定義される． これについては，後述する． 先の例では，イコール記号の左側にあるのがパタンの名前であり， 右側にあるのが，その意味の宣言になる． パタンは，特別な型を取ることもある． 例えば，要素パタン，属性パタンというものがある． 先の例には，4つ(訳注：5つ)の要素パタンがある． パタンの名前と，そのパタンが記述する属性の名前が，同じよう に書かれていることに注意すること． 例えば， anthology_p = element anthology {poem_p+} では，要素パタンの名前としてanthology_pが， そのパタンが定義する要素名としてanthologyが使われ ている． このような名前の付け方自体は，さほど重要ではない． パタンと要素に同じ名前を付けることは可能であり，その場合で も，この2つは，統語上，全く別のものである． キーワード'element'の次に，要素名，すなわち共通識別子 (GI)が書かれ，要素内容は波括弧の中に定義される． これらの詳細については，以下で解説する．

先の例にある，一番最後の行は，RELAX NG検証ソフトに，どの要素が ルート要素であるかを教えるためのものである． この場合，要素anthologyが，それに 該当する． これにより，検証ソフトは，当該文書が整形式であるが妥当ではない， 等を確認することが出来る． これは，処理作業の開始点を示すともいえる．

属性リスト宣言TEI: 属性リスト宣言¶

属性は，スキーマの中で，要素と似た形で宣言される． 属性の名前と，それが付加される要素が特定され，さらに，取り 得る属性値の種類を指定することができる．

属性が取り得る値を定義しているパタンは，要素パタンの時と同 様に，波括弧で括られている． 先の例では，属性値は明示されている3つのうちから，ひとつを 選択する必要がある．

これらに加えて，ID型と呼ばれる，識別子を値とするデータ型と， URI型が，XML文書を管理する際には便利なものとして使われている． この詳細は，次の節で解説する．

文字参照TEI: Character References¶

XML文書は，その内部で，文字は同じ符号化方式(訳注：Unicode) を採用している． しかしながら，現行では，全てのコンピュータシステムがこの符 号化方式を直接サポートしているとは限らない． そこで，XMLでは，Unicode文字を，10進数や16進数による数値表 現を使って表現する，特別な書式が用意されている．

例えば，文字éは，Unicodeの 文字としては，16進数の数値で00E9と表現できるが， この文字がXML文書中に入力されていると考えてみる． もし，この文書が，この文字をサポートしていないシステム上で 使う(または入力)する場合，この文字を，文字参照 é(記号xは，以下の数値が16進数であるこ とを示している)，またはé(これは10進数) による表記)として表現することが出来る． この種のエンティティ参照は，事前に定義をしておく必要はない． なぜならば，XMLの内部で想定する符号化方式は同じだからであ る．

読みやすさを考慮して，文字参照に覚えやすい名前(例 えば，eacute)を使うことも可能である． その際には，「エンティティ宣言」と呼ばれる方法 を使い，その名前とUnicode上の番号が対応付けられる必要があ る． また，いくつかの文字参照は，事前にXML中で宣言しておく必要 なく，覚えやすい文字を使い，参照することができる． このような文字参照としては，例えば「アンド記号」や「小なり 記号」などがある． これらの記号は，この仕組みがなければ，簡単にはXML文書中に 挿入することが出来ないものである．

名前による文字エンティティ参照は，どれも「アンド 記号」から始まり，続く「名前」「セミコロン」から構成されて いる． 例えば，文字列‘T&C’をXML文章に含みたいときには， T&amp;Cと入力することになる． この様な文字参照には，他にも，&lt; (<) や&apos;(')がある．

PITEI: Processing instructions¶

XMLが作られた背景には，個別の文書処理に関する情報を排除す るという目的があったが，そのような情報を利用することは，時 に大変便利なことがある． 但し，そのような場合でも，文書構造とは明白に分けられる場合 に限ってである． 例えば，先の例にあるような，XML文書を印刷する際に，フォー マッタに対して，新しいページの開始場所を示す情報を伝える時 である． 一般に，ページ替えは，フォーマッタが独自に判断するものであ るが，この判断を覆したい時もあるだろう． XMLにおいて，PIは，文書中に挿入され，そのような指示を，他 のマークアップタグに影響を与えることなく，とても単純で，か つ効果的な方法を提供するものである．

名前空間TEI: Namespaces¶

妥当なXML文書には，必ずスキーマが指定されている． スキーマでは，当該文書の構成要素となる要素が定義されている． しかし，整形式XML文書は，必ずしもスキーマが指定されている 必要はない(スキーマが存在しないこともある)． それでも，使われている要素名の由来が定義されていることは， 便利である． また，別のスキーマで(恐らく違うように)定義されている要素を， 文書中で使うときには，要素を定義しておくことは，なおさら望ましい． 木工職人が定義した要素 table と，記録係が定義したそれとでは，その中身が異なるのは，もっ ともなことであろう．

「名前空間」がXMLに導入された背景には，この問題についての 対処法として，導入された経緯がある． 仮に，XML文書が，ある言語で書かれていたとすれば，その名前 空間には，その言語の単語が使われていると考えることができる． ある文書中に，複数の言語の単語を含めることが出来るように， 整形式XML文書にも，他の名前空間にある異なる要素を含めるこ とも可能である． 名前空間は，当該要素が所属する集合，すなわち定義されているスキーマを示す 点では，スキーマと似ている． 但し，スキーマは，要素の定義がまとめられているが，名前空間 は，単に，要素集合の存在を示すだけである． すなわち，XML文書中に実存するものは，弁別的な「接頭辞」の みであり，その接頭辞と関連する，識別のための「名前」だけである．

例えば，作品集に，ある複雑な図表を挿入することを考えてみる． この時，まず考えることは，矢や多角形などの図形要素向けのXML マークアップを，現在使っているスキーマを拡張するかどうかである． XMLには，テキストの構造を表現するだけでなく，図表もテキスト と同じように取り入れることが出来るという利点がある．

幸いにも，この様な図表を取り入れるために，新しくスキーマを 作り出す必要はない． 例えば，W3Cで定義されたSVG言語という，図形向けのマークアッ プ言語が既に存在している． ²³ SVGは，XMLを使い，2Dの図を表現するもので，大変よく利用さ れ，多くのソフトウェアでサポートされている． SVGに対応したソフトウェアを使うことで，簡単に図を書くこ とができ，しかもそれを，作品集の中に，XML形式で保存す ることが可能である． この時，SVGソフトウェアが，自分たちが定義した要素 lineと，SVGにある，恐 らく自分たちのとは異なる定義をしてある要素 lineを混乱しないようにする には，当該文書中に，SVGの名前区間にある要素が含まれてい ることを示す必要がある．

文書とエンティティ定義の関連づけTEI: Associating entity definitions with a documentinstance¶

文字参照の節で，eacute のような名前による文字参照の書式を紹介したが，これは，XML がSGMLから継承した仕組みである． スキーマ言語は，それぞれ独自の方法でXMLプロセッサとの連携 が決められているものの，幸いに，現在あるどのスキーマ言語で も共通してサポートしているひとつの手法がある．

XML宣言(PI)に続いて，XML文書インスタンスを書く前に， 特別なDOCTYPE宣言を書くことがある． この宣言は，XMLがSGMLから継承した仕組みである． この仕組みには多くの機能が用意されているが，ここではどのス キーマ言語でもサポートしている機能についてのみ解説をする．

文書とスキーマの関連づけTEI: Associating a document instance with its schema¶

スキーマ言語毎に，文書とスキーマを関連づける方法は異なって いる． XML文書は，スキーマにより妥当性が判定されるが，それを判定 するソフトウェアは，スキーマ言語毎に異なる処理をする． 例えば，RELAX NGには，文書とスキーマを関連づける機能はない． RELAX NGにおいて，この関連づけは，一般的なアーキテクチャの 問題における，ある特定の問題とされている(ISO DSDLの草稿よ り). ²⁵

一方，W3CのXML Schemaと，XMLがSGMLから継承したDTDでは，文 書から直接，妥当性を判断するための情報を参照することが可能 である． W3CのXML Schemaでは，一般に，ルート要素の属性を使い，それ を実現することになる． また，XML DTDでは， 文書とエンティティ定義の関連づけ で解説されている，DOCTYPE宣言を使い，それを実現し ている．

幸いなことに，今あるXMLプロセッサには，文書とスキーマを関 連づける方法が用意されている． 従って，文書の可搬性を最大限に高めたいのであれば，処理系に 依存した情報は文書中には含めない方がよい．

複数の文書類をひとつの文書にまとめるTEI: Assembling multiple resources into a single document¶

先に見たように，XML文書は，複数の異なる部分から構成される ことがあり，その際には，当該文書の妥当性が検証される前に， それらは統合される必要がある． XML DTDでは，特別なエンティティ(システムエンティティ)が定 義されている． このエンティティは， 文字参照で紹介したエンティティと同様に，別のファイルを参照する機 能を持っている． RELAX NGとW3C Schemaでは，この機能は用意されていない． この詳細は，ここでは扱わない．

これと同様の効果を持つ仕組みとして，先の作品集の例で示した ような，ある特別な要素を使い，統合すべき内容を参照すること はできる． W3Cでは，このような仕組みとして XML Inclusions (XInclude)²⁶ という，一般的な機能を定義している． この機能をサポートするソフトウェアの数は増えてきている．

スタイルシートと処理の関連づけTEI: Stylesheet association and processing¶

XML文書を処理する際には，表示に関して特化したスタイルシー トを複数使うことが一般的である． 一般に，XML文書と特定のスタイルシートやスキーマ言語を関連 づける理由は，特に存在しないことから，その関係は，明示して おく必要がある． スタイルシートの処理ソフトが起動されたときに，その関連性が 作られることから，アプリケーションに特化した関係といえる．

しかし，XML文書とスタイルシートとの関連づけは，ブラウザで 表示するときの一般的な利用の形態であることから，W3Cでは， その関連づけを示す文法と手順を定義している(詳細は http://www.w3.org/TR/xml-stylesheet/ を参照)． この規格は，XML文書に，デフォルトのスタイルシートへのリンク を張る手段を提供している． また，「MIME型」を使いスタイルシートを分類する方法も提供して いる． 例えば，CSSやXSLTによるスタイルシートを処理する方法を示して いる．

今ある殆どのブラウザーでは(程度の違いはあるが)CSSがサポートされている． また，いくつかのブラウザーでは，XSLTもサポートされている．