パスとは現在、5月にPOD出版した『スタイルシート開発の基礎』[1]を使って、毎週、社内で勉強会をしています。パス(p.21)の箇所で人によっては結構ひっかかりました。本書はXMLをXSL-FOで本にするということがテーマなので、XSLTの基本説明はさっと流しています。詳しいことはあとで、実際に使えれば良いという実践的な指導書ともいえます。わからないことは詳しく調べてみるのも面白いものです。いうことで、このあたりを少し調べてみました。パスについて調べてみます。XPath仕様[2]を見ますと、パス(ロケーションパス)の生成規則では、次のように絶対パスと相対パスの2種類があります。AbsoluteLocationPath絶対パスは次のように相対パスの先頭が’/’(ルートノード)になっているものです。AbbreviatedAbsoluteLocationPath相対パスは次のように単一のステップまたは複数のステップを’/’で結合して構築します。AbbreviatedRelativeLocationPath‘/’の意味が場所によって違うことで混乱しがちですが、先頭に’/’があったら、それはルートノードを意味し、ステップの間の’/’は結合用オペレータです。ステップの生成規則は次のようになっています。Predicate*で構成する)の二通りがあります。本書の3.4.1パスには省略記法、3.4.2軸には軸指定から始める記法の例が載っています。前回([4])の図のp要素を含むパスは、省略記法では絶対パス:/doc/body/p相対パス:body/pという二種類の書き方があります。これだけですと、WebのURLなどのパスの書き方と似ています。軸指定から始める書き方では、次のようになり違いが明確です。絶対パス:/child::doc/child::body/child::p相対パス:child::body/child::p【注意】pを含む相対パスは、起点の取り方により、上記以外にもいろいろ書けます。属性ノードも指定できます。軸から書くとき、例えば次のようになります。省略記法では@になります。テキストノードは次のように指定できます。絶対パス:/child::doc/child::body/child::p/child::text()相対パス:child::body/child::p/text()すべての子要素ノードを表すときは次のようにも書けます。絶対パス:/child::doc/child::body/child::*相対パス:child::body/child::*ここで述べたロケーションパスは式の構成要素となります(本書3.4.4)。他にパタン(本書3.7.1)としてのパスもあります。Kayさんの本によれば、第一と第二ではパスの意味合いが違うようです。なんども書きますが、本書はXSLTやXPathそのものを詳しく学ぶ本ではありません。【ご注意】筆者はXSLTを勉強中です。ここに書いた内容は、資料を調べながら正確を期していますが、間違いを含んでいる可能性もありますので、ご注意ください。([1])はXPathでは7つのノードが定義されている、と説明しました。このうち重要なのは、ルートノード、要素ノード、属性ノード、テキストノードです。この4種類のノードについてもう少し詳しく見てみましょう。次のようなXML文書があったとします。このXMLの文書要素はdocです。you.</p></body></doc>このXMLをXPathのノードツリーとして表しますと次のようになります。child)になるものがあります。ノードツリーで実線でしめした箇所が親子関係になります。子孫(descendant)ノードとはあるノードの子供と子供の子孫ノードです。兄弟(sibling)ノードは同じ親の子供ノードです。親になれるノードはルートノードと要素ノードのみです。子供になれるノードは要素ノードとテキストノードです。ルートノードは最上位ですので親をもちません。逆にテキストノードは最下位ですので子を持ちません。やっかいなのは属性ノードです。要素には関連する属性があります。要素ノードはそれらの属性ノードの親です。属性ノードは要素の子ではないと規定されています。属性ノードは子を持ちません。属性ノードとして扱われるのは、要素に明示的に指定されているもの、または、DTDでデフォルト値が明示的に規定されているものです。DTDで値が#IMPLEDになっていて要素に指定されていない属性や、xml:lang、xml:spaceのようなある要素に指定されているとき、その子孫に継承することになっている属性は、その子孫では属性ノードとして扱われません。テキストノードは、要素の内容の文字列をできるだけ長くなるように結合したものです。従って、テキストノードには、直前・直後の兄弟はありません。要素ノードの文字列値とは、要素ノードの子孫であるテキストノードを、XML文書に現れる順に結合したものです。ルートノードの文字列置はXML文書のすべてのテキストです。XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う先月『スタイルシート開発の基礎』[1]という本を出版しました。この本は、副題に「XMLとFOで簡単な本を作ってみよう」とあるとおりXSLTの実践学習本です。現在、弊社の社内でも、初心者が集まって、この本を使ってXSLTの学習をはじめたところです[2]。私もメンバーの一人です。『スタイルシート開発の基礎』のはじめにには「XSLT/XPathの知識はない」人が本書の対象とあります。私もXSLTを本格的に学ぶのは初めてですので、本書の想定読者にあてはまりそうです。素直に読めば、この本だけで理解できるのかもしれませんが、折角ですので、他の参考資料や仕様書をにらみ合わせて楽しみながらお勉強。そこで、折角学んだことを整理して、紹介したいと思います。ご存知の方には、初歩的なお話と思いますが、『スタイルシート開発の基礎』の補足として役立てていただけるかもしれません。資料としては次を見ています。2015)[4]さて、今回勉強し始めて知ったのですが、整形式XMLのツリーモデルとXSLT/XPathのツリーモデルはまったく違うんですね。XML1.0では、整形式XML文書はルートが文書の実体ツリーの起点であり、XMLプロセサはルートから処理を始めます。見ますと、ルートまたは文書要素と呼ばれる要素が唯一あるとされています。ルート要素は他の要素の内容になりません(つまり親を持ちません)が、他の要素は親を持ちます[5]。整形式XML文書はルート要素(文書要素)を起点とする要素のツリー構造になります。XPathのデータモデルは、ノードという概念が中核です。ノードの種類として次の7つがあります。ためのコメント、プロローグの中の文書要素の後のコメントノードがある。Model)を見ますと、XSLTでは、ソース文書、スタイルシート、結果文書に同じデータモデルを使います。それらはXPathのデータモデルを基本として、少しだけ変更したものです。・整形式のソースXML文書を読み込んでソースツリーを構築するときは、ルートノードの下にテキストノードはなく、唯一の要素ノードを子として持ちます。DOMなどの他の方法でソースツリーを作るときは、ソースツリーに対する制約は結果ツリー同様に緩められます。・文書スタイルシートのツリーを構築するときは処理命令とコメントノードを無視します。・結果ツリーでは、ルートノードへの制約が緩められており、子供として要素ノードを含む、任意のノードの系列をもつことができます。これにより、整形式XMLでない出力を作ることができます。XSLTでは整形式でないようなソースXMLでも処理できそうです[5]。