第1章 TEIインフラストラクチャ

目次

• 1.1 TEIモジュール
• 1.2 TEIスキーマの定義
• 1.3 TEIクラスシステム
• 1.4 マクロ
• 1.5 TEIインフラストラクチャモジュール
• 1.6 非推奨のデータ型マクロ

　この章では、これらのガイドラインで定義されているエンコーディングスキームのインフラストラクチャについて説明する。以下の章を理解するための概念フレームワークと、その概念フレームワークが実装される手段を紹介する。XMLおよびXMLスキーマ（v. XMLの簡単な導入 を参照 ）にある程度精通していることを前提としているが、これらのガイドラインのすべてのユーザーがアクセスできるようになっている。他の章では、さらに技術的な詳細を提供する。特に、これらのガイドライン自体を表現するために使用されるXMLスキーマを説明する第22章 ドキュメンテーション要素、およびODDプロセッサの意図する動作の説明と変更および適合の問題の説明を組み合わせた第 23 章 TEIの使用 を提供する。これらの章は、新しいTEIベースのシステムを実装しようとする人が読むべきである。

　TEI符号化スキーマは、いくつかの「モジュール」で構成され、それぞれが特定のXML要素とその属性を宣言している。要素の宣言の一部には、1つ以上の要素「クラス」への割り当てが含まれている。別の部分では、これらのクラスを参照して、可能なコンテンツと属性を定義している。この遠回りな方法が、TEIシステムにその強さと柔軟性の多くを与えている。要素を多かれ少なかれ自由に組み合わせることで、特定の要件セットに適した「スキーマ」を形成できる。また、既存のクラスまたは要素を参照する新しい要素をスキーマに簡単に追加できる。これは、スキーマに含まれるモジュールによって提供される要素の一部を除外するためである。

　原則として、TEIスキーマは、モジュールの任意の組み合わせを使用して構築できる。ただし、特定のTEIモジュールは特に重要であり、例外的な状況を除いて常に含まれる必要がある。この章で説明するモジュールteiは、他のすべてのモジュールで使用されるクラス、マクロ、およびデータ型を定義するため、この種類に属する。第 3 章 すべてのTEI文書で使用可能な要素 で定義されているcoreモジュールには、 ほとんどすべての種類の文書で必要となる可能性がある要素と属性の宣言が含まれているため、グローバルな使用が推奨される。第 2 章 TEIヘッダー で定義されている header モジュールは、TEI準拠に必要な構成要素であるTEIヘッダーを構成するメタデータ要素と属性の宣言を提供する。一方、第 4 章 デフォルトのテキスト構造 で定義されている textstructure モジュールは、ほとんどのブックタイプのオブジェクトの符号化に必要な基本的な構造要素を宣言する。したがって、ほとんどのスキーマにはこれらの4つのモジュールを含める必要がある。

　TEIスキーマの仕様はそれ自体がTEI文書であり、第 22 章 ドキュメント要素 で説明されているモジュールの要素を使用する。このような文書は、もともとシステム用に策定された設計目標から略式で ODD 文書、つまり、「One Document Does it all　(1つの文書がすべてを実行する)」と呼ばれる。ODD文書を保守および処理するためのスタイルシートはTEIによって保守されており、これらのガイドラインもそのような文書として保守されている。23.5 ODDシステムの実装 でさらに説明されているように、ODD文書を処理して、現在広く使用されている3つのスキーマ言語（XML DTD言語、ISO RELAX NG言語、またはW3Cスキーマ言語）のいずれかを使用して表されるスキーマを生成できるほか、この『ガイドライン』や関連するWebサイトといった文書を生成できる。

　この章の大部分では、TEIインフラストラクチャモジュール自体について説明する。初めて読む場合は読み飛ばしてもかまわないが、 23.3  カスタマイズ で説明されているTEIカスタマイズテクニックを最大限に活用することを計画している人にとって、ここで取り上げるトピックの理解は不可欠である。

　この章は、TEIスキームで利用可能な各モジュールを簡単に特徴付けることから始まる。セクション 1.2 TEIスキーマの定義 では、XML DTD言語、RELAX NG、W3Cスキーマなどの特定のスキーマ言語でTEIスキーマを構築する方法を一般的な用語で説明している。

　この章のうち次の最大の部分では、要素のグループとその特性を定義するために使用される属性と要素クラスを紹介する（1.3 TEIクラスシステム ）。 最後に、1.4マクロ では、いくつかの一般的に使用されるコンテンツモデルを表すために使用されるマクロの概念を紹介し、TEI属性の有効な値の範囲を制限するために使用される「データ型」をリストする（1.4.2 データ型仕様 ）。

　これらのガイドラインは、あらゆる種類の文書をマークアップするための数百の要素と属性を定義している。各定義には次のコンポーネントがある。

• 簡易な説明
• ISOスキーマ言語RELAX NGから取得した要素と組み合わせて、これらのガイドラインで定義された特別な目的のXMLボキャブラリを使用して表現された正式な宣言
• 使用例

　これらのガイドラインの各章は、関連する要素のグループを提示し、モジュールと呼ばれる対応する宣言のセットも定義する。すべての定義は、付録として提供されるリファレンスセクションにまとめられている。特定の章の正式な宣言は、対応するモジュール内にまとめられている。便宜上、通常、特定のアプリケーション領域で使用するため、または特定の種類の使用法をサポートするために、各要素が単一のモジュールに割り当てられる。したがって、モジュールは、多数の関連する要素宣言をグループ化する便利な方法である。単純な場合、TEIスキーマは、以下のセクション 1.2 TEIスキーマの定義 さらに説明するように、少数のモジュールを組み合わせて作成される。

　次の表に、これらのガイドラインの現在のリリースで定義されているモジュールを示す。

上記の各モジュールについて、対応する章では、スキーマに含まれるときに利用できるようにするクラス、要素、およびマクロの完全な説明が得られる。これらのガイドラインの他の章では、TEIスキーマの使用に関する他の側面を検討している。

　XML文書が（単なる整形式ではなく）妥当であることを判断するには、第v章 XMLの簡単な導入 で説明されているように、その構造をスキーマに対してチェックする必要がある。妥当なTEI文書の場合、このスキーマは、 第　23.4　章　適合性 でさらに定義されているように、適合TEIスキーマでなければならない。ローカルシステムでは、スキーマを暗黙的に許可する場合があるが、交換のために、文書に関連付けられたスキーマを明示的にする必要がある。これらのガイドラインで推奨されているこれを行う方法は、文書を検証できるTEIスキーマ仕様を明示的にまたは参照によって提供することである。

　TEI準拠のスキーマは、TEIモジュールの特定の組み合わせである。たとえば、一部の要素を抑制または名前変更するために、各モジュールに含まれる要素および属性宣言を変更する追加の宣言も含まれることがある。TEIは、アプリケーションに依存せずに、 第 22 章 ドキュメンテーション要素で定義されているschemaSpec要素によって、TEIスキーマを指定する方法を提供する。同じシステムを使用して、明示的に新しい要素を追加するか、他のXMLボキャブラリを参照することにより、TEIを拡張するスキーマを指定することもできる。どちらの場合でも、仕様を処理して、XML DTD言語、RELAX NG、W3Cスキーマなどのさまざまな特定のスキーマ言語で表現された正式なスキーマを生成できる。これらの出力スキーマは、検証ツールやエディターなどのXMLプロセッサで使用され、文書を検証または処理する。TEI形式仕様の処理に関する詳細は、第 23 章TEIの使用 に記載されている。

　TEIスキームの最も単純なカスタマイズは、上記の推奨される4つのモジュールのみを組み合わせたものである。ODD形式では、このスキーマ仕様は次の形式を取る。

<schemaSpec ident=”TEI-minimal” start=”TEI”>
 <moduleRef key=”tei”/>
 <moduleRef key=”header”/>
 <moduleRef key=”core”/>
 <moduleRef key=”textstructure”/>
</schemaSpec>

bibliography 

