「ウェブなんて見えればいい」という意見は、自分が使っている範囲で何も問題がなければごもっともな気もするのだが、実際見えればいいだけの観点で作られたウェブのデータで何かしなければならない事態に追い込まれると「見えればいいなんて意見は、単に意識が低いだけなんと違うんか？」と思ってしまう。情報を構成するすべてのデータは、効率を上げるためのオイシイ材料のような気がしている今日このごろなのだ。
XSLTに移行する際に実現したかったのが、ページ内のナビゲーションの自動作成。以前はコピペでページ上部にidとタイトルを追加していたわけだが、これを付け加えるのを忘れることが多発。非常に面倒くさいと思っていたわけだ。
今回、毎日の日記に埋め込まれている情報を元にページ内ナビゲーションを作り上げることにしたのだが、この際にもうひとつシカケを企てた。それはidすらも自動生成してしまおうというものだ。XMLでは記事の並び順でさえ再利用が可能な情報として扱えるからだ。
つーわけでXSLTファイルの設計を行ったわけだが、キーになるのが日付。これは実際に「2003-02-02」といったかたちで「day」という独自要素でマークアップしている目に見える情報だ。おいらが普段idとして利用しているのは「d2003-02-02c1」といった形式。「d」は「c」それぞれ日付と記事（Contents）を示す定型句で、「c」の後の数字「1」はその日の中での記事の順番を示している。これらの情報を加える必要があるわけだ。
定型句に関してはXSLTの「text」要素を使って直接書き加えればいい。問題は記事の順番を示す数字情報の用意だ。これはXSTLのnumber要素を使い、各記事をマークアップしているsection要素の順番を拾うことにした。おいらの場合、各記事を次のようなツリーでマークアップしている。
マークアップのツリーそのものをどうマークアップするのか、よく考えている余裕がなかったので、単純にテキストを引っぱってくるだけになって申し訳ない。とりあえず、キーになるのはsection要素のclass属性で指定されている値だ。そこでまずリストのリンク先を生成するために、「section[@class='text']」というノードに対して以下の処理を行った。
ここでキーになるのは、number要素のlevel属性に指定されているanyという値だ。これを使ってcountで指定した値（anoh:section[@class='text']）に強制的に順番を振っている。ただし、これだけだと全ての日付を通しで順番を振られてしまう危険がある（未検証）。そのため、順番を振る基点としてfrom属性の値に「anoh:date」を指定して、anoh:date以下で順番を振るように設定している。
一方で、リンク先にも対応するid情報を振るようにしなくてはならない。こちらもリストと同じロジックでできればよかったのだが、なぜか少々処理が異なっている。ただ、基本となる考えは先程と同じだ。
こちらのカレントノードは「text」という値を指定した「class」属性を持つ「anoh:section」要素だ。ところが、value-ofの処理でselectの値に「anoh:day」要素を指定しているためか、それ以降の処理が上手くいかない（というかカレントノードは今いったいどこ？って感じ）。そこで「xsl:number」要素のcount要素で強制的に処理対象を指定しているという次第。これってなんだが不思議マークアップとたいして変らない力技のような感じだし、無駄な処理をしているような気がする。カレントノードの概念や取り扱い方をきちんと理解していないで処理系を書いている以上、こうなってしまうのはしょうがないのだが。（￣△￣；
おいらのページは読み込みがすごく重い。おまけにスクロールが遅い。Opera for Macを使っているのでその辺は痛感していわけだが、2ちゃんねるで「Netscape 7を撃墜してしまう」とか「IE5でCPUを100%使い切ってしまう」とかいう指摘を受けてようやく重い腰をあげることに。
だが、Mac OS XやWindows XPのNetscape 7では同様の症状を確認できず。他の人にもWindows 98上のIE 5で確認してもらったものの、特に重いという状況は再現できなかった。Opera for Mac 6.0が出たときに、スクロールが異常に重い現象が起きていたので、メッシュ画像のサイズを拡大したことがある。その時にいくらか症状が改善してしまっていたのかもしれない。
とは言え、不安要素はとっぱらっておくにこしたことはなく、ページ中のメッシュ画像は排除、さらに大きなサイズでhtml要素に固定配置していた背景画像を非固定配置に切り替え、body要素に固定配置していた縦型の背景画像を取り払ってみた。これで解決するといいんだが。
＜これらの処置を取ったあとで、まだ動きがカクカクしてることに気がついた。どうもNetscape 7.01では、テキストの色が変る場所で引っかかっているような気が。
今日の最初のコンテンツでツリーのよりよいマークアップ法を考えている余裕がない、と書いたが、こういうのは他に例を探すほうが早そう。
つーか、こういった上下のある構造ということを考えるとサイトマップなんかもこれにあたるわけだが、アドビゴーライブのサイト設計機能のファイルはXMLで記述されていることを思い出した。これでどういう風にアーカイブの関係が記述されているのかを確認するのも悪くないなぁ。
自分でXMLを書く際に考えたのは、できるだけ語彙をシンプルな内容にしておきたいということ。それを考えるとHTMLも非常にシンプルであまり不満はなかったんだけど、時系列でコンテンツが増えていく文書に適したマークアップにするためにはカスタマイズが必要だったんだ。
現在本文の構造を作るために使っている要素は、日毎の区切りを表す「date」、日付を記す「day」、記事毎の区切を表わす「section」、記事の表題を示す「ht」、パラグラフなど記事中のひとかたまりの要素を示す「p」がメイン。
この他に、文書そのものを外部文書との置き替え(つまりページ移動)る場合の参照先を示す「link」、なんらかの役割りを持った外部文書と要素を置き替えて埋め込む「image」「source」、要素の内容が他の文書から引用されていることを締めす「quote」、アスキーアートのように情報としてはあまり意味のない要素をマークアップする「face」、直前の文書に対する注意書きなどの備考に当たる一文を示す「remark」などをpの内部に埋め込め込んで、単語レベルでの役割りを示す要素として使っている。
ここまで作ったあとで、先月書籍の紹介をするためにマークアップを行ったわけだが、書籍自体のマークアップを行うための要素は、異なる名前空間を使ってみる試みをしてみた。意味のあることかどうかはわからないが、書籍の情報を示すためのマークアップはおいらのコンテンツの構造を定義している名前空間と役割りが違うような気たしたからだ。
すでにおいらのマークアップでは、外部文書との関わりを持つ要素として定義されている「link」「image」「source」「qupte」では、実際の関わり方を記すのにXLinkの語彙を借りているという前例がある。外部文書の参照先を示すことが、おいらがこのマークアップで必要としてる役割りとは方向性が違うような気がしたというわけだ。
そう思う理由はけっこう曖昧だし、この方針はXMLに関する勉強をしていくうちに変るかもしれない。ただ、現時点では役割りをわけたほうが管理が楽だし、この先スキーマを書くときにもそう多くを書かなくて済むかなぁという目論見もあったりする。
XMLでは名前空間を使うことで他の規格の語彙を借りることができるわけで、例えば会話文を分り易くマークアップするために、XHTMLに会話文の記述に適したマークアップを借りてくるという手を知ったときには非常に驚いたもんだ。だが、それはそれで非常に有用だと考えたもの事実。マークアップの目的を考えながら語彙や機能を用意していくという手はありなのかもしれない。
ただ、語彙を借りてきた場合はXSLTスタイルシート中で、xsl:stylesheet要素のXMLネームスペース属性と、exclude-result-prefixes属性にその旨を書くのを忘れないようにしないと。XHTMLに吐き出したときに思わぬ結果になってしまうので。
今の今までサイトのトップページは後まわしにしてきたわけだが、覚書の2月7日分で触れられていたNaverJapanリンクサーチの検索結果を見てちょっと考えされられた。
つーのも、普リンク集などいつでもある程度のトラフィックの流動があるコンテンツからの流れがこのサイトにほとんどない（というか置きにくい）状況になっているのかなぁと。トップページというのはある程度普遍的なアドレスでもあるので、どこか適切なリンク先がない場合トップページにリンクを張ることになるからだ。現状ではトップページから2回ほどリンクを飛ばないと最新のコンテンツに行けないし、よほど情報の充実した目次ページにリンクが張られることもあったのだ。これではリンクを飛んできた人がサイトの中をうろうろしなくてはならなくなる。
つーわけで、まともなトップページを用意しましたですよ。最近一部でホット（？）な段組みなんかも使ったりして、トップページに必要な情報を集約して配置してみました。それとともに、リンクページなんてもの作ったりして、こちらはXML書くの面倒だったので暫定的にRSSに情報を記述してそれをHTML化しました。 RSS本来の使いかたではないので、そのうちリンク集用のXMLを書きますが。
これ、リンク集をわざわざ別に作ったのはあっちKリンク対策。今までリンク集は各ページに埋め込んでいたんだが、この手のキーワードを読み込んで利用するサービスへ、あまり関係のない情報を渡したくなかったというのがある。
こういったことをし始めたのも、XMLなどの勉強を進めていくうちに目に見えないデータの存在やデータの再利用が嫌というほど意識され始めたからなのだ。これらに対する処理は結局SEOの手法と重なってくるわけだし、情報を分りやくすネットに提供していくのには必要な措置なのかなぁ、と。
半月くらい前の話。「CSSでイケてるデザインサイト7」スレの519に書き込んだ「（ー..ー;へ」と名乗る人物が、リンク（ナビゲーション）をまとめるための段組に対し異論を展開。この手の段組みの根源にあたる発想はフレーム、ならば何故フレームを否定するか、という主旨で発言を繰り返した。
そして、カスイケスレッドから隔離されるかたちで「段組は愚かなのだろうか？」というスレッドがスタートした。その後この人物によってフレームの啓蒙サイトが公開された
スレのタイトルと話の主旨が微妙に食い違っていることもあり、最初、撮み食い程度で見ていたおいらはこの人物の狙いがよくわからなかった。だが、スレが進むにつれ、その主旨はだいたい理解できた。と、ここまでが今回のネタの前置き。
前回もSEOがらみで書いたが、コンテンツの主旨とは直接関係のない情報は、サイトの外へできる限りわたしたくない。そういう意味ではサイトのナビゲーションは、コンテンツにとっては最重要な情報ではなさそうだ。ナビゲーションについての考察は「みんな、accesskeyってどうしてる？ tabindexは？」スレッドでも取り上げられたことがあるようだし、以前にもCSSを無効にした際にナビゲーションの存在がうるさいといったことが各サイトで話題になってたと思った。
そう思いながら「outsider reflex」をJavaScriptを無効にして見たときに気が付いたことがある。ここでは各ページ共通のナビゲーションをJavaScriptを使って読み込んでいるため、このときは当然ナビゲーションが表示されなかった。そして、いわゆる「パン屑リスト」と呼ばれる、サイトのトップページからの道筋を示すリストのみが表示されている状態。これがあるだけでもサイト内を移動することは可能だった。
このほかに最近のブラウザーであれば、ナビゲーションバーのように、サイト内で特定の役割りを持つリソースへのアクセスを用意にする機能が用意されている。そうであればナビゲーションに関する情報は、ページ内に多くを目に見えるかたちで用意しなくてもいいのかもしれない。
目に見えるかたちでの表現が重要でなくなるなら、逆に目に見えない情報に注目することになる。ナビゲーションをページの外へ持っていく方法として「（ー..ー;へ」という人物はフレームを持ち出している。ナビゲーションの情報をページの外へ持っていく発想はおいらも同じだが、ここではそれ以外の選択肢を提示したい。
おいらの発想を支える技術が2つある。1つ目は「メタ情報（RDF）」であり、2つ目が「サイドバー」だ。つまり、ナビゲーションを自動生成して表示するサイドバーがあればいいのだ。
ナビゲーションの自動生成の方法としては、すでにモジラやオペラに実装されている「ナビゲーションバー」があるが、これらがサイト内の特定の役割りを持ったページへのナビゲーションを提供する「役割り型」のものに対し、おいらがこれから提案しようとしているものは、サイトマップそのものを提供する「目次型」のナビゲーションだ。ブラウザーにサイトマップやナビゲーションを実装することで、よりリッチなナビゲーション情報を、ページの見た目や構造をほとんど崩さずに提供できるかもしれない。
発想は簡単だ。サイトの構造を記したRDFを作成。サイト内の各コンテンツにはRDFの位置を示すmeta要素を用意しておく（例えば、<meta rel="map" href="./map.xml" />というように）。サイドバーはこの情報を読み取ってRDFファイルを拾いに行き、サイトマップを整形する。モジラで想像図を作ってみた。
毎度毎度妄想だけで、動かせるものを提示できなくて申しわけないが、ロジックはだいたい見当がついている。RDFファイルはそふぃあさんが提示している雛型が参考になると思う。
サイドバーはフレームを発展させ、ブラウザー機能の一部をウェブアプリケーションとして実現可能にした技術だと思えばいい。
ブラウザー内でサイドバーとワークエリアは、フレームと同様ウィンドウ名で区別されている。サイドバネル上にある「更新」ボタンを押すと、スクリプトがワークエリア上にあるmetaの情報を拾いあげに行く。ブラウザーはここで得たURLをネット上にあるCGIかモジラ内のXSLTプロセッサーに投げ、サイドバーで表示できる形式に情報を変換する、といった流れだ。
必要によっては、現在表示中のページをサイドバー内でハイライト表示するとか、ページを移動するたびにサイドバーの情報を更新するということができてもいいかもしれない。
というわけで、ひとつの妄想を示した。この手法に価値があるかどうかはともかく、最大の問題は、おいら自身がモジラやサイドバー、スクリプトに詳しいわけではなく、こういう機能を持ったプログラムををすぐに作って示せない点だったりして（￣△￣；。
ネットスケープ7でスクロール処理が重いという報告があり、ページのスタイルをいろいろと変更したわけなのだが、それの追記。
ネットスケープ系動きがガックンガックンしているのに、以前モジラをメインブラウザーにしていたころにそれに気が付かなかったのが妙に気になった。それで何が違うのかを検証するために、モジラ1.2.1をインストールしてみた。モジラ1.2.1でも色が変るところやオブジェクト要素で埋め込んだ外部リソースを表示する際に、動きがやや鈍るのだが、ネットスケープほどではない。両者の決定的な違いはアピアランステーマのようだ。
ネットスケープ7の初期状態で選択されているのは「Modern」テーマで、これはブラウザーの各パーツに独自にデザインされたものを利用している。一方でモジラで選択されているのは「Classic」テーマ。こちらはそのプラットフォームで一般的に使われているパーツを引っ張ってきて表示するようになっている。
おいらのマシンはパワーPC G3の500メガヘルツというCPUを積んでいて、メモリーの容量は384メガバイト。Mac OS Xが快適に動かせるかどうかのギリギリのラインにあるスペックだ。このくらいのマシンで両者を比べたとき、Modernテーマの遅さというのはかなり目に付く。
おいらのページは、例えばOpera for Macで見たときにステータスバーのブログレスが終了を示さないなど、ブラウザーに負荷をかけやすい作りをしているようだ（何が原因なのだかわからないが）。そういった環境で、さらにブラウザーに負荷をかけるModernテーマの利用が、ブラウザーのスクロール速度やメモリー空間に圧迫をかけていたのかもしれない。
ウェブで公開されているリソースはいわるゆところ「データ」。データのデジタル化の話が出るときに「一度デジタル化したデータは再利用が容易」という観点で提案が行なわれることがある。この「再利用」という特性が上手く機能していないのがウェブの世界だったりする。
例えば、こんなことがあった。プレゼンの資料を作る機会があったのだが、ウェブに既に掲載されているものをリソースとして使うということになった。非常にコンパクトに纏められていたので、スライド用としても流用可能だろうという判断があったわけだ。
手元のノートパソコンにはパワーポイントとオペラがインストールされていた。パワーポイントを起動するのが通常のパターンだが、ウェブにはすでにHTMLとしてマークアップされたデータがあるわけだし、紙に打ち出すわけでもないので、オペラのフルスクリーンモード（いわゆるオペラショー）を使うほうが早いかもしれない、と考えた。このページにプロジェクションモード用のスタイルシートを設定するわけだが、基本的にトリガーになる要素を決定して、そこに対して改ページを行なうスタイルシートを設定すればいいはずだ。
ところがその目論見は甘かった。ソースを見たところ、ほぼすべてのパラグラフに<br />が挿入されている。ソースに一貫性がないため、単純にスタイルシートを設定するだけでは対応できなさそうな内容。ソースを書き直すか、パワーポイントで1から作るかの選択を迫られたわけだ。
まあ、普段パワーポイントで作っているから、手間は同じってわけで結局パワーポイントにしたわけなんだが。楽しそこねた、だけってことで。ちぇっ（￣△￣；。
データを再利用するだけのスキルがなくて困ったこともある。あるところからデータベースより吐き出されたXMLデータが送られてきた。んでこのデータ、送信元ではそのままXMLスタイルシートを当ててウェブに置いていた模様。「こいつを再利用したいんだけど、HTMLにできない？」と聞かれたわけだ。
XMLスタイルシートはXSLのワーキングドラフト仕様のもの。見たところ、XSLのネームスペースだけ現行のものに書き替えれば、手元のXalanで変換が可能な気がしたんなけど、どうしてもプロセッサーからはじかれてしまう。このスタイルシートを現行のものに変換して吐き出してみたらどうだと思ったが、どうしたらいいか思いつかず。急ぎということもあるので、IEで表示されている内容を見ながらレイアウトを再現して、とお願いした次第。情けなや。
「ウェブなんて見えればいい」という考え方もあるんだが、効率を考えた場合、すでにあるデータを作り直せないような作りになっているのは非常に迷惑。特に少人数で多くの作業をこなさなくてはならなかったり、資料を扱う専門の担当がいないような環境だったり、ネットワークをベースに資料を公開しているような環境であったりする場合、単純な変換作業で資料を再活用できないようでは、デジタルデータで取っておく価値が半減してしまう。コンピュータがただの清書マシンだった頃と何も変っていない。
テキスト部分の再利用ができるだけでもまだマシなのだが、レイアウトや構造など目に見えないデータを作るのも実は苦労する部分だったりする。日頃あれこれデジタルドキュメントを扱っている身からすると、どうしてもこういった部分をおろそかにしたくなくなってくるのだ。
そういう意味もあって、XSLTの勉強はしっかりしておかないとなぁーと思っているわけなのだが。今だに「document関数で複数の文書を順に処理していく」の「順に処理」の部分を理解できない身としては先は遠いんだよなぁ（￣△￣；。
![[Valid RSS]](/common/valid-rss.png "Validate my RSS feed")
![[Valid XHTML 1.1]](/common/noa.png "This page is Valid XHTML 1.1")
