DTD 3.2 概観

line
_________________________________________________________

Outline : Kinder, Gentler Validator' (KGV) のOutlineからのリストです。

[コンパクト版]も作ってありま す。HTML本を読む際の手助けに利用下さい。



 SGML、DTD にそってと、しりごみしたくなる言葉ですが、リラックスして考えてみます。ついで、要約へとすすんで下さい。DTD 3.2 も見えてくと思います。

 [SGMLって]やHTML 4.0仕様書の[SGMLとHTMLについて]も参照して下さい。記号の見方です。

#^topへ戻る


HTML 3.2参考仕様書の構成

目次から意味を探る

目次(Contens)

DTD 部分と目次の関連づけ

<!--================== HTML content models ==============================-->
<!--
       HTML has three basic content models:
       HTMLは、三つの基本的な内容モデルからなっています:

        %text       character level elements and text strings
             (文字符号レベル要素とテキスト文字列)
        %flow       block-like elements e.g. paragraphs and lists
              (ブロック要素、例パラグラフやリスト)
        %bodytext   as %flow plus headers H1-H6 and ADDRESS
              (%flowに見出しと署名を加えたもの)

の記載を以下のように補ってみます。DTDの用語になれていなくても、見えてきます。


# Headings (H1 - H6)  % headings  -----------+
                                             |
                                             |
# The ADDRESS element   ADDRESS -------------+
                                             |--- %bodytext(%body.content)
                                             |
# Block level Elements  %block ---+          |
                     (=<P>%text)  |          |
                                  |-- %flow--+
                                  |
# Text level element    %text ----+

-->

HTML 3.2 DTD は、

<!--=================== Document Body =====================================-->

<!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*">

<!ENTITY % color "CDATA" -- a color specification: #HHHHHH @@ details? -->

<!ENTITY % body-color-attrs "
        bgcolor %color #IMPLIED
        text %color #IMPLIED
        link %color #IMPLIED
        vlink %color #IMPLIED
        alink %color #IMPLIED
        ">

<!ELEMENT BODY O O  %body.content>
<!ATTLIST BODY
        background %URL #IMPLIED  -- texture tile for document background --
        %body-color-attrs;  -- bgcolor, text, link, vlink, alink --
        >
上図は、DTD を図解したもので、
<!ELEMENT BODY O O  %body.content>>
で、ボディ内には%body.contentがきます。
<!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*">

その%body.contentとは、%heading | %text | %block | ADDRESS のことです。つまり、%text も 認められています。

  1. ボディ内には%body.contentがきます ----> %text
  2. <P>ボディ内には%body.contentがきます</P> ----> %block

しかし、ボディ内ではブロック−レベル要素しか認めない方向になり、スタイル・シートでの 箱型モデルもブロック−レベル要素をもとにしていますので、 2の記載方法をとることが大切になります。

<!ENTITY % font "TT | I | B  | U | STRIKE | BIG | SMALL | SUB | SUP">
<!ENTITY % phrase "EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE">
<!ENTITY % special "A | IMG | APPLET | FONT | BASEFONT | BR | SCRIPT | MAP">
<!ENTITY % form "INPUT | SELECT | TEXTAREA">
<!ENTITY % text "#PCDATA | %font | %phrase | %special | %form">

#PCDATA=文字符号