　このスキーマ仕様には、moduleRef要素の@key属性によって識別される4つのモジュールそれぞれへの参照が含まれている。スキーマ仕様自体にも識別子（ TEI-minimal ）が与えられる。ODDプロセッサは、XML DTD言語、ISO RELAX NG言語、W3Cスキーマ言語、または原則として他の適切な強力なスキーマ言語を使用して表現された、この宣言セットから適切なスキーマを生成する。結果のスキーマは、 第v章 XMLの簡単な導入 でさらに説明されているように、さまざまなメカニズムの1つによって文書インスタンスに関連付けられる。スキーマに対して検証される文書インスタンスの開始ポイント（またはルート要素）は、start属性によって指定される。ODD仕様の処理に関する詳細は、 23.5 ODDシステムの実装 に記載されている。

　これらのガイドラインでは、TEIスキームを構成する各モジュールを1つずつ紹介しているため、説明を明確にするために、各章では単一のモジュールから引き出された要素に焦点を当てている。もちろん、実際には、テキストのマークアップは、多くの異なるモジュールから取得した要素を使用する。これは、一つにはテキストが異種のオブジェクトであるため、もう一つには符号化する人の目標が異なるためである。この不均一性の例には次のものがある。

• テキストは、異なる型の他のテキストのコレクションである場合がある。たとえば、散文、詩、ドラマの名詩文集。
• テキストには、他のより小さな埋め込みテキストを含めることができる。たとえば、散文の物語に含まれる詩や歌。
• テキストの一部のセクションはある形式で記述され、別のセクションは別の形式で記述される場合がある。たとえば、いくつかの章が散文である小説、辞書エントリの形式をとる小説、さらに劇中のシーンの形式。
• 符号化されたテキストには、たとえば修辞的または言語的特徴の詳細な分析注釈が含まれる場合がある。
• 符号化されたテキストは、文字起こしを同じまたは異なるソースの転写版と組み合わせることができる。
• たとえば、原稿の資料を詳細に説明する場合など、テキストの説明には追加の特殊なメタデータ要素が必要になる場合がある。

　TEIは、これらすべておよび他の多くのユースケースをサポートするメカニズムを提供する。このアーキテクチャにより、モジュールの任意の組み合わせの要素と属性を単一のスキーマ内に共存させることができる。特定のモジュール内で、テキストの「粒度」のさまざまなビューをサポートするために、要素と属性が提供される。次に例を示す。

• 共通のTEIヘッダーを共有する、一連の TEI 文書としてのコーパスまたはコレクションの定義（第 15 章 言語コーパス を参照 ）
• オプションの前付けと後付けを、それ自体が複合された可能性のある収集されたテキストのグループと組み合わせる複合テキストの定義（セクション 4.3.1 グループ化されたテキスト を参照 ）
• 埋め込まれたテキストを表現するための要素で、ある物語が別の物語の中に「浮いている」ように見える（セクション 4.3.2 フローティングテキスト を参照 ）

　これらのガイドラインの後続の章では、これらおよびその他の多くの可能な対象機能に適したマークアップ構成体について詳細に説明する。マークアップ構成は、アプリケーションまたはプロジェクトの任意のセットの必要に応じて組み合わせることができる。 たとえば、原稿のコレクションの野心的なデジタル版を作成することを目的としたプロジェクトで、各ソースに関する詳細なメタデータ、コンテンツのデジタル画像、各ソースの詳細な文字起こし、およびサポートする伝記および地理データベースを含めるには、次のようにいくつかのモジュールを組み合わせたスキーマが必要になる場合がある。

<schemaSpec ident=”TEI-PROJECT” start=”TEI”>
 <moduleRef key=”tei”/>
 <moduleRef key=”header”/>
 <moduleRef key=”core”/>
 <moduleRef key=”textstructure”/>
 <moduleRef key=”msdescription”/>
<!– manuscript description –>
 <moduleRef key=”transcr”/>
<!– transcription of primary sources –>
 <moduleRef key=”figures”/>
<!– figures and tables –>
 <moduleRef key=”namesdates”/>
<!– names, dates, people, and places –>
</schemaSpec>

bibliography 

　あるいは、そのようなプロジェクトの一部に、より単純なスキーマを使用することもできる。たとえば、トランスクリプションを準備する人は、 core 、 textstructure 、およびtranscrモジュールの要素のみが必要な場合があり、したがって、以下によって生成される。

<schemaSpec ident=”TEI-TRANSCR” start=”TEI”>
 <moduleRef key=”tei”/>
 <moduleRef key=”core”/>
 <moduleRef key=”textstructure”/>
 <moduleRef key=”transcr”/>
</schemaSpec>

bibliography

  TEIアーキテクチャは、モジュールの単純な選択を超えた、より詳細なカスタマイズもサポートする。スキーマは、モジュールの要素を抑制したり、属性の一部を抑制したり、名前を変更したり、新しい要素や属性を追加したりできる。このように可能な種類の修正の詳細な議論は 23.3 カスタマイズ で提供され、それらのアプリケーションに関連する適合規則は 23.4 適合 で議論される。これらの機能は、すべてのスキーマ言語で使用できる（ただし、一部の機能はすべての言語で使用できるわけではない）。また、 ODD 言語は、非TEIモジュールがRELAX NGスキーマ言語を使用して表現されている場合、TEIおよび非TEIモジュールを単一のスキーマに結合することを可能にする（詳細については、 22.8.2 TEIモジュールと非TEIモジュールの組み合わせ を参照する）。

　TEIスキームは、約500の異なる要素を区別する。理解、モジュール方式、および変更を支援するために、これらの要素の大部分は何らかの方法で正式に分類されている。クラスは、要素間の2つの異なる種類の共通性を表すために使用される。クラスの要素はいくつかの属性セットを共有するか、コンテンツモデルの同じ場所に表示される場合がある。クラスは、メンバーが属性を共有する場合は属性クラスと呼ばれ、メンバーが同じ場所に表示される場合はモデルクラスと呼ばれる。どちらの場合でも、要素は、それがメンバーであるクラスからプロパティを継承すると言われている。

　クラス（およびそれらのクラスのメンバーである要素）は、他のクラスからプロパティを継承する場合もある。たとえば、クラスAがクラスBのメンバー（またはサブクラス ）であるとすると、クラスAのメンバーである要素は、クラスAによって定義されたプロパティだけでなく、クラスBによって定義されたプロパティも継承する。状況では、クラスBはクラスAのスーパークラスであるとも言う。 スーパークラスのプロパティは、そのサブクラスのすべてのメンバーによって継承される。 TEIスキームが編成されるクラスの基本的な理解を強くお勧めする。これは、システムのカスタマイズを成功させるために不可欠である。

　属性クラスは、共通の属性セットを共有する要素をグループ化する。属性クラスには、接頭辞 att. で構成される名前が付けられる。それは、しばしば形容詞が続く。たとえば、クラスのメンバー att.canonical 共通のkeyとref属性があり、どちらも各要素ごとに個別に定義されるのではなく、クラスのメンバーシップから継承される。これらの属性は、att.canonicalクラスによって定義されている（または継承されている）。これらの属性が有用であると考えられるTEIスキームに別の要素を追加する場合、それらを提供する最も簡単な方法は、新しい要素を att.canonical クラスのメンバーにすることである。また、このメソッドは、どの要素に関連付けられていても、問題の属性が常に同じ方法で定義され、同じデフォルト値などをとることを保証することに注意する。

　一部の属性クラスは、 teiインフラストラクチャモジュール内で定義されているため、グローバルに使用できる。他の属性クラスは特定のモジュールに固有であるため、他の章で定義されている。そのようなクラスによって定義された属性は、関係するモジュールがスキーマに含まれていない限り利用できない。

　属性クラスによって提供される属性は、クラス自体によって、直接、または別のクラスからの継承によって指定された属性である。たとえば、属性クラス att.pointing.group のすべてのメンバーに属性@domainと@targFuncを提供する。ただし、この att.pointing クラスはクラスのサブクラスであり、そのメンバーは属性@target、@targetLangおよび@evaluateも継承する。したがって、クラス att.pointing のメンバーにはこれら3つの属性があり、クラス att.pointing.group のメンバーには5つすべてがある。

