ビレッジセンターHTML&SGML研究チーム著『正しいHTML4.0作法&リファレンス』（ビレッジセンター出版局、ISBN4-89436-111-6）を勢いで買ってしまいましたが、変な本でした。「はじめに」で
本書が先行する他の解説書と差別化するところは、
仕様書に照らし合わせて、いかに正確であるか!
の1点だ。もちろん、本当に正確な仕様を知りたければ原文の仕様書を読むべきである。本として分かりやすくするというフィルターを通している以上、それはそのまま、表現をあいまいにしてしまうフィルターでもありえる。我々の理解力と表現力（と信念）に起因するところの曲解もありえるかもしれないが、それが解説書の宿命だから仕方ない。
と記されているところの「フィルター」の効きが良すぎるように見えるのです。
丁度わたし自身、HTML4.0仕様書邦訳計画の改訂作業の傍ら用語について色々記しておこうと思っていたところなので、同書序章の「1 用語について」と対比させつつ、用語や訳語に関するあれこれを書き記すことにしようと思います。
わたしの記述に変なところがある場合は、uchida@happy.email.ne.jp宛てにお教え下さると嬉しいです。
それぞれ、Hypertext Markup Language と Standard Generalized Markup Language の略。SGMLとはマークアップ言語のためのシステムを指し、HTMLはその1形態である。マークアップ言語とはテキスト内にタグを埋め込むことで論理構造を作る言語で、HTMLはハイパーテキストを目的としたマークアップ言語だ。
書き換え
SGMLというのは、あるマークづけのルールを作るための標準書式で、ISOやJISなどの工業規格になっています。SGMLで書かれた個々のマークづけルールはSGMLアプリケーションと呼ばれ、HTML2.0、2.x、3.2、4.0はSGMLアプリケーションであるところの「マークアップ言語」です。同じ「マークアップ言語」と呼ばれるものであっても、SGMLやXMLは「ルールを書くためのルール」で、HTMLは「SGMLで書かれた特定のマークづけルール」だという違いがあります。
マークづけ、つまり「目印」をつける目的や目印の種類は様々ですが、プレーンテキストである原文に、他人が見ても意味が分かるような目印をプレーンテキストでつけていき、文章全体を1つの階層構造体として表すという点が、SGMLアプリケーションに共通します。
HTMLは、開発者の言をちょっと意訳すると、「特定のソフトウエアやハードウエアに縛られずにハイパーテキスト化した電子文書をみんなで利用できるようになると便利だし、そんなハイパーテキストを簡単に読み書きできたらうれしいよね」という主旨で考え出されたマークづけルールです。
世間がタグと呼んでいるものの正しい一般名詞はエレメントである。HTML仕様書にも誤用されていることに対する注釈がついているので、誤用は日本だけの事情ではないようだ。以下の使用例でエレメントとタグの違いを理解して欲しい。
- Pエレメントの終了タグ</P>は省略できる
- タグ<P>は改行を表すものではなく、段落エレメントの開始タグである
- 行変えは<br>というタグで表される。
感想
文脈に依存することを一般化して「正しい」とか「間違っている」とか断定してしまうのは危険じゃないかなぁ。という話はさておき。
HTML4.0仕様書 3.2.1 末尾の注意書きは、「タグはタグだしエレメントはエレメントだ」ということを言いたいのではないでしょうか。
それからそれから、element を「要素」ではなく「エレメント」と表記し、後で出てくる content を「内容」や「コンテント」ではなく「要素」と表記する合理的理由がわたしには分かりません。先行するほかの解説書と差別化したい気持ちは分かりますが、HTML&SGML研究チームであれば、まず日本工業規格 JIS X 4151-1992を、ある程度尊重しませんか?
もひとつオマケに、「段落エレメント」って何? P elementのこと?
書き換えないけど
RFC1866の2.TermsによるElementの定義を、次のように訳してみちゃぁマズいでしょうか。いえ、JISの訳語が「要素」だってのは承知の上で。
'<' を '<' に、'C34;' などを対応する文字に展開する仕組み。
明確には '<' は「文字実体参照（Character entity references）」で 'C34;' は「数文字参照（Numeric character references）」、両方合わせて「文字参照」。DTDの中で使われているのは「引数実体参照（Parameter entity references）」となる。総称すると「実体参照」である。
書き換え
実体参照や文字参照には3つの役割があります。1つは、マークアップしようとする文章中にマークアップで利用する記号などが現れる際、それをマークアップ記号ではなく単なる文字として扱わせるために行う表現。2つ目は、直接入力するのが困難であるような文字・記号を一種のコード入力として表現すること。3つ目は、繰り返し現れるコトバを一種の単語登録によって表すこと。
HTMLのルールでは、HTML文書の書き手が銘々勝手な実体参照や文字参照を定義することが禁じられており、上の3番目の役割については DTD を読むときにしか縁がありませんし、1番目と2番目の目的に使えるものにも数の制限があります。
HTMLのマークアップで書き手が利用できる実体参照・文字参照の一覧は、仕様書に掲載されています。
例えばアンパサンド記号（ampersand: &）は、正にこの文字参照の開始部分を表すために使う記号なので上の1番目の目的で書き換える必要があり、仕様書に文字参照での表現方法が掲載されています。アンパサンド記号を「&」のように記すものを「文字実体参照」、「&」のように記すものを「数値文字参照」と呼びます。
あ、それから、
一般的にSGML関係では数値文字参照を十進法で表し、HTML3.2までのHTMLでも十進法表記のみでした。これは現在のSGML仕様から来る制約で、HTML4.0ではSGML仕様の改定案を先取りして十六進法でも表せるようにした、とHTML4.0仕様書 5.3.1では説明されています。
SGMLの一般的な構文と違うことをやろうとする場合、SGML Declarationの方を、うっかり十進法しか利用できない形態のまま放置してしまっていたりするようなことがあるので注意が必要らしいです。
要素とは原語で Content と呼んでいるもので、開始タグと終了タグの間にはさむことのできるものを指す。
要素を入れる器 ---- すなわち終了タグを持つエレメント ---- はコンテナ（Container）となる。コンテナに対してコンテントはカタカナ語として一般的でないと判断して要素と呼ぶことにしたが、どうもバランスが悪い。
感想
上にも書きましたが、element を「要素」ではなく「エレメント」と表記し、ここで content を「内容」や「コンテント」ではなく「要素」と表記する合理的理由がわたしには分かりません。
THIS element の content model は THAT だ、という事柄を「THISエレメントの要素モデルはTHATだ」と表記するよりは「THIS要素の内容モデルはTHATだ」と表記する方が一般的だと思うのだけれど。
どうしても「コンテナ」っていう "WDG風" の言い回しを使いたかっただけ、としか見えないなぁ。仕様書にしか依拠しないんじゃなかったの?
RFC1866には「MM element contains NN」っていう表現は頻出してても「container」っていう表現は無いみたいですし。
「コンテナ」を忘れて「器」で考えれば、普通「器」に contain されるものは「中身」とかって言いませんか?
書き換えませんけど
もし上に書いたようにElementを「元素」と呼ぶことにするなら、「この元素の構成要素は、容器としての開始タグ・終了タグ、そしてその中身だ」「容器部分、しかも開始タグしか存在しちゃいけないような、Empty Elementと呼ばれる元素も存在する」とか言ってみたいもんです。
ただし、上に書いた定義文の方にある「構造単位」という語を Element の訳語にする方が、例えば小河原誠『読み書きの技法』（ちくま新書059、ISBN4-480-05659-9）における「構造明示子」という用語などへの親和性もありますから、自分なら「構造単位」を選びたいと思いますが。
属性と訳している本もあるが、言語の Attributes をそのまま使うことにした。十分認知されたカタカナだろう。
アトリビュートの取りうる値（Value）がアトリビュート値である。
感想
これも、どんな集団が認知しているのでしょう。ひょっとして、どこかの会社のSGML研究会? そういう集団なら attribute と表記しちゃえばいいのに。
他の本が属性と訳しているのは、SGMLの日本工業規格を尊重しているからだと思いますよ。まぁ中にはネタ本を書き写してるだけの本もあるでしょうけど。
書き換えませんが
HTML化されている日本工業規格 JIS X 4151-1992『文書記述言語SGML(Standard Generalized Markup Language)』の3.用語についてを、まず読んでから、Element、Attribute、Contentについて独自訳にするかどうかを判断しましょう。
個人的には、Elementを構造単位、Attributeを付帯情報（nameは付帯項目名、valueは付帯項目値）、Contentを包含内容と訳してみたいと思っていて、JIS X4151-1992よりも良い訳語だと妄想しているのですが、HTML4.0 Specificationの邦訳に使うのはやめておきます。
本書でワープロと呼んでいるものは、HTMLの編集作成機能を持ったソフトのうち、HTMLのタグを画面に表示せず、HTMLの知識がなくても、ふつうに文章を入力したりデザインすることでHTML文書が作成できるものを指す。
このようなワープロもHTMLエディターの一つだが、HTMLは字を書くことができればどんなソフトでも作ることができる。Windows標準のメモ帳（Notepad）でさえ作れる。このメモ帳に代表される字を書くことだけを主目的としたエディタを指すとき、意味を明確にするため「素（す）のエディタ」と本書では呼んでいる。
感想
上の意味の「ワープロ」のことをHTML4.0仕様書では「オーサリングツール」と呼んでいます。その種のソフトウエアの雑誌記事なんかでも「オーサリングツール」と書かれているんじゃないでしょうか。
また、上で「素（す）のエディタ」という呼び名を使うようなケースで、それを「テキストエディタ」と呼ぶ方が普通でしょう。
なお、蛇足ですが、人力で直接文字を入力するのではないソフトウエアでも、テキストファイルを生成できるものであればHTML文書を作り出せますね。
こういう項目は書き換えずに削除したい。
HTML言語を用いて作成した拡張子.html（または.htm）の文書ファイルをHTML文書、そして、HTML文書をブラウザやワープロではなく、メモ帳のような素のエディタで表示させたときの状態をソースと呼ぶ。
書き換え
HTMLのDTDに準拠してマークアップが施されているテキストデータを（HTMLの）ソースと呼び、ソースを保存したファイルをHTML文書とかHTML文書ファイルなどと呼びます。WWWブラウザの「ソースを見る」等のメニューは、マークアップに基づいて出力用の加工を終えた最終表示形態の文章ではなく、加工前の元々のテキストデータを表示する、という役割を果たします。
保存された静的な状態にあるHTML文書以外にも、プログラムによって動的に生成されるソースもあります。
人力で作成したソースはファイル名の末尾に拡張子「html」や「htm」をつけて保存するのが普通ですが、プログラム的に生成されたソースの場合は他の様々な拡張子がついていたり、拡張子自体がついていなかったりします。
HTMLでハイパーリンクによってリンクする先は、HTML文書とは限らない。リンク先はJPEG画像だったり ftp サイトだったりとさまざまだ。HTMLの仕様書では、リンクされる先にあるものをリソースと呼んでいる。
感想
リンクされたものじゃなくてもリソースはリソースですね。
書き換えられるものなら
すみけんたろうさんの、「Resources!!」なんかはどうでしょう。
HTML仕様書とはW3C（World Wide Web Consoetium）が公開しているHTML Specificationのこと。W3Cのサイトから誰でもダウンロードできる。プレーンテキスト形式やHTML文書形式のものが用意されている。
DTDとは、HTML文書型式のHTML仕様書の中に含まれているHTML言語仕様の定義ファイルで、Document Type Difinition の略。
感想
IETFが公開している仕様RFC1866によるHTML2.0とRFC2070によるHTML2.xはまだ生きているし、ISOもHTML仕様の規格化を試みていて、早ければ今年中には正式な規格になるらしい。です。
HTML3.2や4.0の仕様がまとまるまで間があった時期に、Microsoft社がIE30DTDを公開していたりしましたしね。
書き換え
HTMLのマークづけルールであるDTDには、世界に公開されている現役のものとしては、IETFによる「HTML」「HTML i18n」、W3Cによる「HTML3.2」「HTML4.0 Strict」「HTML4.0 Transitional」「HTML4.0 Frameset」の6つがあります。もちろんSGML宣言もあります。
HTML4.0の3つのDTDは、各々
として公開されていますよ、とDTDそのものにも書いてあります。
DTDやSGML宣言を含み、かつその設計意図を普通の英語で説明した文章を追加した文書が「仕様書」として書かれていて、IETFのは各々「RFC1866」「RFC2070」として文書化されており、W3CのHTML3.2は「HTML 3.2 Reference Specification」、HTML4.0は各DTDをひっくるめて「HTML 4.0 Specification」として文書化されています。
RFCとは、インターネットの技術的な企画を提案した文書群で、Request for Comments の略。ISOは International Organization for Standardization の略で国際標準化規格を定めた文書群である。
HTML仕様の真実を知るには、HTML仕様書以外にこれらの文書群もすべて（仕様書で引用されているものは）ひも解かなければならない。
感想
「真実」を知るには例えば"HTML1.0"に関するインターネットドラフト文書なんかも知る必要があるかも。T.B.L.氏にインタビューする必要とか。
例えば「何でPはこうなのか」は、T.B.L.氏に尋ねないと真相が不明。たぶん。
ちなみに、RFC1866を本当にひも解いたなら、こんなめちゃくちゃな用語集にはならなかったでしょうし、Universal Resourece Identifier じゃなくて Uniform Resource Identifier であるところの URI について説明して下さるなら、Uniform Resource Identifier に関するインターネットドラフト文書もお読みになったのでしょうね。
URL（Uniform Resource Locators）はインターネット上のリソース（文書などの資源）の統一的な表記法である。一般にプロトコル名（例: http://）とフルドメイン表記（例: www.somewhere.com/document）で構成される。
URIs（Uniform Resource Identifiers）は URL を含む表記の一般名であり、URLの他に URNs（Uniform Resource Names）、URCs（Uniform Resource Characteristics）、及びインターネット技術特別調査委員会（Internet Engineering Task Fource）の URI部会（URI working group）が定めるあらゆるものを含んでいる。
HTML4.0の最終草案までは URL と表記されていたものが、正式公布ではすべて URIs と書き換えられていた。リンク先にあるものは「何でもあり」ということを明言し直したのだろう。
感想
HTML4.0仕様書原典を読んだ限り、複数形で表す必要がある文脈では「URLs」であったり「URIs」であったりし、単数形の状況では「URL」や「URI」と記されています、ね。
ちなみに、HTML4.0仕様書で勉強を始めたわたしには、RFC1866でURIとURLがちゃんときっちり区別されているなんて事はRFC1866を読むまで解りませんでしたよ。HTML3.2ではURL一本みたい、なんてことも。
書き換えないけど
邦文中では特別な必要がない限り常に単数形で書くんじゃないかなぁ。と、昔私は言われました。その通りだと思いました。
HTMLやSGMLを解釈して表現するソフトウエアという意味の正式な用語はユーザエージェントである。
ブラウザと言った場合、画像や動画、そしてJAVAアプレット、Netニュース、e-mailなど、ありとあらゆるリソースをブラウズ（閲覧）する機能がついている。ことさらにHTMLブラウザと断るときは、ブラウザからNetニュースやe-mailの機能を除いた部分を言う。
書き直し
HTMLやSGMLを解釈（parse）するソフトウエアの名称はパーザ（parser）です。ユーザエージェントとは、ユーザの利用目的に従ってサーバとの折衝などの仕事をするソフトウエアのことです。
HTML4.0の仕様書では「ユーザエージェント」と「ブラウザ」の語が使い分けられていますが、「ユーザエージェント」を「ブラウザ」に言い換えて構わない局面と、言い替えが効かない局面があります。例えば「サーチロボット」も「HTMLユーザエージェント」ですが、「ブラウザ」ではありません。
感想
ブラウザには、上で「ブラウザ」と呼んでいるような統合ソフトウエアたろうとするものもあるかもしれませんが、それは少数派なのではないかと思います。
どのくらい色々なブラウザがあるかは、Browser Museum Browseなどを訪ねてみましょう。
また、WebブラウザあるいはWWWブラウザという語はあってもHTMLブラウザという語は普通使わないはずで、またWWWブラウザ = HTMLユーザエージェントというわけでもありませんね。
本書では、HTML文書を表現するソフトウエアのことをHTMLブラウザと呼んだりユーザエージェントと呼んだり用語が統一されていないが、許して欲しい。
SGML（HTMLはその一つ）を解析するソフトの正式な普通名詞はこのユーザエージェントだ。本書でユーザエージェントと呼ぶときは、文法の説明であったり、SGMLの仕様を正しく表現することを目的とした、まだ見ぬ理想のソフトを指していると思って欲しい。
感想
ユーザエージェントが何であるかというのは上に書いた通りだと思うし、HTML4.0仕様書における「ユーザエージェント」と「ブラウザ」の使い分けにはかなりの気配りを感じるんだけど、この人たち、それを台無しにしたいのかしら。
HTMLは「SGMLアプリケーション」の1つで、SGMLやHTMLを解析するソフトウエアはパーザですよね。
SGMLの仕様を正しく表現するのはSGMLの仕様書じゃないかなぁ?
もし上で想定しているものが「現在のWWWブラウザと違ってソースを厳密に解析した上で表示を行うソフトウエア」というようなものであるなら、素直に「理想のブラウザ」等と呼んではいけないのでしょうか。
ところで、VoyagerのT-Timeのようなものは、「HTMLリーダ/ビュア」などと呼ぶべきでしょうか。「ブラウザ」でしょうか。
書き直し（但し「ブラウザ」等を含む）
HTML文書ファイルだけとは限らない様々なリソースへ、HTTPとは限らないプロトコルでアクセスし、画面表示したりダウンロードしたりするようなモノをWebブラウザと呼びます。
様々な目的を持って読み手（ユーザ）がHTML文書を利用するためのソフトウエアをHTMLユーザエージェントと呼びます。WebブラウザはHTMLユーザエージェントの一形態、でもあります。HTMLユーザエージェントには、ブラウザの他、サーチロボットなどが含まれます。
また、ニュースサーバとの折衝が主任務であるユーザエージェントの「ニュースリーダ」や、メールサーバとの折衝が主任務であるユーザエージェントの「メーラ」なんだけど、HTMLメールやHTMLニュースを扱えちゃう、というモノは「HTMLユーザエージェント」でもある、かもしれませんね。
HTMLのマークづけをDTDに照らして解析するソフトウエアをパーザ、HTMLのマークづけがDTDに照らして正しいかどうかを検証するためのソフトウエアをチェッカと呼びます。
MicrosoftのHTMLブラウザを含む統合ソフトウエア Internet Explorer、及び Netscape社のHTMLブラウザを含む統合ソフトウエア Netscape Communicator や Navigator をこのように略記させていただく。
Netscape社の最新ブラウザを Communicator、旧バージョンを Navigator と呼んで区別するむきもあるが、Communicator のブラウザ部分は現在も Navigator と命名されているようなので、支障はないだろう。
感想
Microsoft社には「社」がつかず、Netscape Communications社には「社」はつくけど「Communications」はつかないのね。
というのはさておき、Netscape Communications社の「統合ソフトウエア」の呼び名が Communicator で、「ブラウザ」の呼び名が Navigator でしょう。まぁ上のブラウザの定義が定義だけに変な表現になってしまったようですが。また、Microsoft社の製品の場合、ブラウザは Internet Explorerで、メーらやニュースリーダは Outlook Expressなど別個のものとして扱われていませんか?
書き換えませんが
何となく、個人的には上の前者を「MSIE」、後者を「Mozilla」と呼びたいような気がします。サーバとお話する際に、きゃつらは何と名乗っているのでしょうか。まぁ後者が「ネスケ」じゃないことは確かでしょうけど。
ほとんどの人が勘違いしているが、HTMLは画面上の見栄えを決定しない。あくまで書くときの論理的意味を定義するもので、その見栄えは個々のブラウザ（ユーザエージェント）に任されている。
HTML文書の画面上の見栄えを定義するものがスタイルシートである。HTML同様W3Cが仕様を公示しており、CSS1は Cascading Style Sheet, level 1 の略だ。すでにCSS2の Working Draft（仕様草案）も存在するが、IEもNavigatorも現在（98年2月）のところCSS1にすら満足に対応できていない。
スタイルシートを使ってHTML文書を作るのは時期尚早である、と考える人たちは多い。だが、スタイルシートに対応したブラウザでも、対応していないブラウザでも、何を使って閲覧しても不都合のないHTML文書を作ることが重要なことであり、それは今後いくら時間を待っても変わることはない。IEやNavigatorだけがユーザエージェントではないからだ。
感想
HTML4.0の Strict DTD においてすら、<B>や<I>、<TT>などの、「見栄えを決定するためのマークアップを行うためのもの」は存在します。『正しいHTML4.0作法&リファレンス』p.69にも、その旨が記してありますよね。
「強調が目的だったら<B>より<strong>でマークアップした方がいいよ」という話と、HTMLに見栄えコントロール要素があるかないかという話と、書き手が見栄えのコントロールを意図した通りに読み手側で表示されるかどうかという話は、各々別物でしょう。それが分かっているからこそのp.69なのではないのですか?
書き換えませんが
CSS2の Working Draftまで見ていたなら、スタイルシートは「画面上の見栄え」を指定するだけではないということに気づいていて良かったはず。
インターネット上には、守らなければならないルールが数多く存在し、それらはネチケット（Net-Etiquetteの略）と呼ばれる。HTML文書の書き方についても同様だ。しかし、RFC文書群にその裏付けを発見することができないものも少なくはない。
そんな、昔から言われてはいるが根拠が曖昧なことをくどくどと言う人たちは、ある種の宗教信者に喩えられている。ことあるごとに相手が納得するまで説法するからだ。宗派といっても団体が実在するわけではなく、同じルールに固執する人たちを指している。
感想
HTML原理主義という宗教の本、という見方もあるよなぁ、この本。教義を正しく受け継ぎ損ねて粗雑になってる気がするけど。
それはそれとして、RFCに根拠が記してないのもでも、RFCにする必要がないほどの常識を根拠に意見を述べるのもいかんのかなぁ。
書き換えないけど
RFC1866は、HTML4.0の勉強にも非常に役立つ優れた文書なので、HTML4.0のリファレンスを書こうなんて思う場合には必ず熟読するようにしよう。