级别： 初级 Don Day (dond@us.ibm.com)IBM Corporation
Michael Priestley (mpriestl@ca.ibm.com)IBM Corporation
David Schell (dschell@us.ibm.com)IBM Corporation
2001 年 3 月 01 日
更新 2006 年 2 月 20 日 Darwin Information Typing Architecture (DITA) 是一种基于 XML 的、端到端的编辑、生产和交付技术信息的体系结构。该体系结构由一组在主题层创建 “information-typed” 模块和在交付模式中使用这些内容（比如在线帮助和 Web 上的产品支持门户）和设计原则组成。本文是 DITA 的路线图：它是什么以及如何将其应用于技术文档。
Darwin Information Typing Architecture (DITA) 是一种基于 XML 的、端到端的编辑、生产和交付技术信息的体系结构。该体系结构由一组在主题层创建 “information-typed” 模块和在交付模式中使用这些内容（比如在线帮助和 Web 上的产品支持门户）和设计原则组成。
DITA 的核心是一个称为 “主题 DTD” 的 XML 文档类型定义（DTD），代表面向主题的信息体系结构的一般构造块。不过，这种可扩展的体系结构是此技术信息设计的定义部分，主题 DTD 或者任何以此为基础的模式，仅仅是这种体系结构设计原则的一个实例。
本文是 Darwin Information Typing Architecture 的路线图：它是什么以及如何将其应用于技术文档。它也是这种体系结果的一个产物，完全用 XML 编写并采用这里描述的基本原则。
背景
这种体系结构和 DTD 是由代表不同 IBM 子公司用户支持部门的跨部门联合工作组设计的。在 1999 年末经过初步调研后，2000 年通过使用数据库记录和每周一次的电话会议，工作组共同开发了这种体系结构。这种体系结构作为一种可选的基于 XML 的文档系统放在 IBM developerWorks 网站上，利用 XML 作为编码格式。随着这些重要更新的发布，其中包括对一致性和灵活性的改进，我们认为 DITA 设计已经完成了原型阶段。
信息交换、工具管理和可扩展性
IBM 的产品文档有数百万页，拥有自己非常复杂的 SGML DTD、IBMIDDoc，从 20 世纪 90 年代起开始支持这些文档。工作组在一开始必须考虑，“为何不简单地修改一下 IBMIDDoc，或者使用现有的 XML DTD 如 DocBook、TEI 或 XHTML？” 答案要从技术信息的特点中寻找。
首先，SGML 和 XML 都是按照元语言组织的，允许数据所有者团体以反映其信息开发、存储和处理的方式描述信息资产。因为知识表示与企业文化以及社区行话密切相关，多数定义定义 DTD 的尝试结果都毫无用处或者无疾而终。信息交换的理想 是与其他数据拥有团体分享这些信息的语义和转换规则。
其次，多数企业依赖于很多交付系统，或者以各不相同的方式处理信息。因此试图建立一套通用工具集 的任何尝试都被证明是无效的。工具管理的目标 是根据标准化的处理体系结构，利用其他很多人的经验，解决较大范围内的公共问题。
第三，形式化文档描述词汇表（DTD 或模式）的多数努力已经作为捕捉数据所有者当前业务实践 的信息建模活动而完成。这种方法倾向于在最终的 DTD 或词汇表中编码
遗留的 实践。技术信息（或者先进技术不断利用的任何信息）DTD 中未来可扩展的目标 是在 DTD 设计中对自顶向下的处理系统作尽可能少的假设。
一开始，工作组试图理解 XML 在这种信息技术进步中的作用。随着工作的进展，工作组认识到任何 DTD 设计工作都必须考虑到词汇表的多样性、工具不确定性处理范型和摆脱过去对信息结构的观点。目前很多 DTD 包含了解决其中一些问题的方法，但问题的广度决定了不仅仅是一个 DTD 能解决的。为了支持多种产品、品牌、企业、风格和交付方法，我们必须考虑整个编辑到交付的过程。最终我们得到了大量的建议，要求我们不能仅仅把设计表示成一个 DTD 而是一种信息体系结构。
DITA 体系结构的主要特性
正如 DITA 这一名称中的 “体系结构” 所暗示的，DITA 在组织和集成信息方面具有独到的特性：
-
面向主题。DITA 中最高的标准结构是主题。任何比主题更高的结构通常都是主题处理上下文中的一部分，比如打印组织结构或者一组主题中类似帮助集合的导航。主题也没有内部层次嵌套，而依赖于定义或直接支持主题的 section。
-
重用。DITA 的一个主要目标是减少将内容从一个地方复制到另一个地方来重用内容的需要。DITA 中的重用在两个层次上：
-
主题重用。因为主题没有嵌套结构，所以主题可在任何类似主题的上下文中重用。信息设计者知道何时需要在新的信息模型中重用一个主题，体系结构则在新的上下文中以一致的方式处理它。
-
内容重用。XML 用户也能使用声明可重用外部实体的 SGML 方法，但是 XML 中这种方法有一些实际的限制。DITA 倾向于采用一种不同的 SGML 重用技术，为每个元素提供了一个 conref 属性，可以指向同一主题或不同主题中的其他任何等价元素。这种引用机制从一个基准元素开始，从而保证故障安全结构总是调用主题（包含带有 conref 属性的元素的主题）的一部分。新内容在功能上一定和它代替的元素等价。
-
规范。CSS 中的 class 机制代表着适用于具有匹配 class 值的任何元素的公共格式化语义。同样，任何 DITA 元素都可以扩展成一个新元素，其标识符通过 DTD 增加到 class 属性中。因此，新元素总是和其基准或者规定序列中的任何元素联系在一起。
-
主题专门化。应用于主题结构，自然专门化就成为将一般主题扩展成新信息类型（或 infotype）的一种方式，后者又可以扩展成更特殊的信息结构实例。比如，菜谱、重要的安全数据表以及百科全书文章都可能从一个公共的引用主题派生出来。
-
领域专门化。利用同样的专门化原理，一般主题（或者信息类型化主题集）中的元素词汇表可以通过引入反映这些主题所服务的特定信息领域的元素来进行扩展。比方说，一个关键字可以扩展成菜谱中的重量单位、硬件参考中的部件名称或者编程参考中的变量。专门的领域，如编程惯用语，可通过在任何允许根元素的地方进行置换来引入。这样，学科中使用的所有信息类型化主题就都能使用整个词汇表。此外，还可以替换现有信息类型化主题中的领域，向处理其他学科内容的作者隐藏该学科中的行话。同时这两套主题可能都适合执行任务或者获取引用信息的同一用户角色。
-
基于属性的处理。DITA 模型提供了元数据和属性，可用于通过诸如内容管理系统、搜索引擎、处理过滤器之类的应用程序来关联或者过滤 DITA 主题的内容。
-
广泛的元数据使得主题更容易发现。DITA 元数据模型支持 Dublin Core Metadata
Initiative 标准分类。此外，DITA 元数据还支持将很多不同的内容管理方法应用于内容。
-
统一的属性。主题 DTD 中的多数元素都包含一组统一的属性，使元素可以用作选择器、过滤器、内容引用基础设施和多语言支持。此外，有些元素经过分析以保证它们的枚举值为专门化提供丰富的基础（通常包含约束值，而且不会增加），这些元素的属性有特殊的作用。
-
利用已有的标记和工具。DITA 没有背弃大家熟悉的事物，而是采用了广为接受的一组标记，可用标准 XML 工具处理。
-
利用流行的语言子集。DITA 主题 DTD 的核心元素借自 HTML 和 XHTML，在类似 HTML 的主题结构中使用众所周知的元素名如 p、ol、ul 和 dl。事实上，编写的 DITA 主题可以像 HTML 一样直接在浏览器中呈现。在更为雄心勃勃的设计中，DITA 主题可以像 SGML 那样通过处理规范化成交付品，比如 XHTML 或者利用特定浏览器 XML 处理能力的结构良好的 XML。此外，DITA 还利用了流行的 OASIS（原来的 CALS）表格模型。
-
利用流行的和得到广泛支持的工具。XML 处理模型得到了很多厂商的广泛支持。DITA 基于 class 的扩展机制很容易转化成 W3C 定义的 XSLT 和 CSS 样式表语言的设计特性，这些特性得到了众多转换工具、编辑器和浏览器的支持。DITA 主题可以用各种工具处理，包括共享软件和自定义产品，差不多能在所有操作系统上使用。
 |
