Darwin Information Typing Architecture (DITA) は、拡張可能な技術情報を表現するためのXMLアーキテクチャーです。ドメインは、組織または知識分野に固有の名前と内容モデルを持つ要素セットによって、DITAを拡張します。設計者と文書作成者は、任意の数のドメインから取った要素を組み合わせることができるため、情報のセマンティクス (意味体系) と構造を写し取る面で、柔軟性と正確さが大幅に向上します。この概説記事では、自分で独自のドメインを定義する方法を学びます。

ドメイン特殊化の紹介

DITAでは、トピックが、処理可能な内容の基本単位です。トピックは、内容のタイトル、メタデータ、および構造を提供します。トピックのタイプによっては、内容の構造が非常にシンプルです。たとえば、concept トピックには、概念内容のすべてを表す概念の本文が1つあります。それとは対照的に、task トピックには、前提条件、手順、および結果など、タスク内容の各部分を区別する明確に分かれた構造があります。

ほとんどの場合、これらのトピック構造には、トピック・タイプに特有ではない内容要素が含まれています。たとえば、概念の本文とタスクの前提条件はどちらも、p (段落) やul (番号なしリスト) などの共通ブロックを含むことができます。

ドメイン特殊化 では、トピック・タイプからは独立して、内容要素の新しいタイプを定義できます。つまり、既存のインライン (phrase) 要素やブロック要素から、新しいインライン要素やブロック要素を派生させることができるということです。特殊化した内容要素は、その要素の基本要素を置くことのできる任意のトピック構造内で使用できます。たとえば、p 段落は概念の本文にもタスクの前提条件にも置くことができるので、特殊化した段落もそれと同じ場所に置くことができます。

このことを、台所にある品物に例えてみましょう。トピックは、様々な方法で調理する食材を入れる様々な器と考えることができます。たとえば、フライパン、ミキサー、グラタン皿などです。内容要素は、これらの器に入れる材料のようなものです。たとえば、香辛料、小麦粉、卵などです。そして、ドメインは、特定の料理向けの材料を取り扱う専門の食料品店に似ています。テキサス風メキシコ料理を調理している時には、食肉店で購入したチョリソーが鍋に入っているでしょうし、イタリア料理を調理しているときにはリゾットが鍋に入っているでしょう。同じように、トピックにも、プログラミング言語について書いている時にはプログラミング・ドメインからの要素が入り、GUIアプリケーションについて書いている時にはUIドメインからの要素が入ります。

DITAの様式は幅広いので、必要に応じてドメインを混在させることができます。GUIアプリケーションをプログラミングする方法について書いているのであれば、そのトピックでは、プログラミングとUIの両方のドメインから要素を引き出せます。さらに、自分の 内容のための新しいドメインを作成することも可能です。たとえば、その新しいドメインでは、ハードウェア・デバイスについて記述するための要素を提供します。また、他の人が作成した新しいドメインを再利用することもでき、そのようにして自分の“料理”のレパートリーを広げることができます。

もう少し正式な定義で言うと、トピック特殊化は、内容を含んでいる要素から始めて、トップダウンで進めていきます。他方、ドメイン特殊化は、含まれている要素から始めて、ボトムアップで進めていきます。

上に戻る

基本ドメインについて理解する

DITAのドメイン は、特定の目的のために特殊化した内容要素を集めたものです。実質的に、ドメインは、特殊化したボキャブラリーを提供します。基本DITAパッケージでは、次のようなドメインが提供されます。

ほとんどのドメインでは、特殊化した要素が基本要素にセマンティクスを追加します。たとえば、プログラミング・ドメインのapiname 要素は、基本的なkeyword 要素にAPI内の名前というセマンティクスを追加して拡張します。

強調表示ドメインは、特殊なケースです。このドメインの要素は、セマンティクス上または構造上のマークアップではなく、スタイル付けされた表示を提供します。強調表示のスタイルは、セマンティクスの定義されていない語句をマークアップするための実用的な手段を文書作成者に提供します。

