やってはいけないDITAの3番名は「過剰なtopicの再利用」です．DITAを導入する時、書きたいことを細かな粒度のtopicに分割し、それをmapで束ねてパブリッシングするんですよ～！と必ず教わります．なので多くの人は素直に文書を細かなtopicに分割します．
ここまではなんの問題もないんですが、世の中の技術文書は単にtopicに分割してため込めばなんとかなるというほど甘くはないのです．当然細かに分割したtopicは様々なmapから再利用されるようになります．ここで弊害が出てきてしまうのです．
@toc="no"のtopicrefで示されたtopicは本文中でもtopic/titleを出さない
最悪なワガママがこれです．topicの内容は再利用したいが、topic/titleのは本文中に出したくないというものです．もちろんtopicref/@toc="no"ですから、PDFのブックマークには現れませんし、ましてや目次にも表れないように実装するのがDITAの掟です．ところがこの場合は、対応するtopic/titleすらも本文中に出現しないようにしたいというのです．
そんなことって本当にあるのか？っていうお気持ちがあるかもしれませんが、この話は最初に日本で、次に中国（zh-CNの方）からサポートリクエストがありましたので、世界でもみんなおんなじことを考えるものだな？と妙に感心してしまいました．
結論から言うと、もしあなたがDITAのXSLTプログラマーだったら、決してこんな要求をインプリメントしてはいけません．完全なDITAの使い方の誤りだからです．解決法はものすごく簡単に言えば
- 共有したいtopicの部分を集めて、ライブラリtopicのようなものを構成します．
- 異なるtopic/titleで出したい場合は、違うtitleの2つのtopicを作って、そのbodyの中からライブラリtopicの該当部分をconrefしてやればいいのです．（ホントはconkeyrefが良い）
ということです．ところがこのようなやり方は、「topicレベルの再利用」しか理解していないユーザーにとっては晴天の霹靂のようなものです．下手をするとDITAを導入して5年も6年も経つのに十年一日のごとく「topicレベルの再利用」を延々とやって来て、それ以上のお知恵がない場合も多々あるようです．こういうのはそろそろDITAの使用法を進歩させないと世界の水準について行けなくなります．
ちなみに、中国から来た問い合わせでは、聞いてきた人がプログラマーレベルの方でしたので、
- topicの再利用ばかりでなく
- 要素レベルの再利用をするように
- 頭を転換するようあなたのボスと闘ってくれ！
ってアドバイスしておきました．まだDITAの導入したてのフェーズだったので、みんなで頭を悩ましてくれたことを期待しています．
DITAが面白いのはXSLTプログラマーレベルでこのようなユーザーのDITA Adoptionのレベルが丸見えになってしまうことです．ここで必死で戦わなければ元のユーザーも実際には幸せにならないんですが、部署の異動があったり、年齢により配転でノウハウが引き継がれなかったりと、残念な例も多いですね．
