当前位置 : 主页 > 网页制作 > xml >

DTD与XSD定义的XML语言范围

来源:互联网 收集:自由互联 发布时间:2021-06-13
以下命题是否成立: 对于每个DTD,都有一个定义完全相同语言的XSD,并且对于每个XSD,都有一个定义完全相同语言的DTD.或换句话说:任何DTD定义的语言集合都是任何XSD定义的语言集合? 稍
以下命题是否成立:
对于每个DTD,都有一个定义完全相同语言的XSD,并且对于每个XSD,都有一个定义完全相同语言的DTD.或换句话说:任何DTD定义的语言集合都是任何XSD定义的语言集合?

稍微扩展一下这个问题:XML文档基本上是一个大字符串.语言是字符串的集合.例如,所有MathML文档的(无限)集合都是一种语言,所有RSS文档的集合也是如此. MathML(RSS,…)也是所有XML文档的(无限)集合的适当子集.您可以使用DTD或XSD来定义这样的XML子集.

现在,每个DTD都只定义一种语言.但是如果你想到所有可能的DTD,你会得到一套语言.我的问题是,这个设置与你从所有可能的XSD获得的设置完全相同吗?如果是这样,那么DTD和XSD在两者所定义的XML语言范围相等的意义上是等价的.

为什么这个问题很重要?如果DTD和XSD都是等效的,则可以编写一个程序,它将DTD作为输入并为您提供等效的XSD,另一个程序则执行相反的操作.我知道有很多程序声称要做到这一点,但我怀疑这是否真的有可能.

一个有趣的问题;好问!

两个方向的答案都是“不”.

这是一个在XSD中没有等效的DTD:

<!ELEMENT e (#PCDATA | e)* >
<!ENTITY egbdf "Every good boy deserves favor.">

该DTD接受的一组字符序列包括< e />和< e>& egbdf;< / e>,但不是< e>& beadgcf;< / e>.

由于XSD验证对已经扩展了实体的信息集进行操作,因此没有XSD架构可以区分第三种情况和第二种情况.

DTD可以表达在XSD中不可表达的约束的第二个区域涉及NOTATION类型.我不会举一个例子;细节太复杂了,我无法正确记住它们,而且没有足够的兴趣让我想要这么做.

第三个方面:DTD以相同的方式处理命名空间属性(也称为命名空间声明)和一般属性;因此,DTD可以约束文档中名称空间声明的外观. XSD架构不能.这同样适用于xsi名称空间中的属性.

如果我们忽略所有这些问题,并仅针对不包含对预定义实体lt,gt等以外的命名实体的引用的字符序列来表达问题,则答案会更改:对于每个不涉及NOTATION声明的DTD ,有一个XSD架构在实体扩展后接受完全相同的文档集,并且以忽略xsi命名空间中的命名空间属性和属性的方式定义“相同”.

在另一个方向,差异的领域包括:

> XSD是名称空间感知:以下XSD架构接受指定目标名称空间中元素e的任何实例,而不管文档实例中哪个前缀绑定到该名称空间.

<xs:schema xmlns:xs="..." targetNamespace="http://example.com/nss/24397">
  <xs:element name="e" type="xs:string"/>
</xs:schema>

没有DTD可以成功接受给定命名空间中的所有和仅e元素.
> XSD具有更丰富的数据类型集,可以使用数据类型来约束元素和属性.以下XSD架构没有等效的DTD:

<xs:schema xmlns:xs="...">
  <xs:element name="e" type="xs:integer"/>
</xs:schema>

该模式接受文档< e> 42< / e>但不是文件< e> 42d Street< / e>.没有DTD可以做出这种区分,因为DTD没有约束#PCDATA内容的机制.最接近的DTD是<!ELEMENT e(#PCDATA)>,它接受两个样本文件.
> XSD的xsi:type属性允许对内容模型进行文档内修改.以下架构文档描述的XSD架构没有等效的DTD:

<xs:schema xmlns:xs="...">
  <xs:complexType name="e">
    <xs:sequence>
      <xs:element ref="e" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="e2">
    <xs:sequence>
      <xs:element ref="e" minOccurs="2" maxOccurs="2"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="e" type="e"/>
</xs:schema>

此架构接受文档< e xmlns:xsi =“...”xsi:type =“e2”>< e />< e />< / e>并拒绝文件< e xmlns:xsi =“...”xsi:type =“e2”>< e />< e />< e />< / e>. DTD没有使内容模型依赖于文档实例中给出的属性值的机制.
> XSD通配符允许在指定元素的子元素中包含任意格式良好的XML;使用DTD最接近的是使用形式<!ELEMENT e ANY>形式的元素声明,这是不一样的,因为它需要声明实际出现的所有元素.
> XSD 1.1提供断言和条件类型赋值,它们在DTD中没有类似物.

XSD的表现力可能超过DTD的其他方式,但我认为这一点已得到充分说明.

我认为一个公平的总结是:XSD可以表达DTD可以表达的所有内容,但实体声明和命名空间声明和xsi:*属性等特殊情况除外,因为XSD旨在能够这样做.因此,在将DTD翻译成XSD架构文档时丢失信息是相对适度的,易于理解的,并且主要涉及大多数词汇设计者认为不具有实质意义的DTD文物的事物.

XSD可以表达超过DTD的能力,因为XSD的设计也是如此.在一般情况下,从XSD到DTD的转换必然涉及信息丢失(接受的文档集可能需要更大或更小,或者是重叠集).可以对如何管理信息丢失做出不同的选择,这就提出了“如何最好地将XSD转换为DTD形式?”的问题.一定的理论兴趣. (然而,很少有人在实践中发现这是一个有趣的问题.)

所有这一切都集中在你的问题上,作为字符序列的文档,作为文档集的语言,以及作为这种意义上的语言生成器的模式语言.在模式中存在的可维护性和信息的问题不会变成文档集的扩展中的差异(例如,文档模型中的类层次结构的处理).

网友评论