プログラミング基礎 I

第七回 (2008年 6月 2日)

DTD の応用

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

Martin J. Dürst

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

AGU

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

目次

先々週と先週の宿題

Well-formed と valid

Well-formed (整形):

Valid (整合):

データ中心の 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 スタイルシートでも) 表示される。

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

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

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

DTD の限界

演習 1: DTD の作成

CD の XML データのための DTD を作成する

XML そのものは変更しないこと

もっとデータがあることなども考えるが、緩すぎないようにする

検証を使って DTD が正しいかどうを必ず確認する

内部 DTD を含む文書を 6月 6日 (金) の 22:00 時までに Moodle に投稿