[25]

文書型定義document type definition (DTD) は、 SGML や XML において文書型を定義するマーク付け宣言等の集合体です。

[27]

DTD はマーク付け言語に関するスキーマ言語の1つですが、現在ではスキーマ言語自体が旧時代の遺物と考えられています。その中でも DTD は特に古い時代を引きずった避けるべきものというのが一般的な認識です。

文書型定義 (SGML)

[17] 文書型定義は、文書型の定義。 Document type definition。 DTD。

[16]

3.24 文書(型)定義document (type) definition, DTD
応用によって決定される規則であって、 SGML を特定の型の文書のマークに適用するもの。文書型定義は文書型宣言で表現された要素型, 要素の関係, 属性の形式的な仕様とマークで表現することができる参照を含む。文書型定義は SGML が構文を定義しているマークの語彙を定義する。

出典: ISO/IEC 10744:1997 3 Definitions http://www.y12.doe.gov/sgml/wg8/docs/n1920/html/clause-3.html#def-3.24

[15]

共通識別子は、その要素がどの種類 (型) のものであるかを表している。その特定の型のすべての文書に適用するマーク宣言の集合を、文書型定義という。 JIS X 4151‐1992 参考3 4.1

意味不明なのは JIS の翻訳が悪いと思われ。

何度も同じことを繰り返さないで済むように、文書型定義は、普通、別個の実体として蓄えてある。それぞれの文書では、その文書型を指定しその実体を参照できるようにした文書型定義を書くことで、その中に取り込んで利用する。 JIS X 4151‐1992 参考3 4.1

[14] SGML では種々のマーク宣言を使って、文書型宣言によって文書型を定義します。

[7] 文書型定義と文書実現値は、 class と instance のような関係にあります。

[2] DOCTYPE 宣言 (文書型宣言) により明示される。直接記述される内部部分集合と、識別子により参照される外部部分集合に大別できる。
[3] DTD の明示は旧来の SGML では必須であったが、 WebSGML では省略 (暗示) することができる。
[4] 本来の SGML よりも非常に機能を制限したものながら、 XML でも DTD を使用することが出来る。 (というか妥当であるためには DTD の明示が必須である。)
[5] しかしながら、 XML では妥当性検証が optional であるがために DTD は本来の実力をほとんど発揮できないばかりか、むしろ前時代の遺産として嫌われる傾向にある。
[6] 嫌われる原因としては、 (1) XML が文書実現値本体の記述では捨てた記述の自由性が比較的 DTD には残されている (よって実装が比較的面倒である) こと、(2) 拡張性のある DTD にするためには超人的トリック(謎)が必要であること、(3) (2) に XML名前空間が加われば DTD との相性は最悪で、使い物にならなくなる場合さえあること、辺りに集約できよう。

[12] SGML では文書型定義/DTD と似たものとして、連結処理定義/LPD を規定していますが、こちらは SGML の必須の機能ではなくあまり使われておらず、 XML にも含まれていません。

[11] ISO/IEC 10744 は体系の定義のための体系的DTD を規定しています。また、 DTD 風のマーク宣言の集合体として字句型定義も規定されています。

文書型定義 (XML)

定義

[19]

DTD
DTD (文書型定義) は XML マーク宣言の集成であり、 DTD に適合する文書で使うことができる合法的な構造、要素、属性を集成として定義するものです。

仕様書:

XHTML 1.0
- 2.2. General Terms IW:XHTML10:"general"

[20]

文書型定義document type definition (DTD)
特定の文書型の文書実現値が適合する XML の構造と構文の規則の形式的で機械可読な表現。 XML 1.0 で文書実現値を宣言された文書型に関して妥当性検証するために使われる scheme の種類。同じマーク付け模型が複数の DTD で表現できます。 XHTML m12n Term

仕様書:

XHTML m12n
- [XHTML m12n Term] 2. Terms and Definitions IW:XHTML1m12n:"terms.html#a_terms"

物理構造

[28] XML DTD は、文書実体中の文書型宣言に直接記述する内部部分集合と、文書型宣言によって参照する外部部分集合によって構成されます。また、内部部分集合や外部部分集合における引数実体参照から参照する引数実体もその一部を構成します。

宣言部分集合
- 内部部分集合
- 外部部分集合
引数実体
マーク区間
- 条件区間
  - INCLUDE
  - IGNORE

