ある関数の比較

function _load_flavors() {
$xns = $this->_xpc->xpath_eval("/config:config/config:flavors/config:flavor");
foreach ($xns->nodeset as $node) {
$ext = $node->get_elements_by_tagname("extension");
$ext = $ext[0]->get_content();
$content_type =$node->get_elements_by_tagname("content-type");
$content_type = $content_type[0]->get_content();
$this->flavor[$ext] = $content_type;
}
$this->default_flavor = $this->_xpc->xpath_eval_expression("string(/config:config/config:flavors/@default)");
$this->default_flavor = $this->default_flavor->value;
}
private
def load_flavors
@flavors = {}
@doc.elements.each("/config/flavors/flavor") do |ele|
@flavors[ele.text("extension")] = ele.text("content-type")
end
@default_flavor = @doc.root.elements["flavors"].attributes["default"]
end

でもここで使ってる Ruby の REXML というパーサは名前空間をあんまり (ほとんど?) 考慮してない (だから接頭辞がついてない。読み込んでいるドキュメントはデフォルト名前空間でやっていて接頭辞がないから) REXMLXPath とか使えるしイケてるけど、やっぱ微妙な部分がいくつかあるわけです。

PHP は書いた気になれる。んで後から読むと読み難い。実際には一回の代入が二行になっていたりするから。だからといって一行に纏めても読み難い。

PHP4 には例外もない。5 からあるけど、5 でやっと?みたいな勢い。

  1. トップ
  2. prog
  3. Ruby or PHP

XML は中間データとして使うようにしてみる。もちろんデータを XML で書いてもいいし、てきとーにデータベースから XML 生成するような実装をすればデータベースを元データとして使えるように。

例えば XMLDB みたいなクラス作っといて、get_latest_xml($num), get_month_xml($year, $month) みたいなメソッドを実装 (できればインターフェイスだけ定義したクラスを作っておきたいけど PHP4 じゃ無理くさい) しとく。それぞれのメソッドは決まった XML を返す。

スクリプトは設定に応じてどのクラスを使うかを決めてインスタンス化&メッセージを投げて XML を得る。あとはそいつを XSLT エンジンに丸投げして、結果を設定した Content-type で出力。

別に PHP でなくてもいいんだけど、Ruby は三郎拡張がローカルで動かないから……

  1. トップ
  2. web
  3. 日記スクリプト思考
  1. トップ
  2. prog
  3. 日記スクリプト思考

新しくするスクリプトではカテゴリではなくてタグという形にしてみる。そもそもカテゴリ的な使い方 (ツリー構造) で使っていないのでそのまま要素を tag 要素にするだけ。

理由は、カテゴリのツリー構造を表現するのが面倒くさいし、実際のところカテゴリのツリー構造ってあんまり上手くいかなかったりするから。

  1. トップ
  2. web
  3. カテゴリ? タグ?
  1. トップ
  2. prog
  3. カテゴリ? タグ?

なにやらeval('$db = new ' . $config->dbclass . '($config, $lang, $tags);');$db = new $config->dbclass($config, $lang, $tags); は同じっぽい。もちろん $config->dbclass はただの文字列。ナンダコレ。

それと $ext = $node->get_elements_by_tagname("extension")[0]->get_content(); がパースエラーって何よ。前にも書いた気がする。

$ext = $node->get_elements_by_tagname("extension");
$ext = $ext[0]->get_content();

上記のようにしないとダメ。

書いてて途中で PHP 捨て実行のために sablot/Ruby とか sablotron を一からやりなおしたりした。まー無理だったわけですが orz

つまり、PHP では汚いコードを心置きなく書けるわけです。あら素敵?

PHP でコードを書く理由って Sablot と mod_php のためだけなんだよね。ホント。関数の命名規則もバラバラだし、謎が多い。

  1. トップ
  2. prog
  3. PHP わけわからん。UNKE PHP

25 日終わったからもとのスタイルに戻したよ。

クリスマスにまず損しない (金は減るけど) 投資 (謎) して、ドレぐらい返ってくるかなぁ、とか思ってみたけど損しない分しか返ってこなかった。残念。まぁ全然いいんだけどももももも。

もっと寒いスタイル作りたいなぁ。モニターに息吹きかけると白くなるぐらい寒いスタイルシート書きたいなぁ。スポットライトと観覧車ってとこかなぁ。遊園地って人が多くて好きじゃないけど、観覧車っつう言葉の響きは好きだ。母親の実家に行く途中古ぼけた遊園地があって、その中に観覧車があるんだけど、幼稚園生のときその観覧車が動いているかどうかを何故か毎回確かめてた。この前通りかかったとき遊園地自体が潰れてた。ついでにもう通りかかることもなさそうだ。

