XML Schemaで単純型要素を定義する
XMLデータの構文ルールを記述するDTDですが、実は最新のXML用途には力不足です。そこでDTDの後継として登場したのがXML Schema。まずは一番やさしいXML Schemaの記述方法である「単純型要素の定義」から解説します。
| カテゴリ | XML Schema | |
| 関連要素 | <xsd:schema>、<xsd:element> | |
| 関連記事 | XML Schemaで複雑型要素を定義する |
システム間におけるXMLデータ交換が恒常化するにつれ、データフォーマットの妥当性検証を自動化・簡潔化するニーズは高まっています。例えば、注文データ1つ交換するにしても、企業ごとにフォーマットが異なっていたらどうでしょう。以下の2つのXML文書を見てください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
いずれの文書も人間の目から見れば同じ意味を表していますが、システム的にはまったく異なる情報です。もしもこのようなデータを解析したいという場合には、まず上記の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の概念はあまりに多岐にわたりますので、今後おいおいご紹介していくことにしますが、ここではまず、最も基本的なサンプルをご紹介しておくことにしましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
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デフォルトのデータ型 | |
いかがですか？ XML Schemaといっても、なんら構える必要はなく、ただこれだけのことです。これから複数の要素や属性を含むXML文書が登場しますが、見掛けの複雑さに惑わされず、本稿のシンプルな例をベースにおいて学習を進めていくと、より分かりやすいでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.