レベル: 中級 Peter Seebach (dw-xml@seebs.net), Writer, Freelance
2008年 2月 19日 OOXML の仕様は、数多くの人から非難されると同時に擁護されてもいます。そのため多くの人は、一体何を大騒ぎしているのかと不思議に思っています。この記事では、OOXML を標準として扱うことに対して、政治的ではなく技術的に反対する根拠を説明します。
私は長年、標準化に積極的に携わってきました (その中には、ISO C 標準化委員会でのボランティアとしての約 10 年の作業も含まれています)。標準化に関心を持つ人達の大部分は、Microsoft® から提案されている XML ベースの文書フォーマットである OOXML (Office Open XML) の標準化プロセスに対して、おそらく何らかの意見を持っているはずです。私は通常、記事を書く際に自分自身のことから書き始めることはないのですが、最近、IBM® が OOXML の標準化を妨げようとしている、という噂があることから、最初に 1 つのことを明確にしておきたいと思います。それは、私は IBM の従業員ではなく、この記事で書くことは私自身の意見であり、私がこうした意見を持つに至ったのはこの問題に関する IBM の立場とは関係がないということです。
OOXML 標準には、いくつかの理由から大きな問題があります。実際、OOXML に関するプロセスの政治的な内容について誰を批判するにせよ、この標準化プロセスには政治的な策略が満ちています (「参考文献」を参照)。しかしそうした政治的な動き以上に、標準として XML が適切な選択肢なのかといった疑問から標準化の目的は何かという疑問に至るまで、広範囲にわたる深刻な技術的疑問が存在します。そうしたニュース報道や議論は、私にとっては標準がなぜ重要なのかを声を大にして語るための良い機会です。
標準の目的は何か
標準は、相互運用を実現するためにあります。私のワード・プロセッサーと皆さんのワード・プロセッサーがどちらも同じファイルを開けるなら、私は皆さんと容易に文書を共有することができます。もしそうでなかったら、私達は問題を抱えることになります。これが何を意味するかと言えば、もし標準がなければ、共通文書フォーマットがないことによる問題を回避するために、信じられないほどの時間と努力を費やさなければならないということです。ワード・プロセッサーのベンダー達は信じられないほどの時間と努力を費やし、お互いの文書フォーマットをリバース・エンジニアリングしなければなりません。そうすることによってようやく、それぞれのワード・プロセッサーでファイルをインポート、エクスポートして単純に文書を開きさえすれば、保存されたときとほぼ同じ状態でその文書が表示されるようになります。
標準によってほとんどすべての人が利益を受けることは、ごく自明のことです。ただし文書フォーマットに関して、ほぼ確実な 1 つの例外が、その業界で支配的な地位にある会社の場合です。実際のところ、そうした会社にとっては標準がない方が有利です。なぜなら彼ら独自のフォーマットをデファクト・スタンダードとして強制できるかもしれないからです。彼らは競争力の面で二重に有利になります。つまりその会社のフォーマットをサポートするために、その会社以外のすべての人たちは余分な時間と費用を費やす必要がありますが、そうして行われたサポートもその支配的な地位にある会社によるサポートほど適切にはなり得ないからです。
標準というものの定義から、優れた交換標準はすべてのベンダーによるすべての動作を規定するわけではない、ということを理解することが重要です。すべてのベンダーは標準のすべての機能をサポートする必要があり、それはつまり標準に追加されるすべての機能は複数のベンダーによって再現されなければならないということを意味します。標準フォーマットの文書の中に組み入れることのできない拡張機能や追加機能については、単にそれらの機能をサポートしてもよいとしておくだけの方が適切なのです。私はユーザーとして、仕様が非常に詳細で複雑なため完全に同じ動作を提供できる会社が 2 社とはない状態よりも、標準文書は確実にどこでも同じように機能するものと想定できた方がよいと思っています。
オフィス文書フォーマットの標準化に対する要求は非常に強いものがあります。さまざまな会社からさまざまな政府に至るまで、多くの組織が、文書の保存に関するオープン・スタンダードのサポートをソフトウェアに要求するルールを策定しています。誰も 1 社のベンダーに独占される状況は望んでおらず、その状況から脱却する道を提供してくれるのが標準なのです。それでは、そうしたことを念頭において、Microsoft が提案する OOXML 標準に関する技術的な疑問を調べてみましょう。
OOXML 標準
ECMA から入手できる OOXML 標準は PDF 文書のセットとして配布されており、全体で約 6000 ページあります。これは大規模な仕様であり、広範かつ詳細にまでわたっています。この仕様がこれほど大規模な理由は単純です。OOXML は実質的に、Microsoft Office アプリケーションがファイルに保存する可能性のある、あらゆる種類のデータ・チャンクの完全な複製なのです。
OOXML に関しては、いくつかの技術的なクレームが上がっています。そうしたクレームはどれも、煎じ詰めれば同じ基本的な内容に行き着きます。つまり OOXML は妥当な共通交換フォーマットを規定するのではなく、バグの適合性に至るまで Microsoft Office の機能セット全体を規定しているのです。このため Microsoft Office 以外の実装者にとっては、OOXML 標準を満たすのは実情にそぐわない (そして満たすことは実際には不可能な) 大きな負担となる一方で、Microsoft が既に出荷しているものには都合良く完全に一致しています。これは大きな懸念事項です。
この意見を、Microsoft が先行していることに対する単なる不満だと誤解しないでください。もし Microsoft の提案が、Microsoft が既に実装した、また誰もが適切に実装できる、小規模で適切に設計された標準であったなら、おそらくあまり大騒ぎにならずに受け入れられたでしょう。致命的な問題は大きく 3 つのカテゴリーに分けられます。つまり不合理なほど実装が困難な機能、不適切な仕様しか提供されていない機能、そして完全に Microsoft Office 固有の機能、という 3 つです。これらのカテゴリーは一部重複する部分もありますが、それぞれが標準として受け入れられるのを妨げている異なる種類の障壁となっています。
不合理な要求
従来、標準では、実装者が解決することが要求される問題は適切に定義され、また範囲が規定されています。例えば、段落の配置方法を十何種類か実装するように要求されるかもしれませんが、どの配置方法も明確に規定され、また適用範囲は合理的に制限されています。一方、OOXML が課す要求はまったく制限がないものです。一例を挙げると、ページのヘッダーを記述する際、提案されている仕様では「フォント名とフォント・タイプは共に、ローカライズされた値にすることが可能である」とされています。この一見単純な文 (この文を指摘したのは Stéphane Rodriguez です。「参考文献」を参照) によって、膨大な数のバグが発生してしまうのです。
ロケールには何を使えるのでしょう。この仕様を実装した他の任意のベンダーが使用している可能性のある、すべてのロケールの完全なリストはあるのでしょうか。また、フォント名やフォント・タイプをローカライズするために選択できる、すべての方法の完全なリストがあるのでしょうか。もし、ある熱狂的な実装者が、皆さんが実装した時点では聞いたこともなかった言語でフォント名とフォント・タイプを選択したらどうするのでしょう。
おそらくこれは、ユーザーに対して表示されたローカライズ値、あるいはユーザーが選択したローカライズ値を保存するという、過去に行ってきた判断を反映しているのです。残念ながら、さらに大量に仕様を提供しない限り (少なくとも、許可されるロケールの完全なリストと、どのロケールが使用されているかを示すための何らかの方法を規定しない限り)、これを実装することは不可能です。この仕様は、特定の実装で行ってきた奇妙な動作を反映したものであり、複数の実装の間で共有される標準フォーマットとしては適切な選択肢ではありません。
不適切な仕様
一部の Microsoft Office 文書は VML と呼ばれるベクトル･マークアップ言語による図を使用するため、OOXML はこれらの図の保存方法を規定しています。これはつまり、OOXML を実装する場合には必ずこれらの図を読み取れるようにしなければならないことを意味します。しかし、あいにく VML による図を読み取るための実際の仕様は提供されていません。特定の項目の内部にストリングとして VML 形状が見つけられるのみです。
許容される値は、正確にはどんな値なのでしょう。その質問には、「この属性が取り得る値は XML Schema のストリング・データ型によって定義されます。」という十分明確な答えがあります。つまり、それはストリングだということです。ストリングは任意のテキストを含むことができ、そのテキストが意味する内容は VML ライブラリーのコードによってしか答えることができません。要するに、たまたまそこらへんに転がっている VML ライブラリーを入手できるのでない限り、これは実装できないのです。
これも、歴史的な経緯による奇妙な動作です。交換のために設計される標準では、描画のための (そしておそらく唯一の) フォーマットを完全に規定し、そしてもし実装者が別の描画ライブラリーを持っている場合には、その実装者は図を標準フォーマットにエクスポートすることが求められます。OOXML はそうした方法をとらず、単に初期の設計の要約を提供し (しかもその設計は他の人が入手できない仕組みになっています)、他の全員がそれを採用することを想定しているのです。
固有の機能
この最後のカテゴリーは、標準化に関する多くのエキスパートが最も憤りを感じる部分です。これは実装が難しいからではなく (不可能以上に困難な実装というものはありません)、元々仕様の中にあってはならないものだからです。このカテゴリーに含まれる機能は、何らかの面で完全に Microsoft Office に依存しています。
おそらく最も有名な例は、OOXML の中に提供されているオプション設定の 1 つでしょう。この設定は「useWord97LineBreakRules」と呼ばれ、東アジア文書用の Word '97 で使われていた改行ルールの使い方を規定しています。これまでに挙げた例とほとんど同じように、これらの改行ルールの仕様は何も提供されていないため、当然ながら他の誰もこの仕様を実装することはできません。実際、OOXML 標準には、これを実装しないように実装者に警告する記述まで含まれています。
リスト 1. OOXML 標準の useWord97LineBreakRules に関する指針
「指針: この動作を忠実に再現するためには、アプリケーションは、(その) アプリケーションの動作を模倣する必要がありますが、(その) アプリケーションに考えられる動作は多岐にわたり、従ってその動作をこの Office Open XML Standard の中に忠実に記述することは不可能です。アプリケーションにこれと同じ動作をさせたい場合には、(その) アプリケーション群の出力を利用し、また複製する必要がありますが、この動作は出力に問題があるため非推奨とされており、また (その) アプリケーションを使って作成された既存の文書との互換性を保つという目的でのみ維持されるものであるため、アプリケーションがこの動作を意図的に複製しないようにすることをお薦めします。指針終わり」
これは素晴らしい指針です。この機能の仕様はないこと、またこの機能は非推奨であるため、どう考えてもこの機能を実装しない方が得策なのです。しかし待ってください。もし実装すべきでないなら、なぜそうした規定が仕様の中にあるのでしょう。既存の文書との互換性を保つ必要があるからと言って、データの交換を目的とする標準に機能を追加してよいことにはなりません。ユーザーは彼らのテキストが別のプログラムで開けるかどうかに関心を持つのであり、すべての改行が正確に同じ位置にあるかどうかに関心を持つわけではありません。
この機能が OOXML 仕様の中にある理由は、OOXML が文書交換のフォーマットではないためです。OOXML は、Microsoft の歴史的なバイナリー・フォーマットを注意深く、1 ビットも例外なく不等号括弧の中に複製したものなのです。
これは XML が不適切な選択肢という意味なのか
一部の IT 専門家達は、OOXML に関するいくつかのクレームを読んだ後、標準化のための選択肢として XML が不適切であるという考えを持つようになりました。私はそうした判断は好意的に見ても早計であり、実際にはその判断は単純に誤りだと思います。OOXML の問題は XML によって起きているわけではありません。問題は、既存のプログラムの後方互換性の残骸や奇妙な動作をすべて忠実に複製するということから起きているのであり、複数のアプリケーションの間で共有され、交換されることを意図した汎用的な文書の構造と内容を規定することによって起きているのではないからです。
汎用的な文書の構造と内容の規定は、XML を使えば非常に適切に行うことができます。OOXML にとって明らかな競合相手は、やはり XML の標準である ODF (Open Document Format) です。ODF は、決して取るに足らない標準でも、規模の小さな標準でもありません。ODF のバージョン 1.1 は 738 ページの文書であり、しかも ODF を作成しているグループは、バージョン 1.1 が完全であるとも最終的なものとも考えていません。例えば、スプレッドシートに使われる Formula 言語は定義されていません (ただし提案されているバージョン 1.2 標準に含まれるように作業が行われています)。いずれにせよ、ODF の仕様を見てわかることは、ODF 仕様がモノリシック構造のレガシー・アプリケーションの動作を記述しようとするのではなく、文書の内容を記述しようとしていることです。
XML の目的は、どのように文書の内容を記述したいのかを明確に表せるようにすることです。ODF の記述はまだ完全ではありませんが、少なくとも、やがて完全なものになることは十分に予測することができます。
まとめ
XML は新しいファイル・フォーマットを定義するための強力で表現力に富んだツールですが、プロジェクトのスコープの選択が不適切という問題を解決してくれるわけではありません。もし、大規模で文書化されていない独自の描画ライブラリーが使われていることをフラグで指定するファイル・フォーマットを作ることにした場合、文書化されていないバイナリー・ストリングの 1 ビットを使ってフラグを指定するのか、あるいは不等号括弧で一杯の 3 ページを使ってフラグを指定するのかはまったく重要ではありません。というのも、この仕様は独自仕様であるため、この仕様以外の方法で (単に XML の中にラッピングすることなどによって) 描画する方法なないのです。
XML は広範な種類のファイル・フォーマットに対して一貫性のある標準化された構文解析機能を提供できる能力を備えていますが、OOXML の欠点に対する非難の一部を XML が受けていることは残念なことです。OOXML は 6000 ページにもなり、特定のワード・プロセッサーが現在行うことのみならず、そのワード・プロセッサーがかつて行っていたことの多くも記述しており、その一部は規定されていると言うよりも遠回しに言及されているにすぎません。OOXML を実装しようという試みについて効果的に説明することは可能ではありますが、そうすることは基礎となっている XML 標準の堅牢さを高く評価していると見なされることになります。
OOXML を作成する作業は、現実的な問題を解決するための確かな取り組みです。その問題というのは、(10 年間にわたって蓄積された動作をコードにした) まったく内容のわからないバイナリー・ファイルを、部分的に読み取り可能な (最後のビットに至るまでそのバイナリー・ファイルと同じ動作をするコードにした) XML ファイルで置き換えるにはどうするか、という問題です。しかしこの問題は残念ながら、オフィス文書の交換フォーマットとして、使用に適した、実装可能なフォーマットを提供することに関する問題ではありません。
もしMicrosoft が OOXML を文書標準に対する提案として真剣に受け取って欲しいと望むなら、選択肢は 1 つしかありません。
OOXML の仕様に、Microsoft Office のすべてのバージョンのありとあらゆる機能を含めようとしたり、一部の文書で使っている可能性のあるすべてのフラグや奇妙な動作などを含めようとしたりするのではなく、もっと小規模で最低限の、交換可能なフォーマットを作成することに焦点を絞り、そのフォーマットの中ですべてが実装可能な形で記述されたコア機能を提供することです。単にスプレッドシートのデータや式をコピーしたいだけの人達に対して、例えば Excel® の計算チェーンなど、実装による奇妙な動作を公開してはいけません。VML ライブラリーや DrawingML ライブラリー、あるいはそれらに類するものの詳細は公開してはならず、それらに言及すらしてはいけません。それよりもむしろ、まったく新しい、オープンで完全に規定された、データを記述するための方法を提供する必要があります。
かつて私が XML に関して「Standards and specs: XML: Half a standard is better than none」という記事を執筆した際、私はそれほど深く考えずに「<bytes>ff ff 00 03 [. . .]</bytes>」を含む XML フォーマットの例を挙げました。その時には冗談のつもりだったのですが、どうやら冗談にはならなかったようです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Peter Seebach は長年にわたって標準化に関心を持っており、約 10 年間ボランティアとして ISO C 委員会で作業を行いました。彼はここ数年、文書交換フォーマットとして XML を使用しています。 |
記事の評価
| 
