これまでも幾つかの取り組みがあり、中断されたり、未完成なままであったりしていましたが、この3つのワープロソフトは、活発に維持管理されて入手可能な状態にあります。いずれもワープロソフトとして素晴らしいものであり、また様々なインポート/エクスポート機能（広く使われているものの、Microsoft固有のフォーマットであるMicrosoft Wordフォーマットも含めて）が用意されています。しかもLinux用にしろ、（フリーのOS、特定メーカのOSを問わず）他のプラットフォーム用にしろ、ソース形式とバイナリ形式の両方が入手可能です。そしてこのコラムにとって一番興味深いのは、AbiWord、KWord、Writerのどれもが、ネイティブの文書フォーマットとしてXMLを使っているという点です。

このコラムでは、3つのワープロソフトの機能や外観、ユーザ・インターフェース等について比較するつもりはありません。どのワープロソフトに関してもルック・アンド・フィールが非常に洗練されており、業務用や個人用の文書を作るために十分な機能を備えている・・・、と言うだけで十分でしょう。私が興味を持っているのはXML文書のフォーマット、つまりこれらプロジェクトの真髄となっている中身なのです。

これらのプロジェクトに馴染みのない人のために、少し説明をしておいた方が良いでしょう。AbiWordはスタンドアローンのワープロソフトで、クロス・プラットフォームでの互換性を追求しています。適度なサイズで、実行速度も申し分ありません。OpenOffice.orgは、Sun MicrosystemsのStarOffice製品から派生したもので、それがフリー・ソフトウェア・ライセンスとしてリリースされたのを受け、開発コミュニティがとりあげたものです。OpenOffice.org Writerは、統合ソフトの一部であり、表計算やベクター描画プログラム、プレゼンテーション等のアプリケーションとの連携動作が可能です。同様にKWordは、KOffice統合ソフトの一部です（KOffice自体も包括的に見てKDEプロジェクトの一部になっています）。KOfficeはOpenOffice.orgよりもさらに多くのコンポーネントを含んでおり、フローチャート作成、ラスター画像編集、図表描画、などのアプリケーションが追加されています。いずれにせよここでは、KOfficeやOpenOffice.org統合ソフトの内、ワープロ機能だけに注目します。

文書フォーマットをテストする

皆さんも予想されているかも知れませんが、こうしたオープン・ソースのワープロソフトの新バージョンでは、文書フォーマットを少しずつ改良しています。幸いXMLは（任意に・・・）新しい属性や子要素を追加することができるので、上位方向への変更に適しています。この変更をうまく行いさえすれば、新しいバージョンのソフトで保存された文書を古いバージョンのソフトで読み込む際にも、認識できないタグや属性を単純に無視するだけなので、古いバージョンのソフトでも（新しい機能は反映されませんが）比較的素直に読み込むことができます。

私が見たXMLフォーマットでは、プロジェクト開発者がDTDを提供していましたが、同じバージョンのアプリケーションで作られた実際のXML文書とは多少同期していない部分がありがちでした。それでも整形式であるという状態は望むべき形に保たれていますが、生成や構文解析はあまり正式なものではないようです。結局最後にものを言うのは、DTDやスキーマではなく、フォーマットを実装するソース・コードなのです。つまり、以降のサンプルでは正常に妥当性検証ができないかも知れないのです。文書がnot validate successfully. To give you an idea of what the documents実際にどんな風に見えるかを説明するために、図1のような非常に簡単なテスト文書を作ってみました。

面白いことに（・・・当然かも知れませんが）、この文書をXMLで表現したものをいくつか見ると、同じ文書を元にしながら結果は同じではないのです。（もちろんこれはXMLなので、ホワイトスペースの正規化のような問題によって、同じではないファイルが同じInfosetを表現できてしまうのですが、これを問題にしているわけではありません）。少なくともある細部においては、文書を作成する際にユーザが行った操作の順序によって（そしておそらく他の要因によっても）、全く同じ書式設定から、異なるマークアップが得られることに私は気が付きました。この事実は必ずしも問題とはなりなりませんし、おそらくMicrosoft Wordの “.doc” フォーマットのようなバイナリ形式の文書にも同様に当てはまると思います。ただし、意味論的なレベルでの正規化が、XML構文レベルでの正規化ほど単純ではないのが、やや残念なことと言えるでしょう。

