XMLはマニュアルで「使える」の？（後編）
1999年10月12日
前回見てきたように、XMLはタグによって意味や階層を記述する言語（Markup Language）の一種です。しかし、「タグによって意味や階層を記述するというのであれば、HTMLやSGMLも基本的に同じはずなのでは？」と思われるかたも多いでしょう。
今回はHTMLやSGMLとXMLの違い、そしてXMLをマニュアルに使う意味についてまとめてみます。
SGMLとXMLはほとんど違いがない . . . らしい（汗）
XMLを利用したデータベース運用という観点から、なぜSGMLではなくXMLなのかという疑問をお持ちの方も多いかと思います。当研究所はSGMLやXMLの専門家というわけではないので詳しいことは差し控えますが、その道のプロのお話によると「SGMLもXMLも、できることにほとんど違いはない」ということです。
それでは、なぜわざわざXMLが提唱されたのでしょう？
それは処理したデータをWebに流したいと考えたときに、現行のSGML規格で処理したデータはWebに不向き（どうしても処理が重くなる）であるという理由からです。この問題を解消するために、Webに対する適性を強化したSGMLのサブセットとして、XML規格を制定することになったと言われています。策定経緯からも推測できるように、SGMLを利用して現状でワークフローを構築していた環境では、XMLへの以降は容易であるようです。つまりSGMLとXMLを比較することはほとんど無意味で、将来的にデータをそのままWebに流せる形式で保持したいのであればXMLを使えば良い、ということだけのようです。
もっとも今後は、何かにつけてWebアプリケーションを中心とした世の中になることが予想されます。EC（Electronic Commerce）運用の面からも注目を浴びるXMLですから、今後はXML関係のツールも数多くリリースされるようになるでしょう。ツールの整備が進み、かつSGMLとできることが同等であることが認知されてくるのであるならば、特に事情がない限りわざわざSGMLを選択する必然性は薄れてくるのかもしれません。
HTMLに対する、XMLのアドバンテージ
ところでWebとの親和性を語るのであるならば、なぜHTMLではいけないのか？という疑問を抱くかたがいらっしゃるのも当然ですね。
前回見てきたように、XMLはHTMLと比較して構造単位でのデータの取り回しがしやすいという長所があります。しかし、それ以上にXMLを採用する利点となるのが、タグを任意に設定可能であるという点です。この「任意に拡張できる」という仕様こそXMLがeXtensibleという名称を持つ所以で、文章の意味に合わせたタグを定義して、使用することができるのです（もちろん「その場に応じて好き勝手に」というわけにはいきませんが、拡張可能であるのかないのかには大きな差があります）。確かにHTMLでもある程度のことはできるようになってはきているものの、やはり強引になんとかしているという感が拭えません。この面に関しては、データの再利用性も含めて、XMLに分があると言えるでしょう。
しかし、最初から使い捨てのつもりで作成するデータや、データの再利用性には目をつぶってでも、見栄えを追求するレイアウトを提供したいような場合には、無理にXML化するのではなく、最初からHTMLで通してしまっても十分なのではないかと思います。また、現状ではXMLをまともに解釈できるブラウザがほとんど存在しないことにも注意が必要です（Microsoft Internet Explorer5のXML解釈も結構怪しい . . . らしいです）。電子マニュアルや一般向けのWebコンテンツをXML形式で提供するつもりであるならば、この辺の問題に十分注意を払う必要があるでしょう。
XMLと紙マニュアルとの相性を考える
HTMLやSGMLとの違いを踏まえた上で、よく言われるようにXMLがマニュアルに対して本当に親和性を持つものであるのかどうか、考えてみましょう。しかし「マニュアル」という対象はあまりに大きすぎるので、紙マニュアルと電子マニュアルの2つに分けて考えてみたいと思います。
紙マニュアルでXMLを利用する場合には、大元の出力データをXMLで記述するかどうかの問題に還元されます。従って、制作データをXML形式で保持すべきかどうかということが問題となります。この点を考慮に入れると、以下の3点がXMLを導入するかどうかの判断ポイントとなるでしょう。
- ad hoc な対応が要求されるマニュアルには向いていない：
Adobe FrameMakerをお使いのかたは実感できるかと思いますが、いくらeXtensibleであるからといって、XML利用時にその場しのぎのスタイル（タグ）設定をすべきではありません。一定ページに情報を詰め込むことが最優先されるような場合のように、その場しのぎ（良く言えば臨機応変）のスタイル設定が要求されるようなマニュアルには向いていないといえるでしょう。そういう意味では、前述の「使い捨てであるならば、XML化せずにHTMLでも良い」という部分と一致します。
この辺の問題に関しては「マニュアル制作データベース？」もあわせてご覧ください。 - 要素の出現順序が定型のものは向いている：
これはDTD（Document Type Definition：文書型定義）で出現順序などを規定する必要があるためですが、普通のマニュアルは明確な階層構造を（それなりのレベルではありますが）実現しているため、それほど問題はないと思います。 - データベース資産としたいならば、XML化も検討すべき：
これはいままでSGMLを利用して制作を行ってきたような領域では、XMLに移行するメリットが大きいということです。これからSGML/XML化を検討しているのであるならば、無理をして一度にすべてをXML化するのではなく、対象とする情報の種類にあわせて段階的にXML化していくという、柔軟な運用も考慮するべきでしょう。
特にトラブルシューティング系の情報など、後からWebに展開することがあらかじめわかっているような種類の情報は、XML形式で保持しておくメリットがあるのではないでしょうか（例：トラブルシューティングであるならば、商品カテゴリー／症状／原因／対策に分けてタグ付けしておくだけで、かなり再利用しやすいデータになるはずです）。
電子マニュアルとの相性を考える
電子マニュアルでは、マニュアルのコンテンツそのものをXML形式で記述して、ユーザーはXML対応のブラウザ（ないしはヘルプビューワ）で閲覧することになります。現実的にXML対応ブラウザが出揃っていない現状ではあくまで可能性に言及するのみとなりますが、XMLを利用することで以下のような可能性が開けてくるのではないかと思われます。
- ユーザー要求に応じて、見せかたを動的に変更できる余地が出てくる：
現在のところまだ仕様が確定していないのですが、XMLのスタイルシート規格であるXSL（eXtensible Style Language）を利用することで、細かな見栄えの指定ができるようです。しかし当研究所としては、XSLよりもXMLのリンク規格であるXLinkを利用することで実現できる、新しい見せかた興味があります。
XLinkではリンク先の内容をリンク元に読み込むことができます。そのため、電子マニュアル中で条件分岐しなければならないようなときは、条件文だけを記載しておき、ユーザーの選択に応じて、該当の条件の説明だけをそのページ内に表示するといったことが可能になります（すべての条件分岐とその内容を羅列する必要がなくなり、すっきりしたページになります）。
XMLを利用したコンテンツの動的なコントロールに関しては、これからも折を見て研究していきたいと考えています。 - クロスプラットフォームを対象とした電子マニュアル制作が変わる可能性もある：
さすがにソフトウェアやOSのシステムに密着した電子マニュアルを制作する場合には、それぞれの動作プラットフォームの標準ヘルプを利用することになります。しかしそれ以外の場合には、現状ではHTMLとPDFしか手段のなかった、クロスプラットフォームでのマニュアル制作／配布の選択肢が増えることになります。
現状のHTMLやPDFの短所に頭を抱えているかたにとって、利用しがいのあるものになってくる可能性も十分にあるでしょう。
いかがでしたか？
結論としては、対象領域の性質を十分に考慮した上で、XML 化を検討すべきというところでしょうか。最終的には導入を決断する人の判断次第ということになってしまうのですが、多少は「XMLってマニュアルに使えるの？」という疑問の解消のお役には立てたのではないかと思います。
前回同様に、厳密に言うと違ったり、誤解を招くような説明もあるかと思います。「とにかく使えるのかどうなのか」という問いに答えられるように理解のしやすさを優先したためなのですが、「それにしてもあんまりでは？」という苦情などありましたら、お手数ですがご意見をお寄せください。
