カテゴリー別アーカイブ: 構造化文書

AH Formatter 機能のご紹介:axf:border-wave-form

AH Formatter V6.3』では、border-style=”wave” の形状(波長と線幅)を axf:border-wave-form で指定できるようになりました。
axf:border-wave-form / CSS -ah-border-wave-form(オンラインマニュアル)

AH Formatter 組版例
– axf:border-wave-form を利用した組版例 –

『AH Formatter』のサンプルページには、
本機能が確認できるサンプル「波枠線と形状の指定例(border-style=”wave”)」を掲載しております。
オンラインマニュアルと併せてご覧ください。

『AH Formatter』の評価版は次のページよりお申し込みいただけます。ご興味のある方は是非お試しください。
AH Formatter 評価版のお申し込み

弊社ではご検討中のお客様向けに技術相談会を行っております。お気軽にお問い合わせください。
アンテナハウス システム製品技術相談会


CSS組版はどこまでいけるだろうか?

表題に関して、最近、参考になった話題をひとつ紹介します。併せて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


Server Based Converter の活用法

■ Antenna House Formatter と組み合わせた文書配信システム

Server Based Converter は、Microsoft Office 文書だけではなく、PDFからも画像、SVG, Flash といった形式のファイルを生成できます。企業ユーザ様、特にグローバル企業では、マニュアルを製作するときに、DITA という規格によって XML 文書を作り、それから PDF を生成することが行われています。

DITA 規格の XML 文書から PDF を生成する際に、欧米のグローバル企業からも非常に高い評価を得ている Antenna House Formatter を使います。こうして出来上がった PDF は、Server Based Converter で、さまざま形式に変換して配信することができます。

PC に配信する場合は、PDF のままで配信できますが、モバイル端末、携帯電話では、PDF が表示できない場合があります。また、PDF が表示できるスマートフォンでも、画像や SVG, Flash といった形式が都合がいい場合があります。その場合、端末の特性、能力に合わせて、画像、SVG、Flash に変換することで、文書を配信するのです。

システムのイメージは、
サーバベース・コンバーター 活用例
にある
携帯電話閲覧用コンバータ
です。

実際に、このように Antenna House Formatter と Server Based Converter を組み合わせて、数多くの PDF を生成し、生成された PDF から必要な部分を抜き出し、Server Based Converter で変換して、毎日、数千ページものページを、配信するシステムを構築しているお客様がいらっしゃいます。

Antenna House Formatter に関する詳しい情報は、
Antenna House Formatter
をご覧ください。

アンテナハウスでは、DITA に関するサービスやコンサルティングも行っています。
詳しくは、
DITA
をご覧ください。

〒103-0004
東京都中央区東日本橋2-1-6 東日本橋藤和ビル5F
アンテナハウス株式会社
◆ご購入に関するお問い合わせ(祝日を除く月~金曜日9:30~18:00)
TEL : 03-5829-9021
FAX : 03-5829-9023
E-mail: sis@antenna.co.jp
URL : http://www.antenna.co.jp/

Server Based Converter は、Microsoft Office, PDF などのファイルを、PDF, Flash, SVG, 各種画像形式にダイレクトに変換する変換エンジンです。 ダイレクト変換の意味は、たとえば、Microsoft Office がない環境でも、ファイルさえあれば、それをダイレクトに内容を見える形式に変換できるのです。ダイレクト変換には、Microsoft Office のライセンスも不要です。
Server Based Converter は、ダイレクト変換というユニークさが評価され、多くのウェブサービス、パブリッククラウド、プライベートクラウドなどで利用されています。

Server Based Converter に関する詳しい情報は、
Server Based Converter
を、ぜひ、ご覧ください。

評価版もご用意しております。
サーバベース・コンバーター 評価版のお申し込み
から、お申し込みください。


Comtech DITA IA ワークショップに参加して

先日、先輩諸兄に混じってComtech 社のIA (インフォメーション・アーキテクト)ワークショップに参加してきました。ワークショップの報告はこれで4度目になりますが、それでもネタが尽きないくらい、DITA にとどまらない知見を得られるほどの濃い内容でした。

先日の記事 でも紹介されていますが、ワークショップでは「ユーザーゴールはどこにあるのか考えろ」という事が強調されていました。「なるほど」と思うと同時にいざ考えてみると、日常の業務(訪問先・展示会でのお客様への製品説明、DITA の Web ページの作成等)で『ユーザーゴール』を(講師の JoAnn Hackos 博士と Dawn Stevens さんが強調していた程には)意識していなかったのではないか、と考えています。