　一部のモジュールは、既存のインフラストラクチャクラスのスーパークラスを定義することに注意する。たとえば、グローバル属性クラスであるatt.divLikeは属性@orgと@sampleを使用可能にし、一方、 verse モジュールに固有のatt.metricalsクラスは属性 @met 、 @real、 @rhyme を提供する。att.metricalはatt.divLike のスーパークラスとして定義されているため、これらの5つの属性はすべて要素で使用できる。att.metrical の宣言は、verseモジュールがスキーマに含まれているときに、att.divLike によってすでに定義されている3つの属性に3つの属性を追加します。ただし、このモジュールがスキーマに含まれていない場合、 att.divLike クラスは、最初に言及した2つの属性のみを提供する。 特定のモジュールに固有の属性は、本章ではないが、関連モジュールとともに文書化されている。ある特定の属性クラスで att.global として知られているものは、すべてのモジュールに共通であるため、次のセクションで詳細に説明する。すべての属性クラスの完全なリストは、 以下の 付録B属性クラス に記載されている。

　次の属性は、すべてのTEI要素のためのインフラストラクチャモジュールで定義される。

　att.globalは、TEI符号化方式のすべての要素に共通の属性を提供する。

　これらの属性の一部（特に@xml：id、@n、@xml:lang、@xml:base、@xml:space）は、 att.global 属性クラス自体によって提供される。他はサブクラスによって提供され att.global.rendition 、 att.global.responsibility 、または att.global.source である。それらの使用法は、後続の諸サブセクションで説明する。

　他のいくつかのグローバルに利用可能な属性は、att.global クラスの他のサブクラスによって定義される。これらは他のモジュールによって提供されるため、そのモジュールについて説明している章で説明されている。簡単な要約表は、以下のセクション 1.3.1.1.7　その他のグローバルに利用可能な属性 に記載されている。

　@xml:id属性に指定する値は、World Wide Web Consortiumの XML勧告で 定義されている有効な名前でなければならない。これは、文字またはアンダースコア文字（’_’）で始まり、文字、数字、ハイフン、アンダースコア、フルストップ、および特定の結合文字と拡張文字以外の文字を含まないことを意味する。 [note]コロンはデフォルトで妥当な名前文字でもある。ただし、XMLには（名前空間プレフィックスを示すために）特定の目的があるため、名前内で他の方法で使用することは許されない。[/note]

　XML名（およびXML TEI文書の@xml:idの値）では、大文字と小文字が区別されるため、 partTimeとparttimeは2つの明確に異なる名前であり、（おそらく賢明ではないが）2つの異なる要素の出現を示すために使用できる。

　2つの要素に同じ識別子が与えられている場合、検証XMLパーサーは構文エラーを通知する。したがって、次の例は無効である。

<p xml:id="PAGE1"><q>What's it going to be then, eh?</q></p><p xml:id="PAGE1">There was me, that is Alex, and my three droogs, that is Pete,
Georgie, and Dim, ... </p>


bibliography

　要素にユニークな識別子を提供する方法については、セクション 3.10.2　新規参照システムの作成 　を参照する。

　@n属性は要素の識別名または番号も提供するが、この場合、情報は有効な@xml:id値である必要はない。その値は任意の文字列である。通常、それは数字または他の同様の列挙子またはラベルである。たとえば、番号付きリストの項目に与えられた番号は、@n属性で記録できる。これにより、この章のリストのように、番号10が2回使用され、11が省略された欠陥のあるオリジナルから転写された、オリジナルの記数法のエラーを記録することができる。

<list rend="numbered">
 <item n="1">About These Guidelines</item>
 <item n="2">A Gentle Introduction to XML</item>
 <item n="9">Verse</item>
 <item n="10">Drama</item>
 <item n="10">Spoken Materials </item>
 <item n="12">Dictionaries</item>
</list>

@n属性は、テキスト内の要素に関連付けられた一意でない名前を記録するためにも使用できる。場合によっては、次の例のようにユニークな識別子と一緒に記録することもできる。

<div type=”book” n=”one” xml:id=”TXT0101″>
<!– … –>
 <div type=”stanza” n=”xlii”>
<!– … –>
 </div>
</div>

bibliography 

上記のように、@xml:idまたは@n属性の値を記録する必要はない。XMLプロセッサは、追加のタグ付けなしで、XML文書内の1つの要素の別の要素内の連続的な位置を識別できる。したがって、長い詩の各行に数値シーケンスで明示的にラベル付けされている符号化は以下である。

<l n=”1″>
<!– … –>
</l>
<l n=”2″>
<!– … –>
</l>
<l n=”3″>
<!– … –>
</l>
<!– … –>
<l n=”100″>
<!– … –>
</l>

bibliography 

これは、おそらく冗長である。

　@xml:lang属性は、特定の要素のコンテンツに適用される自然言語と書記体系を示す。指定されていない場合、値はすぐに囲む要素の値から継承される。したがって、原則として、 TEI 要素で テキストのベース言語を指定し、 ほとんどの要素が@xml:langのデフォルト値を取ることを許可するのが最も簡単である。要素の言語は、基本言語以外の言語の要素に対してのみ明示的に指定する必要がある。このため、 TEI ルート要素、またはteiHeaderとテキスト要素の両方で、@xml:lang属性のデフォルト値を指定することをお勧めする。後者は、TEI文書内のテキスト要素がそれに付属するTEIヘッダーのデフォルト言語とは異なるデフォルト言語を使用するという珍しいケースでは適切である。ソース内の他の言語シフトは、可能な限り適切なレベルの要素で@xml:lang属性を使用して明示的に識別する必要がある。

　次の回路図の例では、英語のTEIヘッダーが英語のテキストに添付されている。

<TEI xml:lang=”en” xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader>
<!– … –>
 </teiHeader>
 <text>
<!– … –>
 </text>
</TEI>

bibliography 

　ヘッダーとテキストの両方にデフォルト言語を指定すると、同じ効果が得られる。

<TEI xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader xml:lang=”en”>
<!– … –>
 </teiHeader>
 <text xml:lang=”en”>
<!– … –>
 </text>
</TEI>

bibliography 

　後者のアプローチは、2つが異なる場合に必要である。たとえば、英語のヘッダーがフランス語のテキストに適用される場合などである。

<TEI xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader xml:lang=”en”>
<!– … –>
 </teiHeader>
 <text xml:lang=”fr”>
<!– … –>
 </text>
</TEI>

bibliography 

　同じ原則がどの階層レベルにも当てはまる。次の例では、テキストのデフォルト言語はフランス語であるが、その一部はドイツ語である。

<TEI xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader xml:lang=”en”>
<!– … –>
 </teiHeader>
 <text xml:lang=”fr”>
  <body>
   <div>
<!– chapter one is in French –>
   </div>
   <div xml:lang=”de”>
<!– chapter two is in German –>
   </div>
   <div>
<!– chapter three is French –>
   </div>
<!– … –>
  </body>
 </text>
</TEI>

bibliography 

　同様に、次の例では、 term 要素 の@xml:lang属性により、 使用されている技術用語が英語ではなくラテン語であるという事実を記録できる。 対照的に、 q 要素には@xml:lang属性は必要ない。 これは、親と同じ言語であるためである。

<p xml:lang=”en”>The
constitution declares <q>that no bill of attainder or <term xml:lang=”la”>ex post
     facto</term> law shall be passed.</q> …</p>

bibliography 

　指示されているテキストの言語を識別することが望ましいか、または必要な場合は、（非グローバル）属性targetLangを使用する必要があることに注意する。たとえば、

<ptr target=”x12″ targetLang=”fr”/>

bibliography 

　では、フランス語で書かれたテキストをポインターは参照している。

　@xml:langおよび@targetLang属性に使用される値は、標準リストの値を使用して、特定の方法で構築する必要がある。詳しくは、vi.1. 言語識別 を参照。

　特定の言語に関する追加情報 は、ヘッダー内の 言語 要素で 提供される場合がある （セクション 2.4.2 言語の使用 を参照 ）。

レンド、レンディション、およびスタイル属性はすべて、ソース内のテキストの物理的な表示に関する情報を提供するために使用される。次の例では、rendを使用して、強調された単語と固有名詞の両方が斜体で印刷されることを示す。

<p> … Their motives <emph rend=”italics”>might</emph> be pure
and pious; but he was equally alarmed by his knowledge of the ambitious <name rend=”italics”>Bohemond</name>, and his ignorance of the Transalpine chiefs:
…</p>

