会社で引き続きDITAの勉強会をやっています．今まではDITA 1.1ベースの「DITA 概説書」（DITAコンソーシアム訳）でしたが、途中でDITA 1.2でないともう古すぎるという話になり、英語版原書の「Introduction to DITA Second Edition」に切り替わりました．今週はDITAのDTD/スキーマに制約要件をつける特殊化の箇所．そこで出ていた例は、DITA 1.2のStrict TaskとGeneral Taskのお話でした．
DITA 1.2が出た頃、それまではとかく制約条件がキツイと言われていたtaskに加えて、より自由度の高いGeneral Taskのモデルが導入されました．両者はtaskbodyのコンテンツモデルが次のように異なります．（DITA 1.2の記法による）
［General Task］
( ( (prereq) or (context) or (section) ) (any number) then ( (steps or steps-unordered or steps-informal) ) (optional) then (result) (optional) then (example) (any number) then (postreq) (any number) )
［Strict Task］
( (prereq) (optional) then (context) (optional) then (steps or steps-unordered) (optional) then (result) (optional) then (example) (optional) then (postreq) (optional) )
もう前の話なのですが、お客様とのディスカッションの中で、「Strict Taskで行くか？」「General Taskも許すか？」というのが議論になったのを覚えています．その結果General Taskの使用は却下となり、今に至るまで使われていません．
今回制約条件の箇所の勉強を会社でしてみて、このような捉え方は誤っていたんだなと反省しました．簡単に言えばDITA 1.2で取りれられたGeneral Taskは単にStrict Taskとの二者択一で論じられるようなものではないということです．
Genral Taskのモデルの役割は．
* より緩やかなコンテンツモデルを提供することで、他のレガシーコンテンツからのtaskへの移行を容易にする．
* 制約条件を適用することにより、ユーザー毎に異なるであろうタスクのモデルの特殊化のベースになる
ということなのです．実際にDTDを見てみるとわかりますが、DITA 1.1まではtaskと言えばDITA 1.2でいうところのStrict Taskしかありませんでした．DITA 1.2では、Strict TaskはGeneral Taskを制約条件をつけて特殊化した形態となっています．最新のDITA-OT（のDITA 1.3）のDTDで言えば
dita-ot-3.0.2\plugins\org.oasis-open.dita.v1_3\dtd\technicalContent\dtd\strictTaskbodyConstraint.mod
が制約条件を付けているモジュールです．これは60行にも満たないものですが、これがtask.dtdの中で
<!-- ============================================================= -->
<!-- CONTENT CONSTRAINT INTEGRATION -->
<!-- ============================================================= -->
<!ENTITY % strictTaskbody-def
PUBLIC "-//OASIS//ELEMENTS DITA 1.3 Strict Taskbody Constraint//EN"
"strictTaskbodyConstraint.mod"
>%strictTaskbody-def;
として取り込まれていることでStrict Taskが実現されています．
実際Strict Taskは使いづらいという話をよく耳にしますが、しかしあまりGenral Taskを特殊化して独自のtaskモデルを構築したという話は耳にしません．
例えば次のような話がありました．必ずしもGeneral Taskに制約条件をつければ実現できるというものではないのですが、よく手順を書くのに、コールアウト付きの機器の画像イメージを先に出して、それを見ながらわかるようにstepを書くというパターンがあります．これには実はimageではなくてfigが必須でした．（あくまで画像としてのimageでなく、図として表したかったため）
ところがあたりまえですがStrict Taskのモデルではそのような位置づけで最初にfigが登場する余地がないのです．確かにfigはstepsの前のprereq（前提条件）、context（背景情報）に書くことはできるのですが、それはsteps（手順）とダイレクトに結びついたものを表現するという点ではふさわしくないというのが、お客様の意見であったというように記憶しています．結局figはtask/abstractに書かれることになりました．
まあ無理をして押し込めてしまえばなんでもできてしまう訳ではありますが、お客様特有のタスクの構造はやはりそれなりに特殊化をして表現するのが一番良いと思います．
この場合例えばsteps（手順）を書くのに特化したfigを表現するsteps-figのようなものを特殊化しておき、taskbodyもモデルを
( (prereq) (optional) then (context) (optional) then (steps-fig) then (steps) then (result) (optional) then (example) (optional) then (postreq) (optional) )
というようにします．こうすれば、steps-figのあとに必ずstepsが続くように強制できます．
特殊化は、それを行うこと自体と、CMSのバージョンアップなどに付随してメンテナンスしてゆかなければならないなど、手数がかかるということで嫌うお客様もおられます．でも長い年月オーサリングを行ってゆくことを考えれば、自分達の情報モデルに適した特殊化をしておいた方が良いはずでしょう．無理をしてオーサリングルールで、「こういうときは、こうする」などと決めておくより、DTD/スキーマにより自動的に強制されるようになった方がよりライターの生産性は上がるからです．
あと制約条件で思い出しましたが、DITAも1.3になってずいぶんと要素が増えました．XMLエディタを使ってオーサリングしてゆくのに、次に入力すべき要素の候補が多すぎるという話もよく耳にします．XMLを表現する、XML mention domainや、MathMLなどは、使用する分野では重宝しますが、使わない側にとっては邪魔であることに変わりはありません．
このような例も制約条件を適用して使用要素を狭めればライターはあれこれ迷うことなく要素を選択できます．
という訳で制約条件をつける特殊化や自分たち自身のタスクモデルを構築するというのは、短期的や周期的な費用より、実際のオーサリング効率を高める意味ででもっと取り入れられても良いのではないかと思います．