このような強調表示スタイルをドメインによって提供することは、出版物のDTDに関する以前からの懸案を解決するものとなります。純粋主義者は、強調表示ドメインを省略することにより、文書が厳密にセマンティックなものになるよう強制できます。実用主義者は、強調表示ドメインを組み込むことにより、実世界の文書作成のために表現上の柔軟性を提供できます。半実用主義者であれば、概念的な文書には強調表示ドメインを組み込んで表現に富んだ文書を作成し、リファレンス文書からは強調表示ドメインを省略して厳密にセマンティックなタグ付けを強制する、ということが可能です。

もっと一般的には、ドメインとトピックを任意に組み合わせて文書を定義できます。「ドメインを一般化する」で説明するとおり、そのようにして生成した文書でも、依然として交換が可能です。

上に戻る

既存のトピックおよびドメインを組み合わせる

DITAパッケージは、各トピック・タイプ用のDTDと、すべてのトピック・タイプを定義している多目的のDTD (ditabase.dtd) を提供しています。これらのDTDにはそれぞれ、事前に定義されているDITAドメインのすべてが含まれています。したがって、提供されているDTDの1つに対して書かれるトピックでは、事前に定義されているドメイン特殊化のすべてを利用できます。

舞台裏では、DITA DTDは単なるシェル (殻) に過ぎません。要素は実際には別のモジュールで定義されており、それらのモジュールがDTDに組み込まれています。これらのモジュールにより、DITAは、トピック・タイプとドメインの新しい組み合わせを作成するための構築ブロックを提供します。

DITAのインストールに新しいドメインを追加すると、その新しいドメインによって追加のモジュールが提供されます。それら追加のモジュールを使って、既存のDTDにドメインを組み込んだり、新しいDTDを作成したりできます。

具体的には、各ドメインは2つのファイルで実装されます。

• ドメインの実体 を宣言するファイル。このファイルの拡張子は.ent です。
• ドメインの要素 を宣言するファイル。このファイルの拡張子は.mod です。

1つの例として、プログラミング言語のリファレンス・トピックを作成している場合のことを考えてみましょう。あなたは表示についての純粋主義者なので、強調表示ドメインは除外したいと考えています。また、このリファレンスでは、ソフトウェア・ドメインとUIドメインが必要ありません。この状況に取り組むには、新しいシェルDTDを定義して、リファレンス・トピックをプログラミング・ドメインと組み合わせ、その他のドメインは除外することができます。

シェルDTDは、明確に定義された少数のセクションのある、一貫したデザイン・パターンになっています。これらのセクションにある命令は、次のような働きをします。

1. ドメインの実体を宣言します。この例のシナリオでは、このセクションに、プログラミング・ドメインの実体を組み込みます。

   <!ENTITY % pr-d-dec PUBLIC "-//IBM//ENTITIES DITA Programming Domain//EN" "programming-domain.ent"> %pr-d-dec;

   
   
2. 基本内容要素の実体を再定義して、特殊化内容要素をドメインから追加します。

   このセクションは、ドメイン特殊化にとって重要です。ここでは、デザイン・パターンは、2種類の実体を利用しています。それぞれの基本内容要素は、それ自身と、その特殊化を指定する要素実体 を持っています。それぞれのドメインは、基本要素に対してドメインが提供する特殊化を列挙する、別個のドメイン特殊化実体 を提供します。この2種類の実体を組み合わせることにより、シェルDTDは、特殊化した内容要素を基本要素と同じコンテキストで使用することを可能にします。

   この例のシナリオでは、pre 要素実体は、pre 要素 (HTMLの場合と同じく、事前フォーマット済みのテキストが入る) と、その特殊化を指定します。プログラミング・ドメインは、pre 基本要素に対する特殊化を列挙する、pr-d-pre ドメイン特殊化実体を提供します。プログラミング・ドメインによって特殊化されるその他の基本要素についても、同じパターンが使用されます。

   <!ENTITY % pre "pre | %pr-d-pre;"> <!ENTITY % keyword "keyword | %pr-d-keyword;"> <!ENTITY % ph "ph | %pr-d-ph;"> <!ENTITY % fig "fig | %pr-d-fig;"> <!ENTITY % dl "dl | %pr-d-dl;">

   
   

   どの内容要素がドメインによって特殊化されているかを調べるには、ドメインの実体宣言ファイルを見てください。

