OOPの知識を活かしてHIMMEL改造大作戦。既存のコードは全部さようなら。
1時間ほどでクラスのインターフェースの設計は完了。後は実装するだけ。そこが大変なんだけど。UMLとも何とも言えない設計図が1枚だけなので、「実装して見たら大失敗」な可能性が恐い。
実装さえ出来ればDBとかXSL-FOとかも対応できるようにしてあるけど、たぶん実際は通常フィルシステム＋XHTMLだけだろうな。
HIMMELの使っているSDFというXMLフォーマットではメタデータ用の要素を既存の名前空間（DC、DCTERMSなど）に格納しているが、これって実は無駄が多いような、という話。
例えば、ATOMやRSS2.0では、意味的にはDC等で既に定義されている語彙を、自分の名前空間で再定義している。一見無駄に見えるが、これらのフォーマットを実際に使う場合、このほうが便利だ。
等々の利点がある。
逆に、デメリットは特にない。拡張性は若干失われるかも知れないが、モジュールを自由に追加できると言われているRSS1.0も、実際のところ相互運用のために標準的なモジュールが定められている。相互運用を基本とするフォーマットを拡張するには、結局は何らかのコンセンサスを得る必要があり、それだったら大本の語彙に新たな要素を追加しても変わらない。
RDFならば標準的な名前空間を使うことによるメリットが存在するかも知れないが、RDFから外れたフォーマットは構文からしてそもそも問題外だ。仮に、XSLTをはさんでRDF互換の構文に変形するのならば、そのとき同時に再定義した要素を標準的な名前空間の要素に置き換えれば良いだけで、元データまで標準的な名前空間を使用する必要は特にない。
というわけで、状況にもよるが（XHTMLの語彙を全部最低限するのはどうかと思う）、メタデータ程度の語彙は再定義する方が良いかもしれない。
実装しながら設計を煮詰めていたら、なにやらこれはクラスライブラリではなくてどちらかと言えば、フレームワークと呼ばれるものになっているのではないかという疑惑が。
大がかりになってきてしまった。当初の予定が狂いまくり。
PHPのマニュアルの検索欄にGoogle Suggestと同じような機能が付いていた。
関数リストみたいに候補が適度に少ないような場合の方がこの機能は便利かも。