上に戻る

単純なものから始める：AbiWord

AbiWordは、外観やレイアウトをCSSのような属性で指定する比較的単純で明快なXML文書フォーマットを使っています。こうした属性の多くはCSSから直接引用されていますが、AbiWordの開発者達はCSSでは要求不足だと判断し、CSSを単なる出発点として捉えることにしたのです。

少し長いですが、作成したワープロ文書の全XMLソースをお見せしたいと思います。私はこのソースをきれいに整理しましたが、私が行った（Infosetに害を与えないような）変更は、再読込みに影響しないことを確認してあります。最初はAbiWordの場合です。

                
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE abiword PUBLIC "-//ABISOURCE//DTD AWML 1.0 Strict//EN"
"http://www.abisource.com/awml.dtd">
<abiword
fileformat="1.1"
props="dom-dir:ltr; lang:en-US"
styles="unlocked"
template="false"
version="2.0.3"
xml:space="preserve"
xmlns="http://www.abisource.com/awml.dtd"
xmlns:awml="http://www.abisource.com/awml.dtd"
xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:math="http://www.w3.org/1998/Math/MathML"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<metadata>
<m key="dc.format">application/x-abiword</m>
<m key="abiword.generator">AbiWord</m>
<m key="abiword.date_last_changed">Tue Feb 10 20:04:46 2004</m>
</metadata>
<styles>
<s followedby="Current Settings"
name="Normal"
props="text-indent:0in; margin-top:0pt; margin-left:0pt;
font-stretch:normal; line-height:1.0; text-align:left;
bgcolor:transparent; lang:en-US; dom-dir:ltr;
margin-bottom:0pt; text-decoration:none;
font-weight:normal; font-variant:normal; color:000000;
text-position:normal; font-size:12pt; margin-right:0pt;
font-style:normal; widows:2; font-family:Times New Roman"
type="P"/>
</styles>
<pagesize height="11.000000"
orientation="portrait"
page-scale="1.000000"
pagetype="Letter"
units="in"
width="8.500000"/>
<section props="page-margin-footer:0.5in; page-margin-header:0.5in">
<p style="Normal">Minimal document with <c
props="font-weight:bold">bold</c><c
props="font-weight:normal"> and </c><c
props="font-style:italic; font-weight:normal">italics</c><c
props="font-style:normal; font-weight:normal">.</c></p>
<p style="Normal"><c
props="font-style:normal; font-weight:normal"/></p>
<p style="Normal"><c
props="font-style:normal;
font-weight:normal">New paragraph with </c><c
props="font-weight:normal;
text-decoration:underline;
font-style:normal">underline</c><c
props="text-decoration:none;
font-weight:normal;
font-style:normal">.</c></p>
</section>
</abiword>

いくつか目に付く特徴があります。XMLがもたらす顕著な利点の一つは、他のグループが開発し、洗練された外部スキーマを示すために名前空間が使えるという点です。例えばMathMLやSVGを使うことで、数式や図形を含むことができます。こうした機能をAbiWordの開発者が自分達で開発し直す必要は全くないわけです。

AbiWordのフォーマットでもう一つ気が付くのは、段落の表現や文字（修飾）範囲の記述に、中途半端にXMLの属性を使っているという点です。つまり一部のXMLフォーマットでは、属性や（DTDで名前付けした）子タグの中に、可能性のある書式設定の全てを初めからリストしておこうとしますが、AbiWordではCSS形式の書式設定を含む汎用のprops属性を、単純に挿入しているだけなのです。これでは、意味体系の表現がXML Infosetの外に追いやられることになります（これが良いことなのか悪いことなのか、私にはよく分かりません）。

上に戻る

正式化の道をたどる：OASIS

Sun MicrosystemsがStarOfficeのために開発した（そしてOpenOffice.orgが採用した）XMLフォーマットは、OASIS技術委員会（参考文献参照）が担当しています。要するにこれは、単なる一つのフォーマットということではなく、標準となる道をたどっているということです。さらに、以前は独自のXMLフォーマットを使っていたKOfficeプロジェクトが最近、OpenOffice.orgのフォーマット（あるいはOASISによる幾つかの将来的な機能拡張を含んだフォーマット）をネイティブとして使う方向に進むことを決めています。ですからここでは、古いKOfficeフォーマットの詳細を説明するよりも、OASIS/OpenOffice.orgフォーマットを説明した方が有益だと思います。ただしこの記事の執筆時点では、KOfficeの現在の安定したバージョンでは、まだフォーマットを切り替えていませんでした。