|
基本结构单位：主题
在线交付的各种信息体系结构都倾向于把主题的概念作为这类信息的主要设计点。主题是一种信息单位，描述了一项任务、一个概念或者一个参考条目。信息范畴（概念、任务或引用）就是其信息类型（或 infotype）。可以通过专门化基础主题 DTD 的结构来引入新的信息类型。类型化主题很容易在内容管理系统中当作可重用的、独立的信息单位。比方说，可以在交付上下文 中收集、安排和处理所选择的主题来提供不同的交付品。交付品可以是一组供审核的最近更新的主题、用于用户支持应用程序的帮助集或者从用户所选搜索结果或 “交易清单” 中打印的手册中的章节。
DITA 体系结构的优点
通过主题粒度和主题类型专门化，DITA 为信息集带来了面向对象模型的以下优点：
-
封装。主题类型的设计值只需要处理特定的、可控的问题域。作者只需要学习针对该主题类型的元素。处理特定类型的实现者只需要处理那些专门的元素。
-
多态。特殊的主题类型可作为更一般的主题类型进行常规处理。
-
消息传递。在元素的派生层次结构中一直保持 class 属性。主题随时可以一般化为任何原来的形式，如果保留 class 属性，这些主题可以重新专门化。这种功能的应用之一是可以让两个不同的学科在专门化层次结构中较早的公共部分合并数据，此后可以将其转化成这种、那种或者一种全新的领域和信息类型化主题集。
之所以将 DITA 看作是面向对象的是因为：
- 数据和处理从环境中分离出来，可以结合在一起提供类似面向对象的行为（比如修改或重定义原有行为的覆盖转换）。
- 通过一系列派生形成的元素分类越来越具体，可能约束越来越多，总是严格地与一致的处理和呈现模型联系在一起。
- 行为的继承，新元素或者完全集成派生层次中其祖先的行为，或者映射到扩展原有行为的经过修改的处理程序。
原则性和灵活性结合，主题信息集的一些优点可以通过图书 DTD 体现出来。具体来说，组块技术可以从图书 DTD 中生成主题。在 DITA 中逆向方法是可能的：可以从一组 DITA 主题组成图书。但无论哪种情况，对于 DTD 的主要目标而言这种适应性是第二位的，就是说，如果编写图书，最好的办法是使用为图书设计的 DTD。如果主要编辑主题，则最好使用为主题设计的 DTD，也可放大到大型的、可处理的主题集合。
DITA 概述
Darwin Information Typing Architecture 在文档各个部分、处理程序和信息的用户团体之间定义了一些关系。DITA 具有下列与其核心 DTD 中表达的具体设计点 topic 有关的层次。
Darwin 信息类型化体系结构中的层次
| 交付上下文 |
| helpset | 聚合打印（aggregate printing） | 网站、信息门户 |
| 跨信息类型的专门化词汇表（领域） |
| 类型化主题： | 概念 | 任务 | 引用 | | 包含的领域： | 突出显示 软件编程用户接口 |
类型化主题，无论概念、任务还是引用，都是独立的、可以发布的信息单位。类型化主题层之上是任何处理应用程序，可能由一个 DTD 超集驱动；之下是作为体系结构中所有专门化 DTD 基础的两种内容模型。下面我们分别讨论每一层。
DITA 交付上下文
这个领域代表主题信息的处理层。主题可以单独处理，也可以在将多个主题结合成定义好的可交付品的交付上下文中处理。交付上下文也包括文档管理系统、编辑单位、传输过程中的打包，等等。
| 交付上下文 |
| helpset | 聚合打印（aggregate printing） | 网站、信息门户 |
DITA 类型化主题的专门化（infotyped 主题）
类型化主题代表 DITA 面向主题内容的基本结构层。该体系结构的基础是主题 结构，由此衍生出了概念、任务 和引用 结构。还可以通过进一步的专门化扩展其他类型化主题。
这四种信息类型（主题、概念、任务和引用）代表了技术文档团体中使用的基本内容类型。此外，如果需要还可以以这四种基本类型为基础专门化其他信息类型。
该体系结构值得一提的一个特点是，团体可以定义或扩展表示自己数据的新的信息类型。这类内容如产品支持信息、编程消息描述和 GUI 定义。除了能够类型化主题和定义特定的内容模型外，DITA 还能够扩展适合于某个领域的标记词汇表。领域专门化代替了 DITA 最初设计中所谓的 “共享结构”。
DITA 词汇表专门化（领域）
一般来说，当一组信息类型化主题在一个知识领域中使用的时候，比如计算机软件或硬件，则信息类型化主题之间会有一个公共的词汇表。但是，同样的类型化主题也能在具有不同词汇表和语义的领域之间使用。比如，硬件参考主题可能引用诊断代码，而软件参考主题可能引用错误消息号，无论哪个领域都不一定要为其作者公开另一个领域的专用词汇表。
使用和主题专门化同样的技术，DITA 允许定义在信息类型化主题之间共享的特定词汇表。也可以完全省略掉领域，生成只有核心元素的类型化主题。
1
领域词汇表可以采用短语、特殊段落和列表等形式，基本上可以是主题最小组织部分 section 中允许的任何形式。
| 跨信息类型的专门化词汇表（领域） |
|
类型化主题：
| 概念 | 任务 | 引用 | |
包括的领域：
| 突出显示软件编程用户接口 |
作为例子定义的 DITA 基本领域有：
|
领域
|
元素
| | highlighting | b, u, i, tt, sup, sub | | software | msgph,
msgblock,
msgnum,
cmdname,
varname,
filepath,
userinput,
systemoutput
| | programming | codeph,
codeblock,
option,
var,
parmname,
synph,
oper,
delim,
sep,
apiname,
parml,
plentry,
pt,
pd,
syntaxdiagram,
synblk,
groupseq,
groupchoice,
groupcomp,
fragment,
fragref,
synnote,
synnoteref,
repsep,
kwd
| | user interface | uicontrol, wintitle, menucascade, shortcut |
按照专门化新的内容领域的规则，可以扩展、替换或删除这些领域。此外，内容专门化使您能够在 DITA 信息类型化主题的范围内命名和扩展任何 内容元素，建立新领域中语义上更重要的角色。
为了支持专门化词汇表，可以为 DTD 中使用的每个元素（如主题或者它的一个特例）声明等价的参数实体，然后在 DTD 内容模型中使用参数实体而不是文字元素记号。以后，在实体替换之后，因为重新定义了元素的参数实体，使其同时包括原始元素和从该元素派生的领域元素，只要原始元素可以出现的地方，派生的领域元素都可以出现。因此，领域未定的主题很容易扩展到不同的领域，只要改变前端 DTD “shell” 中实体集包含的作用域即可，这个 shell 形式化了类型化主题或者类型化主题家族中的词汇表扩展。
DITA 公共结构
DITA 的一个设计要点是充分利用 XML 世界中公共子结构的重用。因此，主题 DTD 结合了 OASIS 表格模型（原来称为 CALS 表格模型）。还定义了一组元数据，可以直接在完全不同的 DTD 或模式元数据模型中共享。
该元数据结构定义了单个主题、较高层次的处理 DTD、作为附属文件或数据库记录与元数据关联的 HTML 文档的文档控制信息。
这个表格结构为 body 层内容提供了表示语义。很多流行的 XML 编辑器都支持 OASIS/CALS 表格显示模型。
为专门化设计的元素
由于在其类架构类型（archetype-like）主题 DTD 中使用了元素的一般化设计，DITA 为专门化提供了坚实的基础。
比如，基本主题 DTD 中的 section 既可以包含文本又可以包含元素数据。不过，可以将 section 专门化来排除 PCDATA，从而形成类似于多数 DTD body 层的纯元素内容模型。如果按照另一个方向专门化，section 可以消除多数类似块的元素，作为定义、字段标签、部件等的描述。
在 DITA 中我们尽量选择大家熟悉或者与 HTML 相同的元素名。一些语义名称借自支持大型 SGML 库的工业 DTD，如 IBMIDDoc 和 DocBook。
主题 DTD 中的属性列表反映了这种设计思想。比如，有一个 “统一属性”（出现在大多数元素中）是 importance，定义了在专门化元素中作为属性出现的权数或者评估值。在任务主题专门化的几个元素中出现时，该属性只能取原来的值集中的两个值：“optional” 和 “required”。而在其他领域中，该元素可能更适合用 “high” 或 “low” 排序，这些值也在顶层提供。
专门化的值
具有特殊信息需求的企业可以定义专门化的主题类型。比如，产品组可以确定三种主要的引用主题类型：消息、工具和 API。通过为每种内容类型创建专门化的主题类型，产品架构师可以保证每种主题类型都有适当的内容。此外，专门化主题也增强了 XML 感知的搜索功能，因为用户可以进行更小粒度的区分。比如，用户可以把搜索 xyz 限制在消息或者 API 中。用户也可以在一般的引用主题中搜索 xyz。
规则控制了如何安全地进行专门化：每种新的信息类型必须映射到一个已有的信息类型，而且必须对允许的内容作更多的限制。通过这种专门化，新的信息类型可以使用转换、打印和 Web 发布的一般处理流程。虽然产品组可以改写或者扩展这些过程，但不需要任何额外的工作或维护就得到了所有已有的过程。
企业可以用一系列 DTD 表示一组统一的信息描述，分别强调这些新信息类型专门化的价值。
内容社区在 DITA 中的角色
设计该体系结构的技术文档团体定义了基础体系结构和共享资源。特定团体（在定义团体之内或之外）拥有的内容可以重用已经定义好的处理程序、样式或其他特性，但是这些团体要根据自己管理的数据定义特殊的业务过程。他们可以通过从一个基本类型开始进一步专门化来管理数据。
下图显示了作为主题层内容所有者的社区如何根据核心体系结构专门化其内容。
图 1. 专门化社区和基本体系结构之间的关系
该图中，重叠部分表示使用该信息体系结构的内容所有者社区之间共享的公共体系结构和工具。根据该体系结构定义类型化文档的新社区可以在一开始使用同样的工具，然后在需要的时候定制针对其内容的工具。
尾注
1在最初的 DITA 设计中，所有共享词汇表都是在主题 DTD 中定义的，从而对所有信息类型都是全局性的，这样做有两个不希望的后果：
- 不增加核心 DTD 的大小就无法增加新的词汇表。
- 不能在不同领域的 DTD 专门化中禁止某些领域专用的词汇表。
说明
本文中提供的信息没有经过任何正式的 IBM 测试，仅供参考，不作任何明确或隐含的保证。使用这些信息或者文中所述这些技术的实现是读者的责任，依赖于读者评价和将其结合到操作环境中的能力。尝试根据自己的环境改变这些技术的后果自负。
? Copyright International Business Machines Corp., 2002. 版权所有。
参考资料
作者简介 | | | Don 是一位专职的丈夫、父亲和爱猫者，同时还为 IBM Information Development 社区设计和支持发布工具，也是 IBM 在 W3C XSL 和 CSS 工作组的代表。他从新墨西哥州立大学获得了英语和新闻专业学士学位、技术和专业通信专业硕士学位。可以通过 dond@us.ibm.com 与 Don 联系。 |
| | | Michael Priestley 是 IBM Toronto Software Development Laboratory 的一位信息开发人员。他撰写了关于超文本导航、信息资源单一化、动态文档接口等方面的一些文章。他目前从事帮助和文档管理的 XML 和 XSL 开发。可以通过 mpriestl@ca.ibm.com 与 Michael 联系。 |
| | | Dave Schell 是 IBM 支持其技术编写（User Technology）社区的首席战略师和工具主管。可以通过 dschell@us.ibm.com 与 Dave 联系。 |
对本文的评价
| 
