サイト全体のより良い見栄えは、CSSで簡単に追求できます。また、文書のより良い構造は、XSLTで簡単に追求できます。
このような欲求があったとき、即座に対応できる。私はCSSやXSLTのこの特長に惹かました。同様にして、より良い「サイト構造」を簡単に追求できる環境を整えたいと思ったわけです。
XSLT でナビリンクをラクチンにしたい系（ねこめしにっき）を読んでいて、ナビゲーション、もとい、文書と文書とのサイト内の関係をどこまで計算機任せにするかについて色々思い浮かびました。
今のトコはとりあえず、各日記ぺーじの元 XML には自分自身のファイル名が書き込んであって、ファイル名の羅列を記した別ファイル (XML) の中から、自分の前後に当たるページがどれなのか探るという、単純でカンターンなもの。
このように謙遜されていますが、このファイル名の羅列を記した別ファイルというものを見て、猛烈にやる気が沸き起こってきました。このような「サイトマップ」を情報源にして、link要素等々のサイト構造や文書間の関係性を全て解決できればすばらしいと思ったのです。サイトマップ自体が公開文書として有用なわけですし、これだけは自分で書いていましたから。蛇足ですが、<span class="tuiki">って何でしょう。既に突っ込まれ済みとのことで。私も何か理由があるのだろうということは分かっていたというかむしろ確信していたのですが、どうしても突っ込まずにいられなかったというか、何と言うか悲しい性です。
私は、変換元となる文書（ソースファイル）にHTMLでいうところの「link要素」を自分で記述したりその場限りのスクリプトを書いて生成していました。このlink要素自体は今後も省略させる予定はありません。何故ならそれは意味を暗示すらしていない状態であり、その文書自身から関係性に関する情報を取り出すことが出来なくなってしまうからです。しかし各文書に自分でlink要素を記述する今の方法では、サイト構造の変化や文書間の関係性の変化が起こった際、速やかに対応できないことに気づきました。
ところで、私はサイトマップをXHTML形式で手書きしていました。サイトマップというのは、サイト構造を定義するファイルであるとも言えます。これは計算機に任せるわけにもいきません。必ず自分で考えて作る必要があるのです。ディレクトリ構造から自動的に作成する方法もありますが、「変化する可能性のあるサイト構造」と「変化してはならないURI」が結びついてしまっているので、私は「ディレクトリ分け」を好みません。尤も、しっかりした製作者ならば「変化する可能性」なんて最初から無いわけですが。
そこで考えたのが以下の方法です：
今のところ全文書の数はごみ箱行きのものを除くと130くらいなので、サイトに一つ文書を追加する程度の変化でさえ、5秒くらいかかってしまいます。サイトマップをジャンル別に小分けにすると良いのかもしれません。