AbiWordとは対照的にOpenOffice.orgのXMLフォーマットは、OpenOffice.orgアプリケーションがサポートするすべての文書形式、つまりワープロ文書だけではなく、グラフや図形描画など・・・を網羅しています。異なる形式のデータは、形式毎に名前空間で示され、同じ文書に複数のデータ・フォーマットが埋め込めるようになっています。あるアプリケーションが、与えられたデータ形式を扱うかどうか、またどのように扱うかはそのアプリケーションに依存します。ただし、アプリケーションによっては、与えられたデータ形式を描画するための制御を（同じ統合アプリ内か、あるいは完全に外部のアプリケーションの）別コンポーネントに渡すという場合もあります。

ここでは、図1に示した単純なワープロ文書にのみ注目しています。それを見てから、リスト1のAbiWord版とリスト2に示すOpenOffice.orgのXMLフォーマットとを比べてみてください。AbiWord版の場合と同様に、XMLをきれいに整えてありますが、Infosetは維持しています。また、AbiWord版の場合と同様ですが、この文書も実際には妥当性検証は行われません。この場合では、私がインストールしたOpenOffice.org（この文書を作成したものと同じもの）に含まれていたDTDには、dr3dとformとmath名前空間の属性が見あたりません。また、注目すべき文書の内容そのものは、リスト2にありますが、完全なOpenOffice.orgのデータファイルは、設定情報やメタデータ、スタイルなどの補助的なXML文書を含んだ”.zip”アーカイブです（通常は拡張子が”.sxw”になっています）。

                
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE office:document-content PUBLIC
"-//OpenOffice.org//DTD OfficeDocument 1.0//EN"
"office.dtd">
<office:document-content office:class="text" office:version="1.0"
xmlns:chart="http://openoffice.org/2000/chart"
xmlns:dr3d="http://openoffice.org/2000/dr3d"
xmlns:draw="http://openoffice.org/2000/drawing"

xmlns:form="http://openoffice.org/2000/form"
xmlns:math="http://www.w3.org/1998/Math/MathML"
xmlns:number="http://openoffice.org/2000/datastyle"
xmlns:office="http://openoffice.org/2000/office"
xmlns:script="http://openoffice.org/2000/script"
xmlns:style="http://openoffice.org/2000/style"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:table="http://openoffice.org/2000/table"
xmlns:text="http://openoffice.org/2000/text"
xmlns:xlink="http://www.w3.org/1999/xlink">
<office:script/>
<office:font-decls>
<style:font-decl fo:font-family=""
style:font-pitch="variable" style:name="F"/>
<style:font-decl fo:font-family="Mincho"
style:font-pitch="variable" style:name="Mincho"/>
<style:font-decl fo:font-family="Times"
style:font-family-generic="roman"
style:font-pitch="variable"
style:name="Times"/>
</office:font-decls>
<office:automatic-styles>
<style:style style:family="paragraph"
style:name="P1" style:parent-style-name="Standard">
<style:properties fo:font-style="normal"
fo:font-weight="normal"/>
</style:style>
<style:style style:family="text" style:name="T1">
<style:properties fo:font-weight="bold"/>
</style:style>
<style:style style:family="text" style:name="T2">
<style:properties fo:font-weight="normal"/>
</style:style>
<style:style style:family="text" style:name="T3">
<style:properties fo:font-style="italic" fo:font-weight="normal"/>
</style:style>
<style:style style:family="text" style:name="T4">
<style:properties fo:font-style="normal" fo:font-weight="normal"/>
</style:style>
<style:style style:family="text" style:name="T5">
<style:properties style:text-underline="single"
style:text-underline-color="font-color"/>
</style:style>
</office:automatic-styles>
<office:body>
<text:sequence-decls>
<text:sequence-decl
text:display-outline-level="0" text:name="Illustration"/>
<text:sequence-decl
text:display-outline-level="0" text:name="Table"/>
<text:sequence-decl
text:display-outline-level="0" text:name="Text"/>
<text:sequence-decl
text:display-outline-level="0" text:name="Drawing"/>
</text:sequence-decls>
<text:p
text:style-name="Standard">Minimal document with <text:span
text:style-name="T1">bold </text:span><text:span
text:style-name="T2">and </text:span><text:span
text:style-name="T3">italics</text:span><text:span
text:style-name="T4">.</text:span>
</text:p>
<text:p text:style-name="P1"/>
<text:p text:style-name="P1">New paragraph with <text:span
text:style-name="T5">underline</text:span>.</text:p>
</office:body>
</office:document-content>

