プログラミング基礎 I

第六回 (2006年 6月 5日)

DTD の応用

http://www.sw.it.aoyama.ac.jp/2006/PB1/lecture7.html

Martin J. Dürst

duerst@it.aoyama.ac.jp, O 棟 529号室

© 2006 Martin J. Dürst 青山学院大学

目次

• 検証
• データ中心の DTD
• 文書中心の DTD
• 要素か属性か

Moodle の使い方

• 先週 Moodle に登録してない学生と Moodle で何かのトラブルがあった学生、演習開始の時に TA と連絡を取って下さい。

先週の宿題

• DTD が明らかに文書と合わない場合が多い
• 検証しないと DTD の意味が全くない

検証のやり方

米ブラウン大学の Scholarly Technology Group の XML Validation Form を使用。

内部の DTD のある XML ファイルを「Local file: 」として指定、「Validate」(検証) を押す。

又は: フォーものページを「表示」→「文字符号化」→「UTF-8」で強制した後、「Text:」のところに文書をコピーして、「Validate」(検証) を押す。

結果のページに "Document validates OK." とだけあると検証が成功した。

"Errors" の場合には完全に失敗した。

"Warnings" (警告) の場合には修正した方がよい。

Well-formed と valid

Well-formed (整形):

• XML の文法に従う
• 要素、属性の名前、構造は問わない
• XML の処理系は必ずチェックしないと行けない

Valid (整合):

• DTD で検証された XML 文書は valid という
• 検証のプロセスは validation (整合検証) という
• ある特定の DTD で valid になることを valid against ... DTD という
• XML の処理系の一部しかしない
• XML Schema valid とかもある

要素や属性の名前の選び方

• <para1>, <para2>, <para3> の例があった
• 分かりやすい名前が大切
• 分かりやすい名前を思いつかないともしかして構造に問題がある

データ中心の DTD のまとめ方

データを種類別にまとめる:

<ELEMENT 書籍 (著者, 出版, 販売)>
<ELEMENT 著者 (著者名, 住所)>
...

データを区切りなく並べる:

<ELEMENT 書籍 (著者名, 住所, 出版社, 出版年, 販売値段,...)>

データ中心の DTD: 複数の扱い方

複数のものがあると全部一つの要素でまとめた方がよい

<ELEMENT authors (author+)>
<ELEMENT author (name, address,...)>

日本語の場合、<著者集> などが使える

英文の DTD で単数形と複数形の違いに注意

データ中心の DTD: 必須のデータか

要素の場合:

<ELEMENT 要素 (必須, (任意?))>

属性の場合:

<ATTLIST 要素 必須属性 CDATA #REQUIRED>

<ATTLIST 要素 任意属性 CDATA #IMPLIED>

開発途中には任意にする方がよい。

任意のものは必須のものの後が良い。

文書中心の DTD: 文書全体の構造

• 前置: 題名、著者、(目次)、前書き、概要など
• 中心: 章、節など
• 後置: 付属、参考文献、(索引) など

括弧内は自動生成可能なので省略が多い

文書中心の DTD: 章や節をそれぞれ区別

<ELEMENT 本 (章+)>
<ELEMENT 章 (節+)>
<ELEMENT 節 (段落+)>
<ELEMENT 段落 (#PCDATA)>

章や節をそれそれ別の構造にしたい場合に便利

ある部分を章から節とかに変更したいときに不便

文書中心の DTD: 章や節を区別しない

同じものを再利用する時:

<ELEMENT 本 (章節+)>
<ELEMENT 章節 ((章節+)|(段落+))>
<ELEMENT 段落 (#PCDATA)>

「章節」は入れ子になっている。情報テクノロジーで「再起」(recursion) ともいう。

文書中心の DTD: 章の分け方

章を必ず節に分けないと行けない:

<ELEMENT 章 (節+)>

章の先頭に節に属してない部分が可能:

<ELEMENT 章 ((段落*),(節+))>

章に節が必ずしも必要ない:

<ELEMENT 章 ((段落*),(節*))>

図、リストの位置

段落の中:

<ELEMENT 段落 (#PCDATA | 図 | リスト)*>

段落の外 (e.g. HTML の <li>, ...):

<ELEMENT 節 (段落 | 図 | リスト)*>

図などの場合には表示の時に必ずマークアップと同じ位置にしないと行けないことはない。

要素か属性か

文書の構造の設計の時、一番よく議論される点

要素か属性か: 順番

XML で要素の順番は重要。勝手に入れ替わることはない。

<a><b/><c/><d/></a> ≠ <a><c/><d/><b/></a>

XML で属性の順番は適当。入れ替わることもある。

<a b='x' c='y' d='z'/> = <a c='y' d='z' b='x'/>

結論: 順番が大切なときは要素を使う。

要素か属性か: 複数

要素は複数合っても良い:

<b/><b/><b/>

同じ名前の属性は一個しかできない:

<a b='x' b='y' b='z'/>

結論: 複数が必要なときは要素を使う。

要素か属性か: 構造

要素には内部構造がある:

• 子要素
• 属性

属性には内部構造がない

結論: 内部構造が必要な時には要素を使う。

人間が読む文書の場合に、内部構造が必要になるときがあるので、要素にした方がよい。

(例: 見出しに数式や振り仮名などが必要なとき)

要素か属性か: 表示

要素は普段 (例えば空の CSS スタイルシートでも) 表示される。

要素ごとにスタイルを細かく設定できる。

属性は普段表示されない。スタイルも細かくは指定できない。

表示したいものは要素にした方が良い。

演習 1: 先週の DTD と文書を再度整合検証

自分の「手紙」の XML 文書のために作った DTD と文書をもう一度整合検証する。

今日のうちに内部 DTD を含む文書を Moodle に投稿。

演習 2: 本のデータのための DTD の作成

先々週作った本についてのデータのための内部 DTD を作る。

今日の授業も参照にして構造を修正する。

自分のデータにはないがありそうな項目も DTD に追加する。

トップのところは <books><book>...</book><book>...</book>...</books> みたいな構造にする。

6月11日 (日曜日) の 23:55 までに Moodle に投稿。