レベル: 初級 Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.
2006年 1月 31日
XMLの使用は広く普及しましたが、その大部分は整形式ではありません。整形式であっても、よい設計でないことが多く、処理や保守が非常に困難です。また、XMLを処理するインフラストラクチャーの多くはこれらの問題をさらに悪化させることがあります。これを受けて、Henri Sivonenの資料『HOWTO Avoid Being Called a Bozo When Producing XML』（XMLを作るときにマヌケと呼ばれないための方法）など、XMLのベスト・プラクティスについて世間で議論されるようになってきました。Uche Ogbujiは、IBM developerWorksでXMLのベスト・プラクティスについて再三述べていますが、今回のコラムではこれらの記事の要点に対する彼の意見を述べます。
私は数年前から、このコラムや他のシリーズでも、XMLベスト・プラクティスについて述べてきました。Elliotte Rusty Haroldなどの他のコラムニストもこの話題を取り上げています。XML設計原則の議論に加わるXMLエキスパートが多いほど、XMLを採用するあらゆるレベルの開発者のために堅実なアドバイスをまとめることができます。この記事では、最近の資料と従来からの資料を使って、XMLのベスト・プラクティスについて詳しく説明します。
マヌケ・ゾーンからの脱出
Henri Sivonenが有用な記事『HOWTO Avoid Being Called a Bozo When Producing XML』を書きました（「参考文献」参照）。彼は、RSSやAtomなど、XMLベースのWebフィード・フォーマットの考え方を採用して、名前空間付きの整形式XMLを生成する際の「すべきこと」と「すべきでないこと」を論じています。その序文で彼は次のように述べています。
XMLをプログラマティックに生成するときに整形式をきちんと守るのは、不可能ではないにしても非常に難しいと思っている開発者と、整形式をきちんと守ることができ、どうして他の人にそれができないのか不思議に思っている開発者がいるようです。誰も無能だと思われたくないし、悪口を言われたくないはずです。したがって、次の「すべきこと」と「すべきでないこと」のリストが、開発者が前者から後者になるために役立つのではないかと思います。
Henriの最初のアドバイスは、「XMLをテキスト形式と考えないこと」です。私は、これは危険なアドバイスだと思います。たしかに彼が言おうとしていることは正しいですし、XMLを単純なテキスト文書として生成したり編集するような軽率なことはみなさんもなさらないでしょう。ただし、これはどんな構造のどんなテキスト・フォーマットにも当てはまることです。ですが、XMLがテキストではないと言うことは、XMLの定義として仕様に含まれている、XMLの最も重要な特性の1つを否定することになります。（「（この仕様に準拠していれば）テキスト・オブジェクトは整形式のXML文書である。」）Henriのアドバイスは、XML内のテキストの技術的定義を、基本的にはXMLとして解釈される文字の並びとしている点でも混乱を招きます。テキストは、単にリーフ（葉）要素または属性に収まる、技術的に文字データと呼ばれるものではありません。テキストは、すべてのXML実体の基本的な骨組みであり、XMLはテキストではないと言うのは矛盾しています。開発者がすでになじんでいるテキスト・フォーマットとXMLの具体的な違いに焦点を当てた方がよいのではないかと思います。
このコメントは、Henriのアドバイスが、整形式のWebフィードを生成する際の問題に対する彼の興味を反映している一例です。文字列を無造作に放り投げて整形式になればいいと願うのは危険なやり方であることを人々に警告したという意味では、彼は正しいです。私も、XMLを生成するときには、単純なテキスト・ツールではなく、成熟したXMLツールキットを使用するようにアドバイスする記事を書いてきました（「参考文献」参照）。私が心配しているのは、Henriのこのアドバイスの表現方法が少々紛らわしく、XML処理をより広い意味で考えた場合に誤解される恐れがあるということです。彼は「テキスト・ベースのテンプレートを使用してはならない」と「プリントしてはならない」のセクションでアドバイスを繰り返しています。これは次のように要約できると思います。「結果が整形式XMLになるとわかっていないメカニズムを使用してはならない」。これは非常に重要なアドバイスです。XML生成を安全にするアプローチの1つは、Henriが「ツリーまたはスタック（またはXMLパーサー）を使用すること」で示唆しているように、SAXイベントを送信することです。ただし、こうしたからと言って安心してはいけません。使用するSAXツールによっては、必要な整形式チェックのすべてが行われないかもしれません。たとえば、一部のUnicode文字はXMLでは許されません。そのような問題に対処するには、さらに上のレベルのチェックが必要になるかもしれません。
Henriが正しく指摘しているように、ユーザーは名前空間を手作業で管理しようとすべきではありません。私がdeveloperWorksで説明してきたように、XML名前空間には細心の注意が必要です。開発者はユニバーサルな名前（名前空間のURI（Uniform Resource Identifier）＋ローカル名）だけを考えるべきであるという彼の忠告は、概ね正しいのですが、ときには、プレフィックスやXML宣言を扱わざるをえないこともあります。XSLTなどの仕様では、QName（プレフィックスとローカル名の組み合わせ）を属性値の中で使用することができ、プレフィックスはスコープ内の名前空間宣言に従って解釈されることになっています。この種のパターンを、「コンテキスト内のQName」といいます。この場合、開発者は宣言されたプレフィックスを制御できなければならず、さもなければ、XML処理は失敗します。開発者が独自の名前空間宣言を管理するとき、XML名前空間の複雑さのために、煩雑な結果になることが少なくありません。
XML処理のパイプラインで受け渡す際に煩雑になりがちな名前空間構文をクリーンアップする方法のひとつは、パイプラインの終わりに正規化ステップを挿入することです。XMLの正規化は、名前空間宣言のパターンなど、XML 1.0とXML名前空間で許される構文のばらつきをなくします。正規化によって、開発者を裏切る名前空間宣言の問題がすべてなくなるわけではありません。正規化は、文書内で使用されているプレフィックスを変更しないので、コンテキスト内のQName問題を解消するわけではありませんが、名前空間宣言の煩雑さを少なくして、問題の特定を容易にしたり、問題を自動的に修正するコードを作成できるようにします。Henriが取り上げているXML生成オプションの1つであるGenXライブラリーは、正規のXMLを自動的に生成しますし、他にも正規化をオプションとして備えているツールが色々あります。
Unicodeと文字の扱いに関するHenriのアドバイスは、ほぼ完璧です。ただし、「文字データにpretty-printingの空白を追加しないこと」というアドバイスについては、少し言い過ぎではないかと思います。pretty-printing XMLは、文字データを伴う要素内ではなく、要素間では、ほとんどの場合安全です。Henriが言うように、リスト1のようなXMLがあった場合、これをリスト2のように記述するのは、通常、安全ではありません。
リスト1. XMLサンプル
リスト2. 文字データに空白が追加されたXMLサンプル
しかし、リスト3のXMLをpretty-printするのは通常安全であり、出力はリスト4のようになります。
リスト3. もうひとつのXMLサンプル
<doc><foo>bar</foo></doc>
|
リスト4. リスト3の文字データに空白が追加されたXMLサンプル
<doc>
<foo>bar</foo>
</doc>
|
多くのXML直列化ツールでは、比較的安全なpretty-printingと比較的安全でないpretty-printingの違いが認識されています。リスト3と4に示されている形式のpretty-printingは、混合内容に空白が追加された場合に形が崩れる恐れがあることを理解しておくことが重要です。このような問題は、スキーマによって直列化を補うことで避けることができます。ただし、現実には、混合内容を使用するほとんどのボキャブラリーは、空白の正規化に対してあまり敏感ではないので、pretty-printingについてそれほど心配する必要はありません。このような問題があることを知っておくべきであり、pretty-printingを無効にするという選択肢もあることを心得ておくべきでしょう（デフォルトではpretty-printでないのが望ましい）。Henriは、リスト5のようなpretty-printingを推奨していますが、マークアップが見にくくなり、操作しにくくなるので、私は賛成できません。
リスト5. Henri Sivonenが推奨しているpretty-printing仕様（著者は推奨しない）
修道院から
大急ぎで、この記事で調べなければならない2つ目のリソースを見てみましょう。それは、Simon St. Laurentの「Monastic XML」です（「参考文献」参照）。これは、最大限の効果を挙げるためのXMLの処理方法と考え方に関するアドバイスを含んだ短いエッセーを集めたものです。Simonは修道院生活と修行のメタファーを用いて、単純なテキスト・ルーツにそぐわない重すぎる荷物を持たせてXMLをロードするのは危険だと示唆しています。「Marking-up at the foundation」（基礎でのマークアップ）で、彼は文字データとマークアップ（要素と属性）の基本的役割を論じています。「Naming things and reading names」（名前を付けることと名前を読み取ること）では、汎用識別子（要素タイプ名とも）が重要な概念である理由と、それをマークアップされる情報の構造体にとって単独の主キーとする方法を説明しています。現実に、XML名前空間を使用する場合、主キーはユニバーサル名（名前空間のURI＋ローカル名）であり、この複雑さが、Simonが「Namespaces as opportunity」（機会としての名前空間）で注意を呼びかけている理由のひとつです。「Accepting the discipline of trees」（ツリーの規律を受け入れる）では、XMLの暗い秘密のひとつに注意を促しています。すなわち、XMLの階層構造はグラフ構造に容易に拡張できるように見えますが、実際には、XMLでのグラフのモデリングは多少難しいことがわかっています。しかし、「Monastic XML」サイトの今までで最も重要な教訓は、「Optimizing markup for processing is always premature」（処理のためのマークアップの最適化は常に早熟」にあります。XMLは宣言型テクノロジーであり、そこに強みがあると同時に、多くの開発者にとってのフラストレーションともなっています。開発者がXML設計を処理の詳細にあまりに近づけようとすると、長い目で見ると、処理がいっそう困難になります。XMLでの成功の鍵は、情報を処理する必要があるシステムの技術的設計から切り離して抽象的に表現する必要がある情報の性質に焦点を当てることにあります。
まとめ
XMLのベスト・プラクティスを考える際、特に初期の段階では、ある程度の意見の相違は避けられませんが、多様な意見があるのは良いことです。このトピックについては、他にも見るべき資料がいくつかありますので、引き続き、このコラムで取り上げたいと思っています。ベスト・プラクティスに関するアドバイスの情報源をご存知の場合や、独自の意見をお持ちの場合は、Thinking XMLディスカッション・フォーラムのディスカッションに参加してください。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Uche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。 |
記事の評価
| 