OpenOffice.orgフォーマットも、大まかにはAbiWordフォーマットと似た構造になっています。AbiWordの<p> タグの代わりにOpenOffice.orgでは<text:p> を使い、AbiWordの<c> の代わりに<text:span> を使います。ここで目立った違いとして、AbiWordでは一連の文字をマークする場合に直接組み入れる形で書式設定の記述を行いますが、（アプリケーションによって、その場その場で生成され自動的に命名されたスタイルであっても）OpenOffice.orgでは常に名前付きスタイルへの間接参照を使うということです。

また、このサンプル文書は、上で説明した文書のInfosetに発生しがちな多少の揺れを示すものになっています。例えば、最初の段落の最後にあるピリオドは、スタイルT4としてマーク付けされていますが、最後の段落にあるピリオドが、どのspanにも含まれていないことに注意してください。さらに、リストの少し前にあるT4のスタイル定義を見てみると、これが標準（つまりデフォルト）の、font-styleとfont-weightを定義していることが分かるでしょう。つまりテキストを、そのテキストを囲む段落に対してPCDATAのままにしておくのであれば、T4スタイルでマーク付けする必要はないのです。

上に戻る

XML文書を処理する

ここで取り上げたワープロソフトで、XMLフォーマットを使う利点として重要なのは、それらの文書が新しいツールで扱い易くなるということです。XMLワープロ文書を処理する新しいアプリケーションを書く方が、バイナリ・フォーマット（特に独自仕様で公開されていないようなフォーマット）のワープロ文書を処理するアプリケーションを書くよりも、とにかく簡単です。RTF （Rich Text Format） も、ある程度までは同じ目標を達成していると言うことができます。RTFは、テキスト形式のマークアップ・フォーマットであり、資料も公開されています。ところが状況の進展に伴って、RTFパーサよりも、XMLパーサの方が有用で選択肢も広くなっているのです。

XMLのワープロ・フォーマットを処理するものとして明確に思い浮かぶのは、新しい文書処理アプリケーションです。例えば、KOffice (KWord) と OpenOffice.org (Writer) の間に透過的な互換性を持たせるようなアプリケーションが予想されます。ただ、もう少し規模の小さなアプリケーションのことも頭に置いておいた方が良いでしょう。索引付け、分析、要約、比較、あるいは文書のバッチ処理なども重宝することの多い機能です。

こうしたバッチ形式のアプリケーションの多くでは、処理言語としてXSLTがひときわ光彩を放っています。そして実際、既存の変換ルーチンでも、XSLTが頻繁に使われています。ただ、私自身はXSLTの推進者達とは違いXSLTをあまり好きではありません。XSLTは、宣言的であるという言語の目標に反して詳細が混乱を招きやすく、維持管理やデバッグも困難だと私は思っています。それはともかくとして、リスト3で紹介するのは、gnosis.xml.objectify Python XMLバインディング（このコラムで何度かとりあげました）を利用した、非常に単純なユーティリティです。ここで紹介するユーティリティは、（HTML文書ではなくOpenOffice.org Writerの文書を処理するという点を除けば）lynxでの-dumpオプションと似ています。私のこのユーティリティは、未完成ですが非常に簡潔であり、結果としてXMLの利点のいくつかを証明しています。

                
                
#!/usr/bin/env python

                
import sys, zipfile
from gnosis.xml.objectifyimport XML_Objectify, EXPAT, \
 children, tagname, content
XML_Objectify.expat_kwargs['nspace_sep'] = None
doc_content = zipfile.ZipFile(sys.argv[1]).read('content.xml')
doc = XML_Objectify(doc_content).make_instance()
write = sys.stdout.write
for oin children(doc.office_body):
if tagname(o)=="text_p":
for sin content(o):
if type(s)is unicodeand s.strip():
write(" "+s.encode('utf-8').strip())
elif tagname(s)=='text_span':
write(" "+s.PCDATA.encode('utf-8'))
write('\n')