論理構造

マーク付け宣言
- 文書型宣言
- 要素宣言
- 属性並び宣言
- 実体宣言
  - 一般実体
    - 非解析対象実体
  - 引数実体
- 記法宣言
処理指令

MIME 型

[29] 外部部分集合の MIME型については、外部部分集合実体を参照。

[30] 外部引数実体のMIME型については、外部引数実体を参照。

構文解析への影響

[36] XML文書を構文解析してDOM木を構築するに当たり、次に示す点で DTD の内容が処理に影響を与えます。

[37] DTD そのものがDOMに反映される場合、当然ながら DTD の内容が木に影響します。現在の DOM Standard の範囲では DOCTYPE 宣言の有無と文書型名、公開識別子、システム識別子が DOM木に反映されます。

[38]

DOM3 時代は更に実体宣言、記法宣言、内部部分集合部分の文字列が (理論上は) DOM木に反映されることとなっていました。また Web 以外での DOM の実装では、これ以外に要素宣言、属性並び宣言、 DTD 内の処理指令も DOM木に反映されることがあります。

[39] 属性並び宣言で CDATA 以外の宣言型が指定されている場合、それに対応する属性値では、通常よりも更に正規化が行われます。

[40] 属性並び宣言で既定値が指定されている場合、それに対応する属性が要素になければ既定値が設定されます。

[41] また次に示す点は木そのものには影響しませんが、 DOM木としては区別がつかない XML文書上の表現方法の違いがXML文書の妥当性に影響します。 (DOM木に変換する前の構文解析途中に DTD に基づきエラーを検出する必要があります。)

[42] 要素の内容が要素内容とされている場合、文字参照やCDATA区間を使ってはなりません。
[43] 要素の内容が EMPTY とされている場合、 CDATA区間や実体参照を使ってはなりません。
[44] 要素の内容が EMPTY とされている場合、空要素タグ構文を使うべきです。
[45] 要素の内容が EMPTY 以外とされている場合、空要素タグ構文を使うべきではありません。

XML DTD 入門編

[21] XML では著者が自由に要素や属性を使えるわけですが、その自由さはともすれば無秩序を招くことになります。たとえば「段落」要素の子供に「章」要素があるとか、「人名」要素の子供に「電話番号」要素があるとか、「本」要素に「敬称」属性がついているとかいうようなことは、普通は認められるべきではないでしょう。しかし XML の構文自体はこのような意味的判断とは独立していますから、ここで挙げた例もすべて認められてしまいます。

そこで、要素や属性の関係の制約を記述する方法が幾つも考えられています。その記述を一般に「schema (スキーマ)」と呼びまして、特に XML 用のものとして「XML DTD」や「XML Schema」などがあります。このような schema を使って文書の正当性を検査することを「妥当性検証 (validation)」といいます。検査に合格すれば「妥当 (valid)」、不合格なら「非妥当 (invalid)」です。データの入力を人間が行う場合には特に間違いが起こりやすいですから、 schema を用意して機械的に検証することは非常に重要です。

今回取り上げるのはそのうちの XML DTD です。「DTD」は「文書型定義 (document type definition)」の略です。 DTD は設計が古いので既に色々な問題点がわかっています (から他の schema 言語が色々と考案されたのです) が、比較的単純で簡単ですし、現時点で他の schema 言語よりもずっと広く使用・実装されています。

今後の予定

2. 要素型宣言 3. 内容モデル 4. 属性定義並び宣言 5. 実体宣言 6. 補足

各回の最後には演習問題を用意する予定です。

メモ

[8] Designing document type definition (DTD) in SGML/XML http://www.chimaira.org/docs/On-DTD.A2.html

[9] DTDs Don’t Work on the Web (Henri Sivonen 著, 2007-01-19 00:24:34 +09:00 版) http://hsivonen.iki.fi/no-dtd/ (名無しさん 2007-01-24 12:40:59 +00:00)

[10] DTD は役に立たない (わかば著, 2007-05-25 09:21:54 +09:00 版) http://suika.suikawiki.org/~wakaba/d/d200705#d25-1 (名無しさん 2007-06-03 14:33:00 +00:00)

[13] ISO/IEC JTC1/SC34 は名前空間・データ型対応DTD の標準化作業を行っていますが、作業はかなりゆっくりしっていってねな感じのようです。

