先日、XPath2.0が出ました。XPathに今さらメジャーバージョンを上げるほどの変更があるのか、と疑問に思い見てみました。

• http://www.w3.org/TR/xpath20/

なんだ、このDefinition注釈の嵐は...。Editorsの名前を見ると、IBM、IBM、IBM。

あ、そっか(部室で長門有希を見つけた時の朝比奈みくる風)。

経験的に、XMLを扱うAPIとしては、DOMよりXPathベースの方が扱い易いと感じています。同じことを昔(http://dev.ariel-networks.com/blog/inoue.php?blogid=2&archive=2004-11-27)も書いています。昔書いた視点うんぬんは、今読むとあまり共感できませんが。

探すと、DOMにXPathベースのAPIを取り込む試み(?)はあるようです。

• http://www.w3.org/TR/DOM-Level-3-XPath/

XPath(文字列そのまま、もしくはコンパイルしたオブジェクト)を引数で渡すevaluate()メソッドの戻り値の型がDOMObjectで、その説明が次のようになっています。

Return Value

DOMObject  The result of the evaluation of the XPath expression.
           For XPath 1.0 results, this object will be of type XPathResult.

XPathResultにダウンキャストしろ、と言うのでしょうか。たぶん、JavaScriptの時代なので、ダウンキャストとか考えること自体が時代遅れなのでしょう。

XPathベースの参照結果は、ノードが一意に決まることもあれば、結果がコレクションになることもあります。XPathResultは全てを一緒に扱おうとして、醜悪なものになっています。

素直にDocumentインターフェースにgetElementsByXPath()メソッドを追加して、戻り値の型をNodeListにするのではダメなのでしょうか。NodeListでは間に合わないので、XPathResultを定義したのだと思いますが、いまいち納得できません。

getElementsByXPath()の追加は、APIの直交性の観点からは感心できません。この文脈での「直交性」の意味は、既存のメソッドの組合せで可能な操作は新しいメソッドとして追加すべきではない、という主張です。XPathベースでノード(コレクション)を取得する操作は、既存のDOMのAPIを組み合わせることで実現可能です。なので、同じレイヤに新しいメソッドとして追加するのは違和感があります。ただ、ぼくは美しくないと文句は言いますが、否定はしません。文句が多いので原理主義者と誤解される時がありますが、プログラミングに関しては、ぼくはどちらかと言えば現実主義者です。

XPathベースのノード生成APIもあると便利です(経験則)。createElementByXPath()のようなメソッドです。