Re：离开DITA的10个原因

Tom Johnson是Google负责文档的资深专家。他写了一篇博客叫做：10 reasons for moving away from DITA。Oxygen的Radu对他的观点进行了回复，挺有意思的，大家来看看。

---

作者 | Radu Coravu

我在推特上关注Tom Johnson@tomjohnson，关注与技术文档相关的有趣文章。他最近的一篇帖子提醒我们，他在大约7年前写的文章中提出了10个离开DITA的原因，所以我重新阅读了这篇文章。我想在他最初的帖子发表7年后，对他在提到的10个原因中一一回复：

1. DITA不容易集成到现有的web框架中

我认为Jarno Elovirta开发的DITA到Markdown转换（在DITA开放工具包中免费提供）为使用静态网站生成器打开了可能性。以下是我写的一篇文章，我在其中使用MKDocs静态站点生成器进行了调查：

使用MKDocs网站生成器发布DITA内容：

https://blog.oxygenxml.com/topics/publishing_dita_content_using_a_markdown_static_web_site_generator.html

2. DITA不容易与JavaScript库集成

同样，一旦可以将DITA发布到Markdown，就可以使用现有的静态网站生成器基础设施。

3. 我从未接受DITA的信息类型模型

我部分同意，因为大多数不受公司或某些出版定制的外部约束而使用显式主题类型的作者（包括我在内）会在他们的所有作品中使用基本DITA主题类型。

4. 用XML编写是件苦差事

对我来说，在Markdown中写作时，添加段落很容易，但在添加链接、图像引用或表格时，这是一件苦差事。这取决于你对什么感到舒服，以及你每天使用什么。如果我每天都写Markdown，我会开始记得我应该如何编码链接，并认为这是一种自然的做事方式。但实际上，一般来说，使用纯文本编辑器编写XML更为困难。有了可视化编辑工具，这就容易多了。

5. 开源DITA解决方案开发太慢

如果我们讨论存储，DITA内容（例如本博客的内容）可以存储在Git存储库中，并与常规Git客户端工具一起使用：DITA for Small Technical Documentation Teams：

https://blog.oxygenxml.com/topics/dita_for_small_teams.html

如果我们讨论的是发布生态系统，一旦您可以使用DITA Open Toolkit将DITA发布为纯HTML或Markdown，您就可以受益于所有可用于Markdown和纯HTML内容的基于web的工具。

6. 你不能轻易地定制输出

同样，这取决于你对什么感到满意。你可以将DITA XML内容生成的Markdown内容与MKDocs或Jekyll等静态网站生成器一起使用。事实上，如果你使用DITA来生成Oxygen WebHelp，尽管大多数自定义都是用CSS进行的，但您可能仍然需要使用XSLT进行更高级的自定义。但是，作为一个花了数小时试图理解Hugo为什么没有正确遵循文章之间的链接的人，任何事情都有一个学习曲线，每个静态网站生成器都有自己的配置功能，需要学习和探索。此外，一旦你对某个出版过程感到满意，你自然会认为这一个很容易，而其他的则更难。

关于将DITA发布为PDF，传统的DITA到PDF发布的默认自定义功能需要了解XSLT和XSL-FO。这就是为什么我们开发了基于Oxygen Chemistry CSS的PDF处理器，以便能够使用CSS对内容进行样式设置，然后将CSS用于WebHelp和PDF发布：https://styles.oxygenxml.com/.

7. DITA不能很好地与其他非DITA内容集成

DITA内容与Markdown集成良好。不到一年前，我们联系了Tom，再次探讨Oxygen使用文档即代码（Doc as Code）方法的功能，他关于将DITA XML与Markdown相结合的深思熟虑的完整文章如下：https://idratherbewriting.com/learnapidoc/pubapis_oxygenxml.html.

在最近的Oxygen版本中，我们还探索了将Word或HTML等其他文件类型直接与DITA项目集成：https://www.oxygenxml.com/doc/ug-editor/topics/dynamically_convert_word_excel_html_markdown_to_dita.html.

8. 我想用DITA做的一切，我可以用Markdown和Jekyll上的Liquid做

我不熟悉Liquid，但我同意确实有一些方法可以使用Markdown重用内容，这不是标准的一部分，而是特定框架如何决定支持此类扩展的一部分。这使得解决方案在基于web的框架之间切换时100%不可移植。我确实认为有更强大的方法可以使用Schematron检查基于XML的标准的结构是否正确。Oxygen验证和完整性检查也进行了大量的一致性检查。

这是篇关于Markdown思考的文章：

https://www.smashingmagazine.com/2022/02/thoughts-on-markdown/.

9. DITA的创新过于依赖供应商

一旦您可以从DITA XML内容中获得纯HTML和纯Markdown，您就可以从为处理和显示HTML和Markdown而创建的所有工具中获益。

Web工具发布领域比DITA XML发布领域动态得多。对我来说，从外部观察Web工具领域，它处于不断的创新动荡中，这给任何想要选择框架的网络开发人员带来了压力。因为有太多的框架是在一夜之间被开发开出来，同时以不同的方式为相同的概念重新发明解决方案，最终你不知道该选择什么，并且包含各种特定于框架的扩展的Markdown内容无法在它们之间轻松切换。这就像拆除整个房子，每天重新发明它，有时忘记了在上一次迭代中解决的各种问题。

虽然Markdown现在可能是未来网络工具的制胜格式，但一些创新者甚至希望在编写网络内容时改用JSON：

https://www.smashingmagazine.com/2022/02/thoughts-on-markdown/.

10. DITA是API文档领域的错误语言

我将进一步探索在API文档领域中使用DITA XML，这是肯定的。现在，我认为通过“API文档”，大多数人都会提到Swagger、OpenAPI文档，主要是基于Web的端点（end point）的API文档。我尝试了使用widdershins来生成从API文档并转到Markdown的文档，然后将Markdown内容转换为DITA XML，将DITA内容转换为WebHelp Responsive。此外，我不确定API文档领域是否比使用REST的基于web的端点更大，但也有其他编程语言，但可能大多数API文档现在都是关于访问服务器端点的。

以上是我对Tom在7年前撰写的DITA文章中提出的10个理由的简短回复。如有任何反馈，我们将一如既往地欢迎。

 英文原文如下：

Re: 10 reasons for moving away from DITA

访问摩拿官网联系我们