2005年 02月 17日

XML マスター DAY

xml

XMLマスターDAY 2005 になんとなく行って来た。

XML で遊びたいけど、しばらく XML っていう言葉をききたくない。

コクヨホールが予想より綺麗だった。

v2 になってから受ける。6月にベーシック、夏にプロぐらい。でも勉強したくない。受験料高いから全力は尽くすけどね（謎

関連エントリー

2005年 01月 21日

名前空間が null?

xml dom xslt

IRC ネタ。

2005年1月の指向性メモ に createElement()で作られたエレメントノードは名前空間がnullになるはずなのに、親要素のデフォルト名前空間を引き継いでしまっている。 って書いてあるけど、何か違う気がする。

確かに DOM Core の createElement の項には localName, prefix, and namespaceURI set to null. とは書いてある (これを根拠にしているかは定かじゃない) けれど、これは名前空間っていう概念がないから、名前空間関連のプロパティにはとりあえず null という値を入れておけよってことで、名前空間URI を空値に設定するっていう意味じゃない気がする。code でマークアップされてるしね？

そもそも自分も書いたことあるんだけれど、名前空間がnullになるっていうのが何かおかしいかもしれないとも思う。Extensible Markup Language (XML) 1.0 にも Namespaces in XML にも null という単語が出てこない。名前空間が null っていう表現が出てくるのは XPath の仕様の日本語訳で、原文の null には code 要素がついていないので、ただたんに“空”といいたいだけなんじゃないかとか。でもそうだったら empty って書くかなぁ……仕様書だし紛らわしいふうには書かないから、あるいは俺の読解力が糞なおかげで違うかもしれない……

まー結局のところ createElement に名前空間の概念がそもそもないので単純に引数の nodeName を引数の名前にするよってことで、それ以上は実装依存なんじゃまいか。みたいな？　併用することは稀なので。。。

しかし自分の解釈があっているかどうかは永遠に謎だ。確かめようがないから困る。誰に聞けばいいのか。その人が言っていることが正しいのか、正しいとしても自分がそれを正しいまま受け取れているかは確かめようがない。あーアレだね。アレ。理解は誤解の総体 (だっけ？) ってヤツ。　わかりあえているように感じるにはできるだけ曖昧な表現をすればいい。アレとかソレとかを、明確にしない「ありえねー」とか。

関連エントリー

2004年 12月 26日

日記の名前空間

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

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

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

関連エントリー

2004年 12月 25日

XSLT で行をマークあっぴ

xslt xml

汎用っぽいテンプレ作っていたら、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>

正規表現使いたい……

関連エントリー

2004年 12月 23日

XSLT の XPath の

web xml xslt xpath

ネームスペース宣言の集合は、式が現れるアトリビュートを持つエレメントのスコープに含まれるものと同じである。この集合には、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 とか利用すんのかなぁと思っていくつかソレっぽく書いてみたけどダメだった……なんかセオリー的なやり方ってないのかな。

関連エントリー

XSLT と DOM との相違

xslt dom xml 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 っぽい考え方をすればいい気がするのでちゃんと書いて、どこがどう違うかを考えてみてる。軸をプロパティと考えればいいの鴨。

// わけわかんコードだ（ｗ
contextNode = current();
with (contextNode) {
contextNode = child["*"];
with (contextNode) {
contextNode = attribute["attr"];
with (contextNode) {
text();
}
}
}

関連エントリー

2004年 12月 22日

結果ツリーフラグメント

web xslt xml

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

変数バインドエレメント (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 がクラッシュしたりとか。

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

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

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

関連エントリー

XPath の紛らわしさ

xpath web xml

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

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

だめだもう寝る。

関連エントリー