レベル: 初級 Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.
2004年 1月 20日
XMLの世界は巨大で、かつ成長しています。標準や技術も広範でお互いに複雑に関係し合っています。初心者にはXMLの最も重要な面をたどりながら進んでいくのは楽ではなく、ユーザにとっても新しい概念の導入や変化に追いつくのは大変です。このシリーズでは、Uche
OgbujiがXMLの標準を紹介していきます。また、さらに詳しく知るために、広範囲にわたる参考資料も推薦として挙げて行きます。
XMLは鳴り物入りで登場し、そして瞬く間に成長しました。XMLが非常に価値のある技術であることは証明されましたが、流動的なあらゆる要素が「XML」という言葉で一括りにされてしまうことを考えると、尻込みしたくなるような技術でもあります。このシリーズでは、最も重要なXML技術と思われるものを要約し、それがXMLの広大な世界の中にどのように収まるのかを議論していきたいと思います。またそれぞれの技術を評価し、使い方を学ぶ上で役に立つようなチュートリアルや資料も紹介していきます。
ここで紹介する技術は、すべて
標準
と呼ばれるものです。実は標準という言葉自体ちょっと曖昧なのですが・・・。標準はあらゆる形式を取り得るもので、同じ領域で複数の標準が競合していることも珍しくありません。標準の定義にあたって私は、現実的な取り組み方をします。つまり広範なベンダーに広く採用されている仕様、または（業界で認知されている）ベンダーから中立の組織が推薦する仕様を標準と定義します。
この記事ではシリーズの最初として、私が核となるXML技術とみなしているものに焦点を当てます。こうした技術はXML文書として表現されるものの基礎をなすものです。今後の記事では、開発者が行うXML処理に関連した標準や、（精選した）最も重要なXMLアプリケーション（つまりボキャブラリ）等も紹介していきます。
XML
XML 1.0 (Second Edition)
[W3C勧告] は当然のことながら、枝が増え続けているXML技術という木の幹にあたるものです。この仕様は、
Unicode
[Unicode コンソーシアム技術レポートとISO標準] の上に構築されており、テキスト書式の厳密な規則と、
文書型定義 (DTD)
妥当性検証言語を定義しています。現在の版（Second
Edition）には、それまでに累積された仕様の修正が含まれています。各種の言語に
翻訳
されていますが、英語版のみが
normative
、つまり標準として強制力を持つもの、となっています。
XML 1.1
[W3C勧告]
は、整形式XML文書の定義を変更する最初の改版です。主な変更はXML仕様での文字の取り扱いを改訂することであり、より自然にUnicode仕様の変更に対応するようにし、また
Character Model for the World Wide Web 1.0
[開発中] を参照することで、Unicodeのバージョンによらず文字が正規化できるようにしています。XML
1.1ではまた、行末文字にNELが追加されていますが、これはIBMのメインフレーム・システムで行の終わり（EOL）として使われているものです。これに関しては、メインフレームに対する些細な改良のために、このように根本的な変更まですべきではない・・・という人もいて、論議の的になっています。また別の論議も起きており、一部の参加者からはXMLのバージョン変更がもたらす互換性問題発生の可能性と比べると、変更が中途半端だという指摘もされています。
XMLはISO 8879:1986 [ISO 標準] で定められた、
標準汎用マークアップ言語 (SGML)
に基づいています。XMLはSGMLを大幅に簡略化したもので、Web環境により適したものとなるように調整されています。
推薦の入門書やチュートリアル
参考文献、その他の資料
カタログ
XML Catalogs
[OASIS 委員会仕様] は、XMLプロセッサがどのようにしてXML
実体
識別子を実際の文書の中に展開するかの命令書式を定義しています。例えば、そのDTDに対するシステム識別子と公開識別子が与えられれば、DTDをロードする場所を指定するのにXMLプロセッサは
実体カタログ
を使うことができます。
システム識別子
は通常URI （
Uniform Resource Identifiers
）で与えられます（URIは
RFC 2396: Uniform Resource Identifiers
[IETF RFC]
で定義されています）。URIはWebブラウザなどでおなじみのURLの拡張です。すべてのURLはURIでもありますが、URLは
RFC 2141: Uniform Resource Names
[IETF RFC]
で定義されるURNを追加しています。URNはWebのリソースを場所ではなく名前で識別します（「
The URN Charter
」も参照してください）。
公開識別子
は通常、SGMLで定義されるFPI（Formal Public
Identifiers）として規定されます。カタログは、使用しているマシンがネットワークにアクセスできず、URLで規定されるリソースにアクセスできない場合、あるいは組織が外部リソースの代用としてローカルにリソースを持ちたい場合などに使うことができます。
XMLカタログ自体はXMLドキュメントですが、XMLだけでなく古いフォーマットのSGMLでも利用できる単純なテキストでカタログ・フォーマットを定義しています（
Entity Management, OASIS Technical Resolution
9401:1997
[OASIS 標準]）。このフォーマットはよく、
OASISオープン・カタログ
と呼ばれます。
推薦の入門書やチュートリアル
カタログ処理は通常XMLパーサに組み込まれた一部の機能として提供されますが、いくつかの入門資料ではカタログを使った実体の解析に焦点を当てています。
XML名前空間
 |