身近な例で考えてみます。お客様の目的、つまり『ユーザーゴール』が「チョコレートケーキを買うこと」で、ケーキの販売店に向かったとします。普通に考えればケーキの販売店は、お客様にチョコレートケーキを買って頂くのが普通です。もしチョコレートケーキがないのであれば、謝罪した上で別の商品を推薦すればいいでしょう。
ですが、ここで販売店がお客様に対して無理やりチーズケーキを買うように進めたらどうなるでしょうか。おそらくお客様は別の店に行くか、仮にチーズケーキを買ってもらえたとしてもお客様の満足度は低いものになります。最悪の場合、悪い評判が広まって販売店の経営に影響することにもなりかねません。

「そんなの当たり前だろう」という声が聞こえてくるようですが、よくよく考えてみると「チョコレートケーキを買いたいお客様にチーズケーキを売りつける」ようなことをしてしまっている場合があるのではないか、というのが私の正直な思いです。今回のワークショップは、IA の知識・技術習得のみならず、日頃の業務について色々と考えさせられる機会ともなりました。

今後、アンテナハウスでは日本における DITA 推進を図るべく、Comtech 社より継承した技術を基に教育コンサルティング活動を行ってまいります。DITA 導入企業のみならず、導入企業様のドキュメントを使用するユーザー様の『ユーザーゴール』も達成できるよう、努力していく所存です。


Comtech DITA IA 育成ワークショップに参加

すでに このブログ にも書かれていますが、7月4日から5日間 Comtech DITA IA 育成ワークショップが開催され私も参加しました。 あまりに濃い内容で、まだまだ消化しきれていませんが、参加して良かったです。

Comtech DITA IA

講義の様子

ここで何度も言われたことは「ユーザーゴールはどこにあるのか考えろ」ということです。
独りよがりになってはいないか? ユーザーは本当にそのようなマニュアルを読みたがっているのか? 誰も読まないであろう「前書き」の内容はそのままでいいのか? というようなことを考えなければいけない、ということを重ねて言っていました。

特に印象的だったのは DITA 導入に必要な準備期間はどれくらいか、というところです。
私は個人的には12ヶ月は必要だと考えています。それ未満だと情報再利用の戦略をうまく立てることができないのではないかと感じているからです。
コムテック社の考えでは「(いろいろなケースがあるけれども)典型的な例としては15ヶ月」とのことです。
「 6ヶ月で導入したいというユーザーもいるが、このようなとき、どのようにユーザーと接すればいいのか?」と質問したところ「やり直すリスクを背負う覚悟があるのか、と問いただす必要はある」との答えでした。

DITA 導入は簡単ではありませんが、時間をかければそれなりの結果は得られるはずだと信じています。


Comtech DITA IA 育成ワークショップを開催しました (その2)

講義も終盤になりますと、お二人が日本にいる間に、またプロの通訳者がいる間にと質疑応答が絶えません。それならばお昼もご一緒して時間を有効にと、大変熱い時間を過ごしました。また参加されたパートナー会社より、ぜひアドバンスクラスのワークショップを開催してほしいとの要望が届いています。今の日本における DITA 分野でまさに必要としていたワークショップであったと言えると思います。

Comtech DITA IA

講義の様子

Comtech Service, Inc. はコロラド州デンバーに位置するコンテンツ管理と情報デザインを扱う会社で、JoAnn Hackos博士が代表を務めています。また、JoAnn Hackos さんはコンテンツ管理と情報開発の実践に焦点を当てた会員組織 CIDM(Center for Information-Development and Management ) を主宰。年3回、DITA North America 、Best Practice 、そして DITA Europe を開催しています。

アンテナハウス(株)日本と Comtech Service, Inc. は、2015年12月にパートナー契約を締結し、アンテナハウスは ワークショップシリーズ:情報モデリングワークショップを日本語で、日本国内の顧客に教える権利を得ました。そして Comtech Service, Inc. は日本国内で情報モデリングのワークショップを行うのに必要なスキルをアンテナハウスに提供します。