bibliography 

　次のように、style属性を使用しても同じ効果が得られる場合がある。

<p> … Their motives <emph style=”font-style: italic”>might</emph> be pure and pious; but he was equally alarmed by his knowledge of
the ambitious <name style=”font-style: italic”>Bohemond</name>, and his ignorance of
the Transalpine chiefs: …</p>

bibliography 

　すべてまたはほとんどの emph および name 要素がイタリック体でテキストに表示される場合、その事実をTEIヘッダーに一度登録する方が便利である（ 以下で説明する rendition 要素 を使用 ）。それから指定されたレンディションから逸脱する要素のみに@rendまたは@style値を指定する。

　@rend属性と@style属性の主な違いは、前者に使用される値には、スペース文字で区切られた符号化する人によって考案された語彙からの1つ以上のトークンが含まれることがあるのに対し、後者に使用される値は、 CSSなどの正式に定義されたスタイル定義言語から取得した単一の文字列でなければならないことである。@rend属性値は、空白で区切られたトークンのシーケンス不定のセットであるが、@style値では、形式的に定義されたスタイル定義言語の一部として空白とシーケンスの関係が許可される。

　2.3.4 タグ付け宣言 で定義された rendition要素 は、 繰り返し使用の形式の記述を保持するために使用されてもよい。rendition 要素は、デフォルトで、またはグローバルな @rendition 属性の手段のいずれかによって、例えば以下のように任意の要素に関連付けることができる。

<tagsDecl>
<!– define italic style using CSS, selecting it as default for emph and hi elements –>
 <rendition xml:id=”IT” scheme=”css”
  selector=”emph, hi”>font-style: italic;</rendition>
<!– define a serif font family, selecting it as default for the text element –>
 <rendition xml:id=”FontRoman” scheme=”css”
  selector=”text”>font-family: serif;</rendition>
</tagsDecl>
<!– … –>
<text>
 <body>
  <div>
   <p rendition=”#IT”>
<!– this paragraph uses the seriffed font, but is in italic–>
   </p>
   <p>
<!– this paragraph uses the seriffed font, but is not in italic –>
   </p>
  </div>
 </body>
</text>

　@rendition属性は常に1つ以上の rendition 要素を指し 、それぞれが元の形式のテキストのレンダリングまたは外観の何らかの側面を定義する。これらの詳細は、CSS（ Lie and Bos（eds.）（1999） ）またはXSL-FO（ Berglund (ed.)（2006） ）などの正式なスタイル定義言語を使用して最も便利に記述できるが、特定のプロジェクト用に開発された他の正式な言語で、または正式ではないが、文章内で記述することもできる。一般的に、CSSやXSL-FOなどの言語は、スクリーンまたは印刷への文書出力を記述するために使用されるが、それでも元文書、特に印刷文書の外観を記述するための正式かつ正確なメカニズムを提供するが、元文書の多くの側面も提供する。たとえば、CSSとXSL-FOの両方は、書体、太さ、スタイル、 文字と行間隔 等々を記述するためのメカニズムを提供する。

　上記のように、@style 属性は、 rendition 要素を参照するというよりはむしろ、CSSなどの言語を使用して個々のソース要素の外観を記述したいと考える、符号化する者に提供される。その値は、選択された正式なスタイル定義言語の任意の表現であることが許されている。

　CSSなどの正式な定義言語は、通常、そのために値が指定されている一連のプロパティ （font-styleやmargin-leftなど）を識別する。このようなプロパティと値のペアのようなシーケンスがスタイルシートを構成する。TEIは、そのような言語を使用して、ソース文書がどうフォーマットされるべきであるのかをコントロールするのではなく、単にソース文書の外観を記述する。

　TEIスキームでは、ソース文書内の要素の外観に関する情報を次の明確な方法で提供できる。

1. rendition 要素とその@selector属性 を使用して、1つ以上のプロパティを一連の要素のデフォルトとして（デフォルトのCSSによる外部スキームに基づいて）指定できる。
2. 1つ以上のシーケンス不定トークンの便利なセットを用いて@rend属性を使用し、個々の要素の出現に対して1つ以上のプロパティを指定できる。
3. @rend属性を使用して rendition 要素を指すことにより、個々の要素の出現に対して1つ以上のプロパティを指定できる。
4. @style属性を使用して、個々の要素の出現に対して明示的に1つ以上のプロパティを指定できる。

　同じプロパティが上記の方法のうちの2つ以上の方法で指定されている場合、上記のリストで最も大きい番号のプロパティが適用可能であると理解される。次に、各々の方法から結果として生じるプロパティを組み合わせて、指定された要素に適用可能なプロパティと値のペアの完全なセット、および（デフォルトで）そのすべての子に提供する。

　処理を簡単にするために、全体を通して同じ正式なスタイル定義を使用する必要がある。ただし、アーキテクチャでは、@scheme属性を使用して1つ以上の rendition 要素のために異なる言語を指示することにより、これを様々なものできる。そのような値をきちんと有意に組み合わせられるように注意する必要がある。これが@renditionまたは@styleと組み合わせて使用される場合、同様の考慮事項がレンド属性の使用に適用される。

　これらのTEI属性は、意図した出力レンディションではなく 、常に元文書のレンディションまたは外観を記述することに注意する。

　@source属性は、たとえば、引用語句のために書誌引用を指摘することによってそれが取られたソースを示すなど、要素のソースとそのコンテンツを示すために使用される。ポインターのターゲットは、何らかの書誌リストのエントリ、またはソース自体のデジタルバージョンへのポインターである場合がある。

　他のTEIポインターと同様に、この属性の値は、絶対URL、相対URL、またはprefixDefに記載されている相対URLまたは絶対URLに展開されるプライベートスキームURIなど、任意の形式のURIとして表現される。 次の典型的な例では、相対的な「ベア名」のURL値を使用して、引用自体の書誌ソースを含む文書の書誌の他のどこかにあるbiblを示す。

<p>
<!– … –>
 <quote source=”#chicago-15_ed”>Grammatical theories
   are in flux, and the more we learn, the less we
   seem to know.</quote>
<!– … –>
</p>
<!– … –>
<bibl xml:id=”chicago-15_ed”>
 <title level=”m”>The Chicago Manual of Style</title>,
<edition>15th edition</edition>.
<pubPlace>Chicago</pubPlace>:
<publisher>University of Chicago Press</publisher>
(<date>2003</date>),
<biblScope unit=”page”>p.147</biblScope>.

</bibl>

　または、完全なURIを使用して、引用語句をこのソースのオンライン版に直接リンクすることもできる。

<p>
<!– … –>
 <quote source=”http://www.chicagomanualofstyle.org/15/ch05/ch05_sec002.html”>Grammatical theories
   are in flux, and the more we learn, the less we
   seem to know.</quote>
<!– … –>
</p>

　@source属性は、schemaSpec または elementRef などのようなスキーマドキュメンテーション要素でも使用され、定義されているコンポーネントのための宣言がODDプロセッサによってそこから取得できる場所を示す。たとえば 、TEI P5のバージョン2.0.1にあったように、特に p 要素 を含めることを希望するカスタマイズは、次のような elementRef要素上のそれのためにソースを示すであろう。

<elementRef key=”p” source=”tei:2.0.1″/>

bibliography 

ここで、@source属性の値は、TEIガイドライン用に事前定義されたショートカットを使用して、プライベートURI構文を使用して提供される。より一般的には、ODDカスタマイズは、そこからあらゆるODDのコンパイル済みバージョンをダウンロードできるURIを指すことができる。上記のショートカットは次と同等である。

<elementRef key=”p”
 source=”http://www.tei-c.org/Vault/P5/2.0.1/xml/tei/odd/p5subset.xml”/>

bibliography 

　moduleRef または elementRef などの要素は、セクション22.8.1 TEI customizationsでさらに説明されているように、この方法で@source属性を使用して、以前にコンパイルされたスキーマに含まれるTEI ODD仕様のセットを指すことが

　@cert属性は、マークアップによって表される操作または解釈に関する符号化する者の確実性を示す方法を提供する。通常、次の例のように、符号化する者がテキストに1つ以上の修正を提供し、それぞれに添付したい確実性を示す場合に使用される。