このユーティリティは、必ずしも全てのOpenOffice.org の作成ファイルを素直に処理するわけではありません（ただし全てのテキスト内容は処理すると思います）。また段落での行の折り返しは行いませんが、この機能はPython 2.3+ のtextwrapモジュールを使うか、または外部ユーティリティfmtにパイプすることで容易に追加できます。例えば次のような感じです。

                
$ ./dumpOO.py simple.sxw | fmt
Minimal document with bold and italics .
New paragraph with underline .

上に戻る

まとめ

フリーソフトとXMLの文書フォーマットは、ごく自然な組み合わせです。XMLは元々読みやすいので交換が容易であり、またフォーマットの仕様化も容易です。また広範なXMLライブラリが入手可能なことから、新しいツールが簡単に作れるようになっています。さらにこうしたワープロ・フォーマットを見ることで、私は名前空間の持つモジュール性の利点を確認するのに本当に役立ちました。適切に行いさえすれば、個々の開発者から成る多くのグループが行っている作業の成果を、名前空間を用いることで活用することができるのです。

ただし、今のところ進んでいるのはXML自体のみです。例えばMicrosoftも将来のMS WordでXMLフォーマットを使う方向に進んでいます。ところがOASIS/OpenOffice.orgフォーマットやAbiWordフォーマットのオープン性に比べてMicrosoftは、そのフォーマットを特許申請することで取り囲み、フォーマットの差異についても秘密のベールで覆っているのです（しかも、それらを自己文書化（self-documenting）すると言うよりもむしろ、謎に満ちたタグや属性名を使っているのです）。

XMLそれ自体だけでは、本当の意味でオープンだと言うわけではありません。ただし幸いなことにKOfficeやAbiWordそれにOpenOffice.orgの開発者達は、XMLを使ってオープン性を達成するという面で、全体としては素晴らしい仕事をしたと言えるでしょう・・・もっともコミュニティ開発という管理されていない環境では、時折（DTDのように）インピーダンス・ミスマッチを起こしてはいますが・・・。

参考文献

• OpenOffice.orgを調べてみてください。OpenOffice.orgは、幾つかのフリーソフトウェア・ライセンスを取り混ぜてライセンスされています（すべてFSFとOSIに承認されています）。どのコンポーネントに興味を持っているかによって、PDL、GPL、LGPL、またはSISSLのどれかが適用されます。さらに、受け入れるライセンス条項に関して多少の選択肢もあります。このサイトでは、ライセンスの詳細だけではなく、このプロジェクト全体に関する情報も得ることができます。
  
  
• GPL （General Public License：一般公衆利用許諾）に基づいて入手可能なKOfficeプロジェクトの 一部であるKWord をダウンロードしてください。KOfficeコンポーネントが使用しているDTD一式 も入手可能です。
  
  
• KOfficeプロジェクトでは、2003 KOffice Developers' Meeting において、ネイティブのファイル・フォーマットとしてOASIS/OpenOffice.orgを使うように切り替える計画を発表しています。
  
  
• オープンでXMLベースのオフィス・アプリケーション用ファイル・フォーマット仕様を作るために、OASIS Technical Committee が組織されています。この仕様の基礎となっているのは、Sunが作成したStarOffice/OpenOffice.orgフォーマット仕様です。
  
  
• OpenOffice.orgのオフィス・スイート間における文書フォーマットの標準化について、このページで説明されていますので、読んでみてください。
  
  
• 専門的な技術文書を作成するのであれば、LyX アプリケーションの使用を検討してみてください。
  
  
• developerWorksのDeveloper Bookstore にはXML関連の書籍が豊富に揃っています。
  
  
• developerWorksのXMLゾーンには他にもXMLに関する資料が豊富に用意されています。
  
  
• XMLおよび関連技術においてIBM認証開発者になる方法についてはこちらを参照してください。
  
  

著者について

David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。

この記事を評価する

コメント

上に戻る

目次

• 文書フォーマットをテストする
• 単純なものから始める：AbiWord
• 正式化の道をたどる：OASIS
• XML文書を処理する
• まとめ
• 参考文献
• 著者について
• コメント