10月26日から幕張メッセで開催されます、「第７回 クラウドコンピューティング EXPO 秋」に出展いたします。
PDFの作成、加工ライブラリを、クラウドコンピューティングを利用したSaaSによるサービスや、特定のシステムまたは、アプリケーションに組み込み販売頂けるライセンスをご紹介いたします。
| 紹介製品： | 長期署名ライブラリ、Server Based Converter、AH Formatter など |
| 会 期： | 2016年10月26日（水）～2016年10月28日（金） 10:00～18:00（28日のみ17:00まで） |
| 場 所： | 幕張メッセ アンテナハウスブース：４ホール NO：14-10 |
| 詳 細： | http://www.cloud-japan.jp/aki/ |
| お問い合わせ先： | アンテナハウス（株）OEM営業グループ<oem@antenna.co.jp> |
『サーバベース・コンバーター V6.0』最新版はもちろん、アンテナハウスの各種ライブラリー、発売したばかりのデスクトップ製品の最新版などを直接ご覧いただけます。ぜひ、お越しください。
『AH Formatter』では、V6.2 改訂２版よりオーバープリントが指定できるようになりました。
→ axf:overprint / CSS -ah-overprint（オンラインマニュアル）
『AH Formatter』のサンプルFO集には、
本機能が確認できるサンプル「オーバープリントの設定例（axf:overprint）」を掲載しております。
『AH Formatter』は主にバージョンアップのたびに機能強化や新機能の追加を行っています。
“あったら便利な機能” も既に追加されていることがございますので、
お気軽にサポートにお問い合わせください。
未実装の機能であれば、ご要望として承り、今後の開発の参考にさせていただきます。
『AH Formatter』の評価版は次のページよりお申し込みいただけます。ご興味のある方は是非お試しください。
→ AH Formatter 評価版のお申し込み
弊社ではご検討中のお客様向けに技術相談会を行っております。お気軽にお問い合わせください。
→ アンテナハウス システム製品技術相談会
『AH Formatter』のサンプルページでは、
「XSL-FO＆AH Formatter 使いこなし技」と称して、
XSL-FO や『AH Formatter』を使いこなすための便利な小技・裏技を紹介しています。
今のところ次の２例のみですが、
今後 XSL-FO/CSS 及び『AH Formatter』ユーザ様のお役に立つよう増やしてまいります。
・表の泣き別れを float で回避する例
・keep-together.within-page=”always” の指定で改ページされる fo:table-row、fo:list-item のオーバーフローを回避する例
『AH Formatter』の評価版は次のページよりお申し込みいただけます。ご興味のある方は是非お試しください。
→ AH Formatter 評価版のお申し込み
弊社ではご検討中のお客様向けに技術相談会を行っております。お気軽にお問い合わせください。
→ アンテナハウス システム製品技術相談会
『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のツリーモデルではルートの意味が違う