「標準」のいろいろ
いくつかの組織が、また非公式なグループで活動する人たちがXMLユーザのための標準作りに関わっています。そうしたグループなどの大部分に関しては
参考文献
でリンクを挙げましたが、この記事で標準を規定するために使っている用語のいくつかを説明しておきましょう。
W3C
は正式に
Recommendations （勧告）
を発行します。勧告は技術的には、さらなる標準化を促すための単なる助言ですが、それ自身デファクト・スタンダードになってしまう傾向があります。
Working Draft （ワーキングドラフト）
が
Candidate Recommendation
（勧告候補： 開発者が実装を通してテストするために、公開される最終形式）になり、次に
Proposed Recommendation
（勧告案： 勧告のためW3Cでの承認待ち）の後、勧告としての地位を得ることになります。
International Organization for
Standardization
（ISO：
国際標準化機構）は、おそらく世界中でもっとも権威ある標準化団体です。ISO標準の多くは関連の産業界において一定の法的強制力を持っています。
Organization for the Advancement of
Structured Information Standards (OASIS）
は、SGMLのころから組織的には発展していますが、その作業の成果は同じようなものです。OASISで
技術決議
（Technical Resolutions）と呼ばれていたものは現在、
委員会仕様
（Committee
Specifications）となっていますが、W3Cの勧告と似た意味合いを持っています。
Internet Engineering Task Force（IETF）
は、草の根の熱意によりながら正式組織としての手段も持とうとしている組織のモデルとなるものです。インターネットにアクセスできる人であればほとんど誰でも、
Internet Draft （インターネット・ドラフト）
を提出し、標準の案として提案できます。運営グループがその提案を検討し、
Request for Comment （RFC）
として公開すべく推薦します。RFCは
Standards Track RFCs
または直接
Standard RFCs
として記録されることになりますが、RFCとなった公開資料は適切な認識を受け、実際に広く使われている場合が多いと言えます。
最後に
XML community
は、大きな組織が取り残した隙間を埋めるために、非公式ながら重要な標準を作るため活発に活動しています。SAXやRDDL、EXSLTなどはその顕著な例です。OASISはそうした標準化の場だったのですが、デファクト・スタンダードを打ち立てるためにメーリング・リストのスレッドを立てたがる人が今でも後を絶たないのです。
|
|
Namespaces in XML 1.0
[W3C 勧告]
は、XML文書で使用される要素や属性に普遍的な名前付けをするための仕組みです。XML名前空間の背景を説明する簡単な例を挙げましょう・・・。今、解剖学的なマークアップの記述として「head」、「body」という要素名が入ったXMLボキャブラリがあり、そして
XHTML
（後ほど説明します）の断片を文書に埋め込みたいとします。XHTMLでも「head」、「body」要素が定義されています。XHTMLの要素を、同じ名前の（自分の）ボキャブラリの要素と区別するにはどうしたらよいでしょうか・・・。XML名前空間を使うことで、それぞれにボキャブラリ・マーカー（vocabulary
markers）を割り当てるのです。XML名前空間では各ボキャブラリが名前空間と呼ばれ、ボキャブラリ・マーカーを表現する特別な構文があります。各要素名、あるいは属性名を一つの名前空間に結びつけることができ、これによって解剖学的な「head」がXHTMLの「head」と区別できるのです。XMLの専門家の間では、XML名前空間に対して議論があります。それは名前空間によってXML処理モデルがかなり複雑になること、名前空間を使う利点はあっても問題が無くなるわけではないと言う人も少なくないからです。それでもXML名前空間は、XMLユーザの間で非常に広く受け入れられており、ほとんどすべてのXML処理技術で名前空間への対応が行われています。
Namespaces in XML 1.1
[W3C 勧告] は、誤りの訂正と、なによりも国際化対応されたURIのサポートを追加しています。
XML名前空間に関連して起きてくる問題の一つは、名前空間URIが規定すべきリソースはどんなものなのかということです。Jonathan
BordenとTim Brayが率いるXML専門家コミュニティでは、名前空間の情報をパッケージングする標準として
RDDL （Resource Directory Description Language）
を提案しています。RDDLでは、名前空間の理解や処理を助けるための重要なリソースへのポインタをボキャブラリに散文的に既述する埋め込みの
XLink
（この記事の中で説明しています）を提供するためにXHTMLを使います。
RDDL 2.0
[開発中] はその更新版で、2つのオプションでXLinkの置き換えを図ろうとしています。一つのオプションは
RDF （Resource Description Framework）
（後ほど説明します）であり、もう一つは
W3C Technical Architecture Group (TAG)
のメーリング・リストで開発された、XMLのリンク方式の代替提案です。
推薦の入門書やチュートリアル
上に挙げたXML 1.0のチュートリアルの中にもXML名前空間をとりあげたものがあります。それに加えて・・・
参考文献、その他の資料
XML Base
XML Base
[W3C勧告]
は、XMLの要素をURIと関連付ける手段を提供するものであり、XMLの処理において、どのように相対URIを解決するかをより正確に規定します。例えば、あるXMLの要素が相対URLを使ったリンクを含んでいるとすると、リンク先の絶対URLはその要素のベースURIを参照することで決定することができます。大部分のXMLプロセッサは、文書を構成する各XMLの実体に対してベースURIを仮定しています。XML
Baseを使うことで、このデフォルトを無効にすることができるのです。
推薦の入門書やチュートリアル
XInclude
XML Inclusions (XInclude) 1.0
[開発中]
は、XML文書をマージするのに使います。XIncludeは一般的に、XML文書を管理しやすい大きさに分割する場合に使います。ドキュメントを好きなように分割し、XIncludeを使って元のようにつなぎ合わせることができるのです。XML
1.0の構成要素である
外部解析対象実体（External parsed entities）
を使っても、同じように別ファイルから文書の一部分をロードできるので、XIncludeは不要な仕様だと主張する人もいます。XIncludeには、取り込もうとするドキュメントの部分を選択できる機能など、特別な機能もあります。
推薦の入門書やチュートリアル
XML Infoset
XML Information Set
[W3C勧告] は、XML Infosetとしても知られており、XML文書を、
information items （情報項目）
と呼ばれる特別なプロパティを持った一連のオブジェクトとして、抽象的に記述する方法を定義しています。この抽象データセットは、XML
1.0、XML名前空間、それにXML
Baseなどで定義されたXML文書のいろいろな側面を取り込んでいます。XML
Infosetは、XML文書を構成オブジェクトの集合として分解しようとしている他のいくつかの仕様の基礎として使われています。
推薦の入門書やチュートリアル
Canonical XML ("c14n")
Canonical XML Version 1.0
[W3C勧告]
は、XML文書を作成する際の標準的な物理的表現方法（正規化形式と呼ばれます）で、意味を変えない範囲で許されるXML構文の揺れを考慮に入れたものです。例えばXMLでは属性の順序は重要ではありません。一つの文書では属性がアルファベット順に並べてあり、別の文書では属性の並べ方だけが違っている場合、たとえ物理的な表現が異なっていても、XML
1.0に関する限りどちらのドキュメントも同じになってしまうのです。これは実用上ちょっとした問題となります。例えば文書が不正に改竄されないように、デジタル的に暗号化された署名が欲しい場合を考えてください。属性を並べ替えてしまうと、XML
1.0の基準の範囲内では文書に変更が無いにもかかわらず、署名を意味のないものにしてしまうかも知れないのです。その解決方法としては、署名、テキスト比較、あるいはその他の操作の前に文書を正規化形式に変換することです（この処理は「正規化（"
Canonicalization： c14n"）」と呼ばれます）。これによってXML
1.0では重要とされない変更も、正しく処理されることになります。
比較対象のXMLまたは、署名が必要なXMLが、大きなドキュメントの一部という場合もあります。こうした場合であっても、c14nは一般的にこれに対応できなければなりません。これは例えば名前空間宣言のような細部を処理する場合です。c14nを文書のサブセットに限定する必要がある場合には、関連のアルゴリズム
Exclusive XML Canonicalization Version 1.0
[W3C勧告] を使わなければなりません。
XPath
XML Path Language (XPath) 1.0
[W3C勧告]
は、XML文書の一部を指し示す、構文とデータ・モデルです。汎用の表現言語の特長を一部含んでおり、XMLシステム内でアプリケーションから中立的な処理で使えるような、ちょっとした言語として設計されています。例えばXPathを使うと、文書中のセクションのタイトル要素をすべて見つけることができるのです。
XPathはXML
1.0自体を除けば、おそらくXML技術の中で最も成功しているものです。XPathは、非常に成功したXML変換言語である
XSLT
の中核であり、XML処理に関して、ほとんどすべてのプラットフォームに対応しています。
XPath 2.0
[開発中] では、新しい機能を数多く追加しており、
W3C XML Schema
（今後解説予定）サポートの他、多くのコア関数を追加しています。XPath
2.0は、仕様が非常に複雑になってしまったため論議を呼んでおり、多くのユーザや実装を行っている人たち（私も含めて）は、大幅に単純化しない限りXPath
2.0は使わない、と言っています。
推薦の入門書やチュートリアル
XSLTの入門書は必ずと言えるほどXPathについても説明しています。ここでは、XPathだけに焦点を当てたチュートリアルを挙げておきます。
XPointer
XPointer Framework
[W3C勧告]
は、XML文書の断片を参照するのに使える言語を定義しています。読者は既に、HTML文書の特定の部分にリンクするためにハッシュ（「#」）を付けたURLをどう使えばよいか知っているのではないでしょうか。XPointerはそれと似ていますが、XML文書にリンクしたりXML文書を参照したりする場合に、より広範な力を発揮するものです。XPointerのフレームワークは、
xpointer() scheme
[開発中] や
element() scheme
[W3C勧告] それに
xmlns() scheme
[W3C勧告]
等と合わせて使いますが、こうしたスキームは対象とする文書の断片をXPointerフレームワークの中で表現するための具体的な方法を定義するものです。
XPointerは異論を唱える人が多く、ちょっと混乱気味の道をたどっています。XPointerワーキング・グループのメンバ自身が
FIXptr
[コミュニティ標準] という対立提案を出していますし、代替のXPointerスキームのいくつかは
the xpath1() scheme
[IETFインターネット・ドラフト] を含んでいます。
推薦の入門書やチュートリアル
XPointerは勧告になる直前に大幅に変更されたため、世にあるチュートリアルの多くが古いバージョンの方を説明していることに注意してください。
XLink
XML Linking Language (XLink) 1.0
[W3C勧告]
は、XML文書でリンクを表現するための一般的な枠組みを提供しています。リンクを必要とするハイパーテキストはWebの基本ですが、高度なリンク機能を追加することはXMLの基本理念として常に期待を受けてきました。実際、XLinkは当初「XML
part
2」と呼ばれていたのです。残念ながらHTMLのような静的なボキャブラリに対してリンクを定義するのに比べて、XMLでリンク・システムを定義するのはずっと難しいことが分かってきました。XLinkの開発は調和に欠けた長い道のりを経ています。例えばXHTML
（このシリーズで説明します）の開発者達は、XLinkを使わないことを決め、代わりに独自の
HLink
[開発中]
と呼ばれるシステムを作りました。XLinkの仕様が完成してから数年経った現在でも、あまり採用は進んでいません。
それでもXLinkは、多くの重要なXML関連のプロジェクトの中心にあるものとして重要であり、ごく基本的で一方通行のHTMLリンクよりもずっと豊富なリンクができるよう考慮されています。XLinkは単純なリンク（
単純リンク
）と、複数のエンドポイントが持てるもっと複雑なリンク（
拡張リンク
）を提供します。さらに、リンクされた文書と言うことではなく、むしろ（
linkbases
と呼ばれる）特別なハブ文書で表現されるリンクも提供します。
推薦の入門書やチュートリアル
XLinkチュートリアルの中には昔のドラフトを説明していて、古くなってしまっているものもあります。次に挙げるものは新しいものです。
参考文献、その他の資料
RELAX NG
RELAX NG
[OASIS 委員会仕様、ISOドラフト標準] は、
XMLスキーマ
言語、つまりXMLボキャブラリを定義、制約するために使われる言語です。元々のXMLスキーマ言語は、XML
1.0自体で定義されているDTD （Document Type
Definition）ですが、一部の人はDTDを嫌っています。これはDTDの構文が扱いにくいものであること、表現できるテキストやマークアップ構成に制限があることや名前空間がうまく扱えないことなどからです。DTDに取って代わるべく、またはDTDを強化するために、RELAX
NGを含めていくつかの新しいXMLスキーマが現れていますが、RELAX
NGはその単純さと表現力の豊かさを評価されているものです。RELAX
NGの核となる仕様では、スキーマに対するXML構文を定義しており、また
RELAX NG Compact Syntax
[OASIS 委員会仕様] では、RELAX
NGスキーマの単純テキスト構文を定義しています。テキスト構文は補遺としてISO標準に採り入れられる見込みです。またRELAX
NGは、（Document Schema Definition Languages
（DSDL）と呼ばれる）XMLスキーマ処理システムに対するISO全体としての取り組みの一部となっています。
推薦の入門書やチュートリアル
-
Nicholas Chaseによる入門チュートリアル「
Understanding RELAX NG
」を読んでください。これを読めば、XMLベースの完全な構文と短縮構文の両方を含めてRELAX
NGの持つ単純さと強力さにすぐに追従することができます（developerWorks
2003年12月）。
-
David MertzによるdeveloperWorksのXMLの論考コラムでは「RELAX
NGによる逆襲」シリーズでRELAX NGに焦点を当てています。
-
第1回
ではRELAX
NGの一般的な意味体系をとりあげ、データ型について触れています（2003年2月）。
-
第2回
では第１回の議論を続け、意味体系の問題としていくつかを追加してとりあげています。またRELAX
NGに対応したツールについても説明しています（2003年3月）。
-
第3回
ではRELAX
NGの短縮構文を詳細にとりあげ、短縮構文とXML構文の厳密な対応について説明しています（2003年5月）。
-
公式なチュートリアルでRELAX NGの
核となる
構文と
compact syntax
（短縮構文）が説明されています。
-
ZVONでは
RELAX NG and W3C XML Schema language
（このシリーズで説明します）で両方のチュートリアルを提供しています。
参考文献、その他の資料
W3C XML Schema
XML Schema Part 1: Structures
と
XML Schema Part 2: Datatypes
[W3C勧告] はXMLに対して、（DTDとは）別のスキーマ言語を定義しています。Part
1ではドキュメントの構造を制約することに言及し、Part
2では単純な要素や属性の内容を制約することに言及しています。W3C XML Schema
（WXS）は、複雑で表現力に乏しいとの批判を受け、結果としてRELAX
NGなどのような競争相手が出てきてしまいました。次第にXMLのユーザは、自分の目的に合えばどのようなスキーマ言語でも使うようになってきています。その上で必要があれば、次々と出現してくる豊富なツール群を使って別の形式に変換するわけです。他の仕様でWXS
Datatypes仕様を使ったものも多くありますが、代わりのデータ型システムを開発すべきだという声もまた起きています。ワーキング・グループがWXS
1.1の作業に取りかかっています。
推薦の入門書やチュートリアル
参考文献、その他の資料
Schematron
The Schematron Assertion Language 1.5
[コミュニティ標準、ISOドラフト標準] は、DTDやRELAX
NG、WXSとは異なった手法によるスキーマ言語です。Schematronでは、ルート・ノードから枝葉にわたるまでのXMLフォーマットの全体的なツリー構造を描き出すのではなく、チェックすべきXML文書のルールの集合を登録します。これによってSchematronは、単独のスキーマ言語としてのみならず、他のスキーマ言語を補完するものとしても非常に使い道の広いものになります。Schematronは、私がこれまでに説明した言語では表現できなかった制約を表現することができるので、他のスキーマ言語と組み合わせて使われる場合がよくあります。
推薦の入門書やチュートリアル
参考文献、その他の資料
今後は・・・
この記事では核となる重要なXML標準のほとんどについて概説してきました。第2回では、アプリケーション処理にXML
を使っている人たちにとって重要な標準を概説する予定です。
参考文献
-
XML標準に関するこのシリーズ
第2回（英文）
ではUche OgbujiがXML処理技術に注目しています（developerWorks
2004年2月）。また
第3回（英文）
では最も重要なXMLボキャブラリを説明しています。
-
XMLについてしっかりとした基礎を勉強したいけれども、本は一冊しか買いたくないというのであれば、Elliotte
Rusty Harold著による
The XML Bible, 2nd Edition
（2001年John Wiley & Sons刊）を読んでみてください。
-
XML標準を開発している一番重要な組織のWebサイトを見てみてください。
-
Simon St. Laurentによる
Outsider's Guide to the W3C
はFAQですが、HTMLやXMLをもたらした組織のいろいろな側面を明らかにしています。
-
Robin Coverによる
The Cover Pages
は分かりやすくまとめられたXMLの資料ガイドです。XML技術のほとんどすべての面が分かります。
-
XML開発者のニュース・サイト
xmlhack
を見てください。私も編集に一役買っています。
-
developerWorksの
XML記事一覧
にはUche Ogbujiの
XMLの論考
コラムを含めて、さらにたくさんのXMLに関する資料があります。
-
XMLおよび関連テクノロジーの
IBM認証開発者になる方法
を参照してください。
著者について | 
| | Uche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。 |
記事の評価
| 