[18] Ending DTD proliferation at the W3C ( (Michael[tm] Smith 著, 2014-01-14 04:22:05 +09:00 版)) http://lists.w3.org/Archives/Public/www-tag/2014Jan/0033.html

[23] Don’t call me DOM » Generating HTML documentation from DTD (2007-08-04 11:19:37 +09:00 版) http://people.w3.org/~dom/archives/2007/07/generating-html-documentation-from-dtd/ (名無しさん 2007-08-04 02:21:17 +00:00)

[24] Don’t call me DOM » DTD comparison (2007-09-13 21:14:26 +09:00 版) http://people.w3.org/~dom/archives/2007/09/dtd-comparison/

メモ

[1] 俗に、 DTD によって記述される対象であるマーク付け言語のことを DTD と言うこともあります。場合によっては DTD が存在しないマーク付け言語のことすら DTD ということすらあります。

[31] DTD は歴史的にマーク付け言語の形式的定義とみなされており、特に SGML 時代は (XML DTD よりも表現力が高かったこと、他にスキーマ言語がなかったこと、一般に現在よりも仕様(書)に求められる厳密度が低かったことから) DTD による妥当性検証を通過することが文書へのマーク付け言語への適合 (SGML 用語である「妥当」) と考えられていました。

[32] しかし現在では DTD によって記述できるのは仕様のごく基本的な部分のみであること、にも関わらず DTD による妥当性検証を通過することが適合と誤解されることが多いことなどから、 DTD はむしろ有害と見なされるようになっています。

[33]

W3C は長年 Validator と称して HTML4 への適合性を検証するサービスを提供していましたが、実態はほぼ DTD による妥当性検証を行っているに過ぎず、自身の勧告である HTML4 仕様書の記述に従っているかどうかのチェックは実装していませんでした。当時 W3C Validator で検査したことを根拠に HTML4 や XHTML1 の正しい文書であると主張する Webページは世界的に相当数ありましたが、そのうちのどれだけが HTML4/XHTML1 の仕様上の要件にすべて従っていたのか大変怪しいところです。 (その HTML4/XHTML1 仕様書の方も、一体どれが適合性の要件なのかはっきりしない低品質の仕様書ではあったので、それ以上のものを実装するのも難しかったでしょうが...)

[34]

W3C の XHTML2 WG が本文と DTD と XML Schema と RELAX NG とで矛盾する内容の仕様書を発行し続けていたように、複数の異なる「正式」な定義が併存しているとその整合性を保つのは事実上不可能です。 DTD で適合性の要件を記述できないのは明白ですし、 XML Schema は複雑で理解困難にも関わらずやはりすべての適合性の要件を記述できるわけではないので、スキーマによる定義を正式な仕様の一部としない近年の傾向は自然な流れでしょう。

[22] ANN: Web 2.0 Mashup Ajax JavaScript Json Web Standards Validator Poniez <3 from Bjoern Hoehrmann on 2006-11-01 (www-qa@w3.org from November 2006) http://lists.w3.org/Archives/Public/www-qa/2006Nov/0000.html (名無しさん 2006-11-12 09:59:34 +00:00)

[35] DTD++

[46]

Inline XBRL Part 0: Primer 1.0 (2013-06-04 02:32:15 +09:00 版) http://www.xbrl.org/specification/inlinexbrl-part0/rec-2010-04-20/inlinexbrl-part0-rec-2010-04-20.html

It is worth noting that the Public Text Class "DTD", when used as part of the Formal Public Identifier, means "document type declaration subset" and not "Document Type Definition"; so the use of the Formal Public Identifier should not be taken to imply the existence of a Document Type Definition.

[47] 型定義type definition = 文書型定義。 JIS X 4151‐1992 3. (36)

[50]

RFC 5689 - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) (2017-09-17 19:54:27 +09:00) https://tools.ietf.org/html/rfc5689#section-2

This document uses XML DTD fragments (Section 3.2 of
[W3C.REC-xml-20081126]) as a purely notational convention.

[51]

RFC 5842 - Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) (2017-09-30 00:47:40 +09:00) https://tools.ietf.org/html/rfc5842#section-1.1

This document uses XML DTD fragments ([XML]) as a notational
convention, using the rules defined in Section 17 of [RFC4918].

DTD の版