Edit

Page

Page title:

Page body:

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

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

* DTD の版

[26] [[DTD]] には歴史的にいくつかの版があります。

[FIG(middle list)[ [49] [[DTD]] の版
- [[SGML]] [[DTD]]
- [[Web SGML]] [[DTD]]
- [[XML DTD]]
- [[DT4DTD]]
- [[データ型・名前空間対応DTD]]
- [[SGML]] [[LPD]]
- [[ISO/IEC 10744]] [[体系的DTD]]
- [[ETDS]]
- [[XHTML m12n]]

]FIG]

[48] [[XML]] の影響を受けた [[EBML]] は[[スキーマ言語]]を [[EBML DTD]]
と呼んでいます。 [[SGML]] 系の [[DTD]] と ([[スキーマ言語]]であるということ以外に)
互換性はありません。

* 文書型定義 (SGML)

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

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

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

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

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

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

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

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

- [2] [CODE(SGML)[[[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]]
-- [CITE[2.2. General Terms]]
<IW:XHTML10:"general">

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

仕様書:
-[[XHTML m12n]]
--[XHTML m12n Term] [CSECTION[2. Terms and Definitions]]
<IW:XHTML1m12n:"terms.html#a_terms">

** 物理構造

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

[FIG(short list)[
- [[宣言部分集合]]
-- [[内部部分集合]]
-- [[外部部分集合]]
- [[引数実体]]
- [[マーク区間]]
-- [[条件区間]]
--- [CODE(XML)@en[[[INCLUDE]]]]
--- [CODE(XML)@en[[[IGNORE]]]]
]FIG]

** 論理構造

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

** MIME 型

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

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

** 構文解析への影響

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

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

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

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

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

[41] また次に示す点は[[木]]そのものには影響しませんが、 [[DOM木]]としては区別がつかない
[[XML文書]]上の表現方法の違いが[[XML文書]]の[[妥当性]]に影響します。
([[DOM木]]に変換する前の[[構文解析]]途中に [[DTD]] に基づきエラーを検出する必要があります。)
[FIG(list)[
- [42] [[要素]]の[[内容]]が[[要素内容]]とされている場合、
[[文字参照]]や[[CDATA区間]]を使ってはなりません。
- [43] [[要素]]の[[内容]]が [CODE(XML)@en[[[EMPTY]]]] とされている場合、
[[CDATA区間]]や[[実体参照]]を使ってはなりません。
- [44] [[要素]]の[[内容]]が [CODE(XML)@en[[[EMPTY]]]] とされている場合、
[[空要素タグ]]構文を使うべきです。
- [45] [[要素]]の[[内容]]が [CODE(XML)@en[[[EMPTY]]]] 以外とされている場合、
[[空要素タグ]]構文を使うべきではありません。
]FIG]

** 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]
[CITE[Designing document type definition (DTD) in SGML/XML]] <http://www.chimaira.org/docs/On-DTD.A2.html>

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

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

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

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

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

[24] [CITE[Don’t call me DOM &#187; DTD comparison]] ([TIME[2007-09-13 21:14:26 +09:00]] 版) <http://people.w3.org/~dom/archives/2007/09/dtd-comparison/>

* 応用

[SEE[ [[SGML応用]] ]]

* メモ

[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] [CITE[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>
([[名無しさん]] [WEAK[2006-11-12 09:59:34 +00:00]])

[35] [[DTD++]]

[FIG(quote)[
[FIGCAPTION[
[46] [CITE[Inline XBRL Part 0: Primer 1.0]]
([TIME[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>
]FIGCAPTION]

> 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.

]FIG]

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

[FIG(quote)[
[FIGCAPTION[
[50] [CITE@en[RFC 5689 - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)]]
([TIME[2017-09-17 19:54:27 +09:00]])
<https://tools.ietf.org/html/rfc5689#section-2>
]FIGCAPTION]

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

]FIG]

[FIG(quote)[
[FIGCAPTION[
[51] [CITE@en[RFC 5842 - Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)]]
([TIME[2017-09-30 00:47:40 +09:00]])
<https://tools.ietf.org/html/rfc5842#section-1.1>
]FIGCAPTION]

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

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)