技術解説 Office 2003のXMLスキーマ・サポートがもたらすインパクト コラム：スキーマの役割とは Greg DeMichillie 2003/10/03 Copyright (C) 2003, Redmond Communications Inc. and Mediaselect Inc.

---

　スキーマとは従来、リレーショナル・データベースのテーブルや列など、データの順番や構造を定義したもののことだ。だが、この用語は、XMLも含め、組織化されたあらゆるデータの集合に適用できる。実際、XMLスキーマはXMLベースのアプリケーションを構築、運用する際の中心となる要素だ。

スキーマ：XMLデータのルール

　XMLデータ・フィールドは、HTMLマークアップと同様、かぎ括弧のタグでくくられたテキスト（要素と呼ばれる）で構成される。XMLスキーマは、任意のデータ・セットにどのような要素を含めるべきかを定義した文書だ。そのため、スキーマでは以下のような情報を記述する必要がある。

• 要素の名前と種類

• 必要な要素とオプショナルの要素

• 繰り返せる要素と一度しか使えない要素

　例えば、経費報告書用のXMLスキーマであれば、従業員の氏名、目的地、出張日程の要素のほか、オプションで従業員がメモを記入するための要素を加え、特定の経費項目については繰り返し出現する要素を指定することになる。

　XMLスキーマは、World Wide Web Consortium（W3C）が定義したXML Schemaと呼ばれるXSD（XMLスキーマ定義言語）で記述される。XSDファイルはそれ自身がXMLファイルであるため、別個に特別なスキーマ構文解析プログラムを用意する必要がなく、その分、開発は簡略化される。

スキーマの用途

　スキーマはXMLアプリケーションにおいて重要な役割を果たす。スキーマがあれば、IT開発者が追加のコーディングを行わなくても、アプリケーションに重要なタスクを実行させられるからだ。そうした重要なタスクとしては、以下のような項目が考えられる。

●妥当性の検証
　あらゆるXML処理において重要となるのは、処理中のデータが正しくフォーマットされていることを確認するステップだ。つまり、XMLの妥当性を検証することだ。XMLスキーマを使えば、特定のXMLデータ・セットが「ルールに従っているか」をアプリケーションが自動的に判断できる。スキーマがなければ、開発者は受け取るXMLデータの妥当性を検証するコードを手作業で書かなければならなかっただろう。

●ユーザー・インターフェースの調整
　Officeのようなエンド・ユーザー向けのアプリケーションは、技術的な詳細を隠し、XMLデータの存在をできる限り透過的なものにしなければならない。そのための方法の1つが、XMLスキーマをベースにユーザー・インターフェースを調整するというものだ。たとえば、Excelでは、スキーマに繰り返しの要素が見つかった場合には、そうした繰り返しの要素を入力するためのシンプルなユーザー・インターフェースが自動的に提供されるようになっている。

スキーマの作成は大変な作業

　エンド・ユーザーのXML体験はXMLスキーマを選択した時点で始まることになるが、そのスキーマ自体は「棚ぼた」のように簡単に完成するわけではない。エンド・ユーザーがドラッグ＆ドロップでXML機能を利用できるようになるまでには、カスタム・スキーマを開発するのであれ、開発中の業界標準スキーマの中からどれかを選ぶのであれ、IT企業による舞台裏での多大な作業が必要になる。

　スキーマの作成は大変だが、非常に重要な作業だ。なぜ大変かと言えば、それは一部には、スキーマ・オーサリング・ツールがまだ比較的未成熟な段階にあることによるものだが、その状況も急速に改善されつつある。だが、もっと重要なのは、XMLデータのオーサリングはかなり率直な「空白を埋める」作業であるのに対し、XMLスキーマのオーサリングはプログラミング作業に似ていることだ。比較の対象として最も似ているのはデータベース管理システム（DBMS）だろう。大半のユーザーは電子フォームを使ってデータを入力できるが、基底のデータベース・テーブルを設計し、それらの関係を定義するのはITの専門家でなければできない作業である。

　ITの専門家にスキーマを設計してもらう以外の選択肢としては、XMLデータからスキーマを推論するという方法がある。Officeコンポーネントによるスキーマの推論はそれなりのレベルに達している。ただし、企業は注意すべきだ。どのようなデータ処理の方法を好むかという点で、各アプリケーションにそれぞれ固有の傾向が見られるからだ。例えば、Excelは基本的には二次元のデータ・グリッドであるため、Excelが推論するスキーマも厳密な二次元構造に従う傾向があるが、必ずしもそれが適切な推論とは限らない。また、アプリケーションの種類が違えば（Visual Studioなど、スキーマを推論できる開発ツールも含めて）、同じデータ・セットから異なるスキーマを推論することもあるだろう。

　スキーマの重要性を考えれば、企業は不要な複雑さを防ぐために、エンド・ユーザーの先手を打ち、全社標準のスキーマを推進する必要がある。各部門がOfficeのスキーマ・オーサリング機能を自由に使うようなことになれば、いずれ、同じようなデータを定義した複数の「自家製」スキーマの存在に悩まされることになりかねない。そうなれば、部門間の相互運用やバックエンド・システムとの相互運用はより一層難しくなる。

　ただし、複数の業界団体が現在、企業が直接採用できるようなスキーマの定義を進めており、こうした問題の緩和につながることが期待されている。例えば、Extensible Business Reporting Language（XBRL）はIBMやMicrosoftなどの企業がアメリカ公認会計士協会（American Institute for Certified Public Accountants）と共同で開発したオープン標準のXMLスキーマで、政府により提出が義務付けられている四半期ごとの報告書（Form 10-Q）などの業務報告をXMLでどのように表現すべきかを指定したものだ。また、SAPやSiebelなどの主要なアプリケーション・ベンダーやMicrosoftのビジネス・ソリューション部門なども、自社のアプリケーション向けのスキーマを開発する見通しだ。

INDEX
	［技術解説］Office 2003のXMLスキーマ・サポートがもたらすインパクト
	1．スマート・クライアント向けプラットフォームの本命
	コラム：スキーマの役割とは
	2．Excel／InfoPathとXML
	コラム：オフラインのアプリケーション・サポートはなぜ難しいか
	3．Wordデータをビジネス・プロセスに認識させる
	コラム：Office向けの開発ツール

　

技術解説

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）