ああ輝く大地の上 ふきだす命は神の血潮
宣伝
サイト構成ツール3
CMSについてやうやく納得がいつた。CMSなんていふけれど、要は今まで個人サイトで行はれてゐたことの自動化に過ぎないわけだ。方法論的には。ゆゑに、comment機能の実装や、日付管理のどうたらといふのは、あくまでも（CGIによるサーバ側で実現された）自動化によつて実現可能になつた副次的なものに過ぎず、例へば仮に今の高天原を、現状の形式を全く維持したままCMSの導入といふことも、原理的には可能なのである（勿論、CMSの考へ方は基本的にローカル・グローバルの環境を選ばない。作業汎用性とサーバ負荷とどちらを優先させるかは時と場合次第である）
つまり、今まで私が感じてきたCMSの問題点は、つまりそれを成立させる（例へばブログなどの）ツールや使ひ手の問題なのである。現在の機能が不備という話は、情況次第で実装するだけなので どうでも宜しい。
と言ふ点には、実際の状況を思へば、私には到底看過出来ないレベルの問題ではあるのだけれど、それは考への違ひなのでそれこそどうでも良い。
となれば、この辺の問題を巧く解決したCMSツールの登場を望みたいところ。CMSとしてのブログといふあり方に対する評価はともかく、CMSそのものに対する評価は私の中で大きく変はつた。前に言つたローカルで利用する下書きXHTMLを採用するとなると、どのみちCMSのやうな管理システムが必要不可欠になるのだし、うちでも採用を考へてみても良いかも知れない。
三宅さん、ありがたうございます。
サイト構成ツール2
それから、書いたものが直ぐ一般公開されると考えることが おかしいよ。 そういうのなら Web 掲示板で充分。 CMS である必要はない。
ええと、ブログには記事の公開・非公開を制御する機能――みたいなものがあり、管理者だけが全ての記事を等しく確認でき、適宜修正を行ひ、その後公開にするか、非公開にするかを適切に選択できるやうな機能があるのでせうか。（いや、まあ理論的には可能である以上はあるのだらう）それなら、確かに作業環境の汎用性は有効といへる。
といふか、三宅さんの話を聞いてゐると、ブログやCMSと言ふ方法論そのものにそれほど問題があるのではなく、現在普及してゐるツールや使ひ方といつた実体面での問題があまりにも多すぎるのではないかといふ気がしてきた。とするれば、現状のブログはHTML4.01のやうに、全く正しい使ひ方をされ得ぬまま可能性の存在として埋もれていく運命にあるのかも知れない。
要は “使う側”の問題ということか…。
サイト構成ツール
IRCにてなんか最近、opera使いで、正字正かなの人に限ってブロッグなんて…、つー人が多いように思うのですが気のせいでしょうか？
なんて言はれれば嫌でも意識せざるを得なくなるなあ。いや、確かにさういふ気はしてたけどね。ところで、ブログと言へば、この雑念雑記は歴としたブログなのですが、恐らくここで言ふのはブログツールの話だと思ふのでそこは考へないことにします。
サイト構成としてブログツールを用ゐるのは構はないと思ふ。だけど、それをオンライン上で行ふ理由はどこにあるのかといふ点に私は大いに疑問に感じる。フィードバックを自動化するだけであれば、今の大多数のブログがcomment 0
とあるやうに、さして――私のサイトで導入する――意味を持つとは思へない。ローカル上でサイトを構成するツールとしてブログツールを用ゐるのは「あり」だと思ふ。その方がシステム資源の無駄遣ひが少ないだらう。
ローカルであれば、CGIではなくソフトウェアにしてしまへば、結構色々なことが出来ますよ。根本的には、データをどういふ形式で保存するかなどどうでも良い。Wiki記法だらうが、下書き用XMLだらうが、一般的な掲示板式でも構はない。出力さへきちんとしてゐればね。
昔野嵜さんが言はれてゐたことだけど、HTMLエディタで言はれるWordの操作性、アウトライン機能、スタイル機能──これらをデッドコピーしたHTMLエディタ
が実現し、これにWindowsのやうな感覚で操作できるサイト管理の機能を加味すれば、最強のサイト構成ツールになるのではないだらうか。
三宅さんの話（スポンサード）を読んでゐると、どこかプロジェクタ機能に似てゐるなあと言ふ気がする。あと、私は別に携帯端末や会社から雑念雑記を更新する気はないので、やはり私にとつてオンライン上でブログツールを使ふ魅力は、必要な資源の量と比べて小さい。といふか、ただでさへ現状でも誤解誤字脱字が多いのに、出かけ先で書いたやうな文章なんてとてもぢやないけど公開する気にはなれません（ミクシのやうな閉鎖的環境ならともかく）
ただ、自分のPCがぶつ潰れた時には有効かも知れませんね。
下書きXHTML
IRCにて私が現状と次世代のXHTMLについての不満をぶちまけてゐると、どうもその手のえらい人が言ふには、XHTMLなんて考へず全部RDFにしてしまへば、全ての些事難題は、あたかも快刀乱麻を断つが如く雲散霧消するらしい。それは素晴らしいと早速神崎本を買つて今読んでゐるのであるが、さてはて、どうにもRFDといふものは、確かに利用性は高いと思はれるが、直接書くに際してあまりにも仕様が煩雑すぎるやうである。
それが悪いことだとは言はない。互換性や相互発展性を追求するのであれば、仕様自体が複雑化するのは必要な犠牲とみることは妥当である。妥当であるが、オーサリングツールの類にどうしても馴染めない私のやうな古人間には、些かつらいものがあるのも事実。
といふわけで、掲題の件に戻るのだが、つまり、公開する分にはRDFだらうが何だらうが構はない、しかし、その前の下書き段階での記述言語にまでRDFを使ふのは、メンテナンス性を考慮すると酷く不都合であると私は思ふ。ゆゑに、相当簡略化したXHTMLの下書き版みたいなものをローカルで定義し、それにXSTLを通してRDFに変換、公開と言ふ運びにするのが妥当ではないかと漠然と考へてゐる（尤も、これは以前から度々考へてきたことだから、別に目新し事を言つてゐるわけではない）
下書きなのだから、書式はどちらかと言へば原稿用紙的な――所謂リニアな
――方が書き心地が良い。データを厳密に定義する必要はなく、適宜省略することも許されるだらう。以下その草案。前に公開した奴を改造して定義した。なほ、強調部分は出現が必須であると解釈していただきたい。
-
html要素
- title要素
- creator要素
- contact属性（連絡先URI）
- date要素
- part属性（公開・更新・破毀等：デフォルト公開）
- link要素
- href属性
- part属性（relとrevの合併）
- s要素（section）が複数出現
- （html要素と同じ要素）
- p要素
- q要素
- em要素
- a要素
- obj要素
- list要素
- q要素（blockquote要素と合併）
- citeuri属性
- citetitle属性
- （p要素と同じ要素）
- p要素
- note要素（注釈）
- （p要素と同じ要素）
- p要素
- ins要素（追記）
- date属性
- （p要素と同じ要素）
- p要素
- del要素（削除）
- date属性
- （p要素と同じ要素）
- p要素
- obj要素
- src属性
- （別言語の記述、例：数式、表、メニュー、化学式、等々）
- list要素（ulとolの合併）
- order属性（昇順・降順・順不同：デフォルト順不同）
- li要素
- （p要素と同じ要素）
インライン系の細かい記述は省略、ほぼ現行のXHTMLを踏襲してゐる。また、順不同リストで書いてゐるのだから、当然これらは全て順不同で記述出来る。署名（creator）要素や日付（date）要素を最初に持つてくるのも最後に持つてくるのも自由である。
headerだのmetaだのbodyだの小難しいことは含めず、全て暗示してゐるものとする。下書きなのだから、コスト最適化を求めない。極端な構造化を嫌ひ、自然言語を、ありのままに記述し、必要最低限のマーク付けを行ふ。そしてその暗示された部分を明示化し、構造化を行ひ、複雑で利用性の高いXML（RDF）に変換するのが、XSLTなりツールなりの仕事とする。
note要素はどうだらう。引用と同じぐらゐ、文章中に書くことの多い要素であるやうに私は思ふ。ins/del要素はISO-HTMLとは逆にブロック要素に限定する。修正するなら段落毎修正すべき。
これで通常の文章の9割は補足出来ると思ふのですが、荒削りなのは自覚してをりますので、批評、批判、賛同など、あつたら嬉しいです。
それにしても、今のXHTMLはどんどんHTMLやXMLの理念から遠ざかつてゐるやうな気がしてならない。何だつて、さうXHTMLだけで全部を詰め込んでしまはうとするのか。何のための拡張性か。XHTML策定者は『テキスト』と『（マルチ）ドキュメント』との区別を本当につけてゐるのか。つけてゐないのであれば、HTML3x時代に逆行してゐるのではないのか。目次は目次、表は表であり、これらは全てテキスト（本文）ではない。もしXHTMLをハイパーマルチドキュメントを記述するための言語にしたいのであれば、まづXHTMLなんて名前をさつさと変更すべきだ。名は体を表すべきである。
なんか、全部PDFは言ひ過ぎた模様。まあ別に元ファイルがあれば出力形式などどうとでもなるんだけど。
私がFirefoxを使はない理由
某方面でFirefoxとOperaの比較考察が行はれてゐる模様。勿論、どちらのInternetExplorerと比べて遙かに優れてゐることは事実。そして、どちらにもそれなりの長所・短所があることも事実。以下の文章はその前提をおいた上で読んでいただきたく思ひます。
さて、私はどちらかと言へば――といふより、XSLTの簡易出力とCSSの標準準拠度を測る時、後はOperaで不具合が出るサイトを読む時以外では、専らOperaを利用してゐる。
私が思ふに、PiroさんがFirefoxをショップブランドのPC
と見立てた指摘は、どちらかと言へばOperaの方に当てはまつてゐるやうな気がする。Firefoxは何も知らない、使へれば良いといふ素人と、あれこれを自分の思ふやうに、究極のブラウザとして使ひたいといふ玄人の、両方に向いた作りになつてゐる。反面、Operaは、取り敢ず上級向け機能は欲しいけど拡張なんて本格的機能は要らない、といふ、私を含めた中途半端な中級者向けに近い作りになつてゐるやうに感じる。ショップブランドのPC
といふのはさういふ人向けの代物だらう。Firefoxは、例へるなら知人に作つてもらつた将来拡張を出来る余地を残した最低限の装備の自作PC、といふ感じがするのである。
確かに、Firefoxの（最も）基本的部分は初心者向けである。といふ事実はさうかも知れないし、ずぶの初心者であればそれでも十分だと思ふ。ただ、その初心者が、「ちよつとここを変へたいな」と思つた時、要は、初心者から中級者へと変はるその瞬間において、突然上級者と初心者の壁が大きく隔たつてゐるやうに思へる。脱初心者指向者（とここでは表現させて貰ふ）がFirefoxに関する少し突つ込んだ資料を調べたとき、果たしてXULだとか、その前提であるXMLだとか、拡張だとか、その根幹原理だとか、さういふ話が理解出来るかどうか――恐らく不可能だらう。
その一方で、バージョンが改まる度に拡張の仕様が変更され、それを一々入れ直さなければならない。といふその「理由」を、根幹原理を知らない中級者は理解することが出来ない。そこにFirefoxに対する何とも言へぬもどかしさを生じさせる原因があるように思へるのである。その点において、ある程度「分つてゐる」人であれば、機能の取捨選択の余地があり、バージョンアップしてもある程度それが保証され、かつそれについてあとで勉強すると言ふ多少の余地があるOperaの方が、中級者にとつてはとても便利が良いのである。
FirefoxにしてもWindowsにしてもその他色々なものにしても、最近の製品には脱初心者にかかる負担があまりにも大きすぎる気がする。「簡単に始められます」といふのは結構。だけど、FirefoxにしてもPerlにしてもPHPにしてもXMLにしても、私は未だに初心者の域を脱せないでゐる。なんで、かういふ中途半端な理解者向けへの解説が少ないのだらうか。なんで、ちよつと複雑な話をしやうとすると突然桁違ひに専門用語が増えるのか。今の技術は、どうにも初心者と上級者と分別し過ぎてゐるやうな気がしてならなず、それが、私があまりFirefoxを使ひ切れてゐない大きな理由の一つだと思はれる。
逆に言へば、HTMLにしろCSSにしろ、私がすんなりと理解出来、移行できたのは、この中級者辺りの解説が豊富に揃へられてゐた（或いはある程度理解出来ればすぐに上級者並みの理解が得られた）といふ面が大きいやうな気がするのである。この辺りを、Firefoxを含めた（相当広い意味での）Mozilla関係者はもつと理解していただきたいと思ふ（勿論、最近、中・上級者向けの隠し設定を弄る拡張が公開されてゐるのも知つてはゐます。ただ、それはあくまで拡張であり、勿論バージョンアップとともに無効化される危険性を持つ事には変はりないのも事実です）
他方、だからといつて、Mozilla系でなにがしらの機能を標準装備したブラウザが登場したとして、果たしてそれが流行るかどうか。結局、既存のFirefoxユーザはFirefoxを選ぶだらうし、さういふ人たちを見本とする新規初心者や脱初心者指向者が、その新たなブラウザを利用していくかどうか、といふのは、はつきり言つて私は疑問に思へてしまふ。
まあ、Mozilla系のレタリングが気に入らないといへば気に入らないといふのも理由の一つではある。気に入らないのだから、私にとつてFirefoxはいつまで経つてもうんこ未満
であることには変はりないのも事実とは言へます。大きな理由ではないにしろ。といふか、何か、Firefoxの言ふ拡張といふあり方自体、どうにもブラウザ本体との親和性にどこか違和感を持つてしまふし、そもそも隠し設定なりその記述法なり必要な拡張なんなりを覚えやうとする気力があれば、Operaぐらゐ簡単に使ひこなせてしまふやうな気がするのですが、それは言ひ過ぎなのでせうか。
あ、でも私も片一歩上級者（？）に足を突つ込んだ中級者でありますので、MoziillaやFirefoxがなくなるとか、さういふ極端なことになつてしまふのも非常に困るのであります。要は、競争相手でも何でも良いから共存共栄してくれ、と。Operaだつて競争相手がゐなければいつIEみたくに成り下がるか分つたものぢやないしね。
高天原アンテナ整理
FFT+A Capture2関係のオフレポはもう少しお待ち下さい。以前雑記で書いたオフレポを発掘してまとめて高天原横町で再公開する予定です。
取り急ぎ一つサイト関係で感想を挙げると、「高天原アンテナ使つてます」といふ声をちらほらと聞いたのが私にとつてかなり意外でした。「月夜同舟使つてます」とか「地下書庫案内所使つてます」といふ言葉は聞かなかつたけど、アンテナだけ使つてゐるのです。まあ、FFTが発売されてから既に8年目といふ時期を考へれば、確かにそりあさうだらうなあとも思ふけどね。
それはともかく、アンテナは最近全然整理・修正してゐなかつたので、これを機にやつてみた。主に移転・削除の対応。寂しいが、これは仕方ないともう諦めた。諦めなければ、前に進めない。後ろを振り向くときはInternet Archiveさんにでも頼りますよ。
あと、高天原アンテナにしても月夜同舟にしても、最終的には定時的な更新を自分のドメイン内でやりたいという気持ちがある。ただ、アンテナ程度ならともかく、月夜同舟ぐらゐのデータ量――現時点で更新を確認してゐるリンク数は297件。そして今年度末までには恐らく400件近くに膨れあがると思はれる――になると、それを処理するCGIのサーバ負荷が洒落にならないことになるので、これはもう、消費電力を極力抑へたノートPCでも買つて「ローカル内で処理→サーバにアップロード」という流れにするしかないかなあと考へてゐる。終夜運転のPCは前々から欲しいと思つてゐたところだから、丁度良いと言へば良いのだけどね。
さういふわけで、T+Aは無事に終りましたが、イヴァリースの世界はまだまだ続きます。天照白書やアンテナや月夜同舟も、どんどんパワーアップしていく（つもりです）ので、T+Aで知つて初めてこちらに来られた方、また今まで定期的に見ていただいてゐる方々へ、これからも弓状列島「高天原」をよろしくお願いいたします（XML関係の方はまだ修行中の身であります。ただ、サイト関係について言ひたいことはちらほら溜まつてゐるので、それもまたより良いWWW覚書に書き足しておきたいです）
新たな誓いを胸にT+AはCapture3――偽らざる者――へ！