XML に関して知っておく必要のある、5 つの「すべきこと」と 5 つの「すべきでないこと」

XML を適切に使用する方法

XML は強力な技術ですが、誤った使い方をされる場合があります。この記事では、最も適切な方法で XML を使用するために従う必要のある 10 項目のルール、つまり基本的な「すべきこと」と「すべきでないこと」について掘り下げます。

ツールとしての XML

よく使われる頭文字語

  • CDATA: Character DATA
  • DOM: Document Object Model
  • E4X: ECMAScript for XML
  • IDE: Integrated Development Environment
  • W3C: World Wide Web Consortium
  • XML: Extensible Markup Language
  • XSLT: Extensible Stylesheet Language Transformations

最近では XML がごく当たり前のものとして考えられるようになっており、至るところで XML が使われています。しかし一歩下がって XML を見てみると、改めて XML が強力な技術であることがわかります。例えば IDE を使うことで XML ツリーを構築することができます。また、いくつかの妥当性検証技術を使えば、XML コードが妥当な XML であることを確実にすることもできます。XML を変換するための専用の言語 XSLT もあります。さらには言語の構文の中にでさえ、XML のサポートが直接組み込まれているほどです (ActionScript の E4X など)。

その一方で XML には問題もあります。XML は誤った使い方をされる場合や、質が悪い場合があります。具体的には、あまりにも複雑な場合や、十分な定義がされていない場合、そしてとにかく扱うのが大変な場合などがあります。では、この強力な技術をより有効に活用するためにはどうすればよいのでしょう。この記事では、使いやすい XML を作成するために「すべきこと」と「すべきでないこと」を具体的に 10 項目説明し、皆さんが XML を作成する上で適切な作業を行えるようにします。


ファイルの拡張子やルート・タグに「xml」を使用しないこと

XML コードが保存されたファイルが .xml 拡張子を持っている例を何度見たことがあるか、その数は数えきれないほどです。拡張子を .xml にするのはあまり意味がありません。そのようにしても、ファイルの内容を表示しただけではわからないことを伝えてくれるわけではありません。ファイルの内容を表示すれば、タグを見た瞬間、私にはそのファイルが XML であることがわかります。拡張子に .xml を使う代わりに、顧客にとって意味のある拡張子を使うようにしてください。また、拡張子に独特な名前を付けておけば、その拡張子を Google で検索することで (当然検索が行われ)、検索結果として、その XML ファイル・フォーマットのドキュメントやサンプルへのリンクが返されるはずです。

一部の XML で見られる問題として、ルート・タグが <xml> になっている場合があります。この場合も、<xml> では何も伝わりません。そのファイルの中に何があるのでしょう。そのファイルが連絡先リストであるなら、ルート・ノードを <contacts> にする必要があります。XML は人間が読んで理解できるものにしなければなりません。そのため、対象となるビジネスの問題に関係のあるタグ名や属性名を使うようにしてください。ルート・ノードが <contacts> であれば、その中に <contact> タグがあり、さらにその中に <name> タグがあり、<name> タグの中には <first><middle><last> などのタグが含まれている等々を想定することができます。


あまりにも汎用的な構成体や、言語に特有の構成体を使用しないこと

XML は永続化フォーマットです。そしてほとんどの言語にはデータ構造を XML に永続化する方法が用意されています。その XML が、同じ言語で作成されたプロセスでしか読み書きされないことが確実にわかっているのであれば問題ありませんが、そうしたことは稀です。アプリケーションの中でファイルに書き込みを行っている場合、ある時点でユーザーがそのファイルを読み取るか、あるいは別の言語で作成された何らかのアプリケーションがそのファイルを読み取ることになるはずです。

私が言いたいのは、言語に特有の構成体を XML から排除する必要がある、ということです。皆さんは 例えば <data type="NSDate">07-18-2010</data> という記述をどれほど見たことがあるでしょうか?NSDate とは何でしょうか?実は、NSDate はあるアプリケーションのプラットフォームでの日付用のクラス名なのです。ではプラットフォームや言語を別のものに切り換えた場合にはどうなるのでしょう?その場合には、”NSDate” が指定されているタグと新しいプラットフォームで想定される構成体との間で変換を行うレイヤーが必要になります。

言語特有の機能を XML から排除し、<date>…</date> のような単純なものを使う必要があります。そうすれば、人間が理解できる、わかりやすい XML になり、特定の言語やフレームワークに依存することもなくなります。

これと関連して学んでおくとよい、もう 1 つの重要なことは、あまりにも汎用的な XML にならないようにすることです。そうした XML の例として、リスト 1 を見てください。