今回のワークショップで得た知識を元に、更に勉強して、アンテナハウスとパートナーは Comtech 社の技術を継承し、今度は私たちが Comtech 社にならって日本における DITA 推進を図るべく、教育コンサルティング活動を行ってまいります。DITA 導入をお考えの企業様、ぜひお声をかけてください。きっとお手伝いできる事があると思います。

アンテナハウス海外サイト
http://www.antennahouse.com/
http://rainbowpdf.com/

<< Comtech DITA IA 育成ワークショップを開催しました(その1)


Comtech DITA IA 育成ワークショップを開催しました(その1)

先週7月4日から5日間、Comtech Service社 より講師をお招きし、IA(情報アーキテクト)育成ワークショップを開催致しました。そしてトピックベースオーサリングのための情報モデリングについてみっちり講義をしていただきました。

Comtech IA

講義の様子

講義は JoAnn Hackos 博士と Dawn Stevens さんの2名と、逐次通訳者2名で10時から6時まで、行われました。講義内容は大変に有意義なもので、高度の知識を得ることができました。このワークショップは、IA(情報アーキテクト)の養成を目的としているので、お客様から依頼を受けた時に既存の文書の情報モデルを作成することができるよう、常にユーザーゴールを意識し、講義をしてくださいました。

また実際に与えられた文書を、聴講者がグループに分かれて、コンテンツをタイトル、要約文、前提条件、Task のコンテクスト、ステップ、後要件にあてはめる作業を行ったり、また、ホワイトボード、フリップチャートを使って、講義を聴くのみではなく、コンテンツの定義付けを自分たちが考え、書き出すことで、より理解を深めることができたと思います。

興味深かった事は、グループ別で行ったワークショップの結果がグループによって全く違ったことであり、これに対し、正解はどれですということが講師より示されなかった事。つまり、その企業にとって何が一番適切か、歩み寄って決めていく必要があるということを学ばせていただきました。

5日間で学んだテーマは次の内容でした。

● DITA 導入における次の分野での情報モデルの実践方法。

  • 情報タイプ
  • コンテンツ単位とインライン要素
  • 文書構造とマップストラテジー
  • リンクストラテジー
  • コンテンツ管理
  • 再利用ストラテジー
  • メタデータ

● 必要とされる情報が最大限に保障されるよう、異なるチーム間で情報を共有する方法。

● 双方歩み寄って円滑に妥協案を推進し、アプローチの異なるチーム間の問題を解決する方法。

● DITA 1.3についての現時点の情報を公開し、どういったところに取り入れるべきか、推奨されるテーマ。

● オーサリング処理過程を円滑に行うために、どのようなオーサリングテンプレートを開発すべきか。

● 執筆チームが情報モデルを固守するために必要な DITA 制約を学習。適所に制約があることで、執筆者は、現在の文脈内でサポートされていない要素または属性を選ぶことができず、要素に掛かっている制限を理解し、また、トピックが無効であれば、エラーが訂正されるまで処理できないことを理解。

● 顧客の情報開発要件をサポートするのに最適で、最も必要とされる DITA 特殊化の理解。

● 共通のオーサリングガイドラインを実施するのに役立つスキマトロン規則。情報モデルと制作ガイドラインに記述されている実践方法に執筆者が従えるように、スキマトロン規則は執筆者にガイダンスを提供することの理解。

明日もこのワークショップについてお伝えします。

アンテナハウス海外サイト
http://www.antennahouse.com/
http://rainbowpdf.com/

Comtech DITA IA 育成ワークショップを開催しました(その2) >>


XSLTを学ぶ (11)論理値(Boolean)と関連する基本的な関数のいくつか

第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に変換されます。
・論理値の真は1に変換され、論理値の偽は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のツリーモデルではルートの意味が違う


XSLTを学ぶ (10)式によるノード集合の作成、ノード集合の和集合、フィルター式

前回[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のツリーモデルではルートの意味が違う


XSLTを学ぶ(9) ステップの文法を追求する-述部(Predicates)と式

第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

ロケーションパスについては第3回[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回を参照してください。

【広告】★AH Formatter XML関連出版物の紹介

次回:
XSLTを学ぶ (10)式によるノード集合の作成、ノード集合の和集合、フィルター式

前回:
XSLTを学ぶ(8)ステップの文法を追求する-NodeTest

初回:
XSLTを学ぶ(1)XMLのツリーモデルとXPath/XSLTのツリーモデルではルートの意味が違う


Pages: Prev 1 2 3 4 5 6 7 8 9 10 Next