XML文档本身只负责携带数据，至于数据是否合法、结构是否完整，要靠外部约束来检查。DTD（文档类型定义）和XSD（XML Schema Definition）是两种主流的验证方式，前者出现较早，后者由W3C推荐并逐渐成为默认选择。但它们的工作机制、数据类型支持、命名空间处理等方面存在显著差异，选错验证方式可能导致校验不充分或维护成本上升。
DTD验证：轻量但缺乏类型约束
DTD的语法继承自SGML，可以使用内部子集直接嵌入XML文档，也可以作为独立的外部文件被引用。内部DTD的典型写法如下：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <note> <to>Tom</to> <from>Jerry</from> <heading>Reminder</heading> <body>Don't forget the meeting</body> </note>
上面的定义中，<!ELEMENT>声明了note元素必须包含to、from、heading、body四个子元素，并且每个子元素只能出现一次。DTD支持的元素内容模型包括#PCDATA、EMPTY、ANY以及用逗号、竖线表示的序列和选择关系，出现次数则用?、*、+表示零或一、零或多、一或多。
DTD验证的过程比较直接：XML解析器读取文档类型声明，根据元素和属性列表逐项检查结构。如果某个元素缺失或出现顺序不对，解析器会报错并停止处理。但DTD的报错信息往往不够友好，比如只提示某个元素处出现意外内容，却无法指出具体是因为类型不匹配还是顺序错误。更深层的问题是，DTD几乎不支持数据类型，所有文本内容都被当作字符串看待，无法验证数字范围、日期格式或枚举取值。
此外，DTD对命名空间完全无能为力。一个带有默认命名空间的XML文档在DTD里需要用前缀显式声明，而且DTD本身不识别xmlns属性，容易导致验证冲突。这些限制使得DTD在简单配置场景下够用，却难以胜任现代复杂的数据交换需求。
XSD验证：强类型与命名空间支持
XSD本身就是一个XML文档，根元素为<xs:schema>。它不仅描述元素结构，还把元素和属性当成类型来管理。一个与前面DTD等价的XSD定义如下：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ipipp.com/note"
xmlns="http://www.ipipp.com/note"
elementFormDefault="qualified">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
可以看到，XSD通过<xs:element>定义元素，用type属性指定数据类型，例如xs:string。更关键的是，XSD支持<xs:complexType>和<xs:simpleType>，前者描述包含子元素的结构，后者描述纯文本内容。在简单类型中可以使用<xs:restriction>施加约束，比如限定字符串长度、数值范围、枚举值或正则表达式模式。
XSD的验证引擎会先解析模式文档，建立类型和元素声明的符号表，再对实例文档进行遍历。因为类型信息丰富，XSD报错通常更精确，例如会明确指出某个元素的取值不符合xs:integer类型，或者某个属性缺失。对于命名空间，XSD通过targetNamespace和xmlns声明将元素与命名空间绑定，并可通过elementFormDefault控制局部元素是否需要限定前缀。
数据类型方面，XSD内置了字符串、整数、浮点数、布尔值、日期、时间等多种类型，还允许通过限制、列表、联合等方式派生自定义类型。比如可以定义一个只允许“男”或“女”的枚举类型，或者限制年龄为0到120的整数。这种能力让XSD不仅能判断结构是否合法，还能检查数据本身是否符合业务规则。
关键差异对比与选型思路
为了更直观地比较两种验证模式，下面用表格列出几个核心维度的差异。
| 对比项 | DTD | XSD |
|---|---|---|
| 语法形式 | 非XML语法，紧凑 | XML语法，冗长但规范 |
| 数据类型 | 仅支持字符串类 | 丰富内置类型和派生类型 |
| 命名空间 | 不支持 | 完整支持 |
| 可扩展性 | 弱，难以复用 | 强，支持继承和组合 |
| 错误提示 | 粗略 | 精确到元素和类型 |
| 工具支持 | 基本解析器支持 | IDE、代码生成、验证工具丰富 |
从实际项目角度出发，如果只是为老系统维护一个简单的配置文件，DTD足够轻量，且修改起来直接。但如果是新建的Web服务接口，或者需要在多个系统之间交换结构复杂、约束严格的数据，XSD几乎是更合理的选择。很多现代框架和协议，比如SOAP和部分配置管理系统，默认要求使用XSD进行模式定义。
从DTD迁移到XSD时，不能简单地把元素声明照搬过去。DTD中的#PCDATA一般可以映射为xs:string，但复杂内容模型需要重新用<xs:sequence>或<xs:choice>表达。默认属性、实体引用等DTD特性在XSD中要么有替代方案，要么需要放弃。迁移过程中还应注意命名空间的定义，避免因为elementFormDefault设置不当导致实例文档验证失败。
总体来说，DTD适合轻量、历史兼容或无需强类型的场景；XSD适合需要严格数据校验、命名空间隔离和大规模工具链集成的场景。选择时不仅要看当前需求，还要考虑后续数据模型的扩展可能。