久しぶりに批判を行ってみます。最近RDFやOWL関連の文書を読みふけっていたせいか語彙がそっち系に偏ってしまっていますが悪しからず。
従来、xmlは意味的な内容と表現を分離して、内容だけを取り出すと言われていたが、実際に取り扱ってみるとよくわかることだが、表現を完全に分離してしまうと、内容だけからは表現を再現することができない場合が多い。更新日記のような簡単な構造のものでさえそうである。
例えば新聞のチラシから表現に関する情報を全て削除し、意味とその構造のみをXMLとしてマークアップしたなら、そこから表現を再現することは難しいかもしれません。例えば、チラシにおける各種の見出しは、見出しというクラスに属しているものの、極めて多種多様な「サブクラス」にも同時に属しており、デザイナはそのサブクラスに基づいて（殆ど無意識に）スタイルを決めます。従って、「見出し」という意味を与えただけでは全く足りないのです。難しいと書いたのは、そのサブクラスを認識し、語彙として定義してやる過程のことであります。
さて、「更新日記」ではどうでしょうか。チラシ並に押し付けがましくアピールすべき要素が、「更新日記」に存在するでしょうか。否。「更新日記」の読者はチラシのような「プレゼンテーション」を望んでいません。やりたいならやっても良いでしょうが、所謂フォント弄り系になるのがオチでしょう。
何れにしろ、内容だけからは表現を再現することができない
というのは良く分からない話です。「内容」を「各要素の意味と文書構造」に置き換えて考えてみたとしても、詳細なクラスを定義してやれば表現を再現することは恐らく可能です。出来なかったとすれば、その表現に問題があると言えましょう。一切の理由が存在しないまま気まぐれで設定された表現というのは読書の邪魔ですから。もしくは、その表現を定義する言語が非力なだけかもしれません。例えば一文字ずつフォントタグでマークアップして「レインボーカラー」を実現していたとして、そのマークアップを排除した場合、それを再現することは難しいと言えます。まあ難しいだけで十分可能ですけれども、確かに標準規格だけでは無理かもしれません。
手短に纏めますと、内容だけからは表現を再現することができない
というのは：
この何れかが原因です。
Documentation for NITFを調べてみた。バージョンは3.1になっている。xmlとhtmlのサンプルを比較してみるとよくわかる。表現に関わる部分はHTMLに近い。リストやパラグラフはそのままだが、テーブルにはメタデータを記述するためのタグがある。イメージはmediaというタグで属性を細かく指定することができる。結論、XMLにも表示用タグは必要。メタデータ用タグ(メタデータ) + 表示用タグ(コンテンツ) = XML である。表示用タグはメタタグで包まれる関係になる。意味・内容はXMLで、表示はXSLでという図式は思い込みの幻想だった。コンテンツと表現の分離はどう考えても原理的に無理があるということ。XML + XSL = HTML + meta data のほうが実際的な表現かもしれない。
イメージ（画像）におけるwidthやheightといった属性は、本質的に論理属性です。高さや幅が存在しなかったら画像にはなりません。要素の性質を叙述したものが論理属性です。画像という概念（クラス）には、幅と高さという性質（プロパティ）が必ず付属しますが、見出しという概念には幅や高さといった性質がありません。そこを勘違いされてコンテンツと表現の分離はどう考えても原理的に無理がある
という結論にもってゆくのは早過ぎであると思います。私はむしろ、原理的には可能だが、現状、完全な実現は難しい、と考えています。
因みにそのxmlは、かなりのレベルで分離が実現されているようにしか見えません。
全然関係ありませんが、RDF関連の仕様書を読み終えて、このサイトのサイト構造はかなり腐っていることを認識しました。そのうち大幅に修正します（各文書のURLは変わりません）。
indexは索引という意味で、その文書内に登場する語句を「あいうえお順」に並べて参照先を示すようなものを言います。例えばHTML4.01仕様書の概念索引が良い例です。
MozillaやOpera等のステキなブラウザの日本語版のナビゲーションバーで「索引」をクリックしたらホームページ（トップページ）に移動してしまった……という事態が起こることも予想されますので、意地悪をするつもりがなければ改善しておいた方が良いと思います。
文書構造に基づかない「表題」について。
tableのcaptionのような表題を意味するものとして、既に使われているtitle属性を汎用的なtitle要素として使えるようにすれば良いというような意見が[XHTML2] Suggestion: generalize CAPTION element (英語)の一連の投稿の中にありました。
人間が読むテキストは属性にすべきではないという見解もありましたが、なるほどそう考えると属性にするか内容にするか悩む必要がなくなって良いかもしれません。
サイトマップを、サイト構造定義ファイルとして再定義してみました（仮）。とはいっても殆ど何も変わっていません。今までと同じようなXHTML文書です。しかしそれを実際のサイト構造に反映させる為には「自分だけが構造の意味を理解できる」ゆえに書ける「場当たり的なスクリプト」を書かざるを得ませんでした。
しかしそれでは駄目なのです。何故なら、将来的にスクリプトをメンテナンスするのが困難になるからです。
サイト構造定義ファイルとしてのサイトマップは純粋なメタデータですから、当然RDF/XMLで再定義できる筈です。また、このサイトの運営目的はリンクを見極めることですので、計算機に都合の良いリソースとリソースの関係の明示方法は調べておかねばなりません。
そういうわけで、RDF/XMLの勉強を始めました。え? XLink? ……今の編集メンバが全員首になってBehavior Attributesが削除されたら、その時にでも見てみます。すみません。ちょっと、脱線してしまいました。
私の場合、RDF (英語)を、predicate（述語） object（目的語） subject（主語）のtripleとやらで考えていると頭が混乱してくるのですが、一般的なオブジェクトモデルで考えて、それぞれ、property、value、objectに脳内変換したら理解が進むようになりました（現在は脳内変換していません）。
まずは基本ということで、rdf:Descriptionを主語にした基本フォームで書いてみました。
語彙が貧弱なのでまだ殆ど実用性がありません。
過去の記事を読み返してみたら、rss:channel要素のrdf:about属性という記事の「追記」が欠けてしまっていることに気づきました。確かSjoerd Visscherさん (英語)とのメールのやり取りを書いたのだと思います。
確かここで私はどこぞのリソースの参照を促したのですが、良く覚えていません（再セットアップの際メールを紛失）。たしかchannelもfeedも比喩的表現であって、元は同じような意味であったというような文章ですが、とりあえずこの後返信が途絶えたことは確かです。私もなんだか自信がなくなってきたのでそれ以上追求するのは止めました。
改めてchannel要素をRDF的に見てみます。
channel要素には、そのプロパティとしての子要素（propertyElt）たち（link要素、title要素等）が存在します：
<channel rdf:about="http://foo.com/bar">
<title>baz</title>
<link>http://foo.com/bar</link>
</channel>http://foo.com/bar という「リソース」は、linkという性質を持っていることになり、その値は、http://foo.com/bar という「文字列」です。なんだか訳がわかりませんが、link要素の定義を見てみます：
The URL to which an HTML rendering of the channel title will link, commonly the parent site's home or news page.
なんだかアレな定義ですが訳しますと、link要素は、channelのtitleのHTML整形結果がリンクするURLで、通常親サイトのホームかニュースページになるのだそうです。整形結果に依存した定義でちょっぴり虫唾が走りますが、この例の場合、RDF的な意味は（意訳すれば）大体次のようになります：
馬鹿馬鹿しくて力が抜けましたが、これで明確になりました。rss:channel要素のrdf:about属性には、そのRSSファイル自身のURIを記述しないと矛盾が発生します。http://foo.com/bar が要約対象のウェブサイトであったならば、title要素なんてありません。大目に見てウェブサイトをあるウェブページ（HTML文書）と見なしたとしても、整形されたtitle（title要素）はリンクを形成しません。linkという語彙をもうちょっとマシなもの、例えば、「リンクしているリソースのURL」に訂正しても駄目です。
自分自身にリンクしていることを叙述してどうするのでしょうか。
海外のRDFに明るそうな人物のRSS1.0 feedを調べてみました。
RDF/XML Syntax Specification (Revised) (英語)の著者のサイトのRSS 1.0 feedです。さてchannel要素のrdf:about属性は……。
やはりfeed自身のURIが記述されています。RDF/XML Syntax Specification (Revised) (英語)をこれからも安心して読むことが出来ます。
サイト全体のより良い見栄えは、CSSで簡単に追求できます。また、文書のより良い構造は、XSLTで簡単に追求できます。
このような欲求があったとき、即座に対応できる。私はCSSやXSLTのこの特長に惹かました。同様にして、より良い「サイト構造」を簡単に追求できる環境を整えたいと思ったわけです。
XSLT でナビリンクをラクチンにしたい系（ねこめしにっき）を読んでいて、ナビゲーション、もとい、文書と文書とのサイト内の関係をどこまで計算機任せにするかについて色々思い浮かびました。
今のトコはとりあえず、各日記ぺーじの元 XML には自分自身のファイル名が書き込んであって、ファイル名の羅列を記した別ファイル (XML) の中から、自分の前後に当たるページがどれなのか探るという、単純でカンターンなもの。
このように謙遜されていますが、このファイル名の羅列を記した別ファイルというものを見て、猛烈にやる気が沸き起こってきました。このような「サイトマップ」を情報源にして、link要素等々のサイト構造や文書間の関係性を全て解決できればすばらしいと思ったのです。サイトマップ自体が公開文書として有用なわけですし、これだけは自分で書いていましたから。蛇足ですが、<span class="tuiki">って何でしょう。既に突っ込まれ済みとのことで。私も何か理由があるのだろうということは分かっていたというかむしろ確信していたのですが、どうしても突っ込まずにいられなかったというか、何と言うか悲しい性です。
私は、変換元となる文書（ソースファイル）にHTMLでいうところの「link要素」を自分で記述したりその場限りのスクリプトを書いて生成していました。このlink要素自体は今後も省略させる予定はありません。何故ならそれは意味を暗示すらしていない状態であり、その文書自身から関係性に関する情報を取り出すことが出来なくなってしまうからです。しかし各文書に自分でlink要素を記述する今の方法では、サイト構造の変化や文書間の関係性の変化が起こった際、速やかに対応できないことに気づきました。
ところで、私はサイトマップをXHTML形式で手書きしていました。サイトマップというのは、サイト構造を定義するファイルであるとも言えます。これは計算機に任せるわけにもいきません。必ず自分で考えて作る必要があるのです。ディレクトリ構造から自動的に作成する方法もありますが、「変化する可能性のあるサイト構造」と「変化してはならないURI」が結びついてしまっているので、私は「ディレクトリ分け」を好みません。尤も、しっかりした製作者ならば「変化する可能性」なんて最初から無いわけですが。
そこで考えたのが以下の方法です：
今のところ全文書の数はごみ箱行きのものを除くと130くらいなので、サイトに一つ文書を追加する程度の変化でさえ、5秒くらいかかってしまいます。サイトマップをジャンル別に小分けにすると良いのかもしれません。