3. トピック要素のdomains 属性を定義して、文書で表現されているドメインを宣言します。

   class 属性と同じように、domains 属性は依存関係を識別します。class 属性は基本要素を識別するのに対して、domains 属性はトピック内で利用可能なドメインを識別します。各ドメインは、ドメイン識別実体 を提供して、domains 属性で自身を識別します。

   この例のシナリオでは、唯一のトピックがreference トピックです。また、唯一のドメインがプログラミング・ドメインで、pr-d-att ドメイン識別実体によって識別されます。

   <!ATTLIST reference domains CDATA "&pr-d-att;">

   
   
4. 情報タイプ実体を再定義して、トピック内でネストできるトピック・タイプを指定します。

   この例のシナリオでは、このセクションでreference トピックを宣言します。

   <!ENTITY % info-types "reference">

   
   
5. トピック・タイプの要素を、基本トピックを含めて、定義します。

   この例のシナリオでは、このセクションに、基本トピックおよびリファレンス・トピックのモジュールを組み込みます。

   <!ENTITY % topic-type PUBLIC "-//IBM//ELEMENTS DITA Topic//EN" "topic.mod"> %topic-type; <!ENTITY % reference-typemod PUBLIC "-//IBM//ELEMENTS DITA Reference//EN" "reference.mod"> %reference-typemod;

   
   
6. ドメインの要素を定義します。

   この例のシナリオでは、このセクションに、プログラミング・ドメインの定義モジュールを組み込みます。

   <!ENTITY % pr-d-def PUBLIC "-//IBM//ELEMENTS DITA Programming Domain//EN" "programming-domain.mod"> %pr-d-def;

   
   

多くの場合、既存のDTDをコピーし、トピックやドメインを必要に応じて追加または削除するという方法で作業するのが、最も簡単です。この例のシナリオでは、reference.dtd を土台にして、強調表示、ソフトウェア、およびUIドメイン (下のリストで太字で強調表示されている) を削除するわけです。

<!--vocabulary declarations-->

<!ENTITY % ui-d-dec PUBLIC 
"-//IBM//ENTITIES DITA User Interface Domain//EN" 
"ui-domain.ent">
%ui-d-dec;

<!ENTITY % hi-d-dec PUBLIC 
"-//IBM//ENTITIES DITA Highlight Domain//EN" 
"highlight-domain.ent">
%hi-d-dec;
<!ENTITY % pr-d-dec PUBLIC 
"-//IBM//ENTITIES DITA Programming Domain//EN" 
"programming-domain.ent">
%pr-d-dec;

<!ENTITY % sw-d-dec PUBLIC 
"-//IBM//ENTITIES DITA Software Domain//EN" 
"software-domain.ent">
%sw-d-dec;

<!--vocabulary substitution-->
<!ENTITY % pre     "pre     | %pr-d-pre;     | %sw-d-pre;">
<!ENTITY % keyword "keyword | %pr-d-keyword; | %sw-d-keyword; 
| %ui-d-keyword;">
<!ENTITY % ph      "ph      | %pr-d-ph;      | %sw-d-ph;      | %hi-d-ph; 
| %ui-d-ph;">
<!ENTITY % fig     "fig     | %pr-d-fig;">
<!ENTITY % dl      "dl      | %pr-d-dl;">

<!--vocabulary attributes-->
<!ATTLIST reference  domains CDATA "(topic ui-d) (topic hi-d) (topic pr-d) 

(topic sw-d)">

<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "reference">

<!--Embed topic to get generic elements -->
<!ENTITY % topic-type PUBLIC 
"-//IBM//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;

<!--Embed reference to get specific elements -->
<!ENTITY % reference-typemod PUBLIC 
"-//IBM//ELEMENTS DITA Reference//EN" 
"reference.mod">
%reference-typemod;

<!--vocabulary definitions-->

<!ENTITY % ui-d-def PUBLIC 
"-//IBM//ELEMENTS DITA User Interface Domain//EN" 
"ui-domain.mod">
%ui-d-def;
<!ENTITY % hi-d-def PUBLIC 
"-//IBM//ELEMENTS DITA Highlight Domain//EN" 
"highlight-domain.mod">
%hi-d-def;

<!ENTITY % pr-d-def PUBLIC 
"-//IBM//ELEMENTS DITA Programming Domain//EN" 
"programming-domain.mod">
%pr-d-def;

