XMLを使った執筆

How I got started（どのように始めたか）

Typing in the text（テキストの入力）

人々が最初に尋ねる質問は、「何を使ってテキストを入力していますか」のようです。答えは私には明らかです。テキストエディタです。プログラマーとして、私は多くのテキストエディタに精通しており、XML形式の強みの1つは、好きなテキストエディタを使って入力できることです。これは共同作業者にとって素晴らしいことでした。なぜなら、彼らに高価なソフトウェアを購入してもらって本のセクションに貢献してもらう必要がなかったからです。

本を執筆している間、私が選んだテキストエディタはTextPadでした。これまでソフトウェアに費やした30ドルの中で間違いなく最高のものです。高速で、シンプルながらも便利な機能が満載です。クリップライブラリは、テキストにタグを付けるのに非常に役立ちました。

他のXML編集ツールも検討しましたが、さまざまな選択肢に魅力を感じませんでした。それらのほとんどは、何か面白いことをするにはDTDが必要でしたが、私はゲームの後半になってようやくDTDを使い始めました。

つい最近、XEmacsを使い始めました。長年Emacsを断続的に使用してきましたが、ほとんどの場合、使用していたコンピュータにはEmacsがインストールされていなかったか、Windowsポートはシステムの他の部分についてあまり詳しくありませんでした（カットアンドペーストは基本的な機能と考えています）。Windows版のXemacs 21.4は、Windowsに非常に 친숙합니다。SGMLメジャーモードは、テキストベースのドキュメント、特にDTDがある場合に非常にうまく機能します。もちろん、最近は時代遅れに感じるEmacsのキーコンビネーションに慣れている必要があります。

XML Spyを何度か試してみましたが、私の目的にはあまり合いませんでした。データ指向のXMLに重点を置いており、テキストを入力するのには適していません。キーの組み合わせに慣れてしまうと、XEmacsの便利なキーが恋しくなりました。

今後の動向を見ていきます。シンプルなテキストエディタよりも優れたツールは確かに想像できますが、今のところ、テキストエディタは非常に高機能で高価なツールよりも優れています。

Converting to HTML（HTMLへの変換）

このアプローチは、HTMLページを作成する場合に特に効果的です。XMLで記述し、XSLTで変換するのは、私にとって非常にうまく機能します。

最初はそうではありませんでした。XSLTは厄介な言語です。XMLベースのものをプログラミング言語として使用すべきではないという素晴らしい理由です。データとプログラムの類似性というLispのような性質に魅力を感じる人もいるかもしれません。私は、書くのも扱うのも非常に難しいと感じています。また、かなり複雑で、役に立ちません。

欠点はあるものの、XSLTは強力です。しかし、生活を楽にするためのヒントがいくつかあります。

• XSLTは関数型プログラミング言語のようなもので、通常の方法では変数を使用できないため、ループする場合は再帰を使用します。
• 出力を駆動するためではなく、パターンを照合するために使用します。そのため、<xsl:for-each>ではなく、<xsl:template match = "foo">を優先します。（awkを使ったことがあるなら、こちらの方が快適でしょう）。
• Michael Kayの「XSLTプログラマーリファレンス」を入手してください。非常に分厚い本ですが、非常に優れたリファレンスです。XSLTを学ぶための最高の کتابではありませんが、詳細な質問に答えるのに最適です。

HTMLの作成、そして実際には他の多くの場所でも、私はビルドスクリプトに頼っていました。この本のために、コードをビルドし、本のページを自動的にビルドするAntスクリプトを用意しました。ビルドスクリプトのおかげで、生活はずっと楽になりました。

しかし、全体的に、XML/XSLTがもたらす分離は本当に気に入っています。ページのフォーマットは非常にシンプルですが、シンプルな論理タグセットで書く方がはるかに簡単です。いつか、素敵なウェブサイトを作るかもしれません。

Converting to print（印刷用への変換）

HTMLへの変換はシンプルで明白ですが、書籍には印刷スタイルのフォーマットが必要です。それはもっと問題でした。

最初の試みは、ApacheのFOPでXSL-FOを使用することでした。当時（2002年初頭）、XSL-FOには明らかに必要な機能がすべて備わっていましたが、FOPには限界があり、特にこれほど大きな本では、私は太刀打ちできませんでした。FOPルートのもう1つの問題は、少なくとも現時点では、出版社がまだ準備ができていなかったことです。

これらの問題は一時的なものだと考えています。より優れたXSL-FOツールが手に入れば、印刷可能な出力を作成するための明白な方法となるでしょう。次に印刷可能な出力を作成する必要があるときは、XSL-FOをもう一度検討します。