Blessed are the <choice>
 <sic>cheesemakers</sic>
 <corr cert=”high”>peacemakers</corr>
 <corr cert=”low”>placemakers</corr>
</choice>:
for they shall be called the children of God.

bibliography 

　@cert属性は、通常、ここにあるように、確実性の程度を単純に高、中、または低として特徴付ける。より詳細または微妙な指示が必要な状況では、代わりに0（最小確率）から1（最大確率）の間の確率値を指定できる。他のより洗練されたメカニズムについては、 第 21 章　確実性、精度、および責任　 で説明する。

　@resp属性は、要素によって符号化された情報のいくつかの側面に対して責任があると見なされる個人または組織を示すために使用される。たとえば、上記の例を次のように修正して、2つの修正を担当する編集者を示すことができる。

… <corr cert=”high” resp=”#ed1″>peacemakers</corr>
<corr cert=”low” resp=”#ed2″>placemakers</corr>…

bibliography 

　責任のより詳細または微妙な表現が必要な場合、@resp属性によって示される要素は、一般的なエージェント（たとえば、 person または org ）ではなく、より正確な要素 であることが推奨される。例えば、エージェントが果たした正確な役割を文書化できるrespStmt、author、editorなどである。次の例では、nからuへの修正が特定の名前の転写者によって行われたことを示している。

<!– in the <text> … –><lg>
<!– … –>
 <l>Punkes, Panders, baſe extortionizing
   sla<choice>
   <sic>n</sic>
   <corr resp=”#JENSJ”>u</corr>
  </choice>es,</l>
<!– … –>
</lg>
<!– in the <teiHeader> … –>
<!– … –>
<respStmt xml:id=”JENSJ”>
 <resp>Transcriber</resp>
 <name>Janelle Jenstad</name>
</respStmt>

bibliography 

　複数の respStmt により、符号化する者はTEIファイルの一部で演じられている各役割（作成、転写、符号化、編集、校正など）を明確に指定できる。必要に応じて、第13章 名前、日付、人、および場所で説明する方法を使用して、respStmt 内の name 要素をより詳細な person または org 要素にも関連付けてもよい。

　いくつかのTEI要素は、値が anyURI として定義されている属性を保持する。 つまり、そのような属性は、典型的にはURLとして表されるリンクまたはポインターを提供する。他のXMLアプリケーションと同様に、TEIでは特別な属性を使用して、そこで相対URLが評価されるべきコンテキストを設定できる。グローバル属性@xml:baseはXML仕様の一部として定義され、TEI名前空間よりもむしろXML名前空間に属する。ここでは詳しく説明しないが、@xml:base に関する参照情報は Marsh and Tobin (eds.) （2009） によって提供されている。

　本質的に、@xml:base は、指定された要素のスコープ内のすべての相対URLのコンテキストを設定するために、例えば次のように使用される。

<body>
 <div xml:base=”http://www.example.org/somewhere.xml”>
  <p>
<!–… –>
   <ptr target=”elsewhere.xml”/>
<!–… –>
  </p>
 </div>
 <div>
  <p>
<!–… –>
   <ptr target=”elsewhere.xml”/>
<!–… –>
  </p>
 </div>
</body>

bibliography 

　ここの最初のptr 要素は、@xml:base　の値を提供するdiv のスコープ内にある。 そのため、そのターゲットはhttp://www.example.org/elsewhere.xmlにある。ただし、二番目の ptr は、デフォルトコンテキストを変更しない div のスコープ内にあるため、そのターゲットは現在の文書と同じディレクトリにある文書である。

　@xml:base 属性は、文書のコンテキストが変更された後（たとえば、XIncludeを介して別の文書に埋め込まれた結果）、文書内の相対URIの安定した解決を可能にすることを目的としている。単に@xml:base を符号化する者がより短いURIを記述できるようにする方法として設定することはお勧めしない。特に、@xml:base は、 # id （ id は@xml:id） の形式において同一文書参照の参照先に関してあいまいさを引き起こす可能性がある。RFC 3986 は、この型のURIが別の文書の読み込みをもたらすべきではないと述べている。したがって、RFCは、そのような参照はそれらが置かれている文書の内部にあると想定している。@xml:base を使用して任意の外部ベースを示し、同時に同じ文書参照を使用すると、ソフトウェアエージェントがこれらのリンクを予期しない一貫性のない方法で処理する可能性がある、ということになるかもしれない。この属性とTEIリンクメソッドへの影響の詳細については、第 16 章 リンク、セグメンテーション、およびアライメント  で説明する。

　グローバル属性@xml:spaceは、XMLファイルを処理するシステムに、空白、つまり連続するタブ（＃x09）、スペース（＃x20）、キャリッジリターン（＃x0D）またはラインフィード（＃x0A）の文字のシーケンスを処理する方法を示すメカニズムを提供する。xml：idと同様に、この属性はXML仕様の一部として定義され、TEI名前空間よりもむしろXML名前空間に属する。この属性に関する完全な情報は、 XML仕様に関するセクション2.10 で提供されている。  ここでは、その使用がTEIスキームのユーザーにどのように影響を与えるかの概要を示す。

　@xml:space属性には、”preserve”と”default”の2つの値のみが許可されている。1番目は、テキストノード内の空白（すべてのキャリッジリターン、すべてのタブなど）が文書の処理時にそのまま維持されるべきであることを示す。2番目（属性が指定されていない場合に暗示される）は、空白が「適切に」処理されるべきであることを示す。適切とみなされるものは、XML勧告では指定されていない。

　これらのガイドラインは、要素のコンテンツモデルに応じて、空白を処理する2つの異なる方法のいずれかが特定のケースに適用されることを前提としている。介在する非空白文字を含まない他の要素のみを含むことができる要素の場合、空白は意味的な重要性を持たないと見なされるため、プロセッサによって破棄される必要がある。たとえば 、次のような choice 要素で、

<choice>
 <sic>1724</sic>
 <corr>1728</corr>
</choice>

　空白以外のテキストは、 choice 開始タグと sic タグの間、または sic と corr タグの間で許されないため、そこで見つかったあらゆる空白には意味がなく、プロセッサはこれらを完全に無視できる。

　同様に、 address 要素には要素のみを含むコンテンツモデルがある。したがって、入力文書に存在する空白は無視されるため、住所の行間に必要な句読点または空白はプロセッサによって提供されなければならない。

　この型のコンテンツモデルを持つ要素は、TEIでは比較的珍しいものである。それらのリストは、XSLスタイルシートのコマンド<xsl:strip-space> として使用するためにフォーマットされたTEIリリースファイルstripspace.xsl.modelで提供される

　ほとんどのTEI要素は、混合コンテンツと呼ばれるものを許可する。つまり、テキストと他の要素の両方を含めることができる。ここで、これらのガイドラインの前提は、空白が正規化されることである。つまり、すべてのスペース、キャリッジリターン、ラインフィード、タブ文字がスペースに変換され、連続するすべてのスペースが削除されて1つのスペースに置き換えられ、開始タグの直後または終了タグが削除される直前のスペースになる。結果は、この符号化、

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type=”linked”>Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

　「エドワード・ジョージ・ブルワー・リットン、ネブワースの男爵リットン」としてレンダリングされる。彼の名前の前のスペースが削除され、彼の2つの名 (forename) の間でスペースが含まれ、コンマが保持され、彼の名前の中の改行がすべて削除された。

　上記のデフォルトの処理が混合コンテンツ要素に適していない場合、必要な処理はTEIヘッダーのencodingDesc要素であるが、汎用のXML処理ツールはこれに注意しない場合がある。

　または、@xml:space属性にpreserveの値を指定して、処理中の文書のその要素内にあるすべてのスペース、タブ、キャリッジリターン、ラインフィード文字が重要であることを示すことができる。通常、その処理の結果、出力に空白文字が保持される。したがって、上記の例が<persName xml:space=”preserve”>で始まった場合、結果として生じるテキストは、5行にわたってレンダリング、そしてインデントされ、その後に空白行が続く可能性が非常に高いだろう。

