什么时候适合用 HTML 创作呢？重要的是首先要肯定这一点，与 DITA XML 相比，有时候直接用 HTML 制作输出可能更合理。
您制作的是专用的基于 HTML 的 UI如果您需要制作某一类型的界面，如计算器工具，HTML 比 DITA 更合适。DITA 不是 HTML + JavaScript + CGI/ASP 后端代码 + applets + CSS + DHTML + （等等）所提供的自由编程空间的完全替代品。您需要根据特定的要求选择适当的工具。DITA 代表了一个技术产品内容的信息模型。从这个意义上讲，DITA 告诉 用户关于 系统的信息，而 UI 构造工具则是帮助告诉 系统关于 用户的信息，或者修饰用户所看到的系统信息。DITA 是这些信息的语义框架。与此相对比，表单和样式工具创建的是该框架的行为和表现。如果您提供的是行为和表现而不是内容，直接使用 HTML 可能更合理。
您处理的是原型或者某种类型的交付品对于不准备长期维护的某种类型的项目或交付品，选择直接在 HTML 中创作技术产品内容这条快捷但讨厌的路径可能是合理的。比方说，您可能选择直接在 HTML 中编写个别网页或者临时新闻。您也可能需要为提供的新产品交付示范性的内容。直接在 HTML 中创作能够提供单独定制的样品。
原型和某些类型的交付品之所以适合用 HTML 制作，是因为具备以下特性：
- 信息的结构和内容是否与同一小组或其他小组的作者制作的类似内容相匹配并不重要。与 HTML 样式匹配需要预先进行细致的协调和规划，并在编辑过程中小心谨慎。
- 不同页面之间的一致性并不重要。
- 确知样式和行为不会中途改变。
- 您乐于对在所有可能使用的浏览器和平台中的式样、观感以及内容的整体表现负全部的责任。
直接用 HTML 创作有什么问题？但是，对于多数技术内容——包括帮助、手册以及其他用户支持——的创作，直接使用 HTML 存在一些限制和问题：
难以进行全局性的修改一旦按照特定的样式和内容原则创建了一组 HTML 页面，就很难进行全局性的修改，如果修改也需要很大的工作量。级联样式表（CSS）可以提供一些帮助，但是需要做的修改类型经常会超出 CSS 的能力。而且修改一个 HTML 页，意味着您必须同时查找和替换其他已经创建的页面。较小的不一致也会给这种查找并替换的方法带来很大的问题。创建 HTML 中的细微变化经常会阻碍查找匹配。
不能扩展您可以开发符合已经认可的信息分类标准的 HTML 内容。但是当您遇到新的信息类型时，通常很难扩展 HTML 设计以同时容纳新的和原有的信息类型。强制实行一致认可的创建信息类型的原则也很困难。使用 HTML，每次调整信息结构时，您总是在重新发明轮子。
难以确定信息的完整性HTML 难以提供一种系统化的方法，检查一系列主题——包括概念主题、任务主题和参考主题的全部集合——是否满足描述产品特性的要求。因此难以衡量进度，也不能保证信息的完整性。
缺乏可移植性或一致性HTML 内容在产品组之间或者与外部商业伙伴之间共享是出了名的难。不错，任何人只要有浏览器都可以显示您的 HTML 页，但是混合和匹配遵循不同内容和表现模型的 HTML 很快就会变得难以处理。当用户从一个主题切换到另一个主题时，导航、布局、标题和一般的表现风格缺乏全局的一致性——实际上也毫无办法，除非重新制作每组信息使其符合共同的标准。但是当商业伙伴要把其他的内容插入到您的信息集中时又会怎么样呢？
为何用 DITA XML 创作？好了，够了！ HTML 可能有其弱点，我知道它是魔鬼。如果不使用 HTML，那么就告诉我用 DITA XML 创作然后再生成 HTML 为何那么迫切吧。
XML 与信息开发XML 为信息开发带来了一些有利之处：
- 它强调的是内容的 结构，而不是 形式；在多数 XML 设计中布局都是单独维护的。
- 它可以更好地保持内容的一致性，并更好地保证内容的表现对各种不同输出设备和格式的一致性。
- 它提供了一种支持条件处理、自动化链接和链接检查的方法，还有一个强大的复用模型。
在 IBM 中，改用 XML 进行信息开发使我们得以利用 XML 独具的一些特性：
- 开放式的标准：XML 为内容共享和交换提供一种独立于应用程序和系统的格式，更便于共享的组织使用一致认可的标记系统，比如用文档类型定义 (DTD) 或其他模式定义的标记系统。
- 形式和内容分离：XML 使得以不同格式表现相同的源内容成为可能——比如以 Web 页、打印稿或者其他提交媒介表现。因此，用一个程序就可以转换表现形式，赋予整个 Web 站点新的风格，而不必改变底层内容。您可以把产品的印记放在单独的表示文件中，这样特定的品牌类型就不会影响内容的复用和整体性。
- 可扩展性和意义明确的标签：XML 标签可以设计成具有明确的含义，标记特定的内容。比如地址的邮政编码可以使用称为 "zipcode" 的标签；过程的步骤可以使用 "step" 标记。处理系统（比如搜索软件和个人软件）可以针对特定的用户群筛选和格式化内容然后提交给他们。
- 可靠的工具：依托开放式标准为创建、管理和发布 XML 内容的各种不同工具的涌现奠定了基础。
使用 DITA 创作和处理IBM 的一个信息开发专家小组设计了 DITA，它是专门用于技术内容的一个 XML DTD 和体系结构。DITA 小组寻求一种方法，使 XML 的这些一般特性能够为我们产品的技术内容的创建、管理和发布带来特别的好处。
DITA 处理技术信息的的独特能力来自于两个重要特性：
- 基于主题与模块化：DITA 是创建和交付基于主题的、模块化的技术信息的体系结构。DITA 的基本信息单位是 主题，它描述了单个任务、概念或者参考项。因为 DITA是基于主题的，DITA 的内容可以组合、重组和复用以创建在线帮助、印刷版的图书、基于 Web 的信息中心、产品支持门户或者许多其他的信息形式。
- 基于专门的信息类型：信息类型定义了主题的角色。DITA 包括三种从基本主题类型派生的信息类型：任务、概念和参考。 任务主题代表任务的一步一步的过程。任务主题对特定任务回答了“ 怎么做？”的问题。 概念主题通过定义术语和解释概念提供了任务背后的原因。 参考主题提供了特定的信息，如命令、消息、程序选项或者 API。因为 DITA 支持任务、概念和参考主题，作者和编辑可以很快确定是否彻底完成某个新增功能的文档。如果发现概念主题所不支持的任务主题，就可能表明还需要继续编写。
通过 DITA 专门化，您可以创建并保持一致的信息体系结构。比如，用于编制 C++ API 文档的专门化主题可以包含这样的规则，要求编写者安排一组必需的内容，如返回值。使用这种高度结构化内容的用户很快就能熟悉信息结构的一致性，并发现他们差不多可以评直觉定位主题，如查找“一个专家的安装步骤”或者“C++ 中的返回值。”
(关于 DITA 信息类型专门化和基于主题处理的例子，请参阅 。)
DITA 保持了 XML 内在的优点，又从以下方面进一步发挥了这些优点：
- 通过定制转换方便地进行全局性修改：通过 DITA 和 XSLT，您可以应用一致的核心转换更新整个信息集的结构和表示。您可以让构造汇总表和列出链接主题这样的事情自动完成。同时因为全局性的修改是在输出过程中完成的，您可以应用不同的全局修改集合得到不同的输出。这样，您可以针对打印还是联机、针对不同的平台或品牌要求定制输出，而不需要每次都编辑和调整源文件。您可以迅速响应用户对新产品和升级产品的信息需求。
- 标准化带来的可移植性：使用 DITA，产品组和外部业务伙伴可以很容易地共享和交换内容。第三方可以对 DITA 使用一般的转换和表示模型，或者建立专门的处理以提供针对特定企业或品牌的内容视图或表示，或者在 DITA 和其他 XML 格式之间进行转换以实现复用。为了维持与第三方伙伴之间的协定，为了在商业重组、合并、收购、分解中保证写作小组的生产率不会降低，这种内容的可移植性要求非常严格。
- 链接和 Web 管理：DITA 允许在主题本身之外创建和维护跨主题的链接。可以在不同的情况下应用不同的链接集。比方说，如果您的主题包含在产品 A 中，那么就包含适合于该产品的链接。对于产品 B，则包含另一组链接。类似地，如果要集成其他小组制作的内容，您可以在处理过程中增加适合于他们的主题的链接，而无需编辑他们的源文件。您甚至可以在主题已经交付转换之后增加链接。
- 条件处理：通过 DITA，您可以根据产品、对象或者其他特性标记主题的一部分。然后您可以包含、排除这些内容，或者为了复用或特殊的表示对其作标记。
- 复用：您可以使用映射在不同的集合中复用主题，也可以在不同的主题之间复用内容，集中维护公共元素，如定义、警告和产品名。利用 DITA，编者可以组合关于特定问题集的主题并作为一种独有的按需提供的产品发布。比如，客户支持小组可能会从已有的不同资源编纂特定的主题集合（如服务器负载和性能），为重要客户报告的问题提供定制的解决方案。
- 内容集中，更容易编写：基于主题的创作改进了编纂工作。把内容分为概念、任务和参考三个主题可以使用户更快地完成任务，因为信息都集中到一块了。处理元数据的交付工具使用户可以根据公司的任务、他们的工作职责和任务目标查找信息。
结束语经过严格的 HTML 创作以及后续处理的训练，也可能取得上述的部分益处。但是这个过程很快就变得非常琐碎。比方说，您可能调整 HTML 以支持条件处理的表单，但是这样做就难以生成定制的表示。然后，当修改 HTML 以改进表示的时候，您可能需要重新处理主题导航链接的内容和形式。
XML 和 DITA 克服了 HTML 这种过于琐细的问题。DITA 集中了一个协调、全面的信息体系结构的全部优点，这种结构可以伴随着产品信息的需要和交付方式的变化、伴随着以交付 XML 作为表示机制的标准工具的进展而不断演化成长。 |
