本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

対象：TEI/XML を触り始めて、ODD・XSLT・Processing Model の関係を整理したい方。XSLT や ODD を一から書ける必要はありません。

TEI/XML（Text Encoding Initiative。人文学のテキストを構造化するための国際標準）を使い始めると、ODD・XSLT・Processing Model という3つの言葉に出会います。どれもファイルやスクリプトの形で登場するため、「結局どれを書けばよいのか」「どれかを選ぶものなのか」が分かりにくいところです。

この3つは二者択一の関係ではなく、それぞれ別の仕事を担当します。本記事では、最小限の例を使って3つの役割と関係を整理します。

3つの役割を一枚で

先に結論を表にします。

名前何をするもの主な成果物
XSLTXML を別の形式に変換するHTML / PDF / 別の XML など
ODDTEI のどの要素・属性を使うかを定義するスキーマ＋仕様書
Processing ModelODD の中に「各要素の描画方法」を宣言する（processor 経由で）HTML など

混同を避けるうえで大事なのは、XSLT と ODD は別レイヤーで、Processing Model は ODD の一部だという点です。関係を整理すると入れ子になります。

ODD ファイル（.odd = 中身は TEI XML）
├── スキーマ定義部 …… どの要素・属性が正しいか
└── Processing Model 部 …… 各要素をどう描画するか（<model> 要素）

XSLT ファイル（.xsl）…… ODD とは独立。変換処理を書く

以下、それぞれを順に見ていきます。例として、次のような簡単な TEI/XML があるとします。

<TEI xmlns="http://www.tei-c.org/ns/1.0">
  <teiHeader><!-- 書誌情報など --></teiHeader>
  <text>
    <body>
      <p><persName type="person">夏目漱石</persName>は
         <placeName>松山</placeName>に滞在した。</p>
    </body>
  </text>
</TEI>

XSLT — TEI を別の形式に変換する

XSLT（XSL Transformations）は、XML を別の形式に変換するための W3C 標準言語です。TEI/XML はそのままではブラウザで読みやすい形にならないため、HTML へ変換する用途でよく使われます。

たとえば TEI の <persName>（人名）を HTML の <span> に変換するなら、次のようなテンプレートを書きます。

<xsl:template match="tei:persName">
  <span class="person">
    <xsl:apply-templates/>
  </span>
</xsl:template>

要素ごとに「これが来たら、こう出力する」というルールを並べていく、というのが XSLT の書き方です。XSLT には 1.0 / 2.0 / 3.0 のバージョンがあり、1.0 は xsltproc、2.0 以降は Saxon などのプロセッサで実行します。

XSLT は変換ルールを自分で書く方式です。自由度が高い反面、出力フォーマットの数だけ（HTML 用、PDF 用…）スタイルシートを保守することになります。

ODD — 使う要素と属性を定義する

ODD は "One Document Does it all" の略で、TEI の「カスタマイズ」を記述するためのものです。中身は TEI XML で書きます。

TEI には数百の要素が定義されていますが、ひとつのプロジェクトでそのすべてを使うことはまずありません。「この資料では <persName> と <placeName> と <date> だけ使う」「<persName> の @type には person だけ許す」といった取り決めを書く場所が ODD です。

ODD からは次の2つを生成できます。

  • スキーマ（RELAX NG など）。XML がこの取り決めに沿っているかを機械的に検証できる
  • 仕様書。どの要素をどう使うか、というプロジェクトのルール文書

たとえば「<persName> の @type は person か place のどちらかに限る」という制約は、ODD では次のように書きます。

<elementSpec ident="persName" mode="change">
  <attList>
    <attDef ident="type" mode="change">
      <valList type="closed">
        <valItem ident="person"/>
        <valItem ident="place"/>
      </valList>
    </attDef>
  </attList>
</elementSpec>

こう書いておくと、<persName type="prson"> のようなタイポがスキーマ検証で弾けます。散文のマニュアルに「type は person か place で」と書くのと違い、機械が強制してくれるのが ODD の値打ちです。

ODD の処理には、ブラウザで使える ODD エディタの Roma や、TEI Stylesheets のコマンド群を使います。

ここで注意したいのは、ODD は HTML を作らないという点です。ODD が決めるのは「何が正しい XML か」であって、表示用の出力ではありません。表示は XSLT か、次に説明する Processing Model の担当です。

