DTD と XSD：XML データ構造をめぐる主導権争い 

ヴォン

こんにちは！私の名前はヴオンです。
株式会社メディアフュージョンで、XML関連製品の開発を担当しているベトナム出身のエンジニアです。
XMLに興味のある方や、XMLを利用されている方に、これまでに蓄積してきた経験を共有できればと思っています。

前回までの2回の記事では、次の2つの基礎的な疑問に答えてきました。 

• なぜ XML は大規模システムの中で今も使われ続けているのか 

• そして XML は実際にどのように構造化されているのか 

しかし、構造を理解するだけでは問題の“半分”に過ぎません。 
エンタープライズ環境では、データは単に「文法的に正しい」だけでなく、 
システム間で取り交わされる“契約”に従って正しいものでなければなりません。 

もしその制御メカニズムが欠けてしまうと── 

• 誤ったデータを入力してもシステムが動いてしまう 

• パートナー企業から送られてくるファイルの形式がバラバラ 

• バリデーションはコードで手作業のように実装するしかない 

• 下流工程で初めてエラーが発覚する 

こうした課題が生まれてしまいます。 
これこそが、次に紹介する概念が存在する理由です。 

well-formed ≠ valid この違いが非常に重要になります。 

1. Well-formed は「XML が読み取れる」ことを保証するだけ 

例： 

 
このドキュメントは 

• 開始タグと終了タグが正しく対応している 

• XML パーサーにとって構造的に問題がない 

→ しかし、システムが total は数値でなければならない と要求している場合、 
　この XML は実際には利用できません。 

2. DTD：XML スキーマの第一世代 

DTD（Document Type Definition）は XML と同時に登場し、次の目的を持っていました。 

• 基本的な構造を記述する 

• XML ドキュメントが「タグだらけの混乱状態」にならないよう保証する 

例： 

【DTD の強み】 

• シンプルで読みやすい 

• パースが速い 

• レガシーシステムでのサポートが広い 

しかし、エンタープライズ環境では DTD の限界が非常に明確になります： 

• データ型がない（すべて文字列扱い） 

• namespace をサポートしない 

• スキーマの拡張が困難 

• 文法自体が XML ではないため、ツールが扱いにくい 

【よく起きる問題】 

• 数値チェック、enum（列挙）、pattern（パターン）検証などをしたい場合、結局は独自にバリデーションコードを書く必要がある。　 

3. XSD：データを厳密にコントロールするために 

• XSD（XML Schema Definition）は、DTD を置き換え、根本的な制約を解決するために設計されました。 

例：データ型の定義 

【XSD のアーキテクチャ上の特徴】 

• データ型をサポート（string, integer, date, boolean, decimal など） 

• 値の制約（min/max, pattern, length） 

• スキーマの再利用（complexType, simpleType） 

• 標準的な namespace のサポート 

これにより、「設計上の取り決め」を「強制ルール」へと昇格させることができます。 

上記の例は、次のような問題を完全に排除します： 

• フォーマット不正なデータ 

• 気まぐれな invoice コード 

• 手入力ミスによるエラー 

4. Namespace ― DTD が“完敗”するポイント 

前回の記事で、namespaceが名前の衝突を避けるために使われることを確認しました。 

もし XML ドキュメントが 

• 業界標準 

• 企業独自の拡張 

• 別システム向けのメタデータ 
  といった要素を組み合わせている場合、namespaceがない構造はほぼ受け入れられません。 

DTD はこの状況をまったく扱えません。 
XSD はそのために生まれた仕組みです。 

5. アーキテクチャ上の問題：DTD を選ぶべきか、XSD を選ぶべきか？ 

実際の導入現場では次のように使い分けられます。 

DTD を使うべきケース 

• 既存のレガシーシステムが DTD を使っている 

• ドキュメントが単純 

• パース速度を最優先したい 

XSD を使うべきケース 

• 組織間でデータをやり取りする 

• 法的コンプライアンスが絡む 

• 長期的に拡張する必要がある 

• namespace を複数扱う 

ポイントはこれだけ： 

• DTD は「構造」をコントロールする 

• XSD は「構造 + データそのもの」をコントロールする 

6. よくある誤り 

多くのチームが DTD を選ぶ理由は、「速くて、作るのが簡単だから」 
というものです。 

しかしその後に起こるのは── 

• フィールドを追加すると schema が崩れる 

• データ型の検証は結局コードで書くしかない 

• 他システム統合時に namespace が衝突する 

その結果： 
schema は存在しているのに、何も enforce できていない状態になり、 
まるで schema が“ない”のと同じになります。 

DTDとXSDの戦いは、実はエンタープライズ環境ではずっと前に終わっています。 
DTD はレガシー環境や単純なドキュメントでは今も有用ですが、 
もしあなたが求めるのが： 

• 厳密なデータコントロール 

• 長期的な拡張性 

• 複数 XML 標準との連携 

• 自動化されたバリデーション 

であるなら、XSD はほぼ必須の選択肢 です。 

次のレッスンでは、次の点について詳しく説明します。 
XPath — XML データを “SQL のように” クエリする方法 
について解説していきます。