　XML:space=”preserve”属性はめったにTEI文書で使用されていない。なぜなら、そのようなレイアウト機能は、lb または space といったネイティブのTEI要素を使用することで、またはセクション 1.3.1.1.3 レンディションインジケータ で説明されているレンディションの諸属性を使用することで、一般的に、リスクが少なく、より正確にキャプチャされるためである。

次の表に、便宜のために、他の潜在的に使用可能なグローバル属性を示す。この表は、関連する属性を提供する属性クラスの名前、属性を使用可能にすべき場合にスキーマに含める必要のあるモジュール、およびクラスが説明されているこれらのガイドラインのセクションを指定する。

　上記のように、所与のTEIモデルクラスのメンバーは、文書内の同じ場所にすべて表示できるというプロパティを共有する。可能な場所ならどこでも、TEI要素のコンテンツモデルは、特定の要素に関して直接表現されるのではなく、特定のモデルクラスに関して間接的に表現される。これにより、コンテンツモデルがよりシンプルで一貫したものになる。また、これによって、はるかに簡単に理解し変更できる。

　属性クラスと同様に、モデルクラスにはサブクラスまたはスーパークラスがある。要素がクラスから継承するのと同じように、文書の特定の場所（クラスを表示できる場所）に表示する機能を継承するため、サブクラスのすべてのメンバーは、スーパークラスを表示できる場所に表示する機能を継承する。したがって、ある程度、クラスシステムは、要素のTEIギャラクシー全体を整然とした階層構造に縮小する方法を提供する。しかし、これは全てのケースに当てはまるわけではない。

　実際、要素の特定のクラスの性質は2つの次元に沿って考慮することができる。前述のように、文書階層内でクラスメンバーが許可される場所のセットを定義する。また、何らかの種類のセマンティックグループ化を含意する。たとえば、段落内に表示できる要素の非常に大きなクラスは、他の多くのクラスで構成され、それらはすべて同じ構造プロパティを持つが、適用分野が異なる。ハイライトに関連するものもあれば、名前や場所などに関連するものもある。場合によっては、「クラスメンバーが許可される場所のセット」は非常に制約されている。たとえば、特定の1要素内、または要素の1つのクラス内にある場合がある。他の場合には、要素が非常に多くの場所、またはそのような場所の複数のセットに現れることが許可される場合がある。

　これらの要因は、モデルクラスの命名方法に反映される。モデルクラスにmodel.divPart または model.biblPartのような ”Part” を含む名前がある場合、主に構造的な場所の観点から定義される。たとえば、 div のコンテンツとして表示される要素（または要素のクラス） は、model.divPartクラスを構成し、biblのコンテンツとして表示されるものはmodel.divPartクラスを構成する。ただし、model.biblLike または model.nameLike のようにモデルクラスに”Like”を含む名前がある場合、そのれは、そのすべてのメンバーが共通のいくつかの追加のセマンティックプロパティを持っていることを含意する。これらの意味的に動機付けされたクラスは、多くの場合、構造的に動機付けされた大きなクラスを分割する便利な方法を提供する。たとえば、非常に一般的な構造クラス model.pPart.data （「段落の一部を形成するデータ要素」）には、4つの意味的に動機付けられたメンバークラス（ model.addressLike 、 model.dateLike 、 model.measureLike 、そして model.nameLike ）、これらの最後はそれ自体がいくつかのメンバーを持つスーパークラスである。

　ほとんどのクラスはteiインフラストラクチャモジュールによって定義されているが、要素宣言はモジュールによって含まれているため、他の特定のモジュールがスキーマに含まれていない限り、クラスをたくさん持たせることはできない。クラスは「トップダウン」で宣言されるのではなく、個々の要素のメンバーシップの宣言の結果としてメンバーを獲得する。したがって、アクティブなモジュールに応じて、同じクラスに異なるメンバーが含まれてもよい。したがって、特定の要素のコンテンツモデル（モデルクラスに関して表現される）は、アクティブなモジュールによって異なる場合がある。

　すべてのモジュールがロードされている場合でも、一部のクラスには単一のメンバーのみが含まれる。このようなクラスを宣言する理由の1つは、カスタマイズによって特定の場所、特にTEIが完全に精巧な提案を行っていない領域に新しいメンバー要素を簡単に追加できるようにするためである。たとえば、最初は空のTEIクラス model.rdgLike は、 TEI rdg要素のみが含まれるようにtextcritモジュールによって展開される。テキスト批評情報を構造化する別の方法を追加したいプロジェクトは、独自の要素を定義し、それをこのクラスに追加することで可能になるだろう。

　単一メンバークラスを宣言するもう1つの理由は、クラスメンバーがすべての文書で必要ではなく、非常に頻繁に必要な要素と同じ場所に表示されることにある。たとえば 、非Unicode文字またはグリフを表すために使用される 特殊な要素 g は、スキーマにgaijiモジュールが追加されるときに、model.gLikeクラスの唯一のメンバーとして提供される  このクラスへの参照は、ほとんどすべてのコンテンツモデルに含まれている。なぜなら、これを使用する場合は、テキストが利用可能な場所であればどこでも g が利用可能である必要があるためである。ただし、外字モジュールがロードされない限り、これらの参照は効果がない。

　スケールのもう一方の端では、teiモジュールによって事前に定義されたいくつかのクラスに、非常に多くのメンバーが続いている。たとえば、model.pPart.editは、すべてのクラスをグループ化して、p 要素または段落要素 内に表示できる簡単な編集修正および転写を行う。coreモジュールだけで、このクラスに50以上の要素が追加される。 namesdatesモジュールは、tagdocsモジュールがするように、さらに20を追加する。p 要素 はTEI文書の基本的なビルディングブロックの1つであるので、 各モジュールがそれに要素を追加する必要があることは驚くべきことではない。ここのクラスシステムは、結果の複雑さを制御する非常に便利な方法を提供する。通常、要素はこれらの非常に一般的なクラスに直接追加されるのではなく、中間的な意味的に動機付けされたクラスを介して追加される。

　単一のメンバーを持つ少数のクラスがあるように、TEIアーキテクチャーで一度だけ使用されるいくつかのクラスがある。これらのクラスはスーパークラスを持たず、そのためここで定義されたクラス階層に適合せず、内部で高度に構造化された要素を維持する便利な方法であるが、外部からは同じレベルの他のオブジェクトのように統一されたオブジェクトとして現れる。 [note]これらのガイドラインの以前の版では、このような要素は比喩的に結晶[crystals]として知られていた。[/note] そのようなクラスのメンバーは、1つの要素、または諸要素の1つのクラス内にのみ現れることができる。たとえば、model.addrPart クラスは、要素 address のためにコンテンツモデルを表現する目的でのみ使用される。これは、他の場所に出現する可能性のある、要素の他のクラス、および住所内にのみ出現できるいくつかの要素を参照する。

　ほとんどのTEI要素は、次のグループのいずれかに属するものとして非公式に分類してもよい。

分割

　高レベル、おそらく自己ネスト、テキストの主要な区分。これらの要素は、model.divLike または model.div1Likeといったクラスを生成し、典型的にはテキストの最大コンポーネントユニットを形成する。

チャンク

　段落やその他の段落レベルの要素などの要素。テキスト内またはテキストの分割内に直接表示できるが、（通常）他のチャンク内には表示できない。これらの要素は model.divPart 、直接または model.pLike などの他のクラス（段落のような要素）を使用して、 model.entryLike クラスを生成する

フレーズレベルの要素

　ハイライトされたフレーズ、書籍のタイトル、編集の修正など、チャンク内でのみ発生し、それらの間では発生しない（したがって、部門内に直接表示できない）要素。これらの要素は、クラス model.phrase を占める。 [note]このコンテキストでは、 フレーズは任意の文字列を意味し、個々の単語、単語の一部、および単語のグループに無差別に適用できることに注意する。言語的に動機付けされた句単位だけを指すのではない。これは、単語をより制限的な意味で適用することに慣れている読者にとって混乱を引き起こす可能性がある。[/note]

　TEIは、また、これら3つから派生したさらに2つのグループも識別する。

レベル間要素

　リスト、メモ、引用などの要素。チャンク間（ div の子として ）または チャンク 内に表示できる。これらの要素がクラスmodel.interを占める。このクラスは model.phrase  と model.divPart クラスのスーパーセットではなく、むしろチャンクのような要素とフレーズのような要素の明確なグループ化がなされたものであることに注意する。 ただし、クラス model.phrase 、 model.pLike 、や model.inter はすべてばらばらである。