リスト 1. 汎用的なノード・ツリー
<nodes>
    <node type="user">
        <node type="first">jack</node>
    </node>
</nodes>

これは何を意味するのでしょう?これがユーザー・リストであることは理解できますが、この XML は人間にとって読みやすいわけでも、容易に編集できるわけでもありません。さらに悪いことに、この XML を XSLT などのツールで使うことや、スキーマを使って妥当性検証することが非常に難しくなります。この XML は実際にはリスト 2 のようなものを意味しています。

リスト 2. 改善されたノード・ツリー
<users>
    <user>
        <first>jack</first>
    </user>
</users>

この方が適切だと思いませんか?この XML は、この XML が持っている意味を表しており、またこの XML が意味しているのは XML によって表現されているとおりの内容です。この形式であれば、読みやすく、構文解析も容易です。妥当性検証や、XSLT を使った変換も容易に行えます。しかもサイズも小さくなっています。


ファイルを大きくしすぎないこと

皆さんが言おうとすることはわかっています。「ディスク・スペースは安価で確保することができます。10 セントで、さらに 1 テラバイトを得ることができます」。確かにそのとおりです。そしてもちろん、何ギガバイトもの XML ファイルを作ることは可能ですが、プログラミングはトレードオフです。ディスク・スペースを大量に使えば時間を節約することができますし、メモリーを大量に使っても時間を節約することができます。しかし XML ファイルが巨大な場合には、すべてが最悪の状態になります。ファイルはドライブ上で大きな場所を占め、構文解析にも妥当性検証にも長い時間がかかります。また、ファイルが大きい場合には DOM ベースのパーサーを使うことができません。DOM ベースのパーサーではツリーを構築するために、非常に長い時間と大量のメモリーが必要になるからです。

では、巨大なファイルに代わる手段は何でしょう?1 つの可能性として、複数のファイルを作成する方法があります。この方法では、インデックスとして機能させる 1 つのファイルとその他のファイルに分けます。大量のリソースを使用するその他のファイルは、XML を利用するクライアントによってすべてが使われるとは限りません。もう 1 つの可能性として、そのファイルの中にある大きな CDATA セクションをすべて XML の外に出し、独自フォーマットの独自ファイルに入れる方法があります。すべてのデータを一緒にまとめておく必要がある場合には、すべてのファイルを圧縮し、新しい拡張子を持つ新しいファイルに入れます。よく使われている言語には、ファイルを手軽に圧縮、解凍するためのモジュールが必ず用意されています。


必要がない限り名前空間を使わないこと

名前空間は XML 語彙のなかでも強力な部分です。名前空間を利用することで、拡張可能なファイル・フォーマットが容易に得られます。アプリケーションに必要な任意のものに対して基本のタグ・セットを定義することができ、また顧客はそのファイルに独自のデータを追加することができます。独自のデータは独自の名前空間に置かれ、ツリーに影響を与えることはありません。

とは言うものの、名前空間を使用すると、データの構文解析や管理が非常に困難になったり、E4X などの言語拡張を使用する場合に混乱を招くことになったりします。さらには XSLT で XML を使うことが難しくなったり、XML が非常に読みにくくなったりもします。

そのため、どうしても必要な場合にのみ XML の名前空間を使うようにしてください。「XML では名前空間を使うのが当然」という理由で名前空間を使ってはなりません。名前空間を使わなくても、XML はまったく問題なく機能するのです。


特殊文字を使用しないこと

これらの「すべきこと」と「すべきでないこと」の要点は、XML を簡潔かつ単純で理解しやすいものにする、ということです。その精神に従い、たとえ XML の仕様で多くのことが許されていても、必ずしもそれらを使う必要はありません。例えば、要素名や属性名にダッシュを使う場合があるかもしれません。しかしダッシュを使うと、その XML を E4X などの言語拡張で使うことが非常に難しくなります。ポイントは、ダッシュを使う価値はあるのか、という点です。

要素名や属性名には特殊文字を使わないようにすることをお勧めします。


積極的に XML スキーマを使うこと

XML の構文解析は簡単ではありません。XML の構文解析を正常に行うためには、タグや属性を検索するコードを保護する必要があります。そのコードは対象のタグや属性を見つけられない場合もあり、見つけられない場合にはグレースフルに終了する必要があります。こうしたことを確実にするには多大な作業を伴います。つまり、コードを追加する必要が出てきて複雑さが増すため、本来の焦点である真のビジネス・ロジックが明確でなくなります。では、どうすればこうした事態を避けられるのでしょう。それには XML を使用するに、XML の妥当性検証を行えばよいのです。そのための標準がいくつかあります。DTD (Document Type Definition) を指定することも、XML Schema を指定することもできます (DTD と XML Schema については「参考文献」を参照)。私は個人的に XML Schema の方がはるかに扱いやすいと思っていますが、XML Schema が初めての人は、他にいくつかある妥当性検証システムを試してみることをお勧めします。

