DTD处理的最佳实践

Question

我正在研究检查格式良好的XML解析器。根据XML Spec，需要这样一个“xml处理器”进程 dtd用于获取实体引用和属性列表定义（即为了解析引用，规范化属性值并提供默认值属性值）。如果我知道应用程序本身将要输出XML，这是否意味着将整个DTD传递到应用程序？

如果不是，那么就保存完全处理的XML文档中的DTD而言，标准最佳实践是什么？我的直觉是要么没有传递DTD，要么传递一个声明standalone=no的XML声明，或者传递一个精简的DTD，该DTD除了文档中实际引用的外部实体的名称和声明外，已被除去。

Answer 1

不，处理外部DTD不一定需要将该DTD的全部内容合并到输出中。除此之外，输出并不总是与输入相同的文档...

但是，这意味着您必须决定如何处理实体引用和默认属性值。一种方法（a）仅仅是扩展它们并将其内容传递给输出文档。另一个是确保输出文档（b）至少包含其内部DTD中的这些信息的声明，或者（c）参考提供这些定义的外部DTD（可能与源文档相同，如果输出文档是与该DTD兼容的类型）。选项（a），扩展所有内容以便不再依赖于DTD的默认值和宏，实际上是用于通用XML处理的最常见解决方案。如果你的工具使用了一组特定的DTD，选项（c）将是一个合适的答案。

请注意，类似的答案适用于XML模式。还要注意，DTD因为与XML名称空间不兼容而处于被禁用的边缘;命名空间对于严肃的XML处理来说太有用了。所有现代的XML解析器都应该支持Schema;如果您绝对需要与最早一代XML代码的向后兼容性，那么现在我会推荐DTD。 （DTD所做的一个事情就是解析实体......但实际上，除了手工构建的文档之外，这些实际上极少使用。）

数字字符引用或少数几个指定的字符引用（&和最显着的<）内置于XML语言和解析器中，因此您不需要通过DTD处理来支持这些语言和解析器。

.....

顺便说一句：见鬼，为什么你重写从头XML解析器？除非你专门研究解析器优化或类似的东西，或者将它作为类的分配，否则没有理由不使用众多现成的解析器之一;在这一点上，我认为它们存在于几乎所有可用的编程语言中，并且它们可能已经为优化和处理XML的微妙问题投入了大量工作，而不是您现有或将要完成的工作。

如果你真的需要重新创造这个特定的轮子，我高度建议花费一些时间与The Annotated XML Specification。 Tim Bray做了一个经历XML 1.0 REC的工作，并准确解释了它的含义，以及为什么一些不太明显的决定是按照他们的方式进行的。不幸的是，这需要足够的努力 - 并且对工作组中的讨论有足够的内部知识 - 没有人愿意为XML 1.1或任何其他W3C规范重做它。