まーとにかく Helvetica ってフォントの名前だよね。

  1. トップ
  2. web
  3. もういくつ寝ると
  1. トップ
  2. life
  3. もういくつ寝ると

  • 日記データの名前空間が適当すぎる。ほぼ XHTML で書いている本文も XHTML の空間じゃない。作ってるときは名前空間いちいち書くのが面倒だったらからそうしたんだけど、今になってみるとキモい。
  • 変換用のデフォルトテンプレートあたりがちょっと気持ち悪い。統一感がないのでもうちょっと blosxom 的にしたい。
  • 設定が .inc とかに入っていて気持ち悪い。スキン的な設定はスクリプトから完全に分離すべき。
  • 本体とは違う (スキン) けど abbr 要素とかを補完する辞書の語彙がやっぱ微妙に気持ち悪いのでスキーマをちゃんと定義しておきたい。一番めんどい

Taglibro を少し作り直そうと思い始めたわけだけど、実際日記本文に使う空間を何にするかとかで悩んでる。今は殆ど XHTML 1.0 と同じだけど、ホントにコレでいいかなぁとか何とか、だからといって XHTML 2.0 はまだ勧告されていないし、XML Schema の場所も決まっていない (TBD) ……一応どっちでもいけるようにはしてみてるけど、実際書くのはどっちかだし。

それと、できるだけ自然に書くため (つまりミスタイプを少なくするため) 名前空間接頭辞をできるだけ付けない様にしたい。ということはデフォルト名前空間を多用する (セクションごとに名前空間書く) ことになるけど、XML Shema の仕様を眺めてみる限り、実態参照の宣言方法がない。というか DTD でいうところの内部サブセットをどうやってやればいいか分からない……名前空間を省略したいだけの参照をスキーマで宣言するのはおかしいから内部サブセット的なものが必要。実態参照だけ DTD 使うのがいいかなとか思ったけど Validator がエラー出す (DTD で要素が宣言されていないよ!っていう) のでダメっぽい。併用すること自体アレだし……

  1. トップ
  2. web
  3. 日記の名前空間
  1. トップ
  2. xml
  3. 日記の名前空間

書こうと思ったんだけどうまく説明できない。たぶん前にも少し見たことがある。

坂がある。高床式の木で出来た小屋が沢山ある。そこに行くために坂がある。木で出来た少し大きめの小屋がある。坂の下には近代的でかなり大きい (とはいえ面積が広いだけで高さはそんなでもない) 建物がある。建物の一階部分はまるまる外で、グレイッシュレッドの柱がたくさん立ってる。二階以上の部分の壁の色はクリームホワイト。たくさん白いテーブルがある。料理が置いてある。人がいっぱいいる。顔見知りばっかりだ。

いくつかやること (忘れた) があった。不安がいくつかありつつもやることは無事に終わった。やることは大き目の小屋で行った。

他には、ロッカー、携帯電話、パーカーぐらい。

  1. トップ
  2. self
  3. 夢、坂、広場

汎用っぽいテンプレ作っていたら、XSLT だけで一行ごとに l 要素とかソレっぽいのでマークアップできることに気付いた……っていうかアレだ。

<xsl:template name="split">
<xsl:param name="value"/>
<xsl:param name="splitter"/>
<xsl:param name="element-name" select="'t:item'"/>
<xsl:choose>
<xsl:when test="contains($value, $splitter)">
<xsl:element name="{$element-name}">
<xsl:value-of select="substring-before($value, $splitter)"/>
</xsl:element>
<xsl:call-template name="split">
<xsl:with-param name="value" select="substring-after($value, $splitter)"/>
<xsl:with-param name="splitter" select="$splitter"/>
<xsl:with-param name="element-name" select="$element-name"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:element name="{$element-name}">
<xsl:value-of select="$value"/>
</xsl:element>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:call-template name="split">
<xsl:with-param name="value" select="'aaa#x0a;bbbb#x0a;cccc#x0a;z'"/>
<xsl:with-param name="splitter" select="'#x0a;'"/>
<xsl:with-param name="element-name" select="'l'"/>
</xsl:call-template>