最終的に私が行ったのは、信頼できるFramemakerに戻ることでした。XMLからFramemakerファイルを自動的に生成することで、これを行いました。これは2段階で行いました。「PofEAA」で使用したタグを、使用していたFrameのサブセットを反映したタグに変換するXSLT変換を行いました。次に、Rubyスクリプトを使用して、FrameのようなXMLをFrameのテキスト形式のMIF形式ファイルに変換しました。最初のステップにXSLTを使用すると、変換に関するすべての難しい作業をうまく行うことができましたが、XSLTはFrameに必要な正確なテキスト形式を処理するのには適していません。XSLTとRubyの組み合わせは完璧に機能しました。

XMLを印刷するためのもう一つの選択肢として、Open Officeを使う方法があります。Open Officeのファイル形式はzip圧縮されたXMLで、コンテンツとフォーマットを分離するように配慮されています。そのため、XSLTを使用してコンテンツを変換し、Open Officeでフォーマットを個別に追加するのは簡単です。将来のバージョンのMicrosoft Wordも、この種の機能をサポートする可能性があります。

Diagrams（図）

私の文章には、特にUML図など、図表がよく含まれており、それには何を使っているのかよく聞かれます。私は以前から高機能なCASEツールではなくVisioを愛用してきました。Visioでさえ、製品に付属する標準のUMLテンプレートは使用していません。CASEツールとVisioのUMLテンプレートの問題点は、それらがインテリジェントになろうとすることです。しかし、UMLに関するこれらのツールのインテリジェンスは平均的な開発者よりもはるかに低いため、ツールは邪魔になるだけです。

そのため、私はPavel Hrubyによって開発された別のテンプレートセットを使用しています（リンクについては、私のリンクページを参照してください）。

Visioの大きな不満は、出力に厄介なグリッチがあることです。たとえば、gifに出力すると、結果はあまり良くなく、図の一番上の線が頻繁に途切れてしまいます。SVGのブラウザサポートが進むことを期待しており、将来的にはOpen Officeの描画機能を試して、より良い結果が得られるかどうかを確認する予定です。

私がすぐにやらなかった重要なことの1つは、すべてのVisio図をgifに自動的にエクスポートするスクリプトを用意することでした。私はこれを後で実行しました（Visioファイルが対応するgifが生成された後に変更されたかどうかを確認します）。スクリプトができてからは作業がはるかに楽になりました。幸いなことに、Visioはほぼすべてのスクリプト言語（私の場合はRuby）で非常に簡単に操作できます。

Automatic Code Import（自動コードインポート）

このスキームを使用する上での最大の利点の1つは、サンプルコードの自動コードインポートでした。ほとんどの著者はサンプルコードに悩まされています。ほとんどの場合、何かがうまくいかず、サンプルコードに一貫性がなかったり、コンパイルできなかったりします。これは、コピーアンドペーストされたコードを同期させておくのが難しいことが原因です。

私はもっとうまくやることができました。すべてのコード例は、Antを使用してディレクトリ全体をビルドおよびテストできるディレクトリに保存されていました。その後、ソースコードファイルにコメントタグを付けて、書籍にインポートするコードセクションをマークすることができました。次に、簡単なJavaコードを記述してソースファイルを処理し、ソースコードからのフラグメントを含むXMLファイルを生成しました。これらのフラグメントは、XSLTを実行したときに簡単に出力にインポートできました。これは、そうでなければ非常に面倒なプロセスを驚くほど排除し、必要なときにいつでも自信を持ってコード例を変更することを可能にしました。

Collaboration and Versioning（共同作業とバージョン管理）

私はP of EAAで何人かと共同作業をしました。最も注目すべきは、本書の大部分を執筆したDavid Riceです。テキストとコード例の両方を変更していたため、作業を慎重に調整する必要がありました。

その答えはCVSでした。XMLファイルは単なるテキストであるため、CVSは共同作業を処理するのに最適な方法であることが証明されました。何かを変更するたびに、ファイルをCVSにアップロードしました。これは、Davidがオーストラリアで作業しているため、締め切りに追われていたため不可欠となりました。

もちろん、CVSは私個人にとっても役立ちました。すべてのファイルの確かなバージョン履歴が常に存在することを知っていれば、いつでも安心してテキストをいじることができました。さまざまなJavaライブラリや.NETアセンブリなど、すべてをバージョン管理しました。プログラマーは常にバージョン管理を使用して作業する必要があるのと同じように、著者もそうする必要があります！

Final Thoughts（最終的な考え）

XML関連技術の黎明期でさえ、XMLは大著を執筆するための非常に優れた方法であることがわかりました。今では、この記事を含め、ほとんどすべての執筆にためらいなく使用しています。（主な例外は、IEEE Softwareのコラムを書いているときです。彼らはWordファイルを受け取ることを好み、他の通常の問題が発生しない程度に短いものです。）

Webサイト、レポート、または書籍にXMLを使用することを検討している場合は、あなたがギークであり、XSLT、スクリプトなどをいじることが好きなら、お勧めします。あまりギークでない場合は、しばらく待つことをお勧めしますが、XML対応のワードプロセッサに注目してください。新しいWordが噂どおりであれば、状況は面白くなるでしょう。