こんにちは。DITAの話は今日でいったんおしまいにします。
昨日までの４日間で漏れてしまった話題について、軽く紹介しておきます。
■conref
昨日、条件処理を使ってコンテンツの一部を出したり出さなかったりをする方法を紹介しましたが、conrefは他のトピックの中のほんの一部を流用する機能です（フラグメント単位での再利用）。
製品名とかコピーライト表記をひとつのトピックファイルにまとめておいて、それを参照したりするような使い方をします。
■関連テーブル
どのトピックとどのトピックが関連し合っているのかを、それぞれのトピックの中ではなくマップの中に記述することができます。
トピックの中に関連情報を書くこともできますが、そうするとトピック間の関連関係が変更されたとき、トピックをこつこつと変更しなくてはなりません。それはそれで大変なので、マップに追いやってしまおうというわけですね。こうすることでマップだけを修正すればいいことになります。
■keyref
これは参照先をマップで解決しようという機能です。言葉で説明するのは難しいのですが、図式化すると次のようになります。

トピックの中には具体的な参照先は書かないで、マップに書いてしまおうということですね。
この機能は最新のDITA1.2仕様で追加された機能です。一度書いたトピックはできるだけ変更しなくてもいいようにしよう、可変データは可能な限りマップに追いやってしまおう、というDITAの設計思想が感じられます。
■DITA Open Tookit
せっかくマップやトピックが用意できたのに、これをどうやってHTMLやPDFにすればいいんだろう、という疑問がありますよね。大丈夫です。マップやトピックを処理して最終成果物を作ってくれる「DITA Open Tookit」という処理系がすでにあります。オープンソースで誰でも無償で使うことができます。入手先は下記です。
http://sourceforge.net/projects/dita-ot/
Open Toolkitは
　　* トピックファイルや画像などの素材を集める
　　* 条件処理を解決する
　　* conrefやkeyrefを解決する
　　* PDFやHTMLを作る
といったことを自動的にやってくれます。
■期待するレイアウトを実現するには
Open Toolkitを使えばPDFを作ることはできるのですが、あくまでもサンプル程度です。
これを期待したレイアウトにするにはそれなりのカスタマイズが必要になります。具体的にはPDF生成用のXSLTスタイルシートを作らないといけないのですが、弊社ではこのスタイルシート作成を請け負っていますので、ぜひご相談ください。
また、Open Toolkitには標準で自動組版エンジンが付いてくるのですが、正直な話、機能的にいまいちです。特にまじめに日本語組版をしたいということであれば、Antenna House Formatterが必須になります。
■お問い合わせ
DITA導入についてのお問い合わせをお待ちしております。
営業担当：小林(guten@antenna.co.jp)までよろしくお願いいたします。
では、5日間ありがとうございました。
最後に関連情報のリンクを少しだけ
OASIS DITA仕様(英語サイト)
DITA News(英語サイト)
DITAコンソーシアムジャパン(日本語サイト)
アンテナハウスDITAサービス(日本語サイト)

Tweet

こんにちは。今週のDITA超入門も、残すところ、あと1回です。
今回は特殊化の話題です。
「DITA」の最初の「D」は（進化論の）ダーウィンの頭文字から来ていますが、ずばり、特殊化という機能があるがゆえにダーウィンの登場というわけです。
昨日までに紹介した機能は、名称や形こそ違え、似たようなことは昔から行われてきました。しかし特殊化という機能はおそらくDITAが最初ではないでしょうか。
■特殊化
特殊化とは既存の情報タイプ（トピックタイプ）を自分が好きなように拡張することです。たとえばdocbookでドキュメントを記述するとき、docbookの仕様の中で定義されている要素をそのまま使うしかありませんが、DITAの場合、都合のいいように要素を定義し直してもいいよ、と。もちろんある程度の制限というか作法のようなものは守らなければいけませんが。
生物は環境に適したものが生き延びる、というのが進化論の教えるところですが、情報タイプもあなたの環境に応じたものを用意していいですよ、というわけです。
次のような手順を出力したい、としましょう。
—
1. 電源スイッチを押す
2. [ラジオ]ボタンを押す
3. チューニングレバーを回す
—
もっとも初歩的な解決方法は次のようなトピックを用意することです。
＜topic＞
　　＜title＞ラジオの聴き方＜/title＞
　　＜body＞
　　　　＜ol＞
　　　　　　＜li＞電源スイッチを押す＜/li＞
　　　　　　＜li＞[ラジオ]ボタンを押す＜/li＞
　　　　　　＜li＞チューニングレバーを回す＜/li＞
　　　　＜/ol＞
　　＜/body＞
＜/topic＞
もちろんこれでも期待する結果は得られますが、では次のような例はどうでしょうか。
＜task＞
　　＜title＞ラジオの聴き方＜/title＞
　　＜taskbody＞
　　　　＜steps＞
　　　　　　＜step＞＜cmd＞電源スイッチを押す＜/cmd＞＜/step＞
　　　　　　＜step＞＜cmd＞[ラジオ]ボタンを押す＜/cmd＞＜/step＞
　　　　　　＜step＞＜cmd＞チューニングレバーを回す＜/cmd＞＜/step＞
　　　　＜/steps＞
　　＜/taskbody＞
＜/task＞
前者は番号付き箇条書きであることは分かりますが、どういった意味の箇条書きであるのかまでは分かりません。それに対して後者の場合、単なる箇条書きではなく、何かの「手順」であるということがはっきりと分かります。どちらの方が情報の質が上かと言えばもちろん後者ですよね。
このように、それまでは＜ol＞を使うしかなかった状況から、（情報の質を高めるために）＜steps＞を使える状況に拡張することが特殊化です。
あ、これは＜ol＞に限ったことではなく、別の要素だって特殊化の対象になりえます。
■情報タイプ（トピックタイプ）
DITAにはすでに下記の情報タイプ（トピックタイプ）が用意されています。
【汎用topic情報タイプ】
DITAの出発点となる情報タイプで、HTMLライクな要素が定義されています。この情報タイプを使えばだいたいどのようなマニュアルも記述できますが、先ほど述べたように情報の質という点では劣ります。
昨日までにいくつかのトピックサンプルを例示しましたが、すべてこの情報タイプで記述したものです。
【task情報タイプ】
操作手順を記述するのに特化した情報タイプです。どのような順番でどういう操作をすればどのような結果が得られるか、というようなことを記述しやすいようになっています。
この情報タイプは上記の汎用topic情報タイプから派生させた（特殊化した）ものです。
【concept情報タイプ】
「それは何か」に対する答えを記述するのに便利な情報タイプです。たとえば「製品の特徴」であるとか「ご使用の前に」とか…etc。上記のtask情報タイプでは記述できないコンテンツは大抵この情報タイプを使うことになるでしょう。
この情報タイプは上記の汎用topic情報タイプから派生させた（特殊化した）ものです。
【reference情報タイプ】
リファレンスマニュアルを記述するのに特化した情報タイプです。
この情報タイプは上記の汎用topic情報タイプから派生させた（特殊化した）ものです。
【glossary情報タイプ】
用語集を記述するのに特化した情報タイプです。
この情報タイプは上記のconcept情報タイプから派生させた（特殊化した）ものです。
おおよそこれらのすでに用意された情報タイプで事足りると思いますが、中にはそれでも不十分だということもあるでしょう。そのときは（上記の情報タイプから派生させる形で）自分で特殊化することになります。
今日の話を図式化すると次のようになります。