コンポーネント

　テキストまたはテキストの部分内に直接現れることのできる要素。これは、上で定義したインターレベル要素とチャンクレベル要素の組み合わせである。これらの要素はクラス model.common を占め、クラス model.divPart 、 model.inter および（辞書モジュールがスキーマに含まれている場合） model.entryLike のスーパーセットとして定義されている。

　大まかに言えば、テキストの前文、本文、および後文はそれぞれ、オプションで部分部分にグループ化された一連のコンポーネントで構成される。

　上記のように、一部の要素はどのモデルクラスにも属しておらず、一部のモデルクラスは上記の非公式のグループ化のいずれにも容易に関連付けられていない。ただし、これらのガイドラインの現在の版で定義されている576要素の3分の2以上がこのように分類されており、これらの推奨事項の将来の版はこの分類スキームを拡張および開発する。

　すべてのモデルクラスの完全なアルファベット順のリストは、 付録A　モデルクラス に ある。

　この章で定義されているインフラストラクチャモジュールは、多くのマクロ 、または他の宣言の頻繁に発生する部分のためのショートカット名も宣言する。マクロは、TEIスキームで2つの方法で使用される。つまり、一つは、頻繁に遭遇するコンテンツモデル、またはコンテンツモデルの一部（ 1.4.1 標準コンテンツモデル ）を表す方法、もう一つは、また、属性データ型を表す（ 1.4.2 データ型仕様 ）方法である。

　可能な限り、TEIスキーマは頻繁に遭遇する次のコンテンツモデルのセットを使用して、異なる要素間の一貫性を実現させる。

• macro.paraContent （段落コンテンツ）は、段落および同様の要素のコンテンツを定義する。
• macro.limitedContent （段落コンテンツ）は、既存の素材の転写に使用されない散文要素のコンテンツを定義する。
• macro.phraseSeq （フレーズシーケンス）は、文字データとフレーズレベル要素のシーケンスを定義する。
• macro.phraseSeq.limited （フレーズシーケンスの制限）は、文字データと既存の文書の転写に通常使用されないフレーズレベルの要素のシーケンスを定義する。
• macro.specialPara （「特別な」段落コンテンツ）は、一連のコンポーネントレベルの要素を含むか、一連のフレーズレベルおよびレベル間要素を含む段落と同じ構造を持つ、メモやリストアイテムなどの要素のコンテンツモデルを定義する。
• macro.xtext （拡張テキスト）は、文字データと外字要素のシーケンスを定義する。

　TEIガイドラインの現在のバージョンには、580個くらいの異なる要素が含まれている。表 4 は、頻度の高い順に、最も一般的に使用される7つのコンテンツモデルを示している。

　TEIスキーマで属性が取りうる値は、ほとんどの場合、TEI データ型仕様を参照して定義される。そのような各仕様は、ほとんどの場合 W3Cスキーマデータ型 、リテラル値、または他のデータ型 から派生した他のプリミティブデータ型の観点から定義されている。この間接化により、TEIアプリケーションは、データ型定義またはそれへの参照をそれぞれ再定義することにより、グローバルに、または個々の場合に制約を設定できる。場合によっては、TEIデータ型には、既存のスキーマ言語では適用できない追加の使用制限が含まれるが、TEI準拠のプロセッサはそれらを検証しようとする必要がある（ 23.4 準拠の詳細な説明を参照）。

　次の要素は、TEIデータ型を定義するために使用される。

<dataSpec> （データ型仕様）はデータ型を文書化する。

　TEIで定義されたデータ型は、数量、確率、または時間表現の正規化された値を定義するデータ型、さまざまな種類の略記コードまたはキーを定義するデータ型、およびポインターまたはリンクを定義するデータ型にグループ化できる。

　次のデータ型は、さまざまな種類の正規化された値を保持するための属性に使用される。まず、量または確率の表現においては以下である。

teidata.certainty 確信度を示す属性値の程度を示す。
teidata.probability 出現度を示す属性値の範囲を定義する。
teidata.numeric 数値をとる属性値の範囲を定義する。
teidata.interval  間隔値を表すために使用される属性値を定義する。
teidata.count 非負整数値を採る属性値の範囲を定義する。

　teidata.probabilityデータ型を使用する属性の例には、 損傷[damage]の度合い または 確実性[certainty]の度合い に関する@degreeが含まれる。 teidata.numericの例には、 att.measurement のクラスのメンバーに関する@quantityまたは数値[numeric]にかんする@valueが含まれる。 teidata.countの例には、 セル[cell] と テーブル[table] の列が含まれる。

　次に、正規化された日付または時刻、期間、真理値、および言語識別子を保持することを目的とした属性に使用されるデータ型は以下である。

teidata.duration.w3c W3Cのデータ型を使い，時間幅を表現する当該属性値の範囲を定義する.
teidata.temporal.w3c 日付や時間などの時間表現をとる属性値の範囲を定義する．これは，W3Cの XML Schema Part 2: Datatypes Second Editionに従ったものになる．
teidata.truthValue 真偽値を示す属性値の範囲を定義する．
teidata.xTruthValue (extended truth value) 不明の場合もある真偽値をとる属性値の範囲を定義する．
teidata.language 自然言語を示す属性値の範囲を定義する．

　これらの各ケースで使用される値は、既存の国際標準で推奨されている値であることに注意する。期間、時刻、日付の場合は、XML Schema Part 2：Datatypes Second Edition でプロファイルされたISO 8601であり、真理値の場合はW3Cスキーマデータ型であり、言語の場合はBCP 47である。

　次のデータ型には、より特殊な用途がある。

teidata.namespace W3CのXML名前空間で定義されている名前空間を示す属性値の範囲を示す.
teidata.namespaceOrName 絶対ネームスペースURIまたは修飾されたXML名のいずれかを含む属性値を定義する。
teidata.outputMeasurement webページ上で表示する際の大きさを定義する値の範囲を定義する．
teidata.pattern 正規表現を属性値として定義する．
teidata.point デカルト空間でポイントを表すために使用されるデータ型を定義する。
teidata.pointer 他の資源へのポインタをとる属性値の範囲を定義する．
teidata.version TEIまたはUnicodeバージョン番号を指定するために使用できる属性値の範囲を定義する。
teidata.versionNumber バージョン番号に使用される属性値の範囲を定義する。
teidata.replacement 置換テンプレートを含む属性値を定義する。
teidata.xpath XPath式を含む属性値を定義する。

　断然最も多くのTEI属性は、コード化された値または何らかの名前である値を取る。これらの値は、次のようにそれぞれ異なる名前が付けられたさまざまな方法で制約または定義される。

teidata.word 一単語またはトークンをとる属性値の範囲を定義する． teidata.text 何らかの種類の識別文字列を、空白を含む可能性のあるユニコード文字の単一シーケンスとして表現するために使用される属性値の範囲を定義する。
teidata.name XML名前としてある属性値の範囲を定義する． teidata.enumerated 符号化されている記述にある，ひつとのXML名前を示す属性値の範囲を定義する．
teidata.sex 人間または動物の性を示す属性値の範囲を定義する． teidata.xmlName XML名を含む属性値を定義する。
teidata.prefix URIスキーム名として機能する可能性のある値の範囲を定義する。

　人[person]に関する@ageなどの属性の型であるteidata.wordは、あらゆる種類の単一のトークンまたは単語として表される識別子を提供するために使用される。TEIは、この目的に使用できる文字にいくつかの制約を課す。この種の属性値には、文字、数字、句読点、または記号として分類されるUnicode文字のみが表示されうる。特に、そのような値には空白文字を含めることができないことに注意する。有効な値には、「cholmondeley」、「été」、「1234」、「e_content」、または「xml:id」が含まれるが、「grand wazoo」は含まれない。この種の属性は、異なる型の要素を（相互参照により）関連付けるために使用されることがある。

