| XML Top | XSL Formatter | AH Formatter V5 | Web Interface | Report Designer | XML エディタ | トップページ |
| DITA | システム製品総合案内 | PDF総合案内 | OEM総合情報 | リセラーページ | XML資料室 | English Site |
アーキテクチャ仕様(第3章 DITAのマークアップ) |
| 目次へ戻る |
DITAを編集する上の2つの主要な単位はトピックとマップである。それぞれ、専門化によって新しい構造型と領域に拡張されることができる。
DITAのトピックは、DITAの内容の基本単位である。各トピックはひとつの主題の回りに組織化されるべきである。トピックは、タスク、参照のように異なる型であって良いし、あるいは特定の型を持たない、一般的なものであっても良い。
トピックは、タイトルとある種の形式の内容をもつ情報の単位であり、ひとつの主題に特定であったり、ひとつの質問に回答するに十分に短く、しかし、それ自身で意味がありかつ一単位として編集するのに十分に長い。
DITAでは、トピックは、編集と再利用の基本的な単位である。XML文書はひとつのトピックまたは多数のトピックを含んで良く、文書型はひとつまたは沢山の種類のトピックをサポートしても良い。しかし、それらがどこに発生しようが、全てのDITAトピックは、同じ基本的な構造と能力を持たねばならない。本、PDFファイル、Webサイト、及びヘルプ・セットは、例えば、すべて下位に同じトピック内容をもつ一組から構築されることができる。しかし、そこには、特定の配布物に特有のある種のトピックがあるかもしれない、そしてトピックの組織化は、夫々の配布機構の特有の能力の利点を活かすために異なっても良い。
DITAのトピックは、他の下位トピックやリンクを組織化するタイトルと程度に小さいか、何ページまたは何画面かに渡る程度に大きくても良い。参照文書や本の章のような複雑な内容のより大きな単位は、ひとつの文書の中で直接的に、あるいは、DITAマップの中の参照を通じて間接的に、トピックをネストして作成することができる。ネストしたDITAのトピックは、古い非トピック志向の内容の移行、あるいは、マーケティング材料やAPI参照文書のような、特別なオーサリングの要求を伴う情報に用立てるために使うことができる。
参照情報は、検索に便利なように、情報がモジュールとなっていて完全独立なので、生来、トピック志向である。
概念的かつタスク情報のためのトピック志向の編集は、最初にJohn Carrollによって取り上げられた、指示的な設計技術であるミニマリズムにその起源をもつ。ミニマリストの情報設計へのアプローチは、タスクの完成を成功させることを許したり、概念の基本的知識を提供する最小の量の指示を識別することに焦点をあてている。読み手は目標をもっており、かれらはその目標をできるだけ迅速に達成したいと望む。一般的に、読み手は読むことの楽しみだけのために情報を読むことは望んでいない。彼らは、学習したり、何かをするために読んでいる。
ミニマリストの鍵になる原則の幾つかは：
DITAのトピック志向のアプローチは、指示設計に根源がある。このトピック志向のアプローチは、人間の読み手を持っていて、一貫した構造をもつあらゆる情報に利用することができる。
トピックは、高品質な情報の基本である。簡単に読むことができるように十分に短く、しかし、それ自身で意味があるように十分に長くするべきである。
内容をトピックに組織化することで、著者は同時に次のような幾つかの目標を達成できる：
トピックは再利用のための沢山の機会を提供するように十分に小さく、しかし、首尾一貫して編集され閲読されるに十分に大きい。DITAは、トピックよりも下位のレベルでの再利用をサポートするが、より小さな塊から組み立てたトピックは、適切に流れるようにするために、しばしば、編集を必要とするので、これは、より多くの思考と検閲を必要とする。それとは対照的に、トピックはひとつの主題の周りに組織化されているので、著者は一組のトピックを論理的に組織化し、それらの間で受け入れ可能なフローを得ることができる。なぜならば、主題から主題への遷移では、ひとつの主題の中での説明ほどシームレスである必要はないから。
情報の型化は、概念、タスク、参照情報のような異なる種類の情報を含むトピックの型を識別する実践である。異なる種類の質問に答えるトピックは、異なる情報の型として分類できる。DITAが提供する基本トピックは、すぐに編集するために採用可能な使用できる初心者向けセットである。
情報を型によって分類することは著者にとって次のように役立つ：
情報の型化は、情報の質を向上させるために技術編集業界を通じて使われる構造化執筆と呼ばれる一般的な編集のアプローチの一部である。Robert HornのInformation MappingとHughes AircraftのSTOP (Sequential Thematic Organization of Proposals)を含む広範な調査と経験に基づいている。
DITAでは情報型はトピック型と表現されている。DITAが提供する基本トピック型はさらなる専門化の基礎として使うことができる。異なる構造と意味を要求する情報型は、トピック型モジュールによって直接サポートされている。その各々は、特定のトピック型を記述するのに要求される特定のマークアップと構造的規則を定義している。これらのモジュールは、情報型化されたトピックの編集を支持するために文書型に統合されることができる。
多くの執筆者は、その中で読者を（「次に、我々は．．．を考えましょう」とか「前のタスクを完了した後に、．．．」のように）ひとつの節から次の節に導く遷移を執筆者が提供する、物語体の文書には親しみがある。DITAの設計に一体化されたトピック志向の方式—そして、DITAマップから導き出されたブックマップ型式—は、このようなトピック間の物語的な埋草の使用を最小にする執筆スタイルを支持する。
トピック志向の執筆は、部品化と情報のつまった単位であるトピックの再使用に力点を置く執筆の訓練されたアプローチである。ひとつのトピックは、アイデアやタスクを一読で完全に伝えるための十分な情報である。うまく執筆されたトピックは、執筆者がいくつかの点について注意深い限り、沢山の文脈で再利用されることができる。
すばやく学習したり、なにかをしようと試みている読者は、追いかけていくのに簡単で、そのタスクを完了したり、事実を把握するのに必要とする情報だけを含むように明白なパターンで情報が執筆されていれば感謝するだろう。処方箋、百科事典の入り口、自動車の修理手続き—すべては、誰かが相談した情報の単位に役立ちかつユニークに焦点をあてた情報単位である。典型的には、文書の並びの中で前または後ろのすべては関心のないものである—そのトピックは読者が最初にそのトピックを探し出した理由に関係する全てを含んでいる。
うまく執筆された情報は、もしそれが、変更された文脈を参照するためにその内容を改訂することなく新しい文書に挿入されることができるという意味で「文脈から自由」であれば、他の文脈で再利用できる。これは、トピック志向に新参者の執筆者にとって、多分最も明白に、物語的テキストに問題がある点である。恐らく、「我々が以前に考えたように．．．」や「あなたが最初のステップを完了したから．．．」のようなものは、トピックが、それらの前提となる条件が異なるか多分もはや存在しない新しい文脈で再使用されるなら、ほとんど意味をなさなくなりそうである。うまく執筆されたトピックは、その中の執筆スタイルは、読者をそのトピックの外部に導かないので、任意の新しい文脈で適切に読まれる。
大部分のHTML Webページは、閲読の順序を表現する内部のリンクや読み手がWebサイトを通じてナビゲートするにつれて行うことのできる選択をもつ、内容とナビゲーションの混じりあったものである。単独のトピックは、その中に、トピックが別の文脈で使われるならば変更される必要があるような、どのようなナビゲーションをもつべきではないのは明らかである。DITAの設計では、このナビゲーションとトピックの分離を、トピックが特定の情報配布物のためにどのように組織化されるべきかを表す、ditamapの使用を通じて支持する。しかし、執筆者にとっては、トピックの内容の中で、読者が外部の情報源を調べることを許すリンクを提供することを望むのは魅力的である。DITAは、そのようなリンクを禁止していない。実際のところ、マークアップでは執筆者がそのようなリンクが外部であることを示すことを—かれらに、読者をナビゲーション上でわき道にそれる代わりに、新たにブラウザのウインドウを開くことを選択させることで—許している。旨く書かれたDITAのトピックは、一般に、文書の組の中で他のトピックへの内部リンクを避けている — これらは、マップ、これによりトピックが内部的な改訂なしに任意の文脈で利用されることを許す、を通じてもっとも良く支持されている。
トピック志向であることは、DITAでの編集では遷移を編集できないことを意味していない。場所から独立であることと意図的な並びの両方を提供するための鍵は、DITAのマークアップの特徴の巧みな使用である。
DITA 1.1では、ditamapのtopicref要素の上の印刷属性は、新しい"printonly"（印刷専用）という値を許す、これによって、もし代わりにマップが遷移が不要なオンライン形式に出力されるならば、そのトピックをスキップする処理を支持する。印刷専用として指定されたトピックでは、執筆者は、そのトピックが印刷された情報の流れの中で移り変わるトピックとして役立つために必要と感じる好きなスタイルで執筆できる。DITAのトピックは、単なるタイトルというほど小さくなることができ、そこで、あなたは遷移的なトピックをこの出力トピックで目下必要とするだけ沢山の情報をもつように精巧に作ることができる。
遷移的な並びをトピックのマップの中に挿入するために使うことができる他の方策はトピックの最後にあるshortdescsまたは段落の内容を含むか除外するかの条件付き（conditionality）を使用することである。チームの中で厳しさを保って、この方策を働くようにできる。しかし、これは印刷専用のアプローチほど一般的ではない—もし、あなたが、他のビジネス仲間やチームとあなたが条件付でマークアップしたトピックを共有するならば、彼らに、適切なランタイム設定において、これらの条件付きをあなたが意図する方法で守られるように指示する必要があるだろう。印刷専用の方法は、遷移するトピックを参照するマップを継承するすべての人にとって一般的に働く。
一般的または非専門化されたトピック型は、他の専門化されたトピック型の基礎を提供する。また、既存の専門化された型に属さない内容を編集する場所を提供する。
専門化するものにとっては、一般トピックは、概念・タスク・参照という型にあてはまらない新しい専門化のための適切な基礎を提供する。著者にとっては、一般トピックは、DITAで型になっていない内容を編集する方法を提供する。
型になった内容は一貫性や処理の関係で、常により好ましいが、一般型は著者が情報の型化に訓練されていないときや、現在利用可能な専門化型が不適切な時に使うことができる。
全トピックは、トピック型に限らず、同じ基本構造をもつ：タイトル、記述または要約、前文、本文、関係リンク、ネストされたトピック。
全DITAトピックはIDとタイトルを持たねばならない。トピック構造は次の部品から構成される：
短い記述は要求されていないが、情報セットの利用し易さに、劇的な差異をもたらし、全てのトピックに提供されるべきである。
全てのトピックは、トピック型に関わらず、同じ共通の構造の上に構築される。
基本的なトピック要素と属性を提供する幾つかのモジュールがある。あるものは、トピックとその専門化に特有であり、他はDITAマップと共有される。
DITAの概念トピックは、「これはなにか．．．」という質問に回答する。節や例示を含め、基本トピック構造をもつ本文レベルの要素を含むことができる。
概念は読者が製品、インターフェイス、タスクについての基本的な情報を理解するのを助ける背景を提供する。しばしば、概念はプロセスまたは関数のような主要な抽象的概念の拡張された定義である。概念情報は、製品について、また、その製品範疇にどのようにあてはまるかを説明することができる。概念情報は、ユーザが既存の知識を製品やシステムに関するタスクや他の基本的な情報にマップするのを助ける。
<concept>要素は、DITAの概念トピックのための最上位要素である。各概念は<title>、<conbody>、そしてオプションの<titlealts>, <shortdesc>, <abstract>, <prolog>, <related-links>そしてネストされたトピックを含む。
<conbody>要素は、概念のための主要な本体レベルの要素である。一般トピックの本体要素と同じように、<conbody>は、節や例示のほか、段落、箇条書き、他の要素を許す。しかし、<conbody>では、節や例示には、他の節や例示のみが後続することができるという制約がある。
ここに単純な概念トピックの例がある。
<concept id="concept">
<title>Bird Calling</title>
<conbody>
<p>Bird calling attracts birds.</p>
<example>
<p>Bird calling requires learning:</p>
<ul>
<li>Popular and classical bird songs</li>
<li>How to whistle like a bird</li>
</ul>
</example>
</conbody>
</concept>
concept.mod (DTD)
conceptMod.xsd, conceptGrp.xsd (Schema)
タスク・トピックは「私はどうする？」という質問に回答し、特定の目標を達成するための手続きをどうやって完了したら良いかを記述するうまく定義された構造を持っている。
タスクは、手続き情報を提供するための基本的な建築ブロックである。ひとつのタスク・トピックは「私はどうする？」という質問に、何をするべきか、それをするための順序について詳しく説明した詳細なステップ毎の指示を提供することで回答する。タスク・トピックには、文脈、前もって必要なこと、期待される結果、あるいはタスクの他の側面を記述するための節を含む。
<task>要素は、タスク・トピックのためのトップ・レベルの要素である。各タスク・トピックは、<title>と<taskbody>、及びオプションの<titlealts>, <shortdesc>または<abstract>, <prolog>, <related-links>そしてネストしたトピックを含む。
<taskbody>要素は、タスク・トピックの中の主な本体レベルの要素である。タスクの本体は、次の要素をこの順番でもつという、特別な構造をもつ：<prereq>, <context>, <steps>, <result>, <example> および <postreq>。各本体の節はオプションである。
<steps>要素は、タスクを達成するために従わなければならない行為を表す。タスクの各ステップは、全体のタスクを達成するために、ユーザが行わねばならない特定の行為を記述する命令<cmd>要素を含まねばならない。ステップ要素には、また、情報 <info>、部分ステップ <substeps>、使い方情報 <tutorialinfo>、ステップの例 <stepxmp>、選択 <choices>あるいはステップの結果 <stepresult>を含むことができる。しかしながらこれらはオプションである。
これがタスク・トピックの例である。
<task id="ertx">
<title>Creating an ERTX file</title>
<taskbody>
<context>Each morning before breakfast you need to create a fresh ERTX file.</context>
<steps>
<step><cmd>Start ERTX.</cmd></step>
<step><cmd>Click New ERTX File.</cmd></step>
</steps>
<result>You now have your ERTX file for today!</result>
</taskbody>
</task>task.mod (DTD)
taskMod.xsd, taskGrp.xsd (Schema)
参照トピックは、プログラミング言語のコマンドのような主題または製品についての通例の機能を記述する。
技術情報においては、しばしば、参照トピックはプログラム言語におけるコマンドなどのような主題をカバーするために使われる。参照トピックは、食物の調理法における材料、参考書のリスト、カタログ、などのような通例の内容をもつものを何でも保持することができる。参照トピックは、事実への迅速なアクセスを提供する。参照トピックのより深い理解や関連する手続きを実行するための情報は、概念またはタスク・トピックで提供するべきである。
<reference>要素は、参照トピックのためのトップ・レベル要素である。全ての参照トピックは、ひとつの<title>と<refbody>と、オプションの<titlealts>, <shortdesc>または<abstract>, <prolog>, <related-links>及びネストしたトピックを含む。
<refbody>要素は、参照トピックの主な内容を保持する。参照トピックは、本文構造を表（単純なもの、標準）、属性リスト、文法節、そして一般的節と例のみに制限している。
参照トピックの例を次に示す。
<reference id="boldproperty">
<title>Bold property</title>
<shortdesc>(Read-write) Whether to use a bold font for the specified
text string.</shortdesc>
<refbody>
<refsyn>
<synph>
<var>object</var><delim>.</delim><kwd>Font</kwd><delim>.</delim>
<kwd>Bold</kwd><delim> = </delim><var>trueorfalse</var>
</synph>
</refsyn>
<properties>
<property>
<proptype>Data type</proptype>
<propvalue>Boolean</propvalue>
</property>
<property>
<proptype>Legal values</proptype>
<propvalue>True (1) or False (0)</propvalue>
</property>
</properties>
</refbody>
</reference>
reference.mod (DTD)
referenceMod.xsd, referenceGrp.xsd (Schema)
DITAの各用語トピックは、ひとつの用語のひとつの意味を定義する。用語を識別し、定義を提供する他に、トピックは関連する用語を識別できる。
著者のチームが同じ用語を同じことに使うことができるように用語を定義することは、著者にとって役にたつ。読者は、身近でない用語の説明を得ることもできる。より一般的には、内容によって記述される事柄の識別は、これらの主題をより精密に扱うことを促進する。用語トピックは、著者またはプロセスによって、本、Webサイト、あるいは開発プロジェクトを含む、様々な目的のための用語集を作成するために組み立てられることができる。
<glossentry>要素は、DITAの用語集トピックのためのトップ・レベルの要素である。各用語集トピックは、<glossterm> と<glossdef>要素とオプションの<related-links>を含む。
用語が複数の意味をもつところでは、著者は<glossterm>要素の中で同じ用語、しかし、<glossdef>要素において別の定義をもつ複数のトピックを作成するべきである。プロセスは、フォーマットされた出力を作成するとき、用語集のエントリを用語毎に照合し、グループ化することができる。ある言語で同じ用語を持つ定義は、他の言語では別の用語をもつことがありうることに注意せよ、そこで、翻訳では、同じ用語集のエントリ集合の異なる照合、グループ化に帰結することがある。
ここに単純な用語集のエントリの例がある：
<glossentry id="ddl"> <glossterm>Data Definition Language</glossterm> <glossdef>A language used for defining database schemas.</glossdef> </glossentry>
用語集を作成するために、ditabase文書型(ditabase.dtd/ditabase.xsd)を使ってコンテナ・トピックの下に、ひとつの文書の中で編集するか、または、マップの中で用語集トピックを参照するか、または、例えば、特定のトピックの集合において、<term>マークアップに基づいてレポジトリから用語集トピックを選択するというような、自動化されたプロセスを使うことによって、著者は複数のエントリを一緒にグループ化することができる。
glossentry.mod (DTD)
glossentryMod.xsd, glossentryGrp.xsd (Schema)
DITA領域は、トピック型に関わりない、特定の主題範囲、または編集要求に関連する要素の組を定義する。
領域における要素は、領域要素をトピック型構造の中で利用できるようにするために、トピック型と統合されることのできる領域モジュールの中で定義されている。現在、次の領域が提供されている。
表9 DITAトピック型領域
| 領域 | 記述 | 短い名前 | モジュール名 |
|---|---|---|---|
| 印刷 | 適切な意味的な要素がまだ存在しないときハイライト化するため | hi-d | highlightDomain.mod (DTD) highlightDomain.xsd (Schema) |
| プログラミング | プログラミングとプログラミング言語を記述するため | pr-d | programmingDomain.mod (DTD) programmingDomain.xsd (Schema) |
| ソフトウェア | ソフトウェアを記述するため | sw-d | softwareDomain.mod (DTD) softwareDomain.xsd (Schema) |
| ユーザインターフェイス | ユーザインターフェイスを記述するため | ui-d | uiDomain.mod (DTD) uiDomain.xsd (Schema) |
| ユーティリティ | imagemapやその他の有益な構造を提供するため | ut-d | utilitiesDomain.mod (DTD) utilitiesDomain.xsd (Schema) |
| 索引付け | 見よ（see）、も見よ（see-also）などの拡張された索引付け機能のため | indexing-d | indexingDomain.mod (DTD) indexingDomain.xsd (Schema) |
マップは、ナビゲーション・ファイルや関係するトピックへのリンクを生成することを含め、特定の配布物のためにトピックを組織化する。
DITAマップは、トピック間の関係性を示すために、DITAトピックへの参照を集めて組織化する文書である。それらは、DITAの配布物のためのアウトラインや目次として、またDITAプロジェクトのビルド目録としても役立てることができる。
DITAマップは、ユーザの目標または他の要求の特定の組をサポートするための情報の組合せ—どんなトピックが必要か、どんな順序または関係か、の構成を表す。
マップは、トピックが読まれる文脈—聴衆、プラットフォーム、関連性、情報の組の要求、を記述する。こうすることで、トピックそれ自身は相対的に文脈から自由になり、マップに定義されるように、多くの異なる文脈でより容易に利用・再利用されることができる。
マップは、階層化したタスク分析のような情報モデルを定義するための既存のベスト・プラクティスや標準の豊富な組を利用する。それらは、また、行列やグループのような非階層化関係の定義も支持する。それらは、RDF（Resource Description Framework）やISOのトピック・マップとある種の類似性をもつ能力の組合せを提供する。これらの標準について、さらなる情報は、http://www.w3.org/RDF/とhttp://www.topicmaps.org/を参照のこと。
DITAマップ・ファイルはひとつ以上のDITAトピック・ファイルを<topicref>を使用して参照する。<topicref>要素は、参照されたトピック間の望ましい関係を反映するためにネスト化または他の方法で組織化されることができる。マップファイルは、適切に処理されるために、.ditamapというファイル拡張子をもつ必要がある。
マップは、内容を沢山の文脈を通じて拡大縮小可能に再利用することを許す。内容を計画、開発、配布するために、情報アークテクト、著者、出版社によって、使用されることができる。
マップがサポートする特定の使用の中には次のものがある：
DITAマップはDITAの内容と同じ共通の属性を多数持っている。しかし、また、異なる出力目的のために関係性が解釈される方法を制御するための幾つかの追加的なものを持っている。
DITAマップは、完全にまたは部分的に特定の媒体または出力の種類（例えば、ハイパーリンクされたWebページや印刷された本）に特有の構造を符号化しても良いので、DITAマップは、プロセサが各出力の種類のためにマップを解釈することを助けるための属性を含む。これらの属性（印刷と目次のような）は、DITAの内容では得ることができない：個別のトピックは、特定の種類の出力に関連付けられた高レベルの構造と依存性とから切り離されたら、複数のメディアを通じて完全に再使用可能であるべきだ。
集合タイプとリンク属性は、マップの中で記述されているトピックのために、どのように関連するリンクが生成されるかに影響を与える。
集合タイプ属性は、兄弟のtopicrefの特定の組が相互にどのように関係するかを示す。集合タイプ属性は、兄弟のtopicrefのためのコンテナ要素に設定する。集合タイプ値は、兄弟間にリンクを生成するか、どのような種類のリンクを生成するか（例えば、並びの次と前のリンク、または家族のための兄弟のリンク）。集合タイプ属性は、また、親のトピックがその子供にどのようにリンクするべきかを示すことができる（例えば、集合タイプが順序の時、子供のリンクを番号付き箇条として示す）。集合タイプ属性が、直接topicrefを含むことができない要素に利用できるところ（reltableやrelcolspecなど）では、属性の振る舞いは将来の使用のために留保されている。
既定値では、あるマップの中のトピックの関係は可逆的である：子供から親へのリンクとその逆；順序の中で次と前のトピックをお互いにリンク；家族の中で兄弟へリンク；関係表の中の同じ行の表セルの中のトピックが相互にリンク。既定の振る舞いは、リンク化属性を使って修正されることができる。これは、トピックが関係の中にどのように参加するかを変更する：
トピックの中で、<xref>または <link>要素をつかって、リンクを直接作成することもできるが、多くの場合マップに基づくリンクの方が好ましい。なぜならば、トピックの中のリンクは、トピック間に、再利用を妨げる依存性を作成するからである。
<topicref href="A.dita" collection-type="sequence">
<topicref href="A1.dita"/>
<topicref href="A2.dita"/>
</topicref>
<reltable>
<relrow>
<relcell>A.dita</relcell>
<relcell>B.dita</relcell>
</relrow>
</reltable>図1 単純なリンクの例
| A | A1, A2へ子供としてリンクする |
| Bへ関係としてリンクする | |
| A1 | Aへ親としてリンクする |
| A2へ、並びの中で次へとしてリンクする | |
| A2 | Aへ親としてリンクする |
| A1へ、並びの中で前へとしてリンクする | |
| B | Aへ関係としてリンクする |
図2 リンク化属性をもつリンク化の例
<topicref href="A.dita" collection-type="sequence">
<topicref href="B.dita" linking="none"/>
<topicref href="A1.dita"/>
<topicref href="A2.dita"/>
</topicref>
<reltable>
<relrow>
<relcell>A.dita</relcell>
<relcell linking="sourceonly">B.dita</relcell>
</relrow>
</reltable>
| A | A1, A2へ子供としてリンクする |
| Bへは子供としてのリンクがなく、Bへは関係としてのリンクがない | |
| A1 | Aへ親としてリンクする |
| A2へ並びの中の次へとしてリンクする | |
| （Bへの前へとしてのリンクはない） | |
| A2 | Aへ親としてリンクする |
| A1へ並びの中で前へとしてリンクする | |
| B | Aへ関係としてリンクする |
特定出力媒体の内容を識別したり、トピックの処理をまとめ直すために使える標準属性がある。
著者はtoc属性を使って、ナビゲーションの出力（オンラインの目次やWebサイトのマップ）からエントリを除外することができる。既定値では、ナビゲーション出力では階層を含めるが、表は除外する。
著者は、navtitle属性を使って、ナビゲーションでの利用のためのより短いタイトルを提供することができる。既定値では、navtitle属性は無視され、著者が対象とするトピックのタイトルを追跡し続けることを支援するためにのみ使われる。locktitle属性は、navtitleが効果を持つことを確信するために設定でき、対象とするトピックの、またはトピック参照メタデータの中のどこかで定義されている、任意のタイトルの値を乗り潰す。
トピックには印刷出力と検索の索引に含めるべきかどうかを示す属性を設定できる。
トピックの組がマップを使って変換されるとき、処理のまとめ（chunk）属性を使って、多数のトピックをもつファイルはより小さなファイルに分割されることができ、また、多数の独立トピックはひとつのより大きなファイルに結合されることができる。処理のまとめ属性には既定値はないが、マップ要素に処理のまとめ属性を設定するか専門化によって、マップ全体の既定値を確立することができる。処理のまとめ属性とその利用についての詳細は、「処理をまとめる（Chunking）」を参照せよ。
一組のトピックをマップを使って変換するとき、copy-to属性を使って、重複するトピックの版を作成することができる。複製されたトピックは、copy-to属性の中で提供される新しいファイル名と位置を持つ。またマップは、topicrefのnavtitleまたはshortdescを使って、マップの中で新しい値を提供することで、この特定の複製のために、既定値のタイトルとshortdescを乗り潰すことができる。copyto属性が、処理のまとめ属性と共にどのように使われるかについての情報は、「処理をまとめる（Chunking）」を参照せよ。
DITAマップは、DITAトピックが使うのと同じメタデータを使い、同じ属性を再利用する。
DITAマップは、DITAの内容でlinkまたはxref要素と共に使われる同じ属性の多くを使う。
新しい属性が、領域としてpropsまたはbaseから専門化されるとき、それらをマップとトピックの構造化型に組み込むことができる。
マップは、トピックを階層、表、グループに組織化し、他のマップを参照するための特殊な要素をもつ。
topicref要素は、マップの基本要素である。topicrefはDITAトピック、マップ、または、処理されたりリンクを張られることのできる任意の他の資源を指し示すことができる。それらは、また、タイトル、短い記述、またトピックで使うことのできるある種の前文レベルのメタデータをもつことができる。
topicref要素は、階層を作るためにネスト化されることができる。それで、印刷出力、オンライン・ナビゲーション、親／子のリンクを定義するために使うことができる。topichead要素は、階層のノードとして使われることができる。それは、同等のトピックなしのコンテナを提供する：それらはnavtitleをもつがhrefまたは同等の参照属性をもたないtopicref要素と同等である。
関係性の表は、reltable要素で定義される。関係性の表は、同じ行の異なるセルにあるトピックの間の関係を定義するのに用いられる。関係表では、列は、その列の中のトピックのための共通の属性またはメタデータを定義する。行は、関係性を定義する。行内の各セルは、関係性において異なる役割を現す。例えば、概念、タスク、参照トピックのために異なる列をもつ表でタスクとそれを支持するトピックの関係を定義することができる。
階層構造と表には、例えば、選択肢、並び、家族など特定の集合の一部である兄弟の組を定義するためのcollection-type属性を使って、注釈をつけることができる。これらのcollection-typeは、リンクの作成に影響を与え、異なる出力において異なる解釈をされることがある。
階層または表の外部のグループや集合は、topicgroup要素によって定義できる。これは、参照する属性またはタイトルがないtopicrefと同等である。例えば、グループを表セルの中または階層中の兄弟の組に含めることによって、グループは階層または表と結合されることができる。
マップの中の大多数の要素は、マップ自身を含めて、メタデータを含むことができる。それは、典型的には要素とその子孫に適用される、これについては、「マップにおける属性とメタデータの継承」に詳しい。
<map> <reltable> <relheader> <relcolspec type="concept"/> <relcolspec type="task"/> <relcolspec type="reference"/> </relheader> <relrow> <relcell> <topicref href="A.dita"/> </relcell> <relcell> <topicref href="B.dita"/> </relcell> <relcell> <topicref href="C1.dita"/> <topicref href="C2.dita"/> </relcell> </relrow> </reltable> </map>
| type=″concept″ | type=″task″ | type=″reference″ |
|---|---|---|
| A | B | C1 C2 |
| A | B, C1, C2へリンク |
| B | A, C1, C2へリンク |
| C1, C2 | A、Bへリンク |
マップは、トピックと同じモジュール構造をもつ。そして、メタデータを定義するための同じモジュールの一部を共有する。
マップの属性とメタデータの一部は、マップの構造に基づいて継承されることができる。
継承は、矛盾を引き起こす場所を除いて追加的である。矛盾が起こる場所では、topicrefの最も近く（最も専門的）に定義された値が効果をもつ。関係表では、行レベルのメタデータは、列レベルのメタデータよりもより専門的であると考えられる。次の抑制階層に示す。
次の属性とメタデータ要素は継承される。
属性とメタデータは、マップ全体に適用するためにルート・レベル（マップ要素それ自身の属性、マップ要素の直接の子供であるtopicmeta）で定義できる。それらは、階層、グループ、表の任意の箇所でも適用され得る。表は、属性とメタデータ管理のために特に有用である。なぜならば、それらは、個別のセルと同様に列全体と行に適用されるからである。
処理のまとめ（chunk）属性は、もはや、コンテナから値を継承しない（DITA 1.1から新たに）、マップまたはマップ専門化要素にchunk属性の値を指定することは、処理のまとめのための既定値を確立する。その既定値は、文書のどこか別の箇所で、より特定のchunk属性の設定によって乗り潰されない限り、マップ全体に適用される。
「マップとトピックの間のメタデータの継承」
マップの中のtopicmeta要素は、メタデータの宣言のための数え切れない要素を含んでいる。一般的に、topicmeta要素でメタデータを指定することは、そのトピックをそのメタデータが適用されない他のマップで再利用することを許しながら、それをトピックの中で指定することに等しい。メタデータの中の多数の項目は、マップの中でネスト化したトピック参照に情報が伝達される。
DITAの標準DITAマップのブックマップ専門化では、DITAトピックを、本または他のページレイアウトとして印刷される集合体に組織化することができる。
DITAのOASISブックマップ応用では、DITAトピックと、さらにすべてのDITAマップを、形式的に定義した本の内容として作成することができる。これにより、オンラインの配布物のためのみでなく、表紙、形式的な注意、前文などを満たした同じ内容のPDFのマップを作成することができる。
ブックマップは、情報を本として製造するマップのための主要な構造と設定情報を定義する特殊な種類のDITAマップである。
典型的なDITAマップは、タイトルと、topicrefの組を、順番に、階層的に、あるいは両方の形で持つかもしれない。これで、トピックを完全な情報配布物としてみることができる構造を定義する。DITAマップは、トピックが、章、前文の内容としてどのように扱われるかを特別に指定したり、あるいは表紙または特殊な内容（版数の注意の雛形など）を構成するための構造を持たない。DITAの内容を、本により近い方式で見ることを可能にするためには、マップまたはマップの組を本として作成することに投資されるであろう、特別な処理を表現する文脈を必要とする。これはDITAのブックマップ専門化の役割である。
ブックマップは次の専門化された主要な構造を持っている：
ブックメタは、DITAマップのtopicmeta要素の専門化である。それは、ブックマップによって表される特定の本に関する情報を保持するための特殊な内容をもつ。
ブックリスト（booklist）とは、本の内容から情報の集合を示す専門化したtopicrefである。<booklist>要素の組（または、booklistから由来する要素）は、<booklists>要素の中に含まれる。
ブックリスト共通の種類は目次である。もし、望むならば、脚注の表のような完全に新しい集合を定義したり、その内容で事前に埋めたトピック、または、本の処理の間にそのトピックの内容を集めて挿入する処理を提供することができる。
OASISのブックマップの中で、次のような用途の特定のbooklist要素を提供している：
本の前付けは典型的には、序文、指示、または実際の本の内容に先行する他の導入素材である。
特定の前付け要素は任意数の次の要素を含む：
本の後付けには、典型的には、本の主内容に続く、閉じる情報を含んでいる。
特定の後付け要素は任意の数の次の項目を含む：
DITAマップの専門化として、DITAブックマップは、DITAを意識したエディタまたは処理ツールでは、典型的なDITAマップのように既定値として支持される。
適切なスタイルと関数の乗り潰しをもって、XMLエディタはDITAブックマップを、あたかも他の、本をサポートするDTDのためのXML構造のように表示できる。そして専門化されたDITAの処理またはDITAブックマップは、本のメタデータと本の特徴を高品質な出力に利用する。
例えば、DITAトピックの特定のWeb配布物のために意図した階層構造を表すDITAマップを持っているかもしれない。そのとき、同時に、箱に入れた製品と一緒にパッケージ化する形式的な本として、そのマップを作ることを望む。新しいブックマップ・インスタンスを開き、その本のためのタイトルを定義し、本のメタ領域に任意の必要な出版者情報を示し、前文の中にリンクし、目次とともに図の一覧を必要とするかどうかを示し、最後に、既存のDITAマップを参照する章要素を作成する。ブックマップの設計で、あなたの配布物を洗練し、そのマップの本版が、Web版に対比して、本版に特有の内容をもつようにすることもできる。
<bookmap id="taskbook">
<booktitle>
<mainbooktitle>Product tasks</mainbooktitle>
<booktitlealt>Tasks and what they do</booktitlealt>
</booktitle>
<bookmeta>
<author>John Doe</author>
<bookrights>
<copyrfirst>
<year>2006</year>
</copyrfirst>
<bookowner>
<person href="janedoe.xml">Jane Doe</person>
</bookowner>
</bookrights>
</bookmeta>
<frontmatter>
<preface/>
</frontmatter>
<chapter format="ditamap" href="installing.ditamap"/>
<chapter href="configuring.xml"/>
<chapter href="maintaining.xml">
<topicref href="maintainstorage.xml"/>
<topicref href="maintainserver.xml"/>
<topicref href="maintaindatabase.xml"/>
</chapter>
<appendix href="task_appendix.xml"/>
</bookmap>
DTD:
bookmap.dtd
bookmap.mod
Schema:
bookmap.xsd
bookmapGrp.xsd
bookmapMod.xsd
次の領域は、それらを統合するマップ文書型の拡張機能を提供する。
本のメタデータは、特に、人や場所の宛名のための、多数の他のメタデータ標準と共通性を持っている。DITAのブックマップ・メタデータ内容モデルから、既存の標準への密接なマッピングを表すために、OASISのxNAL（拡張可能な名前と住所の言語(extensible Name and Address Language)）が選択された。
OASISの、グローバルな顧客情報管理のためのCIQ標準には、OASISのextensible Name and Address Language（xNAL)メタデータ要素の定義を含んでいる。この標準の第2版には次のように記述している：
xNALの目的は、顧客の名前と住所を共通の標準形式で表したいと望む任意のアプリケーションを可能にする、個人または組織の名称と住所の共通構造を記述することである。このアプリケーションは、CRM/e-CRM、顧客情報システム、データの質（パージング、マッチング、妥当性検証、確認など）、顧客データ・ウェアハウス、郵便サービスなどがありうる。
しかしながら、任意のグループが、自身の目的やアプリケーションのためにxNALの文法やその一部を使用することができる。
ブックマップのために定義されているメタデータ要素は、著者や内容の所有者を識別する構造を、当然に、含んでいる。xNALの標準定義を部分集合化して、直接DITAに入れることは、二つの処理機構の間の違いのためにできなかったが、OASISのDITA技術委員会のメンバーは、ブックマップとxNALの名前と住所の定義の間で、最低限、変換による等値性をもつことには価値があると決定した。この等値性により、XMLを意識するツールは、ワークフローの中でDITAのブックマップの名前と住所を標準的な方法で捕らえて、操作することが可能になる。
DITA 1.1では、xNAL領域は、ブックマップ専門化の一部である。このことは、xNAL要素がブックマップが—bookmetaとtopicmetaの中で—<author>要素を許す任意の場所に現れることを意味する。
DITAのトピック型とマップ型で、同じ、メタデータ要素と沢山の同じ属性を使うことができる。メタデータ要素の共有で、トピックが作成されるときに割り当てられたメタデータが、トピックを集合に含めた時に、追加されたり、乗り潰されることが許されることになる。属性の共有は、内容の再利用や条件付の処理などの処理行為が、マップとトピックの間で一貫して実装できることになる。
次のメタデータ要素はマップとトピックの両方で発生する。
DITAのメタデータ要素の多くは、Dublin Core要素のtitleのような、DITAの<title>要素に対応つけられているものを例外として、Dublin Coreメタデータ(http://dublincore.org/)に対応付けられる。
これらの要素は、出版としてのトピックに関する標準の情報を提供する。
ある種の内容プロバイダは、このような情報を、配布物のマップ内または最初のトピックの中でのみ提供することを選ぶかもしれない。
これらの要素はトピックの出版プロセスを管理するための基礎を提供する。
管理要素はワークフローの処理によって更新されるかもしれず、あるいは、その処理への入力を提供する：
これらの要素はトピックについて追加的な情報を提供するために使われることができ、また、属性値について、より多くの情報を提供するために、条件付処理属性と一緒に使われることがある。
メタデータ要素はトピック全体に適用され、また、メタデータを多数のトピックに一度に適用されるために使われることもできる。メタデータ要素はメタデータ属性に使われる値を広げることができる（メタデータ属性を参照のこと）。例えば、トピックの前文の中の聴衆要素は、型、仕事、経験のレベルの用語で聴衆を定義、またそれに名前をつけることができる；トピックの本体にその聴衆のみに適用される内容が存在するとき、その内容は聴衆を前文で使われているのと同じ名前で識別することができる。
メタデータがマップの中で表現されているとき、それは、それが参照しているトピックで表されている任意のメタデータを補う。マップの中のメタデータとトピックが矛盾する（例えば、両方が出版社を定義する）とき、既定値では、マップの中の値が、そのマップの著者が、トピックの著者よりも再利用する内容についてより多くの知識を有しているという仮定のもとに、優先される。
次の属性は、大部分のDITA要素を通じて共通である。
idとconref属性はほとんどすべてのDITA要素で使うことができ、DITAのトピックとマップの間で内容の共有を許す。
IDと参照
DITA識別属性は、検索またはリンクのために内容を識別するための機構を提供する。IDを参照するための文法は、参照機構によらずに一貫している。
内容の包含（conref）
DITAのconref属性は、内容の断片を再使用するための機構を提供している。conref属性は他の要素への参照を蓄積し、参照している要素を、参照されている要素によって置き換えるために処理される。
メタデータ属性は、内容についての修飾を表現する。これらの修飾は、内容の処理を変更するために使われ得る。
メタデータ属性のひとつの典型的な使用は、その値にもとづいて内容にフィルターを掛けることである。他の典型的な使用は、例えば、出力において影響を受けるテキストを強調するなど、その値にもとづいて内容にフラグ付けすることである。典型的には、聴衆、プラットフォーム、製品、その他の特性をフィルター化のために使用し、同じ属性に加えてrevをフラグ付けに使用する。例えば、タスクにおいて、マーク付けしたステップをオプションとするか必須とするか、など状態と重要度をツール特有または変換特有の振る舞いのために使用する。
一般的に、条件付処理属性は、空白で分離された、ひとつ以上のリストを提供する。例えば、audience="administrator programmer"は、内容が管理者とプログラマに適用するとして修飾する。
大部分の要素に使える、条件付処理のためのいくつかの属性がある。
その他の属性は、要素のメタデータの一部と考えられる。しかし、フィルタリングやフラグ化のように、条件付処理のために設計されていない。
DITAは、翻訳を支援するため、また特定の要素の追加的な分類やタイプ化を提供するためのいくつかの要素を持っている。
DITA要素のさまざまな属性には次のものを含む：
@xml:lang, @translate, @dir属性については、「翻訳」により詳しく記述されている。
DITAは、プロセサへ型情報を提供するために、内容の制限や特性の代わりに、ある種の属性を提供している。
通常では、アーキテクチャ属性は、文書のインスタンスのためのソース・ファイルの中には現れない。そうではなく、DTDまたはスキーマ宣言の中で、既定値を通じて、文書インスタンスに現れる。この方法は、文書インスタンスの作成はアークテクチャ属性のための妥当でない値を生み出すことがないことが保証される。これらの属性には次のものが含まれる：
DTDまたはスキーマ宣言なしで、文書インスタンスを利用可能にするために、標準化処理がアーキテクチャ属性を文書インスタンスに染み込ませることができる。
トピック（メタデータ属性とメタデータ要素を含む）の特性は、トピックそれ自身またはマップの中でトピックへの参照によって指定されることができる。
トピックの中で、特性を表現するには、トピック要素のメタデータ属性を使うか、トピックの前文の中で、publication, managementまたはmetadata要素を使うかして可能である。
DITAは、トピック特性を適用する3つのレベルをユーザに提供する。トピック属性とメタデータ要素は、トピックそれ自身の中で定義されることができる。特性はそのトピックを指し示すtopicrefの属性または下位要素として設定されることもできる。加えて、特性は、マップの中のtopicrefのコンテナか先祖に設定されることもできる。ナビゲーションの階層の枝にあるトピックは、典型的に、ある種の共通の主題または特性を持っているので、これは、トピックの組に特性を設定するための便利な機構である。
特性がマップとトピックの両方に設定されているとき、その特性が（聴衆の型のような）値の一覧を取るならば、マップの特性は追加的である。もし、代わりに、その特性が（重要度のように）単一の値を取るなら、マップ特性はトピック特性を乗り潰す。
前文のメタデータ要素は、内容についてのメタデータ属性で使われている値よりも多くの情報を提供することができる。しかしながら、前文のメタデータと属性メタデータは、独立して使われたり表現されることができる。ここに示されている整合性は可能であるが必須ではない。
<prolog>
<metadata>
<audience name="AdminNovice"
type="administrator"
job="customizing"
experiencelevel="novice">
</metadata>
</prolog>
....
<p audience="AdminNovice ProgrammerExp">This paragraph applies to both
novice administrators and expert programmers</p>
上の例では、″AdminNovice″という属性値は同じ名前をもつ聴衆要素、これは著者や処理に対して問題になっている聴衆についてより多くの情報を与えるもの、と連携している。このケースでは、″AdminNovice″な聴衆は、カスタマイズ化（customizing）、新参な（novice）管理者であるという。
トピックのメタデータをマップの中のトピックまたはトピックの枝と連携つけることができる。既定値ではマップの中のメタデータがトピックの中のメタデータを補完するか乗り潰す。もし、lockmeta属性が″no″に設定されているならば、マップの中のメタデータはトピックの中のメタデータより優先することはなく、矛盾があったらトピックを優先する方向で解決される。
マップの中では、メタデータ要素は<topicmeta>要素、これはメタデータを<topicref>またはそれを包含する他の要素と関係つける、とその要素の他の子供の中で編集される。例えば、<relcolspec>の中の<topicmeta> は、<reltable>の中で参照されているすべてのトピックとメタデータを関係付けることができる。
マップの中のメタデータ要素は、トピックの中のそれと同じである。しかし、異なる順序になっても良い。マップ・メタデータは、短い記述と代替タイトルも含み、それは、内容の中の同じものを乗り潰す。まとめると、マップはトピックについて、内容（トピックの本体要素の中の）以外と主タイトルを除くすべてのものを乗り潰し、あるいは、それを補うことができる。
マップの中のtopicmeta要素は、メタデータの記述のために数多くの要素を含んでいる。全体的に、メタデータをtopicmeta要素の中で指定することは、それを、トピックがそのメタデータが適用されない他のマップの中で再利用されることを許しながら、トピックの中で指定することに同等である。メタデータの中の多くの項目はマップの中のネストされたトピック参照にカスケードする（小滝のように落ちる）。
topicmetaの中のそれぞれの要素について、次の表は3つの異なる振る舞いを提供する。
表10 Topicmeta要素とその特性
| 要素 | それがトピックにどのように当てはまるか？ | それがマップの中の他のトピックにカスケードするか？ | マップのレベルで指定されたときの目的はなにか？ |
|---|---|---|---|
| audience | トピックに追加 | はい | マップ全体のための聴衆を指定する。 |
| author | トピックに追加 | はい | マップ全体のための著者を指定する。 |
| category | トピックに追加 | はい | マップ全体のための分類を指定する。 |
| copyright | トピックに追加 | はい | マップ全体のための著作権を指定する。 |
| critdates | トピックに追加 | はい | マップ全体のためのクリティカルな日付を指定する。 |
| data | トピックに追加 | それが継承する目的に専門化されない限り、いいえ | 要素が指定されるまで、言明された目的はない。 |
| data-about | 特性を指定された対象に追加する | それが継承する目的に専門化されない限り、いいえ | 要素が指定されるまで、言明された目的はない。 |
| foreign | トピックに追加 | それが継承する目的に専門化されない限り、いいえ | 要素が指定されるまで、言明された目的はない。 |
| keywords | トピックに追加 | いいえ | 言明された目的はない |
| linktext | トピックに追加されない；マップの中でこの発生に基づいて生成されたリンクに適用する | いいえ | 言明された目的はない |
| othermeta | トピックに追加 | いいえ | マップ全体のためのメタデータを定義する |
| permissions | トピックに追加 | はい | マップ全体のための許可を定義する |
| prodinfo | トピックに追加 | はい | マップ全体のための製品情報を指定する |
| publisher | トピックに追加 | はい | そのマップのための出版社を指定する |
| resourceid | トピックに追加 | はい | そのマップのためのリソースIDを指定 |
| searchtitle | トピックの中のそれを置換する、ひとつの対象に多数の検索タイトルが与えられたとき、プロセッサは警告を発することを選んでも良い | いいえ | 言明された目的はない |
| shortdesc | トピックに追加されていない；マップの中でこの発生に基づいて生成されたリンクに適用される | いいえ | マップの記述を提供する |
| source | トピックに追加 | いいえ | マップのためのソースを指定 |
| unknown | トピックに追加 | カスケードする目的に指定されない限り、いいえ | 要素が指定されるまで、言明された目的はない |