<!ENTITY % sw-d-def PUBLIC 
"-//IBM//ELEMENTS DITA Software Domain//EN" 
"software-domain.mod">
%sw-d-def;
            

上に戻る

ドメイン特殊化の作成

文書によっては、新しいタイプの内容要素が必要になるかもしれません。一般的なシナリオとしては、特別なセマンティクスを持つ語句をマークアップする必要が生じるでしょう。このような必要を取り扱うには、既存の内容要素の新しい特殊化を作成し、その新しい内容要素をトピック構造内で再利用するためにドメインを提供します。

1つの例として、クラス・ライブラリーの文書を書いている場合のことを考えてみましょう。あなたは、文書にクラス別、フィールド別、そしてメソッド別の索引を付ける処理を記述することを考えています。この処理をサポートするには、トピック内容の中のクラス、フィールド、およびメソッドの名前をマークアップする必要があります。たとえば、次の例のとおりです。

<p>The <classname>String</classname> class provides
the <fieldname>length</fieldname> field and 
the <methodname>concatenate()</methodname> method.
</p>

これらの名前のために新しい内容要素を定義しなければなりません。これらの名前は、API内の特別な種類の名前なので、新しい要素は、プログラミング・ドメインが提供しているapiname 要素から特殊化することができます。

ドメインのデザイン・パターンには、ドメインを表す省略語が必要です。クラス・ライブラリー (class library) ドメインの適切な省略語としては、cl が考えられます。ドメインの識別子は、その省略語の後に-d (ドメインを表す) を付けます。

「既存のトピックおよびドメインを組み合わせる」で説明したとおり、ドメインには、実体を宣言するファイルと、要素を定義するファイルが必要です。

上に戻る

実体宣言ファイルを記述する

実体宣言ファイルには、次のような働きをするセクションがあります。

1. ドメイン特殊化実体を定義します。

   ドメイン特殊化実体は、ドメインによって基本要素に提供される、特殊化した要素を列挙します。明確にするために、実体名は、ドメイン識別子と基本要素名で構成されます。ドメインは、祖先要素と基本要素のためのドメイン特殊化実体を提供します。

   この例のシナリオでは、ドメインは、apiname 基本要素とkeyword 祖先要素 (apiname の基本要素) の両方について、ドメイン特殊化実体を定義します。

   <!ENTITY % cl-d-apiname "classname | fieldname | methodname"> <!ENTITY % cl-d-keyword "classname | fieldname | methodname">

   
   
2. ドメイン識別実体を定義します。

   ドメイン識別実体は、トピック・タイプと、現在のドメインが依存関係を持つドメインや他のドメインを列挙します。各ドメインは、そのドメイン識別子によって識別されます。リストは、括弧で囲みます。明確にするために、実体名は、ドメイン識別子と-att で構成されます。

   この例のシナリオでは、クラス・ライブラリー・ドメインは、プログラミング・ドメイン (apiname 要素を提供している) に依存関係があります。

   <!ENTITY cl-d-att "(topic pr-d cl-d)">

   
   

完全な実体宣言ファイルは、次のようになります。

<!ENTITY % cl-d-apiname "classname | fieldname | methodname">
<!ENTITY % cl-d-keyword "classname | fieldname | methodname">
<!ENTITY cl-d-att "(topic pr-d cl-d)">

上に戻る

要素定義ファイルを記述する

要素定義ファイルには、次のような働きをするセクションがあります。

1. ドメインによって導入される要素のための内容要素実体を定義します。

   これらの実体により、他のドメインは、現在のドメインの要素から特殊化することが可能になります。

   この例のシナリオでは、クラス・ライブラリーはこの習慣に従っており、将来、さらに別のドメインを追加することができます。ドメインは、3つの新しい要素のための実体を定義します。

   <!ENTITY % classname "classname"> <!ENTITY % fieldname "fieldname"> <!ENTITY % methodname "methodname">

   
   
