如果你使用定制化的DITA插件，最终你可能需要升级或者更新这些插件。你可能需要进一步升级定制化插件的外观，并测试这些更新。随着发布需求的增长，你可能也需要增加新的定制化插件。
以下是一些定制DITA插件的最佳实践：
-
建立一致的方式，收集specifications。当你在开发新的定制化插件时，你需要收集specification，决定输出物如何呈现。对于印刷版本（如PDF），这些specification包括字体、字号、颜色、页边距、图片和表格显示规则，页眉页脚的位置，等等。对于在线版本（如HTML），这些specification是基于功能的；例如，使用哪种搜索导航，对于用户最为友好？
如果specification明确，收集方式一致，创建定制化插件会容易许多。一个不错的方向是创建checklist或者问卷，让企业的市场部门参与，提供输出物的样式和外观的信息。一旦你拥有这些specification，并且创建了第一版的定制化插件，你可能需要几轮测试，审核并且不断微调发布的输出物。在开发插件之前，你的specification越明确，测试过程就会越高效。
-
支持特殊结构；不要误用结构。创建定制化插件能保证专门化的DITA结构在各种不同的输出格式中显示良好。但是，不能使用定制化插件支持“滥用的标签”或者故意的DITA结构的误用，不管是标准的DITA结构还是专门化的DITA结构。
例如，可能很容易想到在DITA源内容中创建上百种的outputclass，决定PDF输出种样式的差异，同时，在定制化插件中定义上百种的匹配规则，以最后呈现这些outputclass。但是，这只会使你的DITA源内容和定制化插件更复杂，也更难维护。在源内容中增加大量的样式有关的变量也违背了DITA内容与格式相分离的初衷。
-
文档记录定制化插件的升级。如果需要修改定制化插件，增加注释，包括姓名、公司名、日期，以及升级的简要描述。增加注释说明你在插件中的修改，不要直接替换；因为你无法获知什么时候会被要求还原回初始的版本。如果你需要将定制插件转交给另一个开发人员，注释文档也能说明该插件的历史升级记录。
除了记录升级之外，在插件开发过程中，以文档形式记录specification也将大有帮助。这个文件将会是个风格指南，你可以用于确保新的DITA内容显示正确，并在最终发布之前生成测试版本的输出物。