4

次の命題は成立しますか: すべての DTD には、まったく同じ言語を定義する XSD があり、すべての XSD には、まったく同じ言語を定義する DTD があります。または別の言い方をすれば、任意の DTD によって定義された言語のコレクションは、任意の XSD によって定義された言語のコレクションとまったく同じでしょうか?

質問を少し拡張します。XML ドキュメントは、基本的に大きな文字列です。言語は文字列の集まりです。たとえば、すべての MathML ドキュメントの (無限の) セットは言語であり、すべての RSS ドキュメントのセットなども同様です。MathML (RSS、...) も、すべての XML ドキュメントの (無限の) セットの適切なサブセットです。このような XML のサブセットを定義するには、DTD または XSD を使用できます。

現在、すべての DTD は正確に 1 つの言語を定義しています。しかし、考えられるすべての DTD を考えると、一連の言語が得られます。私の質問は、このセットは、考えられるすべての XSD から得られるものとまったく同じですか? その場合、DTD と XSD は、どちらかによって定義される XML 言語の範囲が等しいという意味で同等です。

この質問が重要なのはなぜですか？DTD と XSD の両方が同等である場合、DTD を入力として受け取り、同等の XSD を提供するプログラムと、その逆を行う別のプログラムを作成することができます。まさにこれを行うと主張するプログラムがかなりあることは知っていますが、それが実際に可能かどうかは疑問です。

4

2 に答える 2

5

興味深い質問です。よく尋ねた！

どちらの方向でも、答えは「いいえ」です。

以下は、XSD に相当するものがない DTD です。

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

この DTD が受け入れる一連の文字シーケンスには、<e/>と<e>&egbdf;</e>の両方が含まれますが、 は含まれません<e>&beadgcf;</e>。

XSD 検証は、エンティティがすべて展開済みの情報セットで動作するため、3 番目のケースと 2 番目のケースを区別できる XSD スキーマはありません。

DTD が XSD では表現できない制約を表現できる 2 つ目の領域には、NOTATION 型が含まれます。例は挙げません。詳細は複雑すぎて、調べないと正確に覚えられませんし、調べたくなるほど面白くもありません。

3 番目の領域: DTD は名前空間属性 (別名名前空間宣言) と一般属性を同じ方法で扱います。したがって、DTD はドキュメント内の名前空間宣言の外観を制限できます。XSD スキーマではできません。同じことが xsi 名前空間の属性にも当てはまります。

これらの問題をすべて無視し、事前定義された実体以外の名前付き実体への参照を含まない文字シーケンスのみに関して質問を定式化するとlt、gt答えが変わります: NOTATION 宣言を含まないすべての DTD について、は、エンティティ展開後に正確に同じドキュメント セットを受け入れ、名前空間属性と xsi 名前空間の属性を無視する方法で「同じ」が定義された XSD スキーマです。

反対に、相違点には次のようなものがあります。

  • XSD は名前空間に対応しています。次の XSD スキーマはe、ドキュメント インスタンス内のその名前空間にバインドされているプレフィックスに関係なく、指定されたターゲット名前空間内の要素のインスタンスを受け入れます。 

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

    e指定された名前空間内のすべての要素のみを正常に受け入れることができる DTD はありません。

  • XSD にはより豊富なデータ型のセットがあり、データ型を使用して要素と属性を制約できます。次の XSD スキーマには、同等の DTD がありません。

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

    このスキーマはドキュメントを受け入れますが、ドキュメントは受け入れ<e>42</e>ません<e>42d Street</e>。DTD には #PCDATA コンテンツを制約するメカニズムがないため、どの DTD もそれを区別できません。最も近い 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 は、名前空間宣言や xsi:* 属性などのエンティティ宣言と特殊なケースを除いて、DTD が表現できるすべてを表現できます。XSD はそうできるように設計されているためです。そのため、DTD を XSD スキーマ ドキュメントに変換する際の情報の損失は、比較的控えめで、よく理解されており、ほとんどのボキャブラリ デザイナーが DTD アーティファクトと見なして実質的に関心のないものに関係しています。

XSD はそのように設計されているため、XSD は DTD よりも多くの表現を行うことができます。一般に、XSD から DTD への変換には必然的に情報の損失が伴います (受け入れられるドキュメントのセットを大きくしたり、小さくしたり、重複したセットにしたりする必要がある場合があります)。情報の損失を管理する方法については、さまざまな選択が可能であり、「XSD を DTD 形式に変換するにはどうすればよいか」という疑問が生じます。特定の理論的関心。(ただし、実際にこれを興味深い質問だと考える人はほとんどいないようです。)

これはすべて、あなたの質問と同様に、文字シーケンスとしてのドキュメント、ドキュメント セットとしての言語、およびその意味での言語のジェネレータとしてのスキーマ言語に焦点を当てています。ドキュメント セットの拡張の違いにならないスキーマに存在する保守性と情報の問題 (たとえば、ドキュメント モデル内のクラス階層の扱い) は考慮されていません。

于 2013-11-02T16:24:22.873 に答える
1

修飾子がなければ、答えはノーです。

「言語」と呼ぶものを定義する必要があります。私の考えでは、あなたが参照しているのは、ドキュメントのスキーマを定義するための言語です。スキーマは、ドキュメントの構造とコンテンツに対する制約を定義します。XSD で表現できる制約は、DTD よりもはるかに強力です。いいえ、それらは同じではありません。

DTD と XSD を比較すると、そうでない理由を理解するのに役立つかもしれません。

于 2013-10-30T15:08:53.140 に答える