正規表現使いたい……

  1. トップ
  2. xslt
  3. XSLT で行をマークあっぴ
  1. トップ
  2. xml
  3. XSLT で行をマークあっぴ

Opera 7.54 でコードが途中まで消えるっつう指摘を受けたので、navigator.userAgent.match(/Opera/) && navigator.userAgent.match(/7\.54/) が真だったら色づけしないようにした。消えるのは致命的杉。

たぶんドキュメントフラグメントに大量にノード突っ込んで既存のノードと置き換える部分が原因で最初のほうがレンダリングされなくなるんだと思うけどよくわからない。リロードするたびに消える範囲が変わる;

  1. トップ
  2. web
  3. Opera で色づけ

またメールが来なくなっていたので確認。インデクシングされていない。NMZ.lock2 は最初なかったのに、CGI 経由で実行したらNMZ.lock2 が残っていますというエラーとともに出来た。自分で作って自分でえらー吐いてるのか……?

仕方ないのでまたインデックス全部削除。

  1. トップ
  2. web
  3. Namazu Cron

ネームスペース宣言の集合は、式が現れるアトリビュートを持つエレメントのスコープに含まれるものと同じである。この集合には、XML ネームスペース勧告 (XML Namespaces Recommendation) [XML Names] が必要とする、暗黙的に示されたプレフィックス xml の宣言も含まれる。デフォルトのネームスペース (xmlns を用いて宣言されたもの) は、この集合の一部ではない。 とか書いてあったりする。ソースツリーのデフォルトネームスペース URI が null (特に名前空間を全く宣言していない場合とか) 以外の時は絶対にプリフィックス無しではマッチとかしない。

<foo>
<bar>baz</bar>
</foo>

この場合に string(/foo/bar) = 'baz' は true。

<foo xmlns="http://foo/">
<bar>baz</bar>
</foo>

この場合は string(/foo/bar) = 'baz' は false。/foo/bar は何も選択しない。例え XSLT 側のデフォルト名前空間が http://foo/ であっても何も選択されないxmlns:f="http://foo/" とかやって /f:foo/f:bar ってやらなきゃいけない。

で、困るっていうかよくわからんのはソースツリーのデフォルトネームスペースと結果ツリーのデフォルトネームスペースを同じにしたいときなんですよと。必然的に xmlns:f="http://foo/"xmlns="http://foo/" とか (順番も重要) やるわけですよ。exclude-result-prefixes="f" とかやるわけですよ。そうすると仕様書的に正しいかはよくわからないけど Sablotron の場合はどっちとも (xmlns, xmlns:f) 消えるんですよ (msxsl では大丈夫)。で、どうすんねんと哀さんと話していた次第(謎

xsl:namespace-alias とか利用すんのかなぁと思っていくつかソレっぽく書いてみたけどダメだった……なんかセオリー的なやり方ってないのかな。

  1. トップ
  2. web
  3. XSLT の XPath の
  1. トップ
  2. xml
  3. XSLT の XPath の
  1. トップ
  2. xslt
  3. XSLT の XPath の
  1. トップ
  2. xpath
  3. XSLT の XPath の

XSLT では属性ノードとその親ノード (要素) との関係は片方向……属性ノード側からは @attr[. = ../../@attr] (省略しない場合: attribute::attr[self::node() = parent::node()/parent::node()/attribute::attr])) とかいう風に親がちゃんと親に見える (っておかしいな) けど、その親からは (attribute:: としているように) 軸が違う。ここで親から child::attr とアクセスできたら困るわけだけど、ややこしい。どうも俺は属性を子ノード的にイメージしていて attribute っていう軸がイメージしにくい。

DOM の場合は属性に親ノードはなく (parentNode は null) ownerElement に親要素が入ってる。軸が完全に分離してるっつうのかなぁ。DOM だとあんまり混乱しない。ただのプロパティでしかないからかなぁ。

XSLT の場合も DOM っぽい考え方をすればいい気がするのでちゃんと書いて、どこがどう違うかを考えてみてる。軸をプロパティと考えればいいの鴨。

// わけわかんコードだ(w
contextNode = current();
with (contextNode) {
contextNode = child["*"];
with (contextNode) {
contextNode = attribute["attr"];
with (contextNode) {
text();
}
}
}
  1. トップ
  2. xslt
  3. XSLT と DOM との相違
  1. トップ
  2. dom
  3. XSLT と DOM との相違
  1. トップ
  2. xml
  3. XSLT と DOM との相違
  1. トップ
  2. xpath
  3. XSLT と DOM との相違