なんだか、いかにもダーウィンって感じですね。
特殊化については（それだけで数十ページ書けそうな話題なので）これ以上突っ込んだ話は他の参考書に任せますが、日本語の参考書としては
DITA 101
DITA概説書
があります。
では、また明日。

Tweet

こんにちは。昨日に引き続きDITAのお話です。
昨日は（複数の）トピックとマップを使ってマニュアルを作るという話でした。この仕組みによってトピック単位でのデータ再利用が実現されるわけです。
ここで、ある製品Ａと別の製品Ｂとで充電の方法が「ほんの少しだけ」異なる場合を考えてみましょう。昨日の話の範疇で考えると「充電の方法-Ａ用.dita」と「充電の方法-Ｂ用.dita」のふたつを用意して、マップの中から必要な方のトピックを参照すれば無事解決です。もちろんこの方法で間違っていません。
ただ、「ほんの少しだけ」違うだけなのにトピックを丸ごとふたつに分けるのもなんだかな～、と思いますよね。
そこで条件処理（コンディショナルプロセシング）の出番です。
■条件処理（コンディショナルプロセシング）
条件処理には、大きく２つの機能があります（フィルタリングとフラッギング）。今日は、そのうちのひとつ、「フィルタリング」を紹介します。
●フィルタリング
ひとつのトピックファイルの中に複数の製品の情報を混在して書いておいて、マニュアル生成時にその時の条件によって、特定の情報を出力したり、出力しなかったり、をコントロールすることをフィルタリングといいます。具体例をあげましょう。
＜topic id=”HowToCharge”＞
　　＜title＞充電の方法＜/title＞
　　＜body＞
　　　　：
　　　　：
　　　　＜p product=”上位モデル”＞
　　　　　　充電が完了するのに「30分」程度かかります
　　　　＜/p＞
　　　　＜p product=”下位モデル”＞
　　　　　　充電が完了するのに「60分」程度かかります
　　　　＜/p＞
　　　　＜p＞
　　　　　　充電中は電源を入れないでください
　　　　＜/p＞
　　　　：
　　＜body＞
＜/topic＞
ここには上位モデル用の充電時間と下位モデル用の充電時間が混在して書かれています。このまま何も考えずに処理すると両方ともマニュアル内に出力されてしまいます。
そこで、もうひとつ、ditavalファイルというものを用意します。上位モデル用の出力を得たい場合は次のような内容にしておきます。
＜val>
　　＜prop att=”product” val=”上位モデル” action=”include” /＞
　　＜prop att=”product” val=”下位モデル” action=”exclude” /＞
＜/val>
ここでは、
　* product属性が「上位モデル」のコンテンツは出力してください
　* product属性が「下位モデル」のコンテンツは出力しないでください
　* その他は出力してください
ということを意味しています。
そしてマニュアルを作る時に、このditavalファイルを使ってくださいね、と宣言すると次のような出力が得られるわけです。
—
　充電が完了するのに「30分」程度かかります
　充電中は電源を入れないでください
—
見事に下位モデル用の記述が抜け落ちていますね。
こうすることで、「ほんの少しだけ」違うトピックを複数個作る必要がなくなるわけです。
この機能をうまく使えば、ひとつのトピックの中に「Windows向けとLinux向けの記述」であるとか「上級者向けと入門者向けの記述」であるとかを混在して書いてもいいことになりますね。
では、また明日。

Tweet