• TrackBackの文字コード - http://kitaj.no-ip.com/tdiary/20030425.html#p01

文字コード判別は3のcharset要素（＋ヘッダのcharset）だけ対応しておけばいいと思いますよ。1、2はTrackBackの（今後の）仕様とバッティングしないように、わざと一般的ではない表現を使っているだけなんで。

今のところcharset要素利用者が増えつつあるみたいですし、それが本家仕様に取り込まれる可能性を高めるためにも、中途半端な1、2は非対応にしておいた方がいい気がします。

ところでやっぱり、既存のいわゆる日記システム系にTrackBack送信処理をきれいに（使いやすく）取り込むのは結構難しいですよね……。HNSにも受信＆表示だけならば組み込めるんだけど。

とか考え始めると、TrackBack的な機能を持つ新しい仕様を考えることにまだ未練が残る。

個人的には、tDiaryにTrackBack対応してもらいたいと思いつつも、TrackBack的な機能を利用するためのもっと良くできた新しい技術を作ってもらいたいとも思っていたりもした。自分で作ろうかとも思ったけれども、こういうのはある程度のユーザーベースがないと面白くないし。

TrackBackの仕様のいまいちだと思われる部分は以下。これを解消しつつTrackBackと同等以上の機能を持てればいい。

1. 記事に対応するメタ情報（RDF）の表現が美しくない
2. 世の中のURL表現というものにはかなり揺らぎがある（大文字小文字、インデックスファイルの省略、QueryStringやPATH_INFOなどの引数違い）のに、それを意識せずにURLをキー扱いしている
   1. 1HTMLファイル中に複数の記事（RDF）が混在する状態で、その中の1記事のRDFを抜き出すためには、記事URL（アンカーリンク）をキーで検索するしかない。けれども、URLはキーとしては信頼できない。URLは、「URL→ドキュメント」方向では1：1（これも動的システムでは怪しいけど）だが、「ドキュメント→URL」では1：nなのに。
   2. URLをキーとして使うのではなく、コンテンツ管理システムID（こちらはトップページへのURLをベースにしてもいいかもしれない）＋記事ID（これはURLの一部などから、揺らぎがない要素を抜き出して使うなどで対応）をキーとして利用し、それに対応するURLをlink要素で表現するとか。
3. TrackBackにはいろいろな機能があるが、それぞれの仕様に統一感がない（これはまあ好みの問題だけど）
   1. XML指向なのかREST指向なのか
4. RSSとの連携が中途半端
   1. RSSのitemが持つTrackBack Ping URLと、HTML中に埋め込まれたRDFのTrackBack Ping URLみたいに、連携せずに重複している要素が気持ち悪い。
   2. RDFから記事IDを抜き出して（あるいはURLから記事IDを抜き出すための仕組みを用意して）、RSS取得インターフェースにそのitemのメタ情報を問い合わせて、RSS経由で正規化されたTrackBack Ping URLを受け取ったりすると仕様的にはきれいなんだけど
      1. HTTPアクセス回数が増えるデメリットと1回のHTTPアクセスで受け取るデータ量が減る（解析コストも下がる）メリットのバーターか

なんか書き始めると止まらない＆細かい仕様を考え始めちゃうな。ここ最近はそんなことをやっている時間がないので、このあたりで思考停止。