注意 これは間違ってるかもしれない。実際に実装を使って確かめたわけじゃない。今はめんどくさくて確かめたくないので覚書的なもの。

変数バインドエレメント (xsl:param, xsl:variable) では select でノードセット格納するときと、子要素にテンプレートを書いてごちゃるのとでは違うらしい。後者は結果ツリーフラグメント (Result Tree Fragment) になる。これはルートノードを含む。(select の場合でもルートノードを含むように選択すればルートノードは含まれる。例えば document() を単体で使えば必ずルートノードがノードセットの入る)

<xsl:variable name="foo" select="/bar"/>
<xsl:apply-templates select="$foo"/>
<xsl:variable name="foo">
<xsl:copy-of select="/bar"/>
</xsl:variable>
<xsl:apply-templates select="$foo"/>

前者の場合、ルートノードを含まないノードセットなので、無限ループに陥らずにちゃんとなる。後者の書き方によって $foo に格納されるのは結果ツリーフラグメントで、結果ツリーフラグメントはルートノードを含むので、(現在適用しているスタイルシートの match="/" にマッチして) 無限ループ。

結果ツリーフラグメントをノードセットと混同するとエラい目にあう。例えば Mozilla がクラッシュしたりとか。

  • 結果ツリーフラグメントは、結果ツリーの断片 (フラグメント) を表す。結果ツリーフラグメントは、ルートノードを1つだけ含むノード集合と同様に扱われる。
  • 変数バインドエレメントが select アトリビュートを持たず、コンテンツが空でない場合 (つまり、変数バインドエレメントが1つまたは複数の子ノードを持っている場合)、変数バインドエレメントのコンテンツが変数の値になる。変数バインドエレメントのコンテンツはテンプレートであり、このテンプレートをインスタンス化すると、変数の値が得られる。この値は結果ツリーフラグメントであり、このフラグメントはテンプレートをインスタンス化して生成した一連のノードを子に持つルートノードを1つだけを含むノード集合と同等である。

あっていれば xsl:param にノード集合を渡す。 はノード集合ではなく正確には結果ツリーフラグメントだ。まぁ扱い方的はあまり変わらないけれど……

ってことは <xsl:param name="ggg" select="'unke'"/><xsl:param name="ggg">unke</xsl:param> は違うんだ。実際これらを <xsl:value-of select="$ggg"/> とかやると文字列に変換されるので同じように見えるだけか。この場合前者の方が変換がなくてほんの少し高速かな。

  1. トップ
  2. web
  3. 結果ツリーフラグメント
  1. トップ
  2. xslt
  3. 結果ツリーフラグメント
  1. トップ
  2. xml
  3. 結果ツリーフラグメント

XPathXPath という名前だけでも誤解を招く。Path というだけにディレクトリパスとかを連想する。まぁ、ディレクトリパスとは類似点が多い。UNIX ファイルシステムにおけるルートディレクトリ (名前ナシ) と、ルートノード (展開された名前ナシ) とか、それに省略形による表記を使うとパット見ディレクトリを特定するためのディレクトリパスとなんら変わらない。‘/’ を区切りに使うのが紛らわしい。カレントディレクトリXSLT における カレントノード を混同しやすい。XPath にはカレントノードなんてものはない。コンテキストノード。

XPath は文字列とか数値も表現しえるので、ただたんにどっかのノードを特定する言語ではない。(とはいえ W3C 仕様書には XPath は、XML ドキュメントの一部をアドレッシングするための言語であり とか書いてあって紛らわしい)

だめだもう寝る。

  1. トップ
  2. xpath
  3. XPath の紛らわしさ
  1. トップ
  2. web
  3. XPath の紛らわしさ
  1. トップ
  2. xml
  3. XPath の紛らわしさ

IE (Gecko, Opera, etc) を無視するのと、音声ブラウザを無視するのはおなじ。

  1. トップ
  2. web
  3. IE