この場合の大きなメリットは、妥当性検証を行った XML を信頼できるようになるという点です。アプリケーションが内部で読み取りも書き込みも行う XML に対しては、妥当性検証をする価値はないかもしれません。しかし他のアプリケーションによって XML が生成される場合や、手動で XML が生成される場合には、妥当性検証は非常に有効です。


積極的にバージョン番号を使うこと

ファイルに保存された XML はファイル・フォーマットを表しているという事実は見過ごされがちです。どのようなフォーマットの場合にも言えることですが、ファイルには何よりもまず、ファイルのバージョン番号が含まれていなければなりません。ファイルに <customers version="1">...</customers> のような記述を追加するのはとても簡単です。また、そのファイルを読み取るコードは、バージョン番号が最新バージョンまたはそれより前のバージョンであることを確認し、それ以外のバージョンの場合には例外をスローする必要があります。その確認をすることで、そのコードの将来のバージョンで新しいタグが使われても古いバージョンのコードに混乱が生じることはありません。もちろん、アプリケーションの開発を継続する中で、そのファイルの古いバージョンをすべてサポートする必要があります。


積極的にノードと属性の組み合わせを使うこと

エンジニアは非常に怠惰です。なぜ私がそう言うかというと、私自身が怠惰だからです。しかし結局のところ、私たちは皆、怠惰なのです。フレームワークが私たちに代わって XML をエクスポートしてくれる場合、私たちは「それで十分」と思いがちです。しかしフレームワークによって作成された XML はかなりひどいことがほとんどです。例えば、リスト 3 のようなものが作成されることがよくあります。

リスト 3. ユーザー・リスト
<users>
    <user>
        <id>1</id>
        <first>jack</first>
    </user>
</users>

この場合の <id> は本当にタグでなければならないのでしょうか?<id> は属性であるべきだと私は思います。このリストは短く、何らかの単純な XPath (例えば /users/user[@id=1]) を使うことで id によってユーザーを検索できるようにするのが妥当です。

このファイルを人間が読んで理解できるファイルにするためには、属性を適切に使う必要があります (リスト 4)。

リスト 4. 適切なユーザー・リスト
<users>
    <user id="1">
        <first>jack</first>
    </user>
</users>

なぜフレームワークによってリスト 3 が生成されるのか、私は理由を知っています。常にノードを使った方が安全だからです。しかし属性を使用すれば DOM ツリーに含まれる重要な要素を特定することができるので、属性を使用すべきなのです。


CDATA を使うこと、ただし使いすぎないこと

XML は特定の文字 (引用符、アンパサンド、小なり記号、大なり記号、その他の文字) に多くの制約を課しています。しかし実際には、私たちはこれらの文字を大量に使用します。そのため、すべての文字を XML で使っても安全なエンコーディングに変換するか、あるいはテキストやコードなどの広い範囲を CDATA ブロックに入れる必要があります。開発者が CDATA を避ける理由は、CDATA によって構文解析が難しくなると考えるからではないかと思います。しかし CDATA セクションの構文解析は他の部分の構文解析と比べて難しいということはなく、またほとんどの DOM パーサーでは CDATA セクションを単純にフラットにするため、CDATA 構文解析についてあれこれ考える必要はありません。

CDATA を使うもう 1 つの重要な理由は、CDATA によってデータのフォーマットを正確に保持することができるからです。例えばウィキのページをエクスポートする場合、ウィキのフォーマットでは行頭復帰や改行などの文字が特に重要であるため、これらの文字の位置を正確に維持する必要があります。

では、なぜ CDATA を常に使うようにしないのでしょうか?それは CDATA を使うと文書が非常に読みにくくなるからです。また CDATA が不必要な場合に CDATA が使われていると、特に苛立たしい思いをさせられます。そのため、特殊文字が含まれると思われるデータや、フォーマットを維持したい場合には CDATA を使うようにし、また XML フォーマットに書き込む人々に対して CDATA の使用を推奨してください。しかしそうした場合以外では、CDATA を使うべきではありません。


オプション・データは必ずオプション領域に保持すること

ここまでは、厳密にフォーマット設定された XML 文書について説明してきました。さらには、厳密な構造を強制する XML Schema などのバリデーターを使うことさえ推奨しました。そこには十分な理由があります。つまり構造化されたデータは構文解析が容易なのです。しかし、多少の柔軟性が必要な場合にはどうすればよいのでしょう。私が推奨する方法は、オプション・データはオプション・ブロックの中にある独自のノード内に格納する方法です。例えばリスト 5 を見てください。