Processing Model — ODD の中に描画方法を書く

Processing Model（処理モデル）は、ODD の中に「各要素を出力時にどう描画するか」を宣言する仕組みです。別ファイルでも別技術でもなく、ODD の <elementSpec> の中に <model> 要素を足したものです。

ODD のスキーマ定義部が「何が正しい XML か」を決めるのに対し、Processing Model 部は「その要素をどう見せるか」を決めます。

<elementSpec ident="persName" mode="change">
  <model behaviour="inline">
    <outputRendition>font-weight: bold;</outputRendition>
  </model>
</elementSpec>

behaviour の値は、あらかじめ定められた語彙から選びます。標準では次の26種類が用意されています。

behaviour役割
alternate複数の候補を切り替えて表示する（校訂の sic/corr など）
anchor本文中の位置を指し示すアンカー点
block段落のように改行を伴うブロック
body文書の本文領域
break改ページ・改行などの区切り
cell表のセル
cit引用（引用文と出典のまとまり）
document文書全体
figure図
glyph字形・特殊文字
graphic画像
heading見出し
index索引項目
inline行内に流し込む要素
linkリンク
listリスト
listItemリストの項目
metadataメタデータ（通常は表に出さない書誌情報など）
note注
omit出力しない（省略する）
paragraph段落
row表の行
section章・節などのまとまり
table表
text文字列そのもの
titleタイトル

behaviour のデータ型自体は開かれていて、processor が独自の behaviour を追加することもできますが、標準として推奨されるのはこの26種類です。predicate 属性を使えば「@type が person のときだけこの描画」のように条件分岐もできます。

ここに書いた描画指示は、Processing Model に対応した processor（代表例は TEI Publisher）が読み取り、HTML などを生成します。XSLT を一から書く代わりに、ODD に宣言だけ書く、というのが Processing Model の発想です。

XSLT と Processing Model の使い分け

XSLT と Processing Model はどちらも「TEI を HTML などに変換する」ための手段なので、ここが一番混同しやすいところです。おおまかな目安は次の通りです。

XSLT を直接書くProcessing Model を使う
書き方変換ルールを手続き的に記述ODD に宣言的に記述
自由度高い（どんな出力でも書ける）behaviour の語彙の範囲内
向く場面凝ったレイアウト、特殊な版面の再現一般的な構造の文書、複数フォーマット出力
学習コストXSLT の習得が必要ODD と behaviour 語彙の理解

Processing Model は決まった語彙で宣言するぶん、複数の出力フォーマット（HTML・PDF・EPUB など）を一度の記述でまかなえます。一方、behaviour の語彙は文書の構造的な意味（これは段落、これは見出し）を表すものなので、見た目を細かく作り込む変換には向きません。そうした場合は XSLT を手で書くほうが素直です。調査した限りでは、版面を忠実に再現するような用途では XSLT が選ばれることが多いようです。

典型的なワークフローは次のようになります。

  1. ODD を書いて、プロジェクトで使う要素・属性を決める（あわせてスキーマを生成する）
  2. その ODD でデータ（TEI/XML）を検証しながら符号化する
  3. 表示用の変換は、一般的な構造の文書なら Processing Model、凝った見た目が必要なら XSLT で行う

よくある誤解

  • 「ODD は XSLT の代わりになる」… なりません。ODD はスキーマと仕様書のためのもので、HTML を作るのは XSLT か Processing Model です。
  • 「Processing Model は ODD とは別物」… 別物ではなく、ODD の一部（<elementSpec> の中の <model> 要素）です。
  • 「TEI を使うなら ODD が必須」… 必須ではありません。全要素入りのスキーマ（TEI All）でも検証はできます。ODD はプロジェクト固有のルールを明示・強制したいときに効きます。

3つの関係をもう一度まとめると、ODD が「使ってよい部品の定義」、Processing Model が「ODD の中に書く描画の宣言」、XSLT が「ODD とは独立した変換処理」です。役割の違うレイヤーだと捉えると、混同しにくくなります。

動画版（生成AIによる自動生成）: 本記事の内容を、2キャラクターの掛け合い形式の解説動画にまとめています。VOICEVOX による音声合成で構成しており、自動生成のため内容に誤りが含まれる可能性があります。正確な情報は記事本文をご参照ください。

参考