っていう感じでループさせて15枚セレクトを作ってみる。コメント書くのめっちゃ苦手だ(w

もうちょいページ自体どういう風にするかを考え中。

  1. トップ
  2. music
  3. Jackets 15
  1. トップ
  2. art
  3. Jackets 15

daimas の日記サンズを解雇になった田臥は、五十嵐くんに似てる気がするのだが間違ってる? ってのを、ミカン食ってるとき不意に見て鼻水でた。似てる。特にヒゲが。ヒゲ。

  1. トップ
  2. music
  3. 田臥 || 五十嵐

画像のナニがアレとかでと、規約読み直したらアソシエイト参加できそうジャマイカ的なので、amazon から画像ひっぱってるところ (現状 /jacket, /playing) はアソシエイト ID くっつけるようにしたので、そういうのウゼーよって人はてきとうにコピペすると良いと思います。謎すぎるなコレ。

  1. トップ
  2. web
  3. Amazon

正確にはまだ試験休みなのはいいとして、ここ数日ずっとハイテンション。ちょっと怖い。ずっとは続かない。

とにかく想像力を失くさないようにしようと思う。とりもどせない。既にあんまり無いところが厳しい! 経験的想像力 (?) は外をもっと歩いたり、憂鬱さの沢山味わわないとダメだから難しい。早く気付くべきだね。想像力について。

去年の自分のサイトを見てみたら今よりもっとすごく糞だった。おととしの見たらヤバすぎた。しかも XHTML とか、その他関連技術が自分の中である程度マトモになりはじめたのは今年だった。なんかもう学び始めてから二・三年たっている気がする。この一年はすごく長かったみたいだ。それと日記に書く文章が無駄に長くなったりもしてる。過去の日記とか読むのは微妙に辛い (わらい) けど面白いもんだ。ウェブに公開しちゃうと自分で捨てちゃったやつまで残っていて笑える。消してくれ!とか思う。どうでもいいな。

  1. トップ
  2. life
  3. 生活 of winter vacation

狂人日記 とか、ネット上にも載ってる各種インタビューとかで木下氏が ASIAN KUNG-FU GENERATION がどうとかっていう話が結構出てきて微妙に驚いた。意外だった。むしろ嫌いな系統だと思ってた。

どうでもよすぎてセクション切るか迷ったけど一応記録。

あーあと、LOST IN THE AIR っていうアルバムが出るらしくて楽しみだ。でも二月は永遠に来て欲しくないな。

  1. トップ
  2. music
  3. アート & ASIAN (ry

冬に想像する夏は素敵だと思う。その、夏の中にいるときとは違って、木の緑色だったり、いろんなもんの青さだったり、その他キラキラしたものしか浮かばないからいい。まーようは夏が涼しければいいんです。だよね?

つまりこういう幸せな世の中 (こう表現しざるをえないっていうかそうしないとアレ) では冬が一番素敵な季節なんですよ。秋とか春とか夏は花粉症 (ブタクサ, 杉, イネ) もあるしねー。

  1. トップ
  2. life
  3. 冬における夏
  1. トップ
  2. imagination
  3. 冬における夏

#blosxom にてちょっと kyo さん と話していて、うんちゃら (いきさつ説明するのが面倒になった) いろいろカコイイジャケを見せてもらったりしてみて、カコイイジャケ紹介する blog とかないの?とか。んでとりあえず自分用にアレなのを作ってみるかって感じ。かなぁ。

ジャケ買い? 自分持ってないっつうか聞いたことないのもあるけど、ジャケット見るのはタダっつうかカッコイイジャケットは晒しといたほうがいいんジャマイカって感じで (むしろ教えてもらったのとかメモっとくためなんだけども) とりあえず作ってみた。中間ファイルは普通に XML。 追加するスクリプトが汚すぎ (とりあえず動け的) なのでそのうち直したい。直したい。いつ?

ちなみにヤバ気なのは This May Be the Year I Disappear / Recover, Green Mind / Dinosaur Jr., フェイクファー / スピッツ。女の子ばっかですねとか言わない。

  1. トップ
  2. music
  3. ジャケ買い?。
  1. トップ
  2. web
  3. ジャケ買い?。

最初の頃だいぶ適当でここら辺の考えが甘かったわけで、オリジナルを保持することを考えなきゃなぁとか思った。今のところホワイトスペースで段落の区切りになっているけど、やっぱ一行ずつ l 要素とかソレっぽいのでマークアップして突っ込んだほうがいい。XHTML にするときは <span class="l">一行分</span> みたいにして display: block な感じ。むーできればはやくやったほうがいいだろうなぁ……

  1. 本体の XSLT の修正。
  2. 現在の XML を l 使う形式に変換する XSLT の作成・検証
  3. スクリプトの若干の修正

ついでに URL にもリンク晴れるようにしたほうがいいか。使えるタグ制限とか上手くできないかなぁ。

  1. トップ
  2. web
  3. コメントの XML