リスト 5. 乱雑なユーザー・レコード
<users>
    <user id="1">
        <first>jack</first>
        <middle>d</middle>
        <last>herrington</last>
        <runningpace>8:00</runningpace>
    </user>
</users>

このレコードには、ユーザーの名前に関して想定されるすべてのデータに加え、余分なものが少し含まれています。つまり、<first> (名前)、<middle> (ミドルネーム)、<last> (苗字) がありますが、なぜ <runningpace> (ランニング・ペース) があるのでしょう。<runningpace> は必要なのでしょうか。これらのフィールドは大量にあるのでしょうか。<runningpace> は拡張可能なのでしょうか。これらに対する答えがすべて「イエス」であるなら、私はリスト 6 のようにすることを推奨します。

リスト 6. 適切な構造のユーザー・レコード
<users>
    <user id="1">
        <first>jack</first>
        <middle>d</middle>
        <last>herrington</last>
        <userdata>
        <field name="runningpace">8:00</field>
        </userdata>
    </user>
</users>

こうすることで、いくつでもフィールドを持つことができますが、それらのフィールドによってホスト要素 <user> の名前空間が乱雑になることはありません。さらには、この文書を妥当性検証することもでき、また指定されたフィールドを XPath を使って参照することもできます (//user/userdata/field[@name='runningpace')。


まとめ

この記事では XML に関して考慮すべき多くの事項を説明しました。「すべきでない」5 つの事項を取り上げ、その後でさらに、「すべきこと」として推奨の 5 つの事項を取り上げました。すべての事項がすべての状況に当てはまるわけではありません。場合によると XML は単なる永続化フォーマットであり、ネットワーク上に送信され、存続時間が数ミリ秒にすぎないこともあります。その場合には、XML について気にする人はいません。しかし XML をファイル・フォーマットのように使う場合には、XML をファイル・フォーマットとして扱う必要があり、この記事で概説したベスト・プラクティスの多くを活用する必要があります。

参考文献

学ぶために

  • 「言語の法律家」であれば、W3C の XML 仕様を調べる必要があります。このサイトで「言語の法律家」になり、XML の詳細を掘り下げてください。XML は大規模な電子出版用に設計された単純で非常に柔軟なテキスト・フォーマットであり、Web や至るところでデータ交換に重要な役割を担っています。
  • ウィキペディアで Document Type Definition の項目を見てください。SGML ファミリーのマークアップ言語 (SGML、XML、HTML) の文書型を定義する一連のマークアップ宣言、DTD の詳細が解説されています。
  • ウィキペディアで XML スキーマの項目を見てください。一種の XML 文書である XML スキーマが簡単に解説されています。XML スキーマにより、そのスキーマ・タイプの文書の構造と内容を制約することができます。
  • W3C の XSLT 仕様を読み、XML を多様なフォーマットに変換するための優れた手段について学んでください。
  • W3C の XPath 仕様を読み、最も複雑な XML 文書の中でさえノードを素早く簡単に見つけることができる、非常に貴重な XML ツールを試してみてください。
  • Actionscript 用 E4X 拡張 (ECMAScript) について調べてください。E4X はアプリケーション・ロジックに XML を直接統合するための非常に優れた方法です。E4X によって非常に容易に XML を統合できるため、E4X はほとんど XML でデファクトのオープン・ストレージ・フォーマットになっています。(ウィキペディア)
  • この記事の著者による他の記事として、Ajax、JSON、PHP、XML その他の技術に関する記事を読んでください (Jack Herrington 著、developerWorks、2005年3月から現在まで)。
  • developerWorks の XML ゾーンには XML のスキルを磨くためのリソースが豊富に用意されています。
  • My developerWorks で developerWorks のエクスペリエンスをパーソナライズしてください。
  • XML および関連技術において IBM 認定技術者になる方法を IBM XML certification で参照してください。
  • developerWorks の XML ゾーンを XML の技術ライブラリーとして利用してください。広範な話題を網羅した技術記事やヒント、チュートリアル、技術標準、IBM Redbooks などが用意されています。また、XML に関するヒントについても読んでください。
  • developerWorks の Technical events and webcasts で最新情報を入手してください。
  • 今すぐ Twitter に参加して developerWorks のツイートをフォローしてください。
  • developerWorks podcasts でソフトウェア開発者のための興味深いインタビューや議論を聞いてください。
  • developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=617692
ArticleTitle=XML に関して知っておく必要のある、5 つの「すべきこと」と 5 つの「すべきでないこと」
publish-date=12072010