目次
1 今，なぜXMLなのか？−DTPからの問題提起− ▼ 2 SGMLの仕組み−XMLとどこが違うのか？− ▼ 3 文書型定義の書き方−なぜ文書型定義が要るのか？− ▼ 4 SGML宣言とXML宣言−文書を相互運用するために− ▼ 5 XML文書をHTML文書へ変換−XML文書をウェブで閲覧する− ▼ 6 XSL変換−XML文書を様々な表現形式へ変換する− ▼ 7 XSLによるフォーマット−XML文書を組版する− ▼ 8 要約 ▼
目次
1 今，なぜXMLなのか？−DTPからの問題提起− ▼ 2 SGMLの仕組み−XMLとどこが違うのか？− ▼ 3 文書型定義の書き方−なぜ文書型定義が要るのか？− ▼ 4 SGML宣言とXML宣言−文書を相互運用するために− ▼ 5 XML文書をHTML文書へ変換−XML文書をウェブで閲覧する− ▼ 6 XSL変換−XML文書を様々な表現形式へ変換する− ▼ 7 XSLによるフォーマット−XML文書を組版する− ▼ 8 要約 ▼
XML（拡張可能なマーク言語）についての説明は，最近ではいろいろな雑誌に取り上げられていますが，その具体的な応用であるネットワークでの話が中心になっており，印刷から見た話は少ないようです。私（岸 和孝）は，印刷の立場からXMLを考えたほうが，より本質的な意味を理解できると思っています。今回は，読者の皆さんの身近な仕事であるDTPからお話を始めましょう。
私は，年度末になると，あるコンピュータ業界団体の委員会が作成した活動報告書の編集と組版を行う仕事をしています。私が関わる「印刷」の仕事はその程度のことです。普段は，SGMLやXMLなどの文書記述言語を研究したり，さらにPerlやPythonなどのテキスト処理言語を研究しています。そして，それに関連したセミナーの講師を担当したり，関連記事を書いています。そこで，執筆者と編集者という二つの立場を私なりに総合してXMLを説明したいと思います。
さて，作業の対象となる原稿データは委員会の各委員から電子メールで入ってきます。現在，原稿の大半はWindowsのWordで作られた文書です。私のプラットフォーム（作業環境）はMacintoshのPageMakerですが，なぜかPageMakerではWord文書の入力プラグインがうまく働かないので，いろいろな変換を行ってから編集を行っています。つまり，入稿したWord文書をそのまま使うことはなく，プレーンテキストに一旦変換してしまいます。それから，その行末符号を変換してMacintoshのエディターで扱えるようにします。ところが，変換に当っては厄介な問題が生じています。それらは皆さんもご存知のことかもしれませんが，私の場合は次のとおりです。
先ず，大半のWord原稿の文章にはかなりの数の外字が含まれています。フォントによっては直接再現できるものもあれば，対応する符号へ変えなければならない場合もあります。私は，Perlで組んだツールを使って，外字を検出し確認していますが，結局のところ，一つ一つの外字に気を配ってそれらが再現できるようにPageMakerを操作しています。外字は文字通り「標準以外の文字」ですから何がやってくるか分かりません。ユニコードになれば一挙に解決するという見方もありますが，これは何とかしなければならない問題です。
また，Word固有の問題ではありませんが，外字問題の一つに単位記号の表記があります。例えば，平方メートルという単位記号を“m2”という一つの文字として表すか，英小文字の“m”と上付きスタイルを与えた数字“2”の二つの文字で表すかの選択です。さまざまな単位記号を表す文字がすべてあるわけではありません。果たして，既存の文字をスタイルを使って組み合わせるか，外字で表現しています。
次に，Word原稿の図（正確には，ベクトルで表現された幾何学図形）はWord固有の表現様式ですので，Macintoshの他の大半のアプリケーションのようにカット・アンド・ペーストできるものではありません。そこで内部的な変換を引き起こす発行・引用を指定する必要があります。しかし，MacDrawなどでは引用した図形が元の位置からずれたり，レイヤーが崩れたりするなど，うまく再現できないことがあります。もっと具合の悪いことは，省略時に選択されるフォントがWindowsとMacintoshでは違いますので，文章と図のフォントを一致させるかどうかが問題になってきます。私の知らない便利な変換のユーティリティやプラグインがあるかもしれませんし，バージョンの違いもあるかもしれませんが，これも何とかしなければならない問題です。
ところで，なぜ多くの人はWordで原稿を書くのでしょうか。確かに，WindowsとWordは普及しています。しかし，それは現象の説明であって肝心な答えではありません。執筆者たちがエディターではなくて，ワープロを使う理由は何なのでしょうか。実際，いわゆる棒打ちの文章で原稿を出してくる人はいません。多くの人は，スタイルが指定できるワープロのほうが便利だと思って使っています。つまり，ワープロでは，章節の見出しや段落，箇条書などにスタイルを与えて，文書を構成する要素の関連（これを文書構造と言います）を視覚的に明らかにできるからです。当り前のことのようですが，それが答えなのです。
Word文書にスタイルを与えても，プレーンテキストにしてしまったら，それらは消えてしまいますので，スタイルをPageMakerに引き渡す必要があります。Word文書からスタイル情報を抽出することは可能です。Word文書がrtf形式で保存されたものであれば，Perlで組んだツールを使って，スタイル情報を検出し抽出できますが，実際にはそうしていません。それはスタイルを積極的に正しく使っている人が皆無だからです。どれだけの人がWordの使い方を正しく知っているのでしょうか。Wordを導入している企業や官公庁でWordの執筆要領を訓練しているという話を聞いたことはありません。ともかく，スタイルを利用したくてもできない状況ですので，結局のところ，プレーンテキストを使って別の手法でスタイルを与えることにしています。この手法についての話は長くなりますので，別の機会にお話しましょう。
このように，WindowsとMacintoshという二つのプラットフォームの間には，外字，図，スタイルに関わる問題が横たわっています。おそらく，こうした問題の大半は，皆さんは雑誌などに掲載されたチップスなどに頼って解決しているのだろうと思いますが，それでは真の解決にはなりません。そもそも，こうした問題は，プラットフォームが違うと，文書データの表現様式も違うために引き起こされています。文書データの表現様式が個々のプラットフォームで違っていても，それらの間で交換する場合に標準的な「交換様式」がなければならないはずです。
「WindowsやWordは事実上の標準だからそれに合わせればいいのだ」「Windows DTPを導入すればいいのだ」という乱暴な意見も聞かれます。本当にそうでしょうか。極端な話ですが，現在作られたWord文書データが百年後にも読めるのでしょうか。その時にマイクロソフト社が存在し，WindowsやWordの後継を販売しているという保証を誰もできないと思います。これはアップルコンピュータ社やサンマイクロシステムズ社の場合にも言えることです。大きな技術革新が起きた時の変換は別として，私たちは文書資産の将来のために「真の標準」を作り上げ，それを育て守っていかなければならない責任があるのではないでしょうか。
実際，異なるプラットフォームにおける外字，図，スタイルといった問題の大半は，標準的な文書交換様式を介して交換すれば簡単に解決できます。ODA（開放型文書体系）とSGML（標準汎用マーク言語）という国際規格・JIS規格がそれに相当します。しかし，残念なことにわが国で使えるODA準拠のアプリケーションは皆無です。またSGMLについては，ワープロでは「一太郎」にSGMLエクステンションがあり，DTPソフトでは「FrameMaker+SGML」がありますが，余り普及していないようです。ちなみに，肝心な「Word」はSGMLをまだサポートしていないようです。しかし，米国ではWordのrtf形式からSGMLへ変換するユーティリティが以前から使われています。わが国でそのような使い方がされていないのは，rtf形式がバージョンアップごとに変更が生じる不安定な規格のせいばかりではなく，やはりユーザの使い方が違うせいだと思われます。
さて本題へ進むことにしましょう。現在，標準的な文書交換様式としてSGMLに引き続いてXMLが登場してきました。XMLはSGMLから派生した標準規格です。ですから，XMLを知るには，SGMLについて学ぶ必要があります。ビギナー向けの雑誌に「XMLはHTML（ハイパーテキストマーク言語）を拡張したものだ」と書いた記事を見かけることがありますが，そうした説明は間違っています。正確には「XMLはSGMLを制限したもの」です。では，何のために何を制限したのでしょうか。それを知る上からも，SGMLを初めに学ぶ必要があるのです。
SGMLは，文書の要素や構造を出力機器に依存しない形で表現する仕組みを持ったコンピュータ言語です。PostScriptがページ上の画像の要素や配置を出力機器に依存しない形で表現する仕組みにしたのと同じ考え方から生まれました。前者を文書記述言語，後者をページ記述言語と呼びます。
1969年の頃にIBM社のゴールドファーブ氏は，SGMLの元となったGMLを考案しました。彼は多国籍企業であるIBM社のコンピュータマニュアルを各国で出版する際に，各国の異なる電算写植機へ対応させる方法を研究していました。そのGMLがSGMLとして国際標準化機構（ISO）の規格となったのが1986年でした。この間には17年余りの，コンピュータ界としては稀な長い年月が流れましたが，電子文書の流通がまだ限られていた時代であったためと思われます。
その1980年代には，コンピュータネットワークは開放型システム間相互接続（OSI）で構築し，そこでやりとりされる電子文書は開放型文書体系（ODA）で交換するという国際的な合意の下に開発が進んでいました。ところが，1991年にインターネットが商用化されて，OSIと同じことが実現してしまいました。さらに1993年にウェブが開始され，それがHTMLで表現されました。それはODAに比べると，表現力に乏しいものではありましたが，ネット情報のコンテナとしての役割は同じでありました。そのために，ODAはSGMLと公表がほぼ同じ時期であったにもかかわらず，ヨーロッパ連合（EU）の実現に当っての情報基盤に止まって世界的には普及しませんでした。
1994年にはインターネットを利用した電子商取引が開始されました。それを確実なものにするために，HTMLの表現力を強化することが図られました。ダイナミックHTMLなどの試行錯誤を経て，1996年には表示機能を補助するCSS（段階スタイルシート）が開発され，さらに1997年にはSGMLのリアルタイム処理を実現可能にしたXMLが開発されました。これらの規格の開発は，SGMLやODAを開発してきたISOではなく，有力なメーカーやベンダーの主導の下にワールドワイドウェブコンソーシアム（W3C）で進められました。
|
▲図1-1 SGMLからXMLへ
ここでは，SGMLの仕組みについてお話しします。今後，XMLが普及してくると，「XMLはSGMLやHTMLと比べてどこが違うのか？」とクライアントに尋ねられることが多くなると思います。なるほど「XMLはSGMLから派生したものである」とか「XMLはSGMLの仕様を一部制限したものである」と答えてもいいのですが，では「SGMLとは何か？」と尋ねられた困るでしょう。そこで，まずSGMLの仕組みからお話しするわけです。
SGMLでは，HTMLと同じように，文章にタグを付けるということはよく知られています。では，なぜ文章にタグを付けるのでしょうか。タグとは，何かを表わす「しるし」のことです。その「何か」とは，文章を構成する見出し，段落，文，語句といった要素のことです。私たちが読む文章には通常「しるし」は付いていないように見えます。しかし，大半の文章にはスタイルという「しるし」が施されているのです。
例えば，見出しは見出しらしく，中央揃えとかゴシック体にしてあるとか，本文よりも少し大きめのフォントサイズにしてあります。段落は，字下げが施されてあるとか，見出しに比べて少し小さめのフォントサイズにしてあります。専門用語は括弧でくくられていたりゴシック体にしてあります。そのように，スタイルがうまく施された文章は読みやすいものです。このことは，DTPでは当り前のことですが，実は深い意味があるのです。
つまり，私たちは，そうした見かけによっても文章の内容を読み取ろうとします。この認識作用は，長い間の経験によって無意識のうちに行われています。次に，文章の内容は読み進むうちに文脈から分かるようになります。学校で国語を勉強してきたおかげで，私たちは内容から意味を理解することができます。さて，こうした文脈から内容を読み取る働きは，私たち人間だからできることであって，コンピュータにさせることは殆ど不可能です。文章にタグという「しるし」を付けることは，人間を助けるためというよりも，出来の悪いコンピュータを助けるためのことなのです。「コンピュータ支援」という用語がありますが，タグ付けはその逆の概念と言えるでしょう。
もしスタイルが文章のすべての要素を区別できるようになっていれば，スタイルを「しるし」として使えますが，実際には，スタイルを「しるし」として使うことはありません。その理由は，あるスタイルが意味することをコンピュータに伝える「しかけ」を考えると，ずいぶん面倒な話になってくるからです。タグもスタイルもない，いわゆる棒打ちの文章をコンピュータで解読できるようになれば，タグ付けという作業から私たちは解放されますが，それは遠い将来のことになると思います。
もう一つ大事な話があります。それは文書の「かたち」のことです。例えば，文書と一口に言っても，さまざまな種類があります。報告書，論文，伝票などの文書は，それぞれ特有の「かたち」を持っています。法定書式のような特有の「かたち」をした文書のことを「定型文書」と呼んでいます。定型文書には日付の欄とか氏名の欄といった，内容を記入する際の目印が付いています。そうした「しるし」の種類は文書の「かたち」によって変わってきます。言い換えれば，特定の「しるし」の集まりが文書の「かたち」を決めています。一方，手紙や小説のような文書を「非定型文書」と呼んでいますが，よく分析すれば，そこに「かたち」を見い出すことができます。
つまり，文書をコンピュータで処理する際には，次の三つのものが必要になります。
ここで，「しるし」のことを「タグ」，文書の「かたち」のことを「文書型」，そして「しかけ」のことを「コンピュータ言語」とそれぞれ呼ぶことにしましょう。つまり，SGML（標準汎用マーク言語）とXML（拡張可能なマーク言語）の“ML”は「タグと文書型をマーク（Markup）の形で表わすコンピュータ言語（Language）」を意味します。ちなみに，マークアップは動詞でもありますが，ここでは名詞として訳します。
次に，文章に付けるタグをどのように表わすかの話に移ります。“<TITLE>”とか“<H1>”のようなタグの形は，絶対的な表現ではありません。タグは文章の内容と違う表現であれば何でもいいのです。例えば，大半の電算写植システムのタグは特定のファンクションコードを使って表わしています。また，組版ソフトのTeXや，マイクロソフト社のWordにおけるタグは“\TITLE ”や“\H1 ”のように表わしています。要は，コンピュータで文書データを処理する時にタグと内容とが簡単に区別できればいいわけです。もっとも，最近の組版ソフトでは“<TITLE>”とか“<H1>”のような表現が一般的になってきているようです。
タグは，内容の前後に付けます。前に付けるタグを「開始タグ」，後ろに付けるタグを「終了タグ」，タグの種類を表わす名前を「要素名」とそれぞれ呼んでいます。
次の例では，要素名が“TERM”（用語）で，その内容が“インターネット”と“データベース”です。開始タグは“<”，終了タグは“</”で始まり，“>”で終わります。
この文章は<TERM>ドキュメント</TERM><TERM>データベース</TERM>について説明しています。
開始タグと同じ形をしていますが，内容を持たずに意味だけを持つタグがあります。それを「空要素タグ」と呼んでいます。次の例では，CONNECT（接続）タグがそれに相当します。これによって位置に関わる意味を与えることができます。
この文章は<TERM>ドキュメント</TERM><CONNECT><TERM>データベース</TERM>について説明しています。
この表現はSGMLの場合であって，XMLでは“<CONNECT/>”のように書きます。その理由は，“<CONNECT>”だけ見ても開始タグなのか空要素タグなのか分からないからです。
このように，タグは内容がどのような要素であるかを示すものです。したがって，要素名は要素を連想させるような名前にすべきです。しかし，その要素が名前通りの内容を持つかどうかは，SGMLやXMLとは別の話になります。ここで例にしている要素名は適当に命名したものに過ぎません。
さて，要素には，内容に関わる「属性」を与えることもできます。次の例では，ADDR（住所）タグがPOSTNO（郵便番号）属性を持っています。“POSTNO”を「属性名」，“166-8539”を「属性値」と呼んでいます。郵便番号は住所から導き出せるので，内容ではなく属性にしてあります。何を内容とし，何を属性とするかの判断はなかなか難しく，経験を積む必要があります。
<ADDR POSTNO="166-8539">東京都杉並区和田1-29-11</ADDR>
次の例では，NAME（氏名）タグがFAMILY（姓）タグとFIRST（名）タグから構成されています。さらに，それぞれのタグがRUBY（振り仮名）属性を持っています。このように，属性名はタグごとに自由に持つことができます。
<NAME><FAMILY RUBY="きし">岸</FAMILY><FIRST RUBY="かずたか">和孝</FIRST></NAME>
さて，次の例は上記の例と似ていますが，FAMILYタグとFIRSTタグのそれぞれの終了タグが省略されています。NAME要素がFAMILY要素とFIRST要素しかない場合には，それぞれの終了タグは省略できます。こうした表現を「タグ最小化機能」と呼んでいます。この機能はSGMLにありますが，XMLにはありません。その理由は，空要素タグの扱いと同様に，タグの検査が面倒だからです。
<NAME><FAMILY RUBY="きし">岸<FIRST RUBY="かずたか">和孝</NAME>
文章だけでなく図や写真のような画像も文書の要素です。次の例では，IMAGE（画像）タグは，ファイル名が“TOKYOTOWER.GIF”で，高さが100ポイント，幅が200ポイントの画像を表わしています。これは，属性名から想像してそう思えるだけで，本当のところは何だか分からないのです。SGMLでは，テキストデータだけが「SGMLデータ」と呼ばれ，画像データのようにテキストデータでないものは「非SGMLデータ」と呼ばれます。そこで，次の例は，IMAGEタグは画像が「ここ」にあるというだけの意味に過ぎません。それを意味あるようにするのは，SGMLやXMLとは別の話になります。つまり，こうした表現によって，音楽データや，音と画像を連動させるような時系列を意味する内容も表現できることになります。
<IMAGE FILE="TOKYOTOWER.GIF" HEIGHT="100pt" WIDTH="200pt">
以上，タグの表現をざっと見てきました。SGMLとXMLでは表現が少し違うことがお分かりいただけたと思います。最後の話は，文書型の表現です。その表現したものを「文書型定義（Document Type Definition）」または，その頭文字を取って“DTD”と呼んでいます。文書型定義では，文書を構成する要素（に付けるタグ）の種類とその構成の関係を決めます。
前述した例について文書型を定義してみましょう。NAME（氏名）タグがFAMILY（姓）タグとFIRST（名）タグから構成され，それぞれのタグがRUBY（振り仮名）属性を持っています。この文書型定義は次のようになります［番号は説明のためのものです］。それぞれタグのような書き方ですが，これはタグではなく「マーク」と呼びます。“<!ELEMENT … >”は要素を，“<!ATTLIST … >”は要素が持つ属性を表わしています。タグと対応させてみれば，何となく意味が通じてくると思います。“FAMILY,FIRST”はNAME要素の内容がFAMILY要素とFIRST要素から構成されることを表わしています［1］。さらに，それらの要素の内容は文字データ（#PCDATA）であることを表わしています［2，4］。この“(”と“)”でくくった内容の指定を「内容モデル」と呼んでいます。属性は文字データ（CDATA）で，指定が必須（#REQUIRED）であることを表わしています［3，5］。
[1] <!ELEMENT NAME - - (FAMILY,FIRST) > [2] <!ELEMENT FAMILY - O (#PCDATA) > [3] <!ATTLIST FAMILY RUBY CDATA #REQUIRED > [4] <!ELEMENT FIRST - O (#PCDATA) > [5] <!ATTLIST FIRST RUBY CDATA #REQUIRED >
ここでは「文書型」の表わし方について，もう少し詳細に説明しましょう。
最近，「文書型」を巡っておかしな話をよく耳にします。それは「XMLではHTMLと同じように文書型定義は不要である」「文書型定義が無くても○△ソフトは動く」という声です。これは，どうもHTMLの文書型定義についての誤解から生じているようです。つまり，HTML文書（コンテンツ）に文書型定義（または文書型宣言）が書かれていなくても，サーバー側は送り出せますし，クライアント側はブラウザーで表示できます。これは，現在たまたまそうなっているだけの話であって，実は，文書型を指定していないHTMLコンテンツは，妥当なHTMLコンテンツとは言えません。
HTMLコンテンツの妥当性が問題になるのは，その内容を検索したり，データベースへ登録するような場合です。HTMLの文書型には幾つものバージョン（最新はバージョン4）がありますので，どのバージョンの文書型で表現されているか（言い換えれば，どんなタグが付いているか）が分かっていないと，HTMLコンテンツの内容から必要なデータを正しく抽出できないことになります。XML/SGMLでも同じです。
HTMLでは，HTMLという，たった一つの文書型に対するバージョンですが，XML/SGMLでは，文書型は応用の数（適用業務の文書の数）だけ存在することになりますので，無数の文書型があると言えます。例えば，XMLには，電子ブック“JEPAX”，電子カルテ“MML”などの標準的な文書型があります。そして，それぞれに幾つものバージョンが存在します。ですから，そうしたコンテンツを処理する上で，文書型はそれらの個々を区別するために不可欠なものなのです。
「XMLでは文書型定義は不要である」というのは，「文書型定義は文書に物理的に含まれていなくてもよい」と言うべきです。確かに，XMLでは文書型定義を省略した「整形式」（ウェル・フォームド）と言う形を許しています。しかし私は，前述した理由から整形式のXML文書は扱うべきではないと考えています（手短に言えば，ベスト・フォームドではないからです）。まして，文書型定義はよく分からないから，あるいは面倒だから書かないというのは，本末転倒だと思います。
文書型定義は，文書型を詳細に記述したものです。したがって，大きな文書型定義を文書（コンテンツ）に含めると，それを配信する度に時間がかかり，通信効率は当然下がってしまいます。そこで，文書型定義をコンテンツから分離・独立させます。それを「外部実体」と言います。コンテンツにはその外部実体を参照する情報だけを書くようにします。それが「文書型宣言」です。
次の例は，妥当なHTMLコンテンツです。第1行目が文書型宣言です。第2行目以降のHTMLコンテンツ（この部分を「文書インスタンス」と言います。）がその文書型に基づいて書かれている（タグ付けされている）ことを指定しています。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <HTML> … </HTML>
ここで，“PUBLIC "-//W3C//DTD HTML 4.0//EN"”を「外部識別子」と言います。その先頭が“PUBLIC”ですので，それに続く“-//W3C//DTD HTML 4.0//EN”は「公開識別子」となります。その形式はSGMLで規定されており，“//”でその内容が表3-1のように区切られています。
▼表3-1 公開識別子
|
例えば，ここで私がサンプルとして文書型定義を書きますが，その実体は公開する必要がありませんので，外部識別子は次のような書き方になります。その先頭を“SYSTEM”とし，それに続く“C:\TEXT\NC.DTD”は「システム識別子」（つまり，文書型定義を格納したファイルの名前）を指定します。
<!DOCTYPE NAMECARD SYSTEM "C:\TEXT\NC.DTD"> <NAMECARD> … </NAMECARD>
このように，XML/SGML文書から文書型定義を分離・独立させて外部実体とするには，公開識別子かシステム識別子かのいずれかで参照するようにします。以上で，XML/SGMLでは文書型定義が不可欠であることがお分かりいただけたと思います。
では，文書型定義をどのように書くのか，さらに説明しましょう。例えば，最もありふれた定型文書である名刺について考えてみましょう。図3-1のようにいろいろな形をした名刺があります。しかし，よく観察すれば，名前，会社名，住所，電話番号などといった共通的な項目から構成されていることが分かります。
|
▲図3-1 名刺
こうした幾つかの名刺を表わすことができる文書型定義は，次のようになります［番号は説明のためのものです］。NAMECARD要素はNAME（名前），COMPANY（会社名），ADDR（住所），PERSONAL（個人），HOMEPAGE（ホームページ），LOGO（ロゴ）の要素から構成します［1］。同様にして，NAME要素はFAMILY（姓），FIRST（名）の要素から，またPERSONAL要素は，TEL（電話），FAX（ファックス），EMAIL（Eメール）の要素から構成します［2，8］。それらの内容モデルは，すべて“,”で区切ったように見えますが，これは区切り記号ではなく，要素が順番に出現することを表わしています。また，“?”はその要素の出現が省略可能であることを表わしています。
ここで，ADDR要素のPOSTNO（郵便番号）属性が#IMPLIED（省略可能）であるのに対して，LOGO要素のIMAGE（画像）属性が#REQUIRED（必須）になっているのはなぜでしょうか。これについては「2 SGMLの仕組み」の説明を参照してください。[1] <!ELEMENT NAMECARD - - (NAME,COMPANY?,ADDR,PERSONAL,HOMEPAGE,LOGO?) > [2] <!ELEMENT NAME O O (FAMILY,FIRST) > [3] <!ELEMENT FAMILY - O (#PCDATA) > [4] <!ELEMENT FIRST - O (#PCDATA) > [5] <!ELEMENT COMPANY - O (#PCDATA) > [6] <!ELEMENT ADDR - O (#PCDATA) > [7] <!ATTLIST ADDR POSTNO CDATA #IMPLIED > [8] <!ELEMENT PERSONAL O O (TEL,FAX?,EMAIL?) > [9] <!ELEMENT TEL - O (#PCDATA) > [10] <!ELEMENT FAX - O (#PCDATA) > [11] <!ELEMENT EMAIL - O (#PCDATA) > [12] <!ELEMENT HOMEPAGE - O (#PCDATA) > [13] <!ELEMENT LOGO - O EMPTY > [14] <!ATTLIST LOGO IMAGE CDATA #REQUIRED >
次のSGML文書は，第1行目の文書型宣言でNAMECARDの文書型定義を参照し，第2行目以降がそれに基づいてタグ付けした文書インスタンスです。
<!DOCTYPE NAMECARD SYSTEM "C:\TEXT\NC.DTD"> <NAMECARD> <NAME><FAMILY>岸</FAMILY><FIRST>和孝</FIRST></NAME> <ADDR>福島県喜多方市松山町鳥見山字下堰下4608</ADDR> <TEL>0241-22-3981</TEL> <EMAIL>kisi@nifty.com</EMAIL> <LOGO IMAGE="AIZU.GIF"> </NAMECARD>
あるいは，次のようにもなります。
<!DOCTYPE NAMECARD SYSTEM "C:\TEXT\NC.DTD"> <NAMECARD> <NAME><FAMILY>唐</FAMILY><FIRST>望</FIRST></NAME> <COMPANY>社団法人 日本印刷技術協会</COMPANY> <ADDR POSTNO="166-8539">東京都杉並区和田1-29-22</ADDR> <TEL>03-3384-3112</TEL> <FAX>03-3384-3116</FAX> <HOMEPAGE>http//www.jagat.or.jp</HOMEPAGE> </NAMECARD>
ここでは，SGML文書における「SGML宣言」と，それをXMLではどのように扱うかについて説明します。
電子文書を使ってコミュニケーションを図ろうとする時は，その文書の送り手と受け手のプラットフォーム（コンピュータ環境）が同じでないことを前提に考えなければなりませんが，ややもすると，私たちは相手の環境を考えずに，自分が常用している特定の形式で表わした文書をメールで相手に送り付けがちです。
最近，私のところにメールの添付文書としてワード文書が無断で送り付けられるケースが増えています。確かに，私はワードを使っていますが，相手にそれを伝えた覚えはありません。ウィンドウズが事実上の標準だからというのは，乱暴な考え方です。もし親しい友人に大事な手紙をロンゴロンゴ（イースター島の失われた言語）で書いて送ることはないでしょう。それは友人が言語学者であっても理解不可能だからです。
ですからコミュニケーションを確立するためには，受け手が受け取れ，しかも送り手が意図したとおりに再生できる文書形式と文字符号系でなければなりません。このことは当り前のようですが，現実には理論よりも市場の利害が影響するために，その規格やツールのフレームワーク（枠組み）を作り出すことは極めて困難な状況と言えます。
様々なプラットフォームが使われている状況で，電子文書のコミュニケーションをどのようにして達成すべきなのでしょうか。解決策は，二つあります。一つは，標準または事実上の標準をサポートしている文書処理システム（ワープロやDTPなど）を普及させることです。と言っても，それを選ぶかどうかは利用者次第です。「1 今，なぜXMLなのか？」で述べたように，電子文書の表現形式が標準または事実上の標準でなければならない理由は，当面のコミュニケーションのためだけでなく，文書資産の将来のためなのです。
もう一つの解決策は，個々の文書処理システムでコンバーターを用意することです。この機能は独立したツールよりもプラグインで提供されているものが多いようです。しかし，ワープロやDTPなどのバージョンアップが頻繁なために同期が取れずに，プラグインが働かないことが生じています。コンバーターによる解決策は，多様な文書形式が多い現状では，それでも有効かもしれませんが，逆に余り経済的でないフレームワークと言えます。
現在，ワープロやDTP並みの割り付け済み文書が表現できる標準はODA（開放型文書体系）ですが，残念なことにそれを利用できる状況にありません。SGML文書は，DSSSL（文書意味スタイル指定言語）を介して具体的に割り付ければODAと同じことが実現できます。XML文書もXSL（XMLスタイル言語）を介せば同じです。しかし，DSSSLのツールはまだ充実しておらず，一般の利用は進んでいません。一方，XSLは仕様が確定しておらず，ツールは実験の範囲を出ていません。
事実上の標準について見ると，PDF，RTF，TeXなどが利用できますが，一長一短があります。PDFは文書の再生は優れていますが，再処理ができないという致命的な欠点を持っています。RTFはワードのバージョンアップによって変更が生じる不安定な面があります。TeXは使い勝手の面からは必ずしもまだ満足できるものではありません。
SGML/DSSSLあるいはXML/XSLに基づくワープロやDTPが普及するのは，もう少し先の話になりそうです。とりわけ，SGMLよりもXMLが話題になって，インターネットにおける電子商取引分野にツール開発が集中していますので，従来的なページネーション機能の実現は先送りされるでしょう。したがって，電子文書のコミュニケーションの混乱はまだ当分の間は続くと思われます。
さて，電子文書によるコミュニケーションの基本として「SGML宣言」を見てみましょう。SGML文書では文書に使う文字符号系と文字の範囲，区切り子の種類，機能の選択などを「SGML宣言」によって指定します。SGML宣言はマークの形で表わし，文書型定義と文書インスタンスに先立って受け手に渡されます。つまり，SGML文書処理システムは，SGML文書のSGML宣言を読んで，それらの指定に基づいて文書型定義と文書インスタンスに対する処理を行うわけです。次にSGML宣言の一例を掲載します［右側の文章は説明であり，SGML宣言の一部ではありません］。
<!SGML "ISO 8879:1986" ﾐSGML宣言
CHARSET ﾐ文書を表わす文字
BASESET ﾐ文字符号系ISO 646を使用する
"ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"
DESCSET ﾐ使用する文字の範囲を指定する
0 9 UNUSED
9 2 9
（中略）
32 95 32
127 1 UNUSED
BASESET ﾐ文字符号系JIS X 0208を使用する
"ISO Registration Number 87//CHARSET JIS X 0208-1990//ESC 2/6 4/0 ESC 2/4 4/2"
DESCSET ﾐ使用する文字の範囲を指定する
256 40960 UNUSED
41344 33 UNUSED
（中略）
65185 94 32289
65279 1 UNUSED
CAPACITY ﾐ文書容量
PUBLIC "ISO 8879:1986//CAPACITY Reference//EN"
SCOPE ﾐSYNTAX指定を適用する範囲
DOCUMENT ﾐ文書全体に適用する
SYNTAX ﾐ文書を表わすマークの指定
SHUNCHAR CONTROLS ﾐ制御符号として回避すべき文字
0 1 2 3 4 5 6 7 8 11 12 14 15 16 17 18 19 20 21 22 23
（中略）
148 149 150 151 152 153 154 155 156 157 158 159 255
BASESET ﾐ文字符号系ISO 646を使用する
"ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"
DESCSET ﾐ使用する文字の範囲を指定する
0 9 UNUSED
9 2 9
（中略）
32 95 32
127 1 UNUSED
FUNCTION ﾐ機能文字
RE 13 ﾐレコード終了符号はCR符号とする
RS 10 ﾐレコード開始符号はLF符号とする
SPACE 32 ﾐ空白は間隔符号とする
TAB SEPCHAR 9 ﾐ分離文字TABをHT符号とする
NAMING ﾐ名前の付け方
（中略）
NAMECASE ﾐ大・小文字の区別
GENERAL YES ﾐ要素名や属性名では区別しない
ENTITY NO ﾐ実体名では区別する
DELIM ﾐ区切り子
GENERAL ﾐ一般区切り子
SGMLREF ﾐ予約済みの書き方を使用する
NAMES ﾐ予約名の使用
SGMLREF ﾐ予約済みの名前を使用する
QUANTITY ﾐ量
SGMLREF ﾐ予約済みの最大値にする
NAMELEN 25 ﾐ名前の最大長を25文字にする
FEATURES ﾐSGML機構使用
OMITTAG YES ﾐタグの省略を可能にする
>
このようにSGML宣言は，様々なプラットフォームや様々な文書表現に合わせるために長い指定になり，通常で数十行，場合によっては数百行にも及びます。そのために，この方法で指定された文書を実際に処理をしようとすると，コンピュータに大きな負担を与えることになります。
そこでリアルタイム処理を指向するXMLでは，各種の指定を固定化しています。例えば，「1 今，なぜXMLなのか？」で述べたように，タグの省略（最小化）を禁止したり，“<IMG SRC="…"/>”のように空要素を表わすタグの表現を制約したりしています。
さらにXMLでは，SGMLでは標準でないという理由から扱えなかったシフトJISを扱えるようにするなど，現実的な選択をしています。SGMLの仕様は柔軟である反面，応用面から見ると，現実にそぐわなくなってきていることも事実です。
SGML宣言に対応するXML宣言では，文字符号系は次のように指定だけです。これと上記のSGML宣言を比べれば，いかにXMLが簡単かが分かるでしょう。
<?xml version="1.0" encoding="Shift_JIS"?>
ここからは，XMLの具体的な事例を取り上げていきます。先ず，XML文書をウェブで閲覧するための「XMLスタイルシート」から説明します。
XML文書（コンテンツ）を閲覧するツールは特にありませんが，HTMLコンテンツ閲覧用であるウェブ・ブラウザーによって閲覧できます。つまり，XMLコンテンツをHTMLコンテンツへ変換する仕組みが用意されているわけです。その変換を「XSL変換」と言います。「XSL」とは「XMLスタイル言語」の意味です。なお，XSLの仕様はまだ決定しておらず流動的な部分もありますが，ここでは，おおよそ決まりそうなHTMLコンテンツへの変換機能について説明します。XSLを理解するには，HTMLについての知識が必要です。ここでは，読者の皆さんがHTMLを知っていることを前提にします。
XMLコンテンツをHTMLコンテンツやその他の形式などへ変換するソフトウェアを「XSL変換プロセッサー」と言います。現在，容易に入手できるXSL変換プロセッサーとしては，ジェームズ・クラーク氏の「XT」や，マイクロソフト社のウェブ・ブラウザー「インターネット・エクスプローラー（バージョン5）」（以下，IE5と略します）があります。IE5にはXSLプロセッサーが内蔵されており，XMLコンテンツとXMLスタイルシートを与えると，直ちにHTMLコンテンツへ内部的に変換し画面でスタイル指定された結果を確認できます。
ここに“KISI.XML”という名前のファイルのXMLコンテンツがあるとします。その1行目がXML宣言であり，XMLで記述された文書インスタンスであることを表わしています。2行目がXMLスタイルシートの指定であり，XMLスタイルシートが“NC.XSL”という名前のファイルであることを指定しています。3行目は文書型宣言であり，文書型定義が“NC.DTD”という名前のファイルであることを指定しています。
<?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="NC.XSL"?> <!DOCTYPE NAMECARD SYSTEM "NC.DTD"> <NAMECARD> <NAME><FAMILY>岸</FAMILY><FIRST>和孝</FIRST></NAME> <COMPANY>飯豊山書林</COMPANY> <ADDR>福島県喜多方市松山町鳥見山字下堰下4608</ADDR> <TEL>0241-22-3981</TEL> <EMAIL>kisi@nifty.com</EMAIL> <LOGO IMAGE="AIZU.GIF"/> </NAMECARD>
<!ELEMENT NAMECARD (NAME,COMPANY?,ADDR,PERSONAL,HOMEPAGE,LOGO?)> <!ELEMENT NAME (FAMILY,FIRST)> <!ELEMENT FAMILY (#PCDATA)> <!ELEMENT FIRST (#PCDATA)> <!ELEMENT COMPANY (#PCDATA)> <!ELEMENT ADDR (#PCDATA)> <!ATTLIST ADDR POSTNO CDATA #IMPLIED> <!ELEMENT PERSONAL (TEL,FAX?,EMAIL?)> <!ELEMENT TEL (#PCDATA)> <!ELEMENT FAX (#PCDATA)> <!ELEMENT EMAIL (#PCDATA)> <!ELEMENT HOMEPAGE (#PCDATA)> <!ELEMENT LOGO EMPTY> <!ATTLIST LOGO IMAGE CDATA #REQUIRED>
次に，XMLコンテンツで指定している“NC.XSL”を見てみましょう。その1行目は，XML宣言であり，XMLで記述された文書インスタンスであることを表わしています。つまり，XMLスタイルシートもまた別の文書型定義に基づくXMLコンテンツなのです。2行目がW3Cの仕様（作業案段階）に基づくXMLスタイルシートであることを指定しています。3行目以降がXMLスタイルシートの本体です。その構造を分かりやすくするために字下げしてあります。さらに，イタリック体で示した部分がそのまま生成されるHTMLタグの部分で，それに対して“xsl:”の付いたタグは，XMLコンテンツを選択・参照するXSLタグです。こうしたタグの区別は「名前空間の違い」と言います。初心者にとって，これはややこしい表現方法かもしれません。
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>名刺</TITLE>
</HEAD>
<BODY>
<TABLE BORDER="1"><TR><TD>
<P ALIGN="RIGHT">
<xsl:if test="NAMECARD/LOGO">
<IMG>
<xsl:attribute name="SRC">
<xsl:value-of select="NAMECARD/LOGO/@IMAGE"/>
</xsl:attribute>
</IMG>
</xsl:if>
</P>
<P ALIGN="CENTER"><FONT SIZE="+2" COLOR="BLUE">
<xsl:value-of select="NAMECARD/NAME/FAMILY"/>
<xsl:value-of select="NAMECARD/NAME/FIRST"/>
</FONT></P>
<P ALIGN="CENTER"><FONT COLOR="LIME">
<xsl:value-of select="NAMECARD/COMPANY"/>
</FONT></P>
<P ALIGN="CENTER">
<xsl:value-of select="NAMECARD/ADDR"/>
</P>
</TD></TR></TABLE>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>
先ず，一部のXSLタグについて説明します。XMLスタイルシートは，XMLコンテンツに対するテンプレート（型紙）としてtemplateタグで表わされます。最初の“<xsl:template match="/">”は決まり文句と思ってください。value-ofタグはselect属性で指定したXMLタグに一致すると，その内容に置き換えられます。例えば，“<xsl:value-of select="NAMECARD/NAME/FAMILY"/>”は，FAMILYタグの内容を指しています。このように上位のタグを“/”で区切って指定することにより，同じタグ名であっても一意に指定できます。この置き換えはタグの内容だけでなく，“<xsl:value-of select="NAMECARD/LOGO/@IMAGE"/>”における“@IMAGE”のようにタグの属性値も置き換えできます。
“NC.XSL”の働きによって変換された結果は次のようになります。このソースはIE5で閲覧できますが，XSL変換は内部的に行われ，ソース自体を直接見ることはできません。XMLコンテンツ，XMLスタイルシート，変換結果の三つを見比べると，XSL変換の仕組みが見えてくるはずです。
<HTML> <HEAD><TITLE>名刺</TITLE></HEAD> <BODY> <TABLE BORDER="1"><TR><TD> <P ALIGN="RIGHT"><IMG SRC="AIZU.GIF"></IMG></P> <P ALIGN="CENTER"><FONT SIZE="+2" COLOR="BLUE">岸 和孝</FONT></P> <P ALIGN="CENTER"><FONT COLOR="LIME">飯豊山書林</FONT></P> <P ALIGN="CENTER">福島県喜多方市松山町鳥見山字下堰下4608</P> </TD></TR></TABLE> </BODY> </HTML>
「5 XML文書をHTML文書へ変換」の話で重要であったことは，次の二つです。
一つは，スタイルシートを表わす「XSL」というスタイル言語が，XMLで定義された文書型（タグセット）であるという点です。このことは，XMLが新たなタグセットを生み出せることを意味しています。例えば，BizTalk（電子商取引），G-XML（電子地図），JepaX（電子出版）などといった，様々な応用に向けたタグセットがXMLに基づいて開発されています。さらに，内容のデータ型を詳細に定義するためにDTD（文書型定義）の代りとなる「XML Schema」がXMLに基づいて開発されています。
もう一つは，スタイルシートでは，変換されるHTMLのタグと，それを指示するXSLのタグが混在します。それをタグ名の「名前空間」の違いという形で区別します。その方法は単純であり，タグに接頭語（XSLであれば，“xsl:”）を付けてユニークなタグ名にするだけのことです。この機能によって，いろいろな既存の文書型を必要に応じて混ぜて利用することができ，文書型の開発を効率的に進めることができます。
さて，今までのウェブでは，サーバーはクライアント側から送られた要求（主にURLによるリンク）に対してファイル（HTMLコンテンツ）を返すだけでしたが，これからのウェブでは，電子商取引のような対話的な処理を行う必要があります。XMLのタグセットはHTMLと違って任意ですから，個別の応用に合わせた表現ができます。
XML文書（コンテンツ）を処理するモデルには，次の二つがあります。
一つは，サーバー側でXMLコンテンツをXSL変換するモデルです。このモデルでは，サーバー側は，先ず，データベースから抽出したデータをXMLで表わします。次に，XSLプロセッサーを使って，そのXMLコンテンツとスタイルシートからHTMLコンテンツを作ります。そして，それをクライアント側へ返します（図6-1を参照）。このモデルの利点は，クライアント側のウェブ・ブラウザーがXML対応でなくてもやりとりができることです。また，クライアント側の取引条件などに合わせて，送り返すデータの内容を変えることができます。
|
▲図6-1 サーバー側でXSL変換するモデル
もう一つは，クライアント側でXMLコンテンツをXSL変換するモデルです。このモデルでは，先ず，サーバー側はXMLコンテンツとスタイルシートをクライアント側へ直に送ります。次に，それを受け取ったクライアント側では，ウェブ・ブラウザーに内蔵したXSLプロセッサーによって内部的にHTMLコンテンツへ変換します。そして，それをエンドユーザーが閲覧することになります（図6-2を参照）。このモデルの利点は，サーバーの負荷が少ないことですが，現実には，すべてのエンドユーザーがXML対応のウェブ・ブラウザーを持っているとは考えにくいので，このモデルは，設備管理が可能なイントラネットでしか使われないかもしれません。
|
▲図6-2 クライアント側でXSL変換するモデル
このようにXSL変換はウェブ上でXMLの応用を進めていく上で重要な役割を果たします。スタンドアローンのXSLプロセッサーによるXSL変換は，XMLコンテンツからHTML以外の形式への変換も可能です。印刷業では，XSLプロセッサーによって組版タグの生成にも利用できると思われますが，XSLはDSSSL（文書スタイル意味指定言語）よりも機能が小さいので，余り期待できません。
XSL変換の主要な変換規則は，表6-1のとおりです。一般の手続き型プログラミング言語に似た，条件による選択・場合分け・反復，テンプレートの選択などの指示ができます。組み方次第で応用を広げられるでしょう。
▼表6-1 XSLの変換規則
|
この表6-1における「パターン」とは，XMLコンテンツのタグ（つまり，文書要素）の内容を指示するものです。「5 XML文書をHTML文書へ変換」の例には，次のような部分があります。
<xsl:if test="NAMECARD/LOGO">
<IMG>
<xsl:attribute name="SRC">
<xsl:value-of select="NAMECARD/LOGO/@IMAGE"/>
</xsl:attribute>
</IMG>
</xsl:if>
“<xsl:if test="NAMECARD/LOGO">”は，NAMECARD（名刺）にLOGO（ロゴマーク）要素が出現しているかを調べ，出現していれば“</xsl:if>”までの間の変換規則を適用することを指示します。
LOGO要素が出現した場合，先ず，“<IMG>”がHTMLコンテンツとして書き出されます。次に，“<xsl:attribute name="SRC">”によってIMGタグにSRCという名前の属性を加えることが指示されています。その属性値は“</xsl:attribute>”までの間の変換規則“<xsl:value-of select="NAMECARD/LOGO/@IMAGE"/>”によってLOGO要素のIMAGE属性の値であることが指示されています。
XSLの話は，これですべてではありません。XML文書を主にHTML/CSSコンテンツへ変換する「XSL変換」に加えて，より一般的なフォーマットの指定ができる「フォーマッティング」があります。
XSL規格の前半部分が「XSL変換（Transformation）」であり，XSL規格の後半部分が「フォーマッティング（Formating）」です。「XSL変換」はW3C勧告となりましたが，「フォーマッティング」はまだW3C作業案の段階です。この二つが組み合わされて「XSL変換〜フォーマッティング」として働く時に，XSL規格が初めて有用なものとなります。
そうした「XSL変換〜フォーマッティング」によるXML文書の組版について説明します。
現在，フリーのXSL変換プロセッサーには次のものがあり，ダウンロードして動かしてみれば，「百聞は一見に如かず」で，その機能が容易に理解できるでしょう。
クライアント側でXSL変換するモデルに基づくXSL変換プロセッサーは，ウェブブラウザーに内蔵された形をとっています。Windows版ではInternet Explorer 5（以下IE5と略します，http://www.microsoft.com/），MacOS版ではInDelv XML Client（以下InDelvと略します，http://www.indelv.com）があります。IE5はHTMLへの変換を行う「XSL変換」だけを備えています。InDelvは，未完成ながら「XSL変換〜フォーマッティング」を実現しています。
サーバー側でXSL変換するモデルに基づくXSL変換プロセッサーは，独立したアプリケーションプログラムの形をとっています。Windows版ではXT（http://www.jclark.com/），MacOS版ではTransforMiix（http://www.jagat.or.jp/sgml/）があります。XTにはJavaバーチャルマシンの下で動くプログラムと，単独で実行可能なプログラムがあります。TransforMiixは単独で実行可能なプログラムだけです。
現在，XSLはW3C勧告になった「XSL変換」だけに話題が集中しており，IE5やXTが主に使われています。しかし，いずれも「XSL変換〜フォーマッティング」は実現していませんので，今後のXML応用の方向を勉強するために，InDelvにも目を向けたいものです。
「XSL変換」と「XSL変換〜フォーマッティング」との機能の違いを知るために，同じ表示結果を指示する，それぞれのスタイルシートを比べてみる必要があります。
“KISI.XML”というXML文書インスタンスに対して「XSL変換〜フォーマッティング」によるスタイルシートは“NC.XSL”のようになります。なお，「XSL変換」によるスタイルシートについては「5 XML文書をHTML文書へ変換」を参照してください。
<?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="NC.XSL"?> <!DOCTYPE NAMECARD SYSTEM "NC.DTD"> <NAMECARD> <NAME><FAMILY>岸</FAMILY><FIRST>和孝</FIRST></NAME> <COMPANY>飯豊山書林</COMPANY> <ADDR>福島県喜多方市松山町鳥見山字下堰下4608</ADDR> <TEL>0241-22-3981</TEL> <EMAIL>kisi@nifty.com</EMAIL> <LOGO IMAGE="AIZU.GIF"/> </NAMECARD>
<?xml version="1.0"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
xmlns:fo="http://www.w3.org/XSL/Format/1.0"
result-ns="fo">
<xsl:template match="/">
<fo:block start-indent="20pt"
margin-top="2pt" margin-bottom="2pt"
margin-left="2pt" margin-right="2pt">
<fo:table border-style="solid" table-width="60%">
<fo:table-body>
<fo:table-row>
<fo:table-cell>
<fo:block start-indent="200pt">
<fo:display-graphic href="{NAMECARD/LOGO/@IMAGE}" />
</fo:block>
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell>
<fo:block space-before="10pt" text-align="center"
font-size="18pt">
<xsl:value-of select="NAMECARD/NAME/FAMILY"/>　
<xsl:value-of select="NAMECARD/NAME/FIRST"/>
</fo:block>
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell>
<fo:block space-before="10pt" text-align="center"
font-size="14pt">
<xsl:value-of select="NAMECARD/COMPANY"/>
</fo:block>
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell>
<fo:block space-before="10pt" text-align="center"
font-size="14pt">
<xsl:value-of select="NAMECARD/ADDR"/>
</fo:block>
</fo:table-cell>
</fo:table-row>
</fo:table-body>
</fo:table>
</fo:block>
</xsl:template>
</xsl:stylesheet>
IE5，XTまたはTransforMiix，InDelvにおけるスタイルシートを比べると，次のことが分かります。
IE5におけるスタイルシートでは，次のように「XSL」（W3C作業案）に基づくという指定になりますが，「フォーマッティング」の機能はありません。IE5ではXML文書は「XSL変換」によって内部的にHTMLコンテンツとなり可視化されます。
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
XTにおけるスタイルシートでは，次のように「XSL変換」（W3C勧告）に基づくという指定になります。XTでは，XML文書は「XSL変換」によってHTMLまたは任意な形式のテキストとして出力されます。
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/XSL/Transform">
InDelvにおけるによるスタイルシートでは，次のように「XSL変換」（W3C勧告）と「フォーマッティング」（W3C勧告になったという仮定）に基づくという指定になります。InDelvでは，XML文書は「XSL変換」によって一旦フォーマッティングオブジェクト（fo）に変換され，その後で可視化されます。このfoの機能が「フォーマッティング」の規格というわけです。
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
xmlns:fo="http://www.w3.org/XSL/Format/1.0"
result-ns="fo">
名刺（NAMECARD）を表わしたXML文書インスタンス“KISI.XML”とスタイルシート“NC.XSL”（紙面の関係で，ここにすべてを掲載できませんので，前回の内容を参照してください）について「フォーマッティング」の機能を説明します。
InDelvにおけるスタイルシートでは，次のように「XSL変換」（W3C勧告）と「フォーマッティング」（W3C勧告になったという仮定）に基づくという指定になります。ここで，“fo”が「フォーマッティング」を規定するタグの名前空間を示していることに注目してください。
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
xmlns:fo="http://www.w3.org/XSL/Format/1.0"
result-ns="fo">
<xsl:template match="/">
テンプレート本体
</xsl:template>
</xsl:stylesheet>
テンプレート本体では，XML文書インスタンスの文書要素（つまり，タグが示すその内容）をどのようなスタイルにするかを特定の「フォーマッティングオブジェクト」というものに対応づけします。それは段落，箇条書，表などを可視化するための領域です。次の指定では，文書全体を「ブロックのフォーマッティングオブジェクト（fo:block）」に，さらにその内側の「表のフォーマッティングオブジェクト（fo:table）」へ対応づけています。
<fo:block start-indent="20pt"
margin-top="2pt" margin-bottom="2pt"
margin-left="2pt" margin-right="2pt">
<fo:table border-style="solid" table-width="60%">
表の本体への対応づけ
</fo:table>
</fo:block>
「ブロックのフォーマッティングオブジェクト」の指定は，XML文書インスタンスに対する段階スタイルシートのレベル2（CSS2）の指定に似ています。CSS2では，同じことを次のように指定します。
NAMECARD { display:table; border-style:solid;
margin-top:2pt; margin-bottom:2pt;
margin-left:2pt; margin-right:2pt }
フォーマッティングオブジェクトの書き方がXMLタグの表現であるのに対して，CSSは独自の書き方になっていますが，その意味するところはほとんど同じです。すべてのフォーマッティングオブジェクトの特性がCSS2の特性と対応しているかどうかはまだ調べていませんが，かなり一致しているものと思われます。したがって，フォーマッティングオブジェクトとは，CSS2をXSLの「フォーマッティング」に導入したものと看做せます。
しかし，CSS2でもXML文書インスタンスに対してスタイル指定ができるからと言って，XSLの「フォーマッティング」が不要になるわけではありません。XSLでは「XSL変換」というプログラム処理を介して，一層複雑なスタイル指定が可能だからです。
「表のフォーマッティングオブジェクト（fo:table）」の本体の中では，次のように「行のフォーマッティングオブジェクト（fo:table-row）」と「列のフォーマッティングオブジェクト（fo:table-cell）」のスタイルが指定されています。つまり，1行1列であること，その列は「ブロックのフォーマッティングオブジェクト」で表わされること，その内容が名刺（NAMECARD）の住所（ADDR）であること，それが上部を10ポイント空けて14ポイントのフォントで中央揃えして表示されることが指定されています。ADDRタグの内容に置き換える指示（xsl:value-of）はXSL変換のタグで表わされています。
<fo:table-row>
<fo:table-cell>
<fo:block space-before="10pt" text-align="center"
font-size="14pt">
<xsl:value-of select="NAMECARD/ADDR"/>
</fo:block>
</fo:table-cell>
</fo:table-row>
「ブロックのフォーマッティングオブジェクト」や「表のフォーマッティングオブジェクト」は，CSS2において「ボックス」と呼ばれる長方形の描画領域と同じ概念です。CSS2では「ボックス」に対する内容の対応づけは文書インスタンスのタグの構造に合わせて一対一になります。一方，XSLでは任意の内容を複数の「ボックス」に一対多に対応づけることができます。
XSLでスタイルを指定した結果は，通常はウェブ文書として出力されるでしょう。結果がPDFとかTeXといった「印刷向けの文書形式」へ変換出力されるかどうかはXSLプロセッサー（フォーマッター）の機能次第です。なぜなら，XSLの「フォーマッティング」は出力の装置や形式に依存していないからです。
SGMLとXMLの対比を整理してみました。
近い将来，商業出版物レベルの自動組版を実現したXSLフォーマッターが登場するかもしれません。そうなると「SGMLは紙媒体を対象とした静的な文書の表現であり，XMLはネット媒体を対象とした動的な文書の表現である」という紋切り型の分類はできなくなります。XMLはSGMLに一部制約を加えたものとは言え，従来の出版物の表現には何ら支障はありません。そうしたことから，XML/XSLをポストSGML/DSSSLとして捉えるほうがいいのではないかと思っています。
XML/XSLは発展途上にあり，今後も研究を一層続けていきたいと考えています。
（2001年1月記）