『AH Formatter V6.3』では、<fo:flow> 直下に <fo:page-sequence> を記述して入れ子にできるように拡張されました。
→ 入れ子の <fo:page-sequence>（オンラインマニュアル）
また、<fo:flow> を省略した空の <fo-page-sequence> が許容されようになりました。
『AH Formatter』のサンプルページには、
本機能が確認できるサンプル「fo:page-sequence の入れ子と空の fo:page-sequence の設定例（fo:page-sequence）」を掲載しております。
オンラインマニュアルと併せてご覧ください。
『AH Formatter』の評価版は次のページよりお申し込みいただけます。ご興味のある方は是非お試しください。
→ AH Formatter 評価版のお申し込み
弊社ではご検討中のお客様向けに技術相談会を行っております。お気軽にお問い合わせください。
→ アンテナハウス システム製品技術相談会
『AH Formatter V6.3』では、border-style=”wave” の形状（波長と線幅）を axf:border-wave-form で指定できるようになりました。
→ axf:border-wave-form / CSS -ah-border-wave-form（オンラインマニュアル）
– axf:border-wave-form を利用した組版例 –
『AH Formatter』のサンプルページには、
本機能が確認できるサンプル「波枠線と形状の指定例（border-style=”wave”）」を掲載しております。
オンラインマニュアルと併せてご覧ください。
『AH Formatter』の評価版は次のページよりお申し込みいただけます。ご興味のある方は是非お試しください。
→ AH Formatter 評価版のお申し込み
弊社ではご検討中のお客様向けに技術相談会を行っております。お気軽にお問い合わせください。
→ アンテナハウス システム製品技術相談会
表題に関して、最近、参考になった話題をひとつ紹介します。併せてCSS組版の未来を少し考えます。
去る8月1日に、DITAユーザーズというメーリングリストに「CSS3 vs XSL-FO for PDF output」[1]という質問が投稿されました。
投稿者は、現在、SDL＋AH XSL FormatterでDITAからPDFを作成している[2]とのことですが、次のようなストレートな質問をされました。
「XSL-FOは古くて頑丈です。CSSはひとあたりが良くて単純で、スタイルをWebと共有するのも簡単です。XSL-FOを使い続けることに未来がありますか？ それともCSSに全面移行するべきでしょうか？」
XML組版といえば、ここ十数年XSL-FO一辺倒でしたが、CSSで組版できることへのアピールが増えてきました。製品もいくつかあります（弊社でも出しております）。このところ、DITAコミュニティでもCSS組版の話題が散見されるようになってきました。
この質問は、DITAユーザーズというディープなXMLユーザーのコミュニティで寄せられたもので、参加者は例えば書籍の組版をする人たちとは異なっています。しかし、投稿者の疑問はDITAユーザーに限らず、XMLやHTMLを使う人が共有されているものでしょう。
DITAユーザーズでは、直ちにクールな回答がいくつか寄せられました。
その中でもEliot Kimber氏の意見が参考になりました。Kimber氏は3月に来日されたのですが、その際に聞いたところ、「いま一番関心があるのはVivlioStylesのCSS組版」とのことで、大きな期待を寄せていました。そして、5月にサンフランシスコで開催されたCSSワーキング・グループのF2F会議にオブザーバーとして自ら参加したとのことです。氏のメーリングリストの意見を要約すると、次のようになります。
1． VivlioStyles、Prince、Antenna HouseのCSS組版は歩みを進めているが、CSSの印刷向けの機能が標準化されていないので、必然的にベンダー特有になっている。
2．CSS仕様に印刷向けの機能を入れることには、ブラウザベンダーが団結して反対しているので、標準化は難しそうだ。
3．CSSとXSL-FOの機能を比較してみれば、CSSではできないことがいろいろあることがわかるだろう。これは、だれも行ったことはなさそうだ。
4．CSSにはバージョンXというものはなく、モジュール毎に進化している。
5．ページ組版に特化したHTMLを作り、ブラウザのCSSとJavaScriptでそれを組版するのは確かに可能である。しかし、ブラウザとCSSが両方共進化している中で、それを実装してメンテナンスするのは容易ではないだろう。
氏の結論としては、予測可能な将来において、DITAコミュニティがXSL-FOに代えてCSS組版を採用するのは難しい、ということです。
CSSを組版に使うための根本の仕様は「CSS Paged Media Module Level 3」[4]です。これは1999年に「Paged Media Properties for CSS3」として最初のドラフトができてから何回となく改訂されています。最新は2013年3月版ですが、まだワーキングドラフトの段階から進んでいません。次のバージョンもEditor’s Draftとして用意されているところです。
新しいものを試してみたいという人はどこの世界にも一定数はいると思います。個人で試す範囲では、仕様がどうであろうとあまり関係は無いでしょう。しかし、その一線を超えて、実務の世界で積極的に使うにはまずCSS組版の仕様が勧告になることが前提になるでしょう。
現在のCSS組版は、各社それぞれが自己流の土台の上に築いている、というのが実態です。弊社は2006年からCSS組版の開発に取り組み、2009年に初版をリリースしました。CSS組版仕様の進展は、2006年に予想したよりも、残念ながら、遙かに遅かったと言わざるを得ません。その理由の一つに、CSS組版は、CSSの本流ではない、ということがあるのかもしれません。
弊社の立場としましては、CSSの仕様が勧告案（Candidate Recommendation）に進むのを待ちながら、着実に実装を進めていきたいと考えているところです。
[1] CSS3 vs XSL-FO for PDF output
[2] 同：Message 3
[3] 同：Message 7
[4] CSS Paged Media Module Level 3 W3C Working Draft 14 March 2013
第9回[1]では、式の生成規則を辿っている途中に幾つかわからない項目が出てきました。その一つは、ノード集合に対する演算の扱いです。ここでは論理演算や比較の演算におけるノード集合の扱いを調べてみます。
論理値（Booleans）[2]。
or式は左辺と右辺の両方のオペランドをboolean関数と同じように論理値に変換して評価します。どちらかが真であれば真となり、そうでないとき偽となります。boolean関数はXPathで規定するコア関数の一種であり、引数を論理値に変換します。ノード集合は空でないとき真となります（詳しくは下に紹介しました）。
and式は両方のオペランドをboolean関数と同じように論理値に変換して評価します。両方が真であれば真となります。そうでないとき偽となります。
第9回の規則[23]の関係式（RelationalExpr）すなわち <=、<、>=、>、および等価式（EqualityExpr）すなわち=または!=、は左辺と右辺の二つのオペランドを次のように比較します。（ノード集合が関係するときだけを取り上げてみます。）
ノード集合同士を比較するときは、最初のノード集合と二つ目のノード集合の中に、ノードの文字列値同士を比較したときに真になるようなノードが含まれている時に限り、その比較は真になります。
ノード集合と数値の比較では、ノードの文字列値をnumber関数で数値に変換し、数値同士として比較します。ノード集合の中に、数値同士を比較して真になるようなノードが含まれていれば、比較が真になります。
ノード集合と文字列値の比較では、ノードの文字列値と他方の文字列値を比較し、文字列値同士を比較して真になるようなノードが含まれていれば、比較が真になります。
ノード集合と論理値の比較では、ノード集合をboolean関数で論理値にして、他方の論理値と比較します。
XPathには基本的な関数が規定されています。次に今日出てきた関数を紹介します。
boolean関数[3]
形式: boolean boolean(object)
boolean関数は引数を次のように論理値に変換します。
・数値は、ポジティブゼロでもネガティブゼロでもなく、NaN（Not-a-Number:数値でない）でもないとき真となります。
・ノード集合は空でないとき真となります。
・文字列は、長さがゼロでないとき真となります。
・四つの基本型以外のオブジェクトはその型依存の方法で論理値に変換されます。
number関数[4]
形式: number number(object?)
number関数は引数を次のように論理値に変換します。
・数値の後が空白で、前にオプションのマイナス記号、さらにその前のオプションの空白から構成される文字列は、その文字列によって表現される数学的値に最も近いIEEE 754数に変換されます。それ以外の文字列はNaNに変換されます。
・論理値の真は１に変換され、論理値の偽は0に変換されます。
・ノード集合は最初にstring関数を使ったように文字列に変換され、次いで引数が文字列のときと同様に数値に変換されます。
・四つの基本型以外のオブジェクトはその型依存の方法で数値に変換されます。
もし、引数が省略されたときは、既定値として文脈ノードのみから成るノード集合が使われます。
string関数[5]
形式： string string(object?)
文字列関数はオブジェクトを次のように文字列に変換します。
・ノード集合はノード集合の中で文書順で最初のノードの文字列値を返すことで文字列値に変換されます。ノード集合が空のときは空文字列が返されます。
・数値は次のように文字列に変換されます。
・NaNは文字列NaNに変換されます。
・ポジティブゼロは文字列0に変換されます。
・ネガティブゼロは文字列0に変換されます。
・ポジティブな無限大は文字列Infinityに変換されます。
・ネガティブな無限大は文字列-Infinityに変換されます。
・数値が整数型のときは、小数点や先行するゼロのない十進数で表現されます。数値がマイナスのときは、マイナス記号が先行します。
・整数でないときは、小数点を含み、小数点の前に少なくとも1個の十進数があり、小数点の後に少なくとも1個の十進数があり、マイナスのときは、マイナス記号が先行する形式となります。不要な先行するゼロがあってはならず、少数点の後には他のIEEE 754と区別するのに必要なだけの数値がなければなりません。
・論理値の偽は文字列falseになり、論理値の真は文字列trueになります。
・四つの基本型以外のオブジェクトはその型依存の方法で文字列に変換されます。
もし、引数が省略されたときは、既定値として文脈ノードのみから成るノード集合が使われます。
なお、string 関数は表示用に整形するために用意されているものではありません。整形にはXSLTのxsl:number要素を使います。
[1] XSLTを学ぶ（9）ステップの文法を追求する-述部（Predicates）と式
[2] 3.4 Booleans
[3] boolean関数
[4] number関数
[5] string関数
前回:
XSLTを学ぶ（10）式によるノード集合の作成、ノード集合の和集合、フィルター式
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
前回[1]の定義[19]にあるようにロケーションパスをパス式として使うことができます。そのときパス式はロケーションパスによって選択したノードの集合を返します。
ノードの集合は、’|’オペレータで和集合にできます（前回の定義[18]）。定義[18]だけでは分かりませんが、XPath仕様書[2]には「オペランドはノード集合でなければならない」とされています。
以上により、式の中では、ロケーションパスでノード集合を作り、ノード集合の和集合を作ることができます。
定義[19]では、パス式の生成方法にFilterExpr（フィルター式）を使う方法もあります。フィルター式には、FilterExprの後に述部（Predicate）を付けるものがあります。このときの述部は「ロケーションパスで使われるときと同様に式をフィルターするために使われる。フィルターされる式がノード集合にならなければエラーとなる。述部は、ノード集合をchild軸に関してフィルターする」とされています。
つまり、パス式がFilterExpr Predicateで生成されるとき、FilterExprはノード集合でなければなりません。
FilterExprは基本式（PrimaryExpr）で構成されます。基本式の中でノード集合を生成できるのは、VariableReference（変数参照）、()で囲った式、FunctionCallです。
[15] PrimaryExpr ::= VariableReference
| ‘(‘ Expr ‘)’
| Literal
| Number
| FunctionCall
前回述部に二種類あることに注意しましたが、この違いは()で囲った式と組み合わせると明確になります。
XML文書中で、例えばpが要素ノードであるとき、パス式p（child::p）自体は基本式ではありませんが、(p)は基本式です。
述部[]と組み合わせたとき、次の二種類となります。
(1) p[1]はステップであり、ロケーションパスです。
(2) それに対して、(p)[1]はフィルター式です。
この場合は違いは明確ではありませんが、次のような場合は違いが明確になります。
preceding::foo[1] と(preceding::foo)[1]の比較
preceding軸の定義は次のようになっています。「起点ノードと同じ文書の中で、文書順で起点ノードの前にあるすべてのノードを含みます。但し、先祖と属性ノードと名前空間ノードは除外します。」(XPath 2.2 Axes)
軸には文書順の軸と、逆文書順の軸があります。起点ノードと起点ノードよりも文書の中で後のノードを含む軸は文書順の軸です。起点ノードと起点ノードよりも文書の中で前方のノードを含む軸は逆順の軸です。preceding軸は、逆順の軸に属します（XPath 2.4 Predicates）。
ノード集合のメンバーの軸に関する近接位置（proximity position）とは、文書順の軸ではメンバーを文書順に並べたときの順番、逆順の軸では文書で出現する順序の逆に並べたときの順番です。
そして、述部[]はノード集合を絞り込んで新しいノード集合を作ります。述部の中の式は、ノード集合の各ノードを起点のノードとし、近接位置を文脈位置として評価します。評価結果が真であれば、そのノードは新しいノード集合に含まれます。
そこで、preceding::foo[1] は起点ノードの先行ノードであるfoo要素ノードを文書の逆順にたどり、そのときの1番目のfoo要素ノードを選択します。
(preceding::foo)[1] は[1]に適用する軸はchild軸なので先行ノードであるfoo要素の集合の最初のノードを選択します[3]。
[1] XSLTを学ぶ（9）ステップの文法を追求する-述部（Predicates）と式
[2] XML Path Language (XPath) Version 1.0
[3] 3.3 Node-setsには、このように書かれています。ちょっと強弁の印象がありますが。
【広告】
Formatter（XML）関連技術書、PDF関連書籍ご紹介
次回:
XSLTを学ぶ （11）論理値（Boolean）と関連する基本的な関数のいくつか
前回:
XSLTを学ぶ（9）ステップの文法を追求する-述部（Predicates）と式
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
第3回[1]からパスの文法を調べてきました。パスの重要な構成要素にステップがあり、ステップ（省略）は軸、ノードテスト、述部（オプションなので必須ではない）から構成されることを調べました。
ステップの最後の構成部品はオプションの述部です。第6回[2]で見ましたが、述部は式を[]で囲った形式です。
式とはどんなものでしょうか？ まず、XPathの式の生成規則[3]をトップから辿ってみます。
スタートは定義の[14]ですが、式Exprとは、OrExprです。[21]orExprはAndExprを’or’でつなげたものです。そして、[22]AndExprとは、EqualityExprを’and’でつなげたものです。[23]EqualityExprは、RelationalExprを’=’でつなげたものまたは’!=’でつなげたもの。[24]RelationalExprは、AdditiveExprを'<‘ ‘>”<=’ ‘>=’でつなげたもののようです。つまり、このあたりまでは、式はAdditiveExpr（加算式）の論理演算ということになります。
[14] Expr ::= OrExpr
[21] OrExpr ::= AndExpr | OrExpr ‘or’ AndExpr
[22] AndExpr ::= EqualityExpr | AndExpr ‘and’ EqualityExpr
[23] EqualityExpr ::= RelationalExpr
| EqualityExpr ‘=’ RelationalExpr
| EqualityExpr ‘!=’ RelationalExpr
[24] RelationalExpr ::= AdditiveExpr
| RelationalExpr ‘<‘ AdditiveExpr | RelationalExpr ‘>’ AdditiveExpr
| RelationalExpr ‘<=’ AdditiveExpr | RelationalExpr ‘>=’ AdditiveExpr
ということで、さらにAdditiveExprとは何かを見てみます。[25]ではAdditiveExprは、MultiplicativeExprを’+’または’-‘でつなげたものです。
[25] AdditiveExpr ::= MultiplicativeExpr
| AdditiveExpr ‘+’ MultiplicativeExpr
| AdditiveExpr ‘-‘ MultiplicativeExpr
[26]ではMultiplicativeExprとは、UnaryExpr（単項式）、またはMultiplicativeExprにUnaryExprを掛けた（’*’）、またはMultiplicativeExprをUnaryExprで割り算（’div’）、剰余算（’mod’）したものです。
[26] MultiplicativeExpr ::= UnaryExpr
| MultiplicativeExpr MultiplyOperator UnaryExpr
| MultiplicativeExpr ‘div’ UnaryExpr
| MultiplicativeExpr ‘mod’ UnaryExpr
[34] MultiplyOperator ::= ‘*’
UnaryExprは、UnionExprまたはその前にマイナス記号（’-‘）をつけたもの。
[27] UnaryExpr ::= UnionExpr | ‘-‘ UnaryExpr
UnionExprは、ひとつのPathExpr（パス式）、またはそれを’|’で結合したものです。
[18] UnionExpr ::= PathExpr| UnionExpr ‘|’ PathExpr
PathExpr式は、LocationPath（ロケーションパス）、またはFilterExprまたは、FilterExprと相対ロケーションパスを’/’、’//’ で結合したものです。
[19] PathExpr ::= LocationPath
| FilterExpr
| FilterExpr ‘/’ RelativeLocationPath
| FilterExpr ‘//’ RelativeLocationPath
ロケーションパスについては第３回[2]ですでに学びましたが、XMLツリーのノードを選択するものです。ノードの選択結果はノードの集まり（ノード集合）ですが、これに対して、掛け算（’*’）、割り算（’div’）、剰余算（’mod’）、足し算（’+’）、引き算（’-‘）、比較などの演算をするのは少し不思議な気もします。これは後ほど調べてみることにします（[5]）。
FilterExprの方は、PrimaryExprまたはPrimaryExprに述部（Predicate）を付けたものとなります。ここに出てくる述部はFilterExpr Predicateのように使われますが、ステップの中で出てくる述部の使われ方はAxisSpecifier NodeTest Predicate*です。この2種類の述部の使われ方の違いはなんでしょうか？ これも後ほど調べてみましょう（[4]）。
PrimaryExprは、VariableReference（変数参照）、式を()で囲ったもの、リテラル、数値、FunctionCall（関数呼び出し）のどれかです。ですので、式には数置の四則演算も表現したものも含まれます（よく知っている初歩的な数式も含まれるということで一安心です）。
[20] FilterExpr ::= PrimaryExpr
| FilterExpr Predicate
[15] PrimaryExpr ::= VariableReference
| ‘(‘ Expr ‘)’
| Literal
| Number
| FunctionCall
最も単純なケースでは、一つの数値（Number）だけでも式となります。例えば、次のように下から辿ってみます。
(1) PrimaryExprがNumber:100
(2) FilterExprがPrimaryExpr:100
(3) PathExprがFilterExpr:100
(4) UnionExprがPathExpr:100
(5) UnaryExprがUnionExpr :100
(6) MultiplicativeExprがUnaryExpr:100
(7) AdditiveExprがMultiplicativeExpr:100
(8) RelationalExprがAdditiveExpr :100
(9) EqualityExprがRelationalExpr :100
(10) AndExprがEqualityExpr:100
(11) OrExprがAndExpr:100
(12) ExprがOrExpr:100
ということで、述部に[100]と書くことができます。
まとめますと、述部（[]内）には式を書きますが、式としてはロケーションパスを書くこともできますし、また、数値、変数、関数呼び出し、数式を書くこともできる、ということになります。
途中で、いろいろわからない言葉が出てきていますので、次回以降、もう少し詳しく調べてみます。
[1] XSLTを学ぶ （3） パスとは
[2] XSLTを学ぶ （6） ステップの文法を追求するの[8]、[9]式
[3] 3 Expressions
[4] 次回（第10回）のpreceding::foo[1] と(preceding::foo)[1]の比較 の項を参照してください。
[5] ノード集合の論理演算、比較演算については第11回を参照してください。
次回:
XSLTを学ぶ （10）式によるノード集合の作成、ノード集合の和集合、フィルター式
前回:
XSLTを学ぶ（8）ステップの文法を追求する-NodeTest
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
前回は軸について調べましたので、今回はNodeTestを調べてみます。XPath仕様では、NodeTestを次のように規定しています[1]。
[7] NodeTest ::= NameTest | NodeType ‘(‘ ‘)’ | ‘processing-instruction’ ‘(‘ Literal ‘)’
[37] NameTest ::= ‘*’ | NCName ‘:’ ‘*’ |QName
[38] NodeType ::= ‘comment’|’text’|’processing-instruction’|’node’
まず主ノードタイプを次のように定義します。ステップの文法では軸の指定に続いてNodeTestを記述します。NodeTestでは軸毎に主ノードタイプに該当するノードを選択することになります。
・attribute軸の主ノードタイプは属性
・namespace軸の主ノードタイプは名前空間
・その他の軸の主ノードタイプは要素
文法上は、attribute::text()のような組み合わせができますが、これは無意味なので何も選択しません。
(1) NameTest
NameTestでは要素や属性の名前を指定して一致するものを選択します。
NameTestでは’*’を使えます。’*’は主ノードタイプが何であれすべてのノードに対して真となります。但し、NameTestの前には、軸指定子（AxisSpecifier）が置かれます。軸指定子が省略されないときは、例えば、child::* は起点ノードの子供であるすべての要素ノードを選択します。attribute::*は起点ノードのすべての属性を選択します。
ステップでは軸指定子を省略できます。するとステップは*または@*の形式となります。ステップにおいて*を指定するとchild::*であり、@*とするとAttribute::*です（第6回[3]の[5]と[13]の規定による）。
二番目のNCNameは、名前空間の接頭辞です。接頭辞はXML名前空間の仕様で規定されています[2]。
xmlns:svg=”http://www.w3.org/2000/svg”
という名前空間の宣言があるとしますと、NCNameは’svg’にあたります。svg:*はsvg名前区間にあるすべてのノードを選択し、child::svg:*は文脈ノードの子供でsvg名前空間に属する要素ノードをすべて選択します。
QNameは名前空間接頭辞（オプション）で修飾された名前です。
(2) NodeType ‘(‘ ‘)’
NodeTestは、ノードの種類でノードを選択することもできます。ノードの種類は次の4種類です。
comment()
text()
processing-instruction()
node()
例えば、child::text()は起点ノードの子供のテキストノードを選択します。
comment()はコメントノード、processing-instruction()は処理命令のノードを選択します。
node()は任意の種類のノードを選択します。
ステップで、node()と記述すると、軸を省略したことになり、child::node()を意味します。従って、要素ノードのみを選択します。
[1] 2.3 Node Tests
[2] 3 Declaring Namespaces
[3] XSLTを学ぶ（6）ステップの文法を追求する
次回:
XSLTを学ぶ（9） ステップの文法を追求する-述部（Predicates）と式
前回:
XSLTを学ぶ（7）ステップの文法を追求する-軸とは
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
パスは、ステップを’/’オペレータで結合したものであること、そしてステップは、AxisSpecifier NodeTest Predicate*の形式または省略形で記述されることを前回まで[1]に学びました。
ステップの例として、child::para[position()=1]を取り上げてみます。child::が軸指定子（AxisSpecifier）であり、あるノードを起点とするとき、その起点ノードの子供を選択します[2]。
その後のparaがNodeTestでノードの名前の指定であり、child::paraは、起点ノードの子供で名前がparaのノードを選択します。NodeTestには’*’を使うこともでき、child::*とすると起点ノードの子供であるノードをすべて選択します。
[position()=1]はオプションの述部（Predicate）です。この場合、述部はノード集合の中での最初のノードを選択します。
軸は起点のノードからXML文書のツリーの方向を指定します。第1回[3]で学びましたが、ノードには7種類があり、また、軸の名前にはancestor、ancestor-or-self、attribute、child、descendant、descendant-or-self、following、following-sibling、namespace、parent、preceding、preceding-sibling、selfの13種類があります。
この中でself軸は起点となるノード自身を含みます。起点ノードが要素ノードのとき、self、ancestor、descendant、following、precedingは一つのXML文書の（属性、名前空間を除外して）すべてのノードを網羅します。
例えば、次のようなXML文書を考えてみます。
<!–?xml version=”1.0″?–>
<doc>
<body>
<p s=”man1″>Hello! How are you?</p>
<p s=”man2″><img src=”pic1″/>I am fine, thank you.<img src=”pic2″/></p>
<p s=”man3″>I am fine, thank you.</p>
</body>
</doc>
このXML文書をノードのツリーで表します。仮に起点が二つ目の要素ノードpであるとします。このときself::はpノードです。そこを起点にしてancestor、descendant、following、precedingは次のような関係になります。
上の図では、selfの子供pの属性ノード（src=”pic1″など）は除外しています。第2回[4]で説明しましたように属性ノードは子供（child）にはなりません。XSLT仕様では、decendentは、「childまたはchildの子供である」とされています。従って、属性や（名前空間ノードも）decendentにはなりません[5]。
また、属性や（名前空間ノードも）はprecedenig、followingからも除外されています。
上の図とは異なりますが、もし、属性ノードsrc=”pic1″がselfであった時は、ancestorはその親であるpノードからルートノードまでとなります[6]。しかし、 following-sibling、preceding-siblingは空です。
child、parentについては第2回[4]で説明しました。child軸、parent軸はそれぞれselfノードの子または親です。child軸は複数の子供ノードを含みます。parent軸はあるとしてもひとつの親ノードのみを含みます。
attribute軸、namespace軸はそれぞれselfの属性ノード、名前空間ノードを含みます。
[1] XSLTを学ぶ（3）パスとは、
XSLTを学ぶ（6）ステップの文法を追求する
[2] XPathでは起点ノードを文脈ノードといいます。そして、以下の説明の起点ノードのところは文脈ノードになっています。
[3] XSLTを学ぶ（１）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
[4] XSLTを学ぶ（2）ノードツリーとノードの親子、子孫関係
[5] 2.2 Axes
[6] XPathの仕様の2.2 Axesには、文脈ノードのancestorは、文脈ノードの親（parent）と親の親、以下同じ、から成るとあります。そして、5.3 Attribute Nodesには、要素はそれに付随する属性ノードの親である、と書いてあります。従って、属性ノードのancestorにはその親である要素ノードを選択することになります。
【広告】
次回:
XSLTを学ぶ（8）ステップの文法を追求する-NodeTest
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
第3回（[1]）と前回（[2]）でパスには「式の構成部品としてのパス」（ロケーションパス）と「パターンの記述のためのパス」（パターンパス）の2種類あること、そしてロケーションパスは式の一部でありxsl:要素のselect属性で使われること。パターンパスは、match属性で使われることを説明しました。
パスを構成する文法を調べると、ステップがその基本的な単位になっています。パスはステップを’/’で結合して構成します。
そこで、ステップについてもう少し詳しく調べてみます。
1. ロケーションパスのステップは、XPath仕様[3]で決まっています。第3回でステップの文法の入り口として、次の項を紹介しました。
[4] Step ::= AxisSpecifier NodeTest Predicate* | AbbreviatedStep
ステップは軸の指定子（AxisSpecifier）とノードテスト（NodeTest）とオプション（*）の述部（Predicate）、または、省略形（AbbreviatedStep）から構成します。
ステップの省略形は ‘.’（自分自身、self::node()の省略形）、または’..’（親、parent::node()の省略形）です。
[12] AbbreviatedStep ::= ‘.’ | ‘..’
軸の指定子の定義は、次のようになっています。
[5] AxisSpecifier ::= AxisName ‘::’ | AbbreviatedAxisSpecifier
[6] AxisName ::= ‘ancestor’ | ‘ancestor-or-self’ | ‘attribute’ | ‘child’ | ‘descendant’ | ‘descendant-or-self’ | ‘following’ | ‘following-sibling’ | ‘namespace’ | ‘parent’ | ‘preceding’ | ‘preceding-sibling’ | ‘self’
軸の指定子は、軸の名前（AxisName）と’::’または省略形の軸指定子（AbbreviatedAxisSpecifier）で、軸の名前は’ancestor’から’self’まで13種類あります。
[13] AbbreviatedAxisSpecifier ::= ‘@’?
省略形の軸指定子はなにも指定しないか’@’です。なにも指定しないとデフォルトはchild::です。
@はattribute::の省略形です。その他、’//’は/descendant-or-self::node()/の省略形とされています（規則[11]省略）。
NodeTest以下は次のようになっていますが、次回以降もう少し詳しく調べてみます。
[7] NodeTest ::= NameTest | NodeType ‘(‘ ‘)’ | ‘processing-instruction’ ‘(‘ Literal ‘)’
[37] NameTest ::= ‘*’ | NCName ‘:’ ‘*’ | QName
[38] NodeType ::= ‘comment’ | ‘text’ | ‘processing-instruction’ | ‘node’
NCName、QNameはXML名前空間（[4]）で規定されています。
[8] Predicate ::= ‘[‘ PredicateExpr ‘]’
[9] PredicateExpr ::= Expr
述部は式（Expr）を'[‘ ‘]’で囲ったものです。
2. パターンの構成要素であるステップ（ステップパターン）は、XSLT仕様（[5]）で決まっています。その文法は次の通りです。
[5] StepPattern ::= ChildOrAttributeAxisSpecifier NodeTest Predicate*
[6] ChildOrAttributeAxisSpecifier ::= AbbreviatedAxisSpecifier
| (‘child’ | ‘attribute’) ‘::’
NodeTest、Predicate、AbbreviatedAxisSpecifierはXPathのステップを参照しています。XSLT仕様はXPath仕様を利用して作られていることがよく分かります。
[1] XSLTを学ぶ（3）パスとは
[2] XSLTを学ぶ（5）パターンの記述のためのパス
[3] XML Path Language (XPath) Version 1.0
[4] Namespaces in XML 1.0 (Third Edition)
[5] XSL Transformations (XSLT) Version 1.0
[6] 『スタイルシート開発の基礎』
次回:
XSLTを学ぶ（7）ステップの文法を追求する-軸とは
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
前回[1]は、「式の構成部品としてのパス」を調べてみました。これはXPath仕様[2]で規定されているものです。
もう一つは、「パターンの記述のためのパス」があります。こちらはXSLT仕様[3]で規定されています。本書（『スタイルシート開発の基礎』[4]）では、パターンについては、3.7.1 パタン（p.33）で触れています。しかし、パスの役割についてはあまり詳しく記述されていませんので、仕様書で少し詳しく調べてみます。
式は主にselectの属性の値として設定します。XSLT V1.0ではselect属性は次の要素に定義されています。
xsl:variable
xsl:param
xsl:apply-templates （ノード集合式のみ）
xsl:value-of （文字列式のみ）
xsl:with-param
xsl:sort （文字列式のみ）
xsl:copy-of
xsl:if（論理式のみ）
xsl:when（論理式のみ）
xsl:for-each（ノード集合式のみ）
パターンは、スタイルシート規則（xsl:template）のmatch属性の値として規定されています。これを含めてmatch属性が使えるのは次の三つの要素です。
xsl:template
xsl:key
xsl:number
XSLTのxsl:templateの説明の項（5 Template Rules）にはパターンについて書いてあります。それを読みますと、select属性の式は、主にソース文書から処理の対象とするノードのリストを作るのに使われるのに対して、パターンはノードに適用するテンプレート規則を識別するのに使うという関係のようです。
パターンの構文は、式の構文のサブセットです。具体的には次のようになっています。
[1] Pattern ::= LocationPathPattern
| Pattern ‘|’ LocationPathPattern
パターンは一つのロケーションパスパターンまたは、それを’/’オペレータでつなげたものです。
[2] LocationPathPattern ::= ‘/’ RelativePathPattern?
| IdKeyPattern ((‘/’ | ‘//’) RelativePathPattern)?
| ‘//’? RelativePathPattern
[3] IdKeyPattern ::= ‘id’ ‘(‘ Literal ‘)’
| ‘key’ ‘(‘ Literal ‘,’ Literal ‘)’
IDkeyPatternは式では出てきませんでしたが、IDまたはkeyとなっています。あとは式としてのロケーションパスの生成規則で出てきたもの（第（3）回[5]を参照）と大よそ対応しているようです。
[4] RelativePathPattern ::= StepPattern
| RelativePathPattern ‘/’ StepPattern
| RelativePathPattern ‘//’ StepPattern
[5] StepPattern ::= ChildOrAttributeAxisSpecifier NodeTest Predicate*
[6] ChildOrAttributeAxisSpecifier ::= AbbreviatedAxisSpecifier
| (‘child’ | ‘attribute’) ‘::’
ChildOrAttributeAxisSpecifierは、child軸とattribute軸のみになっています。
[1] XSLTを学ぶ （4） 式の構成部品としてのパスの使い方
[2] XML Path Language (XPath) Version 1.0
[3] XSL Transformations (XSLT) Version 1.0
[4] 『スタイルシート開発の基礎』
[5] XSLTを学ぶ （3） パスとは
前回:
XSLTを学ぶ （4） 式の構成部品としてのパスの使い方
初回:
XSLTを学ぶ（1）XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う