2. 要素を定義します。

   特殊化した内容モデルは、基本要素の内容モデルと一貫していなければなりません。つまり、特殊化した要素の内容として可能な内容は、基本要素の有効な内容に一般化できなければなりません。その制限内であれば、かなりのバリエーションが可能です。特殊化した要素は、基本内容モデル内の要素の代わりに使用できます。オプションの要素は、省略することも、必須にすることもできます。複数回出現する要素は、その要素を特殊化した要素のリストで置き換えることができます、といった具合です。

   特殊化した内容モデルでは、要素をいつも要素実体で指定する必要があり、名前で直接指定してはなりません。この習慣により、他のドメインがそのドメインでの特殊化を、現在のドメインにマージできるようになります。

   この例のシナリオでは、要素は単純な文字内容を持ちます。

   <!ELEMENT classname (#PCDATA)> <!ELEMENT fieldname (#PCDATA)> <!ELEMENT methodname (#PCDATA)>

   
   
3. 要素の特殊化の階層をclass 属性で定義します。

   ドメイン要素では、属性の値はプラス記号で始まらなければなりません。ドメインによって提供される要素は、ドメイン識別子で修飾する必要があります。

   この例のシナリオでは、特殊化の階層に、基本トピックによって提供されるkeyword 祖先要素と、プログラミング・ドメインによって提供されるapiname 要素が含まれます。

   <!ATTLIST classname class CDATA "+ topic/keyword pr-d/apiname cl-d/classname "> <!ATTLIST fieldname class CDATA "+ topic/keyword pr-d/apiname cl-d/fieldname "> <!ATTLIST methodname class CDATA "+ topic/keyword pr-d/apiname cl-d/methodname ">

   
   

完全な要素定義ファイルは、次のようになります。

<!ENTITY % classname  "classname">
<!ENTITY % fieldname  "fieldname">
<!ENTITY % methodname "methodname">

<!ELEMENT classname        (#PCDATA)>
<!ELEMENT fieldname        (#PCDATA)>
<!ELEMENT methodname       (#PCDATA)>

<!ATTLIST classname      class CDATA "+ topic/keyword pr-d/apiname 
cl-d/classname ">
<!ATTLIST fieldname      class CDATA "+ topic/keyword pr-d/apiname 
cl-d/fieldname ">
<!ATTLIST methodname     class CDATA "+ topic/keyword pr-d/apiname 
cl-d/methodname ">

上に戻る

シェルDTDを記述する

ドメイン・ファイルを作成した後、シェルDTDを記述して、ドメインにトピックや他のドメインを組み合わせることができます。シェルDTDには、すべてのドメインの依存関係を含めなければなりません。

この例のシナリオでは、シェルDTDは、クラス・ライブラリー・ドメインに、概念、リファレンス、およびタスク・トピックと、プログラミング・ドメインを組み合わせています。下のリストで、クラス・ライブラリー・ドメインに特有の部分は、太字で強調表示されています。

<!--vocabulary declarations-->
<!ENTITY % pr-d-dec PUBLIC 
"-//IBM//ENTITIES DITA Programming Domain//EN" 
"programming-domain.ent">
%pr-d-dec;
<!ENTITY % cl-d-dec SYSTEM "classlib-domain.ent">
%cl-d-dec;

<!--vocabulary substitution-->
<!ENTITY % pre     "pre     | %pr-d-pre;">
<!ENTITY % keyword "keyword | %pr-d-keyword; | %cl-d-apiname;"> 
<!ENTITY % ph      "ph      | %pr-d-ph;">
<!ENTITY % fig     "fig     | %pr-d-fig;">
<!ENTITY % dl      "dl      | %pr-d-dl;">
<!ENTITY % apiname "apiname | %cl-d-apiname;">

<!--vocabulary attributes-->
<!ATTLIST concept    domains CDATA "&pr-d-att; &cl-d-att;">
<!ATTLIST reference  domains CDATA "&pr-d-att; &cl-d-att;">
<!ATTLIST task       domains CDATA "&pr-d-att; &cl-d-att;">

<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "concept | reference | task">

<!--Embed topic to get generic elements -->
<!ENTITY % topic-type PUBLIC 
"-//IBM//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;

<!--Embed topic types to get specific topic structures-->
<!ENTITY % concept-typemod PUBLIC 
"-//IBM//ELEMENTS DITA Concept//EN" 
"concept.mod">
%concept-typemod;
<!ENTITY % reference-typemod PUBLIC 
"-//IBM//ELEMENTS DITA Reference//EN" 
"reference.mod">
%reference-typemod;
<!ENTITY % task-typemod PUBLIC 
"-//IBM//ELEMENTS DITA Task//EN" "task.mod">
%task-typemod;

<!--vocabulary definitions-->
<!ENTITY % pr-d-def PUBLIC 
"-//IBM//ELEMENTS DITA Programming Domain//EN" 
"programming-domain.mod">
%pr-d-def;
<!ENTITY % cl-d-def SYSTEM "classlib-domain.mod">
%cl-d-def;
            

クラス・ライブラリーの語句が、apiname だけでなくkeyword の要素実体にも追加されていることに注目してください。これにより、クラス・ライブラリーの語句が、明示的にAPI名を許可しているトピック構造だけでなく、キーワードを許可しているトピック構造内で利用できるようになります。実際、reference トピックの構造ではキーワードだけが指定されています。ドメイン特殊化実体をすべての祖先要素に追加するのは、良い習慣です。

上に戻る

ドメイン特殊化の考慮事項

新しいトピック・タイプやドメイン要素を定義するときには、トピック特殊化とドメイン特殊化の階層を区別しなければならないことを覚えておいてください。特殊化したトピックは、内容モデルの中でドメイン要素を使用できません。同様に、ドメイン要素を特殊化できるのは、基本トピックの中または別のドメインの中にある要素からだけです。つまり、トピックとドメインに依存関係を持たせることはできません。トピックとドメインを組み合わせるには、シェルDTDを使用します。

内部構造を持つ要素 (たとえば、ul、ol、dl リストや、table およびsimpletable) を特殊化するときは、内容要素全体を特殊化するべきです。内容構造全体のうち、内部構造の一部について独立して特別なタイプを作成しても、通常はほとんど意味がありません。たとえば、通常のul およびol リストで使うli リスト項目について特別なタイプを作成するのではなく、特別なタイプのリストを作成するのが普通です。

強調表示ドメインの要素から特殊化してはなりません。これらのスタイル要素は、特別なセマンティックを持っていません。強調表示スタイルによるフォーマットは便利に思えるかもしれませんが、フォーマット設定は後になって変更する必要に気付くことがあります。

前にも述べたとおり、内容モデルの中では、リテラルの要素名ではなく、要素実体を使用するべきです。要素実体を使用する必要があるのは、ドメイン特殊化を可能にするためです。

内容モデルでは、要素実体が拡張されてリストになっている可能性を考慮に入れる必要があります。要素実体に修飾子を適用するときには、要素実体を括弧で囲んでください。そうしないと、要素実体が拡張されてリストになっている場合に、リストの最後の要素だけに修飾子が適用されてしまいます。同様の事柄が、要素実体を順番に並べる場合にも当てはまります。

..., ( %classname; ), ...
... ( %classname; )? ...
... ( %classname; )* ...
... ( %classname; )+ ...
... | %classname; | ...

要素実体が既にリストになっている場合には、括弧は必要ありません。

上に戻る

ドメインを一般化する

トピックと同様に、特殊化した内容要素は、その祖先要素の1つに一般化することができます。前の例のシナリオでは、classname を、apiname や、あるいはkeyword にさえ、一般化することができます。その結果、異なるドメインを使用しているが、同じトピックを使用している文書は、トピックを一般化する必要なしに、交換したりマージしたりできます。

「基本ドメインについて理解する」で言及した強調表示スタイルの論議に戻ると、強調表示ドメインを使用する実用主義的な文書作成者は、次のような語句を文書に含めるでしょう。

... the <b>important</b> point is ...

この文書を、トピックは同じでも強調表示ドメインを使用しない文書に一般化すると、実用主義的なb 要素が、純粋主義的なph 要素になり、表示を持ち込まずにその語句が特別であることが示されます。

... the <ph class="+ topic/ph hi-d/b ">important</ph> point is ...

また、前の例のシナリオでは、クラス・ライブラリーの文書作成者は、自分たちのトピックを、クラス・ライブラリー・ドメインを持たない別のDITAショップに送ることができます。その文書を受け取った側では、クラス・ライブラリー・トピックを一般化して、classname 要素をapiname 基本要素に変換します。文書を一般化した後、受け取り手は、クラス名、フィールド名、およびメソッド名を、その他のAPI名と同じ仕方で編集したり処理したりできます。つまり、文書の送り手が、クラス名、フィールド名、およびメソッド名を区別せずに、それらの名前を汎用のAPI名としてマークアップすることにしたのと同じ状況になるわけです。

別の方法として、受け取り手は、自分たちの定義にクラス・ライブラリー・ドメインを追加するという決定をすることもできます。その場合、文書の送り手は、自分たちのトピックだけでなく、ドメインの実体宣言ファイルと要素定義ファイルも提供する必要があります。そうすれば、受け取り手は、自分たちのシェルDTDにクラス・ライブラリー・ドメインを追加できます。こうして、一般化をしないでも、classname 要素を取り扱えるようになります。

文書の受け取り手は、相互運用性に影響を与えずに、追加のドメインを使用することができます。つまり、受け取り手のシェルDTDで使用されているドメインが、送り手のシェルDTDより多くても、トピックの修正が必要になることはありません。

注: 特殊化を定義するときには、基本要素に対する簡単な処理では代替できないような特殊な処理への依存性を導入しないようにしてください。この例のシナリオで言えば、classname 要素に対する特殊な処理としては、出力にリテラルの「クラス」というラベルを生成する処理が考えられます。そのようにして、入力の手間を省き、一貫したラベルを生成するわけです。しかし、自動化された一般化の後には、apiname 要素に対する基本処理では、そのラベルは生成されません。したがって、この依存性では、ソース・ファイルのclassname 要素にリテラルの「クラス」ラベルを付加するという、一般化における特殊な変換が必要になります。

上に戻る

要約

トピック特殊化とドメインにより、DITAは次のような利点を提供します。

• よりシンプルなトピック設計: 文書の設計者は、トピックの構造に注意を集中することができ、構造内で使用される各種の内容すべてを予想しておく必要がありません。
• よりシンプルなトピック階層: 文書の設計者は、新しいタイプのトピックを追加しないでも、新しいタイプの内容を追加できます。
• 既存のトピックの内容を拡張可能: 文書の設計者は、既存のトピック・タイプを新しいタイプの内容について再利用できます。
• セマンティクスの正確さ: より具体的なセマンティクスを持つ内容要素を既存の要素から派生させて、文書内で自由に使用できます。
• 文書作成者にとって、よりシンプルな要素リスト: 文書の設計者は、ドメインを選択できるので、要素セットを最小限にできます。文書の作成者は、文書に適した要素を学ぶことができ、学ぶ際に不必要な要素を無視する必要がありません。

要するに、DITAのドメイン機能は、情報タイプの拡張と再利用に大幅な柔軟性を提供します。基本DITAリリースで提供される強調表示、プログラミング、およびUIドメインは、達成できる事柄の始まりに過ぎないのです。

上に戻る

注意事項

この文書で提供されている情報は、IBMの正式なテストを受けておらず、明示と黙示を問わず、いかなる保証も伴わない、"現状のまま" で配布されています。この情報の使用、またはこの文書に記述されているいずれかの技法の実装は、読者の責任において実施していただきます。また、これらを実動環境に統合して評価することも、読者の能力に依存しています。これらの技法を自分の環境に採用しようとする読者は、自分の責任において実施してください。

© Copyright International Business Machines Corp., 2002. All rights reserved.

参考文献

• developerWorks の更新された記事「DITAの紹介」をお読みください。(developerWorks、2002年5月更新)
  
  
• DITAでトピックを特殊化することにより、新しいトピック構造を定義できます。(developerWorks、2002年5月更新)
  
  
• DITAについてよく尋ねられる質問への回答を読むことができます。(developerWorks、2002年5月更新)
  
  
• DITA Forumへのジャンプ・ページから、イニシアチブのディスカッションにご参加ください。(developerWorks、2002年5月更新)
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ドメイン特殊化の紹介
• 基本ドメインについて理解する
• 既存のトピックおよびドメインを組み合わせる
• ドメイン特殊化の作成
• 実体宣言ファイルを記述する
• 要素定義ファイルを記述する
• シェルDTDを記述する
• ドメイン特殊化の考慮事項
• ドメインを一般化する
• 要約
• 注意事項
• 参考文献
• 著者について
• コメント