XML Schemaで単純型要素を定義する：XMLテクニック集（7）（1/3 ページ）

» 2003年11月12日 10時00分公開

XML Schemaで単純型要素を定義する

XMLデータの構文ルールを記述するDTDですが、実は最新のXML用途には力不足です。そこでDTDの後継として登場したのがXML Schema。まずは一番やさしいXML Schemaの記述方法である「単純型要素の定義」から解説します。


	カテゴリ	XML Schema
	関連要素	<xsd:schema>、<xsd:element>
	関連記事	XML Schemaで複雑型要素を定義する

　システム間におけるXMLデータ交換が恒常化するにつれ、データフォーマットの妥当性検証を自動化・簡潔化するニーズは高まっています。例えば、注文データ1つ交換するにしても、企業ごとにフォーマットが異なっていたらどうでしょう。以下の2つのXML文書を見てください。

<order id="000-00-0" customer="A0001" products="X-009Z" 

 quantity="1" />

<order id="000-00-0">

  <customer>A0001</customer>

  <products>X-009Z</products>

  <quantity>1</quantity>

</order>

　いずれの文書も人間の目から見れば同じ意味を表していますが、システム的にはまったく異なる情報です。もしもこのようなデータを解析したいという場合には、まず上記のXML文書をXSLTなどでフォーマット変換してから、あらためて読み取る必要があります。

　これがまだ2通り程度であればそれも現実的でしょうが、N社と商取引を行うのにN個のデータフォーマットがあったとしたらどうでしょう。それこそ「データ変換のスパゲティ」になってしまいます。しかも、変換ルールを定めるために、多くのコストと工数とを割かなければなりません。

　そこで、データ交換の局面においては、共通の正しい形式をあらかじめルール付けしておく必要が出てくるのです。これが、別稿「DTDで要素型宣言を定義する」「DTDで属性リスト宣言を定義する」などでもご紹介したDTD（Document Type Definition）の役割でした。DTDを使用することで、XMLパーサ（解析アプリケーション）は自動的にデータの妥当性を検証（Validate）することができるので、新たなアプリケーションの開発も、ましてや人手によるデータチェックの必要性もなくなります。

　しかし、DTDにはいくつかの問題点があります。

DTDの問題点

DTDはXMLとは異なる構文である
　別稿「DTDで要素型宣言を定義する」「DTDで属性リスト宣言を定義する」をご覧になるとお分かりのように、DTDはXMLとはまったく異質の構文から構成されます。つまり、開発者はXML文書のルールを記述するために、XML文書とは異なる構文を「別にもう1つ」学習しなければなりません。
DTDはデータ型を持たない
　DTDはもともとは古いSGML（Standard Generalized Markup Language）の時代の産物です。SGMLの時代、文書とは構造化されたデータというよりもワープロで扱われるようなドキュメントでした。つまり、データ型といっても、「#PCDATA」で表現される文字列型が表せればそれで十分だったのです。

　しかし、XMLがターゲットとするのは一般的なドキュメントのみならず、データベースで扱われるような構造化データも含まれています。本当にデータベースの構成情報をXMLとして表現したい場合、数値や日付をはじめ、厳密な制約条件を記述できないのは、ある意味で致命的な「欠陥」でもありました。
DTDは名前空間の概念を持たない
　もう1つ、XMLの重要な概念として忘れてはならないのが、名前空間です。名前空間は2つ以上のXML文書を結合したいという場合、要素や属性の名前が衝突することを防ぐために重要な機能です。

　例えば、ある文書Aにおける<title>要素が書籍タイトルを表し、文書Bにおける<title>要素が人の職制を表すとします。このような場合、もしもこれら文書を同じXML文書内に統合したとしたら、異なる意味を持った<title>要素が混在してしまうこととなり、大変不便です。しかし名前空間を用いることで、前者は<book:title>、後者を<member:title>のように区別することができるようになるのです。

　しかしDTDが考案されたSGMLの時代、こうした複数の文書をやりとりしたり、ましてや統合するという概念は比較的希薄でした。そのため、DTDでは名前空間という概念はサポートされていません。

XML Schemaを使う利点

　以上のような問題点を克服するために登場したのがXML Schemaなのです。XML SchemaはXML構文にのっとって記述される文書型宣言ですので、当然、名前空間の概念をサポートします。また、日付や数値などの主要なデータ型や、さらに数値の中でも負数、正数、－10～10といった範囲までさまざまな制約条件を定義することが可能です。

　XML Schemaの概念はあまりに多岐にわたりますので、今後おいおいご紹介していくことにしますが、ここではまず、最も基本的なサンプルをご紹介しておくことにしましょう。

 ［simple.xml］

                

<?xml version="1.0" encoding="Shift_JIS" ?>

<birthday>2003-08-05</birthday>

 ［simple.xsd］

                

<?xml version="1.0" encoding="Shift_JIS" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:element name="birthday" type="xsd:date" />

</xsd:schema>

　XML Schemaの拡張子は、慣例的に「.xsd」とします。また、XML Schemaのルート要素は<xsd:schema>要素となります。xmlns:xsd属性までを1つの決まり文句として覚えてておくとよいでしょう。

　今回の例で、実際に文書型の定義を行っているのは、<xsd:element>要素になります。上のsimple.xmlは<birthday>要素1つからなる単純なXML文書ですので、XML Schemaの定義も単純な一文を記述するのみです。

　<xsd:element>要素のname属性は要素の名前を、type属性はデータ型を指定します。

XML Schemaのデフォルトデータ型

　type属性に指定可能なXML Schemaデフォルトのデータ型を以下の表に挙げておくことにしましょう。大文字で記述されたものは基本データ型、小文字で記述されたものはXML Schema拡張のデータ型です。拡張データ型を指定するに際しては、頭に「xsd:」と付加しなければならない点に注意してください。


データ型	概要
binary	バイナリデータ
boolean	真偽（true、false）
byte	バイト型（－127～128）
century	世紀（例：21）
date	日付型（例：2003-12-15）
decimal	10進数
double	64bit倍精度浮動小数点
ENTITY	実体型
float	32bit単精度浮動小数点
ID	ID型
IDREF	ID参照型
IDREFS	ID参照型の集合体
integer	整数型（－2147483648～2147483647）
long	長整数型（－9223372036854775808～9223372036854775807）
month	月（例：2003-12）
NAME	名前（例：XML1.0）
NCNAME	コロンなしの名前
negativeInteger	負の整数（0を含まない）
NMTOKEN	NMTOKEN型
NMTOKENS	NMTOKEN型の集合体
nonNegativeInteger	0以上の整数（0を含む）
nonPositiveInteger	0以下の整数（0を含む）
NOTATION	記法型
positiveInteger	正の整数（0を含まない）
QNAME	名前（XML Namespaces）
short	短整数型（－32768～32767）
string	文字列
time	時刻型（例：23:53:15.000）
timeDuration	期間（例：P1Y5M3DT10H13M35.41（1年5カ月3日と10時間13分35.41秒））
unsignedByte	符号なしバイト型（0～255）
unsignedInt	符号なし整数型（0～4294967295）
unsignedLong	符号なし長整数型（0～18446744073709551615）
unsignedShort	符号なし短整数型（0～65535）
uriReference	URI（Uniform Resource Identifier：ネットワーク上の位置情報）（例：http://www.w3.org/2001/XMLSchema/ ）
year	年（例：2003）
XML Schemaデフォルトのデータ型