W3C XML Schema 与文档类型定义 (DTD) 比较

　　除了语义方面的准确性以外，还可以看到模式示例能够执行一些DTD 不可能完成的操作。 prodName 类型在定义之间基本上是相同的，但模式中的 USPrice 和 shipDate 规范分别是 decimal 和 date 类型。 作为文本文件，具有这些元素的 XML实例在元素内部包含一些 ASCII（或Unicode）字符；不过，具有模式意识的确认器可以在 decimal 和 date 元素内部要求更具体的字符格式（其它类型也是一样）。 更有趣的是属性 partNum ，它属于派生的专门类型。类型 SKU 不是内置类型，而是跟在 "SKU"声明中给定模式后的一系列字符（具体来说，它必须有三位：一个连线和两个大写字母，按这样的顺序）。也有可能将 SKU 用于元素类型；它在这种情况下定义属性只是一种巧合。

　　在元素定义的 DTD版本中，所有这些有趣的（如果是专门的，也可能相当复杂）类型一定简单地称之为 PCDATA ，至于字符数据是什么样没有更多说明（在属性情况中是 CDATA ）。

　　在类型丰富的元素／属性值中，模式巧妙地从描述 XML实例的语法渐变到描述其语义。语法分析纯化论者可能会就我的描述提出异议：“内置模式类型是从语法上定义的，因此构建在这些内置类型上的模式在形式上也是符合语法的。”但在实际情况中，当声明一个给定的元素必须是 date 时，您实际上希望的是让元素包含一个日期。当然，表达语义信息不是件坏事，但有人会争论说最好同样将它限制在应用程序级别，而不是格式声明。毕竟有一些语义特性 -- 即使是简单的特性 --避开了模式，但在应用程序中和模式所表达的内容一样重要。 例如，当然"stock-keeping unit" 必须类似于"999-AA"；但可能您还提供在十三以内的小装置。 integer 被13 整除性不能使用 XML 模式表达（因此您仍然无法在这一级别上为 widgetquantity提供所需的约束）。这里的重点是说，即使有模式（胜过DTD）的额外能力，仍可能需要在应用程序级别上执行后确认来确定 XML文档是否 在功能上有效。