断片的(fragmentary)な文書を生成するためのツールは？

GW真っ盛りだというのに真面目な話。

単一(single)文書を作成するためのツールとしてはMicrosoft Word(以下Word)やAdobe Acrobat(以下Acrobat)等が有名です。これらを用いれば、常識の範囲内であればいくらでも文書を書くことができますが、これらのツールの欠点は、複数の文書をリンク付けするような文書(この記事内では断片的(fragmentary)な文書と呼ぶ)を作成することは非常に困難であるということです。

WordにもAcrobatにもハイパーリンクを貼ることで、文書内の任意位置(アンカー、見出し等)への移動や、外部ファイルを開くことができます。しかし外部ファイルへのリンクは、単に「リンク先のファイルの場所」を示すだけであり、そのファイルが移動されたり名前を帰られた時点で意味をなさなくなります。当たり前といえば当たり前です。ここではそれが悪いと言っているわけではありません。

私が言いたいのは、断片的な文書を生成するためのツールがないということです。断片的な文書とは例えばWeb上のサイトのようにURIによってリンクを張り巡らせた文書のことです(この場合でもリンク切れはありえますが)。

例えばWikiのように、各ページが単一の文書であり、その中で他の文書を場所ではなくURIによって指定しているような文書を書こうと思ったときに、それを実現するツールが無いのです。もちろｎWikiを使えばいいのでしょうが、Wikiは文書作成ツールではなく、飽くまでCMSの１つなので、文書毎にWikiを作るというのも妙なものです。

何のためにこんなことを考えているかというと、「仕事で今まで自分が得てきた技術・知識を文書にまとめよう」と思ったことが始まりでした。1つの文書に全てのことを書いてしまうと、後で順番を入れ替えるのが面倒ですし、1つのことだけを参照したいのに単一化された大きな文書を開かなければならないというのも面倒です。そこで、文書の内容を単一ではなく断片化させておけば、内容の追加は記事を追加すればいいことですし、必要な情報も必要な文書だけを開けば良くなります。

色々書きましたがちょっと伝わり辛いかも、、、とにかく、最終的に書いた記事の数だけ(X)HTMLを吐いてくれるようなメタ言語が欲しい。XML+XSLTでもいいんだけど、そんなことをいちいちやらなくても、世の中のデファクトとして確立された仕組みが欲しい。

今日はもう遅いからまた後日書こう。。

HTML5に期待することと期待していないこと

最近何かと話題のHTML5とChrome OS関連(?)の記事より

@IT: 進化するHTML 5、OS化するChrome

講演の中盤を過ぎて耳に飛び込んできた言葉の数々に思わず顔を上げた。HTML 5の枠組みで、ノーティフィケーション、P2P、Webカメラ、ドラッグ＆ドロップ、リッチテキスト編集のAPIを標準化するというような話をしていたのだ。極めつけは、質疑応答での次のようなやり取りだった。Webブラウザ内の複数ウィンドウ管理のAPIを標準化してはどうか、という聴衆の提案に対して「それは考えたことがなかったが、確かにいいアイデアだ」とグーグルの担当者が即答していた。HTML 5には、このまま行けばかつてデスクトップOS上のアプリケーションだけが利用できた機能が次々と取り込まれていきそうだ。

うーーん。。。ありのような、なしのような。。。

便利さと大変さはトレードオフ

思い起こせばプログラミング始めたころは、HTML+JavaScriptのセットではローカルファイルが扱えないことを不便だなと思っていましたが、物心が付いてくると、それができないからこそセキュリティ的に安全なんだなと納得したものです。

確かにHTMLだけでローカルファイルの操作ができたり、3Dグラフィックス関連のAPIがあれば便利なのでしょうが、そのアプリケーションにWeb上のリンクをクリックするだけでアクセスできてしまうのならば、開発者はあらゆるセキュリティ項目を考慮する必要が出てくると思います。

ひょっとしたらHTML5のいくつかの機能は、セキュリティの考慮のために、ブラウザ機能でデフォルトOFFになるかもしれませんね。そしてGoogleを始めとする各種サービスを実行するにはそれらをONにする必要があり、ONにしたままWeb上をうろうろすると色んなウイルスに侵入され、ON/OFFを使い分けるということをユーザに意識させ、情弱は付いていけないという大変息苦しい世の中になるかもしれませんね。