<P>+%text=%block となります。テキスト文(#PCDATA=文字符号)は要素Pで囲ってブロック化しておかなければ、浮いた文と言われます。

%text に、<A>・<IMG>・<BR>もはいることに注意しておいて下さい。

以下のように様に考えておくと、一般性がでてきます。 区切り付けする見出し(%headings)と署名連絡の役をはたすアドレス(ADDRESS)は、%flowとは異なる意味を持つので分けてあります。HTML 3.2では、LIの内容は%flowと定義され見出しやアドレスをリスト化できません。

# Headings (H1 - H6)  % headings  -----------+
                                             |
                                             |
# The ADDRESS element   ADDRESS -------------+
                                             |--- %bodytext(%body.content)
                                             |
# Block level Elements  %block ---+          |
                                  |-- %flow -+
                    <P>%text</P>--+
                         |
                         |
# Text level element    %text
  1. [<A href="URL">ホーム</A>]へ--> %text
    <IMG src="abc.gif" alt="*" width="10" height="20">--> %text
  2. <P>[<A href="URL">ホーム</A>]へ</P>--> %block
    <P><IMG src="abc.gif" alt="*" width="10" height="20"></P>--> %block

2の記載方法をとることが大切になります。分類して、見ておくとただ覚えておくよりも理解しやすく、忘れませんし、DTD で確認しみようと気付くとおもいます。

目次の意味は

 #PCDATA Parsed Character Data: パーサーの解析をうける文字データ
 CDATA Character Data: 終了タグが出てくるまでパーサーの検証を受けない文字データ

  <FONT SIZE="+1"> <HR WIDTH="%75"> など quotate「" " 」が必要
  <FONT SIZE="5"> は <FONT SIZE=5> でもいい。 数字の場合

whitespaceといわれる改行(return)、半角スペース(space)、タブ(tab) は、無視されます。このことを利用して、インデント(字下げ)でHTMLを見やすく書くことができます。


 文書の構造の末端、基本は文字データ(文字列)で、それを修飾マークアップする要素からなります。
<!ENTITY % text "#PCDATA | %font | %phrase | %special | %form">
と定義してありますので、%textが文書の構造の末端にくると言います。
block level elements の内容は、文字とtext level elementつまり%textが基本です。|IMG|A|や|BR|もtext level element(%text)に属するすることに注意しておかなければなりません。

RFC 1866(HTML 2.0)6. Characters, Words, and Paragraphs
An HTML user agent should present the body of an HTML document as a collection of typeset paragraphs and preformatted text.
RFC 1866(HTML 2.0)6. 文字符号・単語そしてパラグラフ
表示代行手段(ブラウザなど)は、植字されたパラグラフや整形文の集まりとして、HTML文書を表現すべきです。
normal Pとparagraph like要素
テキストはP要素で囲みますが、normal Pとも言います。ブロック・レベル要素は、Paragraph like(パタグラフ様)とも言われます。つまり、ブロックを作るという意味では、同じ範疇に入ります。

 text flow などと表現しますが、文字(letter)列文章で内容を伝えるのが基本です。当然のことですが。その内容を構造化しておかないとコンピュータには理解できません。
 そこで、%text で多少表現力もつけたものを基本として、構造化のためにPで囲み、パラフラフですよと知らせます。<p>%text</P>と、Pが囲みますので、Pは container だと言われます。<p>%text</P> も 構造化されたtext flow です。

 もう少し便利に、リスト(UL,OL,DL)があります。これは<p>%text</P>の延長です。やはり text flow ですが、構造化されています。このような構造化された text flow を作るタグは block level element といいます、一方構造化されていない %text は text level element といい、block level elemen の内容になります。

 リストは、入れ子ができます。
 block level element の内容は、上にみたように基本は %text です。入れ子はbolck level element の中にまた bolck level element を入れることを意味しますので、内容が %text から <!ENTITY % flow "(%text | %block)*">と%text|%block に拡張されています。

 タグで囲まれて範囲が指定される構造で一行空白をおいて表示される(パラグラフ・ブリーク)もの、つまり block のあるものを%block、block level elemennt といいますが、これは text flow と言う視点からみた場合です。

<!ENTITY % block
     "P | %list | %preformatted | DL | DIV | CENTER |
      BLOCKQUOTE | FORM | ISINDEX | HR | TABLE">

 text flow からみると、headingとADDRESSは使われ方がことなります。text flowを整理する見出しがheadingで、ADDRESSは text flow とは別な目的につかわれます。

 そこで、text flow という伝達の基本からみて%text|%blockは%flow というカテゴ リーがでてきます。ブロックをつくるタグですが、heading とADDRESS は除外した考 えです。heading とADDRESSもいれるとタグで囲むものがすべて網羅されます。一方、基本の%textは、ブロックの内容としていつも使います。

 そこでまた一つの考えがでてき、%body.content というもので表現します。
<!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*">と定義されています。

ブロックを囲むスーパー・ブロック要素と言われるCENTERやDIVの内容になるものです。%body.content が内容になれるので、heading や ADDRESS も内容になれ、これらの水平位置の表示(センタリングなど)ができます。 list の内容は、%flow でこれには heading と ADDRESS は含まれていません。ここが、%flow と %body.content の違いです。


* %text
 <!ENTITY % text "#PCDATA | %font | %phrase | %special | %form">
 <!ELEMENT ( %heading )  - -  (%text;)*>
 <!ELEMENT ADDRESS - - %address.content>
   <!ENTITY % address.content "((%text;) | P)*">

 <!ELEMENT P     - O (%text)*>
 <!ELEMENT PRE - - (%text)* -(%pre.exclusion)>
   <!ENTITY % pre.exclusion "IMG|BIG|SMALL|SUB|SUP|FONT">
   <P> との違いは-(% pre.exclusion) と (% pre.exclusion) は使
   えません。
 <!ELEMENT DT - O  (%text)*>
     DD とは違って、%text のみです。定義なのですから。

* %flow:  <!ENTITY % flow "(%text | %block)*">
          %text か %block か、
          %text なら上の基本と同じです。
          %block は入れ子ができることを意味します。
          それが、%flow の意味するものだと思います。
          
注意 %blockとは:
     <!ENTITY % block
     "P | %list | %preformatted | DL | DIV | CENTER |
      BLOCKQUOTE | FORM | ISINDEX | HR | TABLE">
      --> %block に、heading や ADDRESS は属しないことに注意します。

 <!ELEMENT LI - O %flow -- list item -->
 <!ELEMENT DD - O %flow;>
 
* %body.content:
      <!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*">
      block level element 開始と終了タグで指定された範囲を持ち、
      その範囲の表示形式を決めます。

 <!ELEMENT DIV - - %body.content>       センタリング形式に
 <!ELEMENT BLOCKQUOTE - - %body.content>   引用形式に
 <!ELEMENT FORM - - %body.content -(FORM)>  Form形式に、
                         -(FORM)で入れ子はできない。
 <!ELEMENT (th|td) - O %body.content>    表形式に
    <!ELEMENT table - - (caption?, tr+)>
    <!ELEMENT tr - O (th|td)*>

 Table で、%body.contentということは、
 
	<!ELEMENT table - - (caption?, tr+)>
	<!ELEMENT tr - O (th|td)*>
	<!ELEMENT (th|td) - O %body.content>

 %body.contentとすべてのbodyの要素を使っていいことになります。
 言い替えると、まずtableを作りそこがbody内容といったことができることを意味
します。
       <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
       <HTML>
       <HEAD><TITLE>table</TLTLE>
       <BODY>
       <TABLE>
       
       </TABLE>
       </BODY>
       </HTML>

 honya.co.jpのもくろみにこの例が見られます。
     (http://www.honya.co.jp/mokuromi.html)

#^topへ戻る


パラグラフとは

 P には、%text しかはいれません。
 と言うよりも、%textはtext level element でそれ自身範囲を指定しません。で、ドキュメントのなかでは、範囲が明確でない文を浮いた文といいます。block level element を使うと範囲は決められます。開始タグから終了タグまでです。

 そこで、text level element に、<!ELEMENT P - O (%text)*>の指定にしたがって、<P>%text</P>として、block level element になりました。
 終了タグは、省略できます。しかし、省略しないで書くことを心がけておきましょう。省略すると、次に続くHR要素やTABLE要素との間にパラグラフ・ブリークがこないブラウザがあります。また、P要素は、内容を持つコンテーナで、改行をする目的であるセパレータではないと言うHTML 2.0以降の定義を意識しておくためにも終了タグを省略しないで、<P>aaa</P>と囲い内容をとるコンテーナとして使います。

参照 
 character :
    An atom of information, for example a letter or a digit.
    Graphic characters have associated glyphs, whereas control characters
    have associated processing semantics.
 文字符号 :
    情報の最小単位、例えば文字や数値。
    グラフィックな文字符号は絵文字(記号)があり、一方制御文字符号に処理構
    文があります。

 data character :
   Characters other than markup, which make up the content of elements
 データー文字符号 :
   要素の内容をマーク付けするマーク付け用以外の文字符号

 Why no <IMG> inside <PRE>?
   http://ugweb.cs.ualberta.ca/‾gerald/validate/img-in-pre.html

#^topへ戻る


検証してみよう

 検証してみ、そこのFAQをみることからはじめました。そして、DTDへといき、羅列 的タグの説明を自分なりに系統立ててみました。「SGMLにそったDTDで規定されているのがHTMLです。」ときて、実体概念はといった日本語の解説も、自分なりにベールをはがしてみました。とにかく検証してみませんか。

WebTechs Validation Serviceでの資料をみます。
 http://www.webtechs.com/html-val-svc/

WebTechs Validation Service
[ Mirror Sites | Notes | What's New | About This Service | Statistics | 
Scott Bigham's FAQ | Icon Methods] 
----------------------------------------------------------------------
| Scott Bigham's FAQ |
The Unofficial WebTechs HTML Validator FAQ
Section 1: WebTechs and other validators
Section 2: HTML and SGML
Section 3: WebTechs's error messages

| Notes |
Important Notes About the WebTechs Validation Service
       Notes and problems with the Mozilla DTD. 
       Notes about the HotJava DTD. 
----------------------------------------------------------------
The DTD's for HTML 2.0で、Public text もえられます。
 http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html
 
HTML 3.0にリンクし、解説もあります。
 http://www.w3.org/pub/WWW/MarkUp/html3/Contents.html

 RFC1866は用語がのっているのでやはりみておくものでしょう。
RFC IndexRFC Index:
 http://ds.internic.net/ds/rfc-index.html

HTML 3.2 Reference SpecificationがFinal になり、
 http://www.w3.org/pub/WWW/TR/REC-html32.html
TABLE については RFC1942 が RFC Index でえられますし、
経緯についてのコメントやNetscapeについてのNoteが、
Introducing HTML 3.2や
 http://www.w3.org/pub/WWW/MarkUp/Wilbur/
WebTechs Mozilla DTD Notesに、
 http://www.webtechs.com/html/mozilla.html
あります。
 
 パラグラフそのものの意味は、ここでは得られません。別の問題ですし、われわれ
に馴染みのうすいものです。

 ここは、
 木下是雄  「理科系の作文技術」    (中公新書)
       「レポートの組み立て方」  (ちくまライブラリー)
   ----------------------------------------------------------
   「レポートの組み立て方」に、
   段落という概念は、日本語にあるのにあえてパラグラフというこ
   とばを使うには理由がある。その解説からはじめよう。
     4.5.1 パラグラフとは何か
     4.5.2 パラグラフの構成
      4.5.3 文章の構成要素としてのパラグラフ
      ----------------------------------------------------------
の領域です。
 paragraph を段落と訳するのは混乱のもとになるとおもいます。パラグラフ
としておくべきでパラグラフのことを知るようにすべきです。
 極端にいえば、段落は
(text level element, %textにはいる)だと。 Section 1: WebTechs and other validators * Why should I validate my HTML pages?  何故 Web ページを検証すべきなのでしょか。 computer programmingの格言のひとつに以下のようなものがあります:   " Be conservative in what you produce; be liberal in what you   accept."  * be liberal in what you accept.    ブラウザは正しくない書式のものでも推測して表示しようと努めます。でも、    問題もでてきます。ブラウザによって、推測の仕方がことなり異なった表示を    します。    書式の間違いがひどいと、ブラウザは推測するには絶望的になり不十分な表示    しかできなくなったり、時にはクラッシュすることもあります。 * be conservative in what you produce Web ページが正しい書式であることを確認することです。 それにはあなたのドキュメントを HTML validators に通すことです。 * What other validators are there? WebTechs以外に 以下のものもあります。 http://www.webtechs.com/html-val-svc/WebTechs Weblintや http://www.cre.canon.co.uk/‾neilb/weblint/ HTMLChekや http://uts.cc.utexas.edu/‾churchh/htmlchek.html `Kinder, Gentler Validator' (KGV)が http://ugweb.cs.ualberta.ca/‾gerald/validate/  * Weblint と HTMLChek は、HTML markupの完全な検証でなく、エラーを探すもので   す。属性を忘れたIMGタグといった"bad style"を指摘してくれるなどいい面もあ   りますが、ある種のエラーはチェックできないという面もあります。     * KGVやWebTechsは、DTDやthe rules of SGMLに厳格にしたがい検証します。これで   検証したら、正しいHTMLドキュメントです(you know it's clean)。     * Weblint か HTMLChek のひとつ --->> エラーチェック用    KGV  か WebTechs のひとつ --->> 厳密なチェック用   の組み合わせで検証します。  * The `Kinder, Gentler Validator' (KGV) は、   Wblintも報告してくれ、outlineとして heading タグの系統図も報告してくれ   便利です。

 でも、現状ではいづれの validator も EUC に変換しないと不要なエラーがいっぱ いでます。

#^topへ戻る


文化的基盤:タイプ社会とパラグラフ

 paragraph パラグラフとはなにかと言うことで、DTDの仕様書は論理構造に忠実なやり方をとっていますが、論理構造の上でのパラグラフの意味は国語教育の範疇になります。
 欧米は、タイプ社会でパラグラフ教育が初等教育を通じて確立しています。通信は、タイプ社会のものですし、インターネットwebは文構造の上に成り立っていますが、パラグラフ感覚は大切な要因です。この二つが、日本人には希薄なので、ここを押さえる努力が必要です。

 諏訪邦夫
   「タイピング革命」       (中公新書)
 室謙二
    室謙二[ワープロ]術 キーボード文章読本(昌文社)
 木下是雄
   「理科系の作文技術」      (中公新書)
 木下是雄
   「レポートの組み立て方」    (ちくまライブラリー)
 ------------------------------------------------------------
 「レポートの組み立て方」に、
  段落という概念は、日本語にあるのにあえてパラグラフというこ
  とばを使うには理由がある。その解説からはじめよう。
  ------------------------------------------------------------


#^topへ戻る


<H1>Internetを支える文化</H1>

<P>  インターネットについて様々な本が出ています。それらを縦横に広げて見た感想で す。</P>

<H2>Internetを支える考え</H2>

<P>  古瀬・広瀬著「インターネットが変える世界」(岩波新書)もその一つです。その 第一章は「つなぐことに魅せられた世代」です。ここで、イリイッチの考えやRFCのこ とについての記述があります。技術的なことをのぞくと、インターネットと言う通信 を支える思想がのべられています。見田宗介「現代社会の理論」(岩波新書)や江下 雅之「ネットワーク社会」(丸善ライブラリ)もこのことにふれた本です。</P>

<P>  この延長線上にマルクス・フロイト・ザメンホフをキーパースンとして考えた、な だいなだ・小林司著「20世紀とは何だったのか」(朝日選書)をおいてみると、前 著の思想がよりひろく見えてきます。<BR>
 さらに、この延長上に羽仁 進著「世界歴史物語」(小学館)をおいて見ると、さ らに広い視点がえられます。</P>

<H2>Internetを支える技術</H2>

<P>  逆に、「インターネットが変える世界」をもとに横に技術的なものをみていくと、 古瀬著「インターネット活用法」(講談社ブルーバックス)があります。岩谷 宏 「基礎からわかるインターネット」(ちくま新書)もあります。<BR>
 HTML書式をみていくと、パラグラフや見出しの意味を考えなくてはいけません。そ れには木下是雄著「理科系の作文技術」(中公新書)と「レポートの組み立て方(ち くまライブラリー)があります。<BR>
 また、キボード社会のことも考えます。諏訪邦夫著「タイピング革命」(中公新 書)や室謙二著「室謙二[ワープロ]術 キーボード文章読本」(昌文社)がありま す。</P>

<P>  段落、パラグラフの考え方については、木下是雄の著書に直接ふれて意味を再確認 しておく努力が大切だと思います。そのことが、<P>、<BR>の使い方に直 接つながってくるからです。<BR>
 以下に、木下是雄の著書のパラグラフの項目を上げてみます。</P>

<PRE>
   ----------------------------------------------------------
   「レポートの組み立て方」に、
   段落という概念は、日本語にあるのにあえてパラグラフというこ
   とばを使うには理由がある。その解説からはじめよう。
     4.5.1 パラグラフとは何か
     4.5.2 パラグラフの構成
      4.5.3 文章の構成要素としてのパラグラフ
      ----------------------------------------------------------
</PRE>
<BLOCKQUOTE>
 昔の文章には段落はなかった。欧語の文章にも古い時代にはそうだったらしいが、 たぶん18世紀ごろまでにパラグラフの概念が確立され、パラグラフごとに改行してア タマを1‾3字さげる記法がおこなわれるようになった。日本文の「行変え、1字さげ」 の記法はそれを輸入したものである。
</BLOCKQUOTE>

<P> とあり、また以下のようにも述べてあります。</P>

<BLOCKQUOTE>
 日本式の段落は、いわば一つづきの文章のほうが先にあってそれを便宜的に切った ものーーーという趣があって、パラグラフとは大分ちがうようである。<BR>
 私は、日本語でも、レポート、論文、取扱い説明書などの文章は、パラグラフの概念をしっかり把握して、以下に述べるルールを守って書くべきものと信じる。
</BLOCKQUOTE>

<P>  HTMLもパラグラフの世界です。</P>

<P>  パラグラフを構造化するタグ<P>を改行につかっていても、エラーとして検 証しない場合もあります。<P></P>と</P>を追加してエラーが見 えませんが、空白のパラグラフを作っているからです。validator のみに頼れませ ん。意味を理解して使わないといけないことになります。</P>

<P>  普通の文章では、パラグラフが変わっても空白行は書くわけではありません。HTML 書式では、空白行が加わります。この空白には馴染めないかもしれませんが、パラグ ラフの考えには馴染まないといけません。<BR>
 <P>の表示で、空白行を加えないブラウザもでてくるのでしょうか。と言う より、block level element タグが空白行をおいて表示されることが、普通の文章に 馴染んでいるものには戸惑を感じます。</P>

<P>  レイアウト上で、空白行を作りたいときに、<P>の追加で処理しようとしているのを見るのが欧米で、日本人の多くは<BR>の追加で処理しようとしています。ここでも<P>文化と<BR>文化が見えてきます。</P>

<H2>Internetを支える英語圏文化の同化</H2>

<P>  パラグラフやキーボードは英語圏文化のものです。それが元にあってインターネッ トが進んできています。また、RFCやイリイッチの言う思想もどれだけ日本に定着して いるか分かりません。<BR>
 インターネットや通信社会が、有効に発展するには、思想と技術面からじっくり考 えなくてはならないと思います。</P>

 

<P> 教育現場での役目が、非常に大切になってきています。</P>


 >>> <P> と <BR> を入れるならと表示してみました。<<<

 そこで、<P>はパラグラフタグで、container であると言うDTDの説明
がわかり、正し<P>が使えるようになります。
</P>

#^topへ戻る

[ホームページへ][ulへ][centeringへ][BRとPへ][検証手順]戻る
[HTML: block structure]へ戻る


JIS版:http://www.asahi-net.or.jp/‾bd9y-ktu/gai_j.html

加藤泰孝
bd9y-ktu@asahi-net.or.jp
Last modified 99.1.2