　識別子が外部で定義されている場合、たとえばデータベースまたはファイルシステムの一部として、値に空白文字やその他の特殊文字を含めることができないことが問題になる場合がある。また、単一の値としてスペースを含む自然言語の単語の短いシーケンスを提供する方が簡単な場合もある。これらの理由から、空白やその他のUnicode文字を許可するデータ型teidata.textも提供している。有効な値には、「cholmondeley」、「été」、「1234」、「e-content」、「xml:id」、および「grand wazoo」が含まれる。XMLはその中の空白文字を正規化しないため、このデータ型は注意して使用する必要がある。たとえば、値 n = “a b” （2つのスペース）と n = “a b” （3つのスペース）は区別される。この場合には、それぞれがこれから正規化する空白で分離され得る複数の値を許可ししている属性のものとは区別されるべきである（さらに 22.5.3.1 データ型 を参照）。

　teidata.name型の属性は、teidata.word型のものと同様であるが、XML 1.0仕様、または後継のバージョンによって定義されるように、有効なXML識別子でなければならないという追加の制約を持つ。したがって、数字または句読点文字で始まっていない場合がある。有効な識別子には、「cholmondeley」、「été」、「e_content」、または「xml:id」が含まれるが、「grand wazoo」または「1234」は含まれない。この種の属性は通常、XML要素または属性名を表すために使用される。

　teidata.xmlName型の属性は、teidata.name型の属性に似ているが、コロン文字（:、U+003A）を含んではならないという追加の制約がある。したがって、この種類の属性は、名前空間プレフィックスを持たないXML要素または属性名を表すために使用される。

　prefixDefの@identといった、teidata.prefix型の属性は、有効なURIプレフィックスを形成する文字列に制限されている。[note]技術的にこの仕様はAからZまでの26の大文字の英字を許可する。ただし、「正規の形式は小文字であり、スキームを指定する文書では小文字を使用しなければならない」ため、TEIのeidata.prefixデータ型では大文字は使用できない。[/note] 妥当な値の例は、「http」、「https」、「tn3270」、「xmlrpc.beep」、そして「view-source」である。

　shift 上のnewやatt.editLikeによって供給される @evidence といった、 teidata.enumerated型の属性は、上記のteidata.wordと同じ定義を持ち、追加された制約によって様々にありうる特定のリストから取得されるという制約が追加されている。いずれの場合も、属性の定義を含む要素またはクラスの仕様には、意図されたように重要な散文での記述とともに、可能な値のリストも含まれる。このリストは、開いている（この場合、リストは勧告である）か、閉じている（この場合、有効な値の範囲を決定する）ことができる。後者の場合、データ型はteidata.enumeratedではなく、可能な値の明示的なリストになる。

　もちろん、属性は、たとえば、ポインタ値のリストや単語のリストなど、特定の型の複数の値を取ることができる。TEIスキームでは、この情報は 、個別の「データ型」としてではなく、問題の属性を文書化するために使用される データ型 要素の プロパティと見なされ、@minOccursまたは@maxOccurs属性によって提供される。詳しくは、22.5.3.1　データ型を見よ。

　少数のケースでは、属性は1つのデータ型または別のデータ型のいずれかの値を取る場合がある。これらのケースは、個別のデータ型と見なされる。

teidata.probCert は、数値の確率またはコード化された確実性値として表現できる属性値の範囲を定義する。
teidata.unboundedInt は、負でない整数または文字列「unbounded」のいずれかである属性値を定義する。
teidata.nullOrName は、null文字列またはXML名を含む属性値を定義する。

　この章で定義するteiモジュールは、あらゆるTEIスキーマの必須コンポーネントである。すべてのデータ型の宣言と、TEIスキームの他のモジュールで使用される属性クラス、モデルクラス、およびマクロの初期宣言を提供する。そのコンポーネントをアルファベット順に以下にリストする。

モジュール tei: 全TEIモジュールで使用可能なデータ型，クラス，マクロ

• 定義済みクラス ：att.ascribed att.ascribed.directed att.breaking att.cReferencing att.canonical att.citing att.damaged att.datable att.datable.w3c att.datcat att.declarable att.declaring att.dimensions att.divLike att.docStatus att.duration.iso att.duration.w3c att.editLike att.edition att.formula att.fragmentable att.global att.global.rendition att.global.responsibility att.global.source att.handFeatures att.internetMedia att.interpLike att.measurement att.media att.naming att.notated att.partials att.personal att.placement att.pointing att.pointing.group att.ranging att.resourced att.scoping att.segLike att.sortable att.spanning att.styleDef att.timed att.transcriptional att.translatable att.typed att.written model.addrPart model.addressLike model.applicationLike model.availabilityPart model.biblLike model.biblPart model.castItemPart model.catDescPart model.certLike model.choicePart model.common model.correspActionPart model.correspContextPart model.correspDescPart model.dateLike model.descLike model.dimLike model.div1Like model.div2Like model.div3Like model.div4Like model.div5Like model.div6Like model.div7Like model.divBottom model.divBottomPart model.divGenLike model.divLike model.divPart model.divTop model.divTopPart model.divWrapper model.editorialDeclPart model.egLike model.emphLike model.encodingDescPart model.entryPart model.entryPart.top model.eventLike model.featureVal model.featureVal.complex model.featureVal.single model.frontPart model.frontPart.drama model.gLike model.global model.global.edit model.global.meta model.glossLike model.graphicLike model.headLike model.hiLike model.highlighted model.imprintPart model.inter model.lLike model.lPart model.labelLike model.limitedPhrase model.linePart model.listLike model.measureLike model.milestoneLike model.msItemPart model.msQuoteLike model.nameLike model.nameLike.agent model.noteLike model.objectLike model.oddDecl model.oddRef model.offsetLike model.orgPart model.orgStateLike model.pLike model.pLike.front model.pPart.data model.pPart.edit model.pPart.editorial model.pPart.msdesc model.pPart.transcriptional model.persStateLike model.personLike model.personPart model.phrase model.phrase.xml model.placeLike model.placeNamePart model.placeStateLike model.profileDescPart model.ptrLike model.publicationStmtPart.agency model.publicationStmtPart.detail model.qLike model.quoteLike model.resourceLike model.respLike model.segLike model.settingPart model.sourceDescPart model.specDescLike model.stageLike model.teiHeaderPart model.textDescPart model.titlepagePart
• 定義済みマクロ: 
  macro.limitedContent macro.paraContent macro.phraseSeq macro.phraseSeq.limited macro.specialPara macro.xtext teidata.certainty teidata.count teidata.duration.iso teidata.duration.w3c teidata.enumerated teidata.interval teidata.language teidata.name teidata.namespace teidata.namespaceOrName teidata.nullOrName teidata.numeric teidata.outputMeasurement teidata.pattern teidata.point teidata.pointer teidata.prefix teidata.probCert teidata.probability teidata.replacement teidata.sex teidata.temporal.iso teidata.temporal.w3c teidata.text teidata.truthValue teidata.unboundedInt teidata.version teidata.versionNumber teidata.word teidata.xTruthValue teidata.xmlName teidata.xpath

　いくつかのクラス宣言は他のクラス宣言を参照するため、インフラストラクチャモジュール内で宣言が行われる順序は重要である。宣言の順序に関するその他の制約は、TEIスキームのモジュール性がさまざまなスキーマ言語で実装される方法に由来する。このTEIモジュールを実装するXML DTDフラグメントは、 パラメーターエンティティ[parameter entities]とマーク付きセクション[marked sections]を広範囲に使用して、一種の条件付き構築を実現する。 RELAX NGスキーマフラグメントも同様に、null（ ‘notAllowed’）値を持ついくつかのパターンを事前に宣言する。これらの問題については、第 23.5 章ODDシステムの実装 でさらに説明する。

　上記の 1.4.2 データ型仕様で 言及されている各データ型には、 これらのガイドライン全体で使用される純粋なODD構文ではなく、RELAX NG構文を使用する古いデータ型マクロも存在する。これらの古いマクロにはプレフィックス[prefix] teidata. ではなくむしろプレフィックス[prefix] data. が付いている。これらは後方互換性のために保持されているが、将来のリリースで削除される予定である。古いスタイルのデータ型、たとえばdata.xxxxを参照するTEIカスタマイズは、その時まで機能し続ける必要がある。ただし、そのような参照をできるだけ早く新しいフォームteidata.xxxxに置き換えることをお勧めする。