Javaの失敗とFlashの成功という教訓

そもそもWebの世界にはJavaという偉大なる失敗の先住民がいます。Javaを使えば確かに色々なことができます。できることで言ったらJavaScripの比ではありません。しかし信じられないほど起動が遅く、メモリを大量に食うわりには、できることはネイティブには遠く及ばない上に速度もそこそこ。加えてセキュリティ面では穴だらけという分かりやすい特徴があるため、結果として一部の信者を除いて全く使われていないという現実があります。

そのような先住民の失敗から、JavaやActiveXのようなブラウザ上で動作するプラグインが忌避された時代もありましたが、そのいわれなき差別を払拭したのがAdobe Flashです。

Adobe Flashもれっきとしたブラウザのプラグインです。しかしインストールが手軽で、読み込みが速く、動作が軽くて、そしてできることもかなり広いという便利プラグインです。おかげでFlashは、プロプライエタリなプラグインであるにもかかわらず、普及率がかなり高いものになっています。Youtubeの普及がそれを示していますよね。

以上より、HTML5の普及には起動が速くとても軽いAPIであることが必須であると言えます。どんなにネイティブアプリケーションと同じスピードでも、起動や読み込みに何秒も待たされるようではダメですよ。;)

ブラウザはアプリケーションの共通基盤として腰を据えてほしい

冒頭で引用した記事にはマルチスレッド用のAPIや通信用のAPIについて書いてあり、それによって完全にバックグラウンドで動作するスレッドやタブ間通信、ノーティフィケーション機能が盛り込まれると書かれていますが、そこまで高度なアプリケーションをブラウザ上で動かす必要があるんでしょうか？ アプリケーションをブラウザ上で動かす利点は、いわゆるS/Cモデルのシステムのように、クライアント側に特別な環境を用意することなく、サーバとやりとりするだけで色んな事が出来る、という点だと思います。であれば、そこまで複雑なマルチスレッドプログラミングは不要ですし、通信もリクエスト送信/レスポンス受信の機能だけ整理してくれればいいんじゃないでしょうか？ バックグラウンドスレッドやノーティフィケーションはブラウザ固有のプラグイン(Firefoxの拡張機能等)で実現すればいいのではないでしょうか？

ブラウザは現在でもOSを(ある程度)意識しないで使えるプラットフォームとして便利に使っています。単純な計算やテキスト処理ならJavaScriptだけで作れば、クライアントはアプリケーションのインストールなしにそれを利用できます。Wikiをサーバ上に作れば、誰でも簡単に情報共有ができます。これをブラウザを使わずに実装するとしたら大変なことです。ブラウザさまさまです。

色々書きましたが、HTML5には大いに期待しています。今できないことがブラウザ1つでできるようになれば、開発者がアプリケーションのプラットフォームを何にするか悩まなくて済みます。ですが、飽くまでHTMLに期待することはページ(タブ)単位の表現力であり、タブをまたいだ通信や、デバイスを制御する機能は(個人的には)不要だと思います。

間違ってもJavaの二の舞にならないようにしてください。

XHTML2終了、HTML5へ一本化

XHTML 2終了、HTML 5一本化: マイコミジャーナル

HTML 4.01の後継となる規約がHTML 5になることが、ほぼ明らかになった。2日(米国時間)、W3CはXHTML2 Working Group Charterが12月31日に期限をむかえても、もはや更新しないことを明かにした。これはW3Cが次世代のHTMLとしてHTML 5を推進していることを明示するとともに、HTML 5の策定作業に割くリソースを増やしたい狙いがある。

HTML 4.01の後継規格としてXHTMLの策定が進められたが、当初期待されていたようには普及しなかった。結局、あとから策定が進められたHTML 5が後継として使われることになった。ただしHTML 5には、XHTML 2で規程されている機能のいくつかは取り込まれている。

最近は勉強不足で、HTML5についてはほぼ無知識状態です。何やらマークアップの仕様レベルでビデオの再生まで規定する、ということぐらいしか知りません。それすら合っているか微妙です。。。

しかしXHTMLが流行らなかったからやめるって。。。W3Cってそんなにいい加減なの？ まー仕様は1つだけあればいいですよ。

何でもXML化するのが世の流行りという中で、HTMLだけは異色の存在となっている現状ですが、これでよりStrictなマークアップ言語になるのでしょうか。だいたいXHTMLが流行らないのはそれ用のソフトウェアが少ないからですよ。

HTMLでは「空要素には閉じタグは不要」とか「属性値をダブルクォーテーションで囲まなくてもよい」とか言われていますが、仕様上許容しているだけであって推奨しているわけではありませんなのでHTML4.01準拠の文書でも「空要素に閉じタグを付ける」「属性値は必ずダブルクォーテーションで囲む」とすればいいんです。

しかしこれは何も作成者が必ず意識しなければならないことではありません。作成するソフトウェア側で吸収すればいいのです。Wordで文書を古いHTMLで出力させると、丁寧に空要素から閉じタグを消してくれますが、これこそ余計なお世話なのです。HTML4.01で出力しようがXHTML1.0で出力しようが、基本的に同じ内容になるようにするべきです。

例えば<i>タグはXHTML1.0では使用できませんが、そもそも斜体はCSSで表現するべきものですし、<i>ではなく<em>を使えばよいのです。無理に<i>タグなんて使わなくてよいのです。

「XMLを必須にするとWebページ制作者への負担が増える」とも言われていますが、そうでしょうか。FlashやActionScriptの方がHTMLよりよっぽど複雑です。それでもFlashは十分市民権を得ています。それはオーサリングソフトが優れているからです。対してHTMLはタグの手打ちか、ひどいタグ出力しかできないWYSIWYGエディタだけです。

「思ったより流行らなかった」とティムバーナーズリーが嘆いているのは、HTML出力ソフトウェアの製作者の志の低さだと言っても過言ではありません。なるべくしてなった結果なのかもしれません。もっとガンガンXMLをプッシュしましょうよ。

ん？待てよ？XHTMLが流行らなかったからHTML5に統合するってことは、HTML5でもぐだぐだな仕様が続くってこと！？まさかね。。。

なお、HTML5が出てきた経緯については、ちょっと古い記事ですが@ITのHTML5が持つ本当の意味が参考になると思います。

Web2.0(Ajax)時代の標準文字コードはUTF-8？

今から3年ぐらい前、Web2.0なんて言葉が出始め、Ajaxはまさに黎明期、Google Mapsとかにみんな驚き、JavaScriptが威厳を取り戻しつつあった時代がありました(そんなに昔の話じゃないですよ。3年前の話ですよ)。私もご多分にもれずそれに感化され、卒研では意味もなくXHTML+JavaScript+PHPをAjaxでつないでいました。

その頃は若かった(?)ため、HTMLに当たり前のようにUTF-8を使い、サーバとのやり取りもすべてUTF-8で行っていました。若い時は「XMLはUTF-8がいい」なんて聞いたら、それ以外を使うのはすべて悪であるかのような錯覚をしていたので、特に違和感もありませんでした。

しかしそれから3年が過ぎ、ふと別件でAjaxについて(今更)調べる中で「decodeURIComponentはUTF-8しかデコードできない」という事実を知り驚きました。それってつまり、HTMLもUTF-8にしなきゃならないってこと?

と思ったら、なぜかデコード後の文字列は、HTML自体がShift_JISの場合はShift_JISになる！ どういうこと？

そもそもdecodeURIComponentにUTF-8以外の文字列をエンコードした文字列を渡すと、「error: malformed URI sequence」になってしまいます。UTF-8以外はデコードできないからですね。それを回避するためにサーバはresponseTextに常にUTF-8文字列が返るように実装しなければなりません。イマドキそんな制限ないっすよ～

decodeURIComponentはRFC2396に準拠しているんですってね。そこにUTF-8以外は認めないとか書いてあるんでしょうか。そのうち勉強します。

• RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax
• RFC3986 Uniform Resource Identifier (URI): 一般的構文