XML と XML テクノロジ ガイド

  • [アーティクル]

Brian Randell and Aaron Skonnard
DevelopMentor

September 1999

要約: XML と XML をサポートするテクノロジ群を紹介します。コア テクノロジのそれぞれがどのような役目を果たすかということと、いくつかの XML をサポートするテクノロジについて述べます。

XML (Extensible Markup Language: 拡張可能なマーク付け言語) がソフトウェア産業を激変させると考える開発者が日増しに増えているようです。彼らの 1 人に、この変化がなぜ、どのようにして起こるのかを説明してほしいと頼んだとしても、おそらく彼らは XML の頭字語だらけの説明をもごもごと口にするばかりで、あなたの好奇心はいっこうに満たされないことでしょう。

XML の確実な理解を難しくしている主な障害は、XML の急速な進化です。W3C (World Wide Web Consortium) XML Web non-ms link サイトへ行ってみると、膨大な量の XML テクノロジとそれらに対応する発行物を目にすることができます。W3C の表記が非常に厳格であるという事実はさておき、それぞれが互いにどのように関連するのかが明確にわかっていない限り、開発者が特定のテクノロジについての大量の情報を本当に吸収するのは非常に困難です。

この記事では、XML と XML をサポートしているテクノロジ群を紹介します。なぜ XML が重要なのかを説明するだけでなく、サポート テクノロジのそれぞれが互いにどのように関連するのかについても説明します。この記事を読んだ後では、少なくとも、それぞれの XML 頭字語が何を意味するかがわかり、皆さんが興味を持った XML テクノロジをさらに深く知るための準備が整っているでしょう。

そもそも XML とは何か？

この質問に答えることは、最近の XML を論じているほとんどの著者にとって人気のある時間つぶしでした。おそらくすでにご存じのように、XML は Extensible Markup Language (拡張可能なマーク付け言語) の正式な頭字語です。E の代わりに X が使われたのは、おそらく、XML の方が EML よりずっとセクシーな響きがあるからでしょう。この頭字語の先へ進むと、マーク付け言語以上のものが見つかります。高度な拡張性と相互運用性を備えたソフトウェア ソリューションを構築できる一群のテクノロジが見つかります。

それはどこから来たか？

XML は、SGML (Standard Generalized Markup Language) から派生しました。XML と SGML はどちらも、自己記述型の文書を作成するためのものです。どちらの言語も、他のアプリケーションやツール (SGML または XML パーサーなど) が正確に情報を読み取って、それでおもしろいことができるように、テキスト形式のマーク付け (タグ) を使用してデータを記述します。XML は、SGML の単純化されたバージョンであり、Web での使用に適しています。

XML の構文

XML は、データを記述するための構文を定義します。以下は、妥当な XML です。

<hamburger name="CowBurger" lowfat="dream on"/>

他のマーク付け言語と違って、XML は大文字/小文字を区別します。<hamburger> 要素と <Hamburger> 要素は同じものではありません。また、XML は空白にも注意を払い (他の言語のように空白を無視しません)、文書構造を混乱させるおそれがある特殊文字にも注意が必要です (例えば、< と > など)。

ルート要素 (文書要素) を 1 つだけ含み、すべての子要素が正しく入れ子になっている XML 文書は、整形式 (well-formed) とみなされます。これは、特定の要素の開始タグと終了タグの両方が、同じ親要素の本体の中に存在しなければならないことを意味します。以下は、整形式 (well-formed) の XML 文書の例 (hamburger.xml) です。

<?xml version="1.0"?>
<hamburgers>
  <hamburger lowfat="dream on">
    <name>CowBurger</name>
    <description>Greasy and good.</description>
    <price>2.99</price>
  </hamburger>
</hamburgers>

誰がタグを定義するか？

前のセクションを読んだ人は、XML の構文について知る必要があることをほとんどすべて知っていることになります。それほど多くのことではありません。シンプルでエレガントです。

XML は HTML (Hypertext Markup Language) によく似ていることに気づいたかもしれません。XML と HTML はどちらも同じマーク付け言語構文を使用して、開始タグと終了タグ、および属性を定義します。HTML は、本質的に XML 言語の特殊ケースであり、要素と動作が事前定義されています。これらの要素とそれらに関連する動作は、特定の文書が Web ブラウザでどのように表示され、エンド ユーザーによってどのように使用されるかを定義しています。

HTML がユーザー インターフェイスを作成するための普遍的な方法を提供しているのと同じように、XML はデータを記述し、操作するための普遍的な方法を提供します。XML では、開発者は特定のデータ構造の記述に適した独自の XML ボキャブラリを作成することができます。ファーストフード チェーン用のソフトウェアを書く場合には、特定の油っこいスナックを記述するのに、hamburger 要素が役に立つかもしれません。

データを記述するために XML のパワーを活用できれば、XML を理解する他の同種または異種混在システムとの相互運用が容易になります。同様に、XML を使用して記述されている限り、他の任意のシステムが持っているデータを利用することができます。XML を利用する開発者は、他のシステムとの相互運用に際して、プラットフォーム、オペレーティング システム、言語、またはデータ ストアの違いを心配する必要がありません。XML は、システム相互運用のための最小公約数になります。

XML 名前空間

XML は相互運用性が高く、誰でも自由に独自の XML ボキャブラリを作成できるので、複数の開発者が概念的に異なるエンティティを表すために同じ要素名を選んだ場合、たちまちすべてが目茶苦茶になってしまいます。このような潜在的な競合から保護するために、 W3C は XML 言語に名前空間を導入しました。

XML 名前空間を使用すると、XML 文書要素にコンテキストを持たせることができます。XML 名前空間によって、開発者は要素を特定の実装上の意味に解決することができます。ハンバーガーの例で言うと、price 要素は、あるシステムでは顧客への販売価格を表し、別のシステムでは店の購入価格を表すかもしれません。次の例は、名前空間が潜在的なあいまいさの解消にどのように役立つかを示しています。

<?xml version="1.0"?>
<hamburgers       
    xmlns:purchase="http://fastfood.org/franchise/prices"
    xmlns:sales="http://fastfood.org/customer/prices">
  <hamburger lowfat="dream on">
    <name>CowBurger</name>
    <description>Greasy and good.</description>
    <purchase:price>0.99</price>
    <sales:price>2.99</price>
  </hamburger>
</hamburgers>

どのように使用するか？

XML 構文を理解するのは難しいことではありません。XML データを利用して、それで何か有益なことをする方がはるかに難しいことです。

XML データで何か有益なことをするには、XML ファイルをプログラム的に処理できなければなりません。W3C は「XML プロセッサ」という用語を、XML 文書を読み取って、その内容と構造へのアクセスを提供できるソフトウェア モジュールとして定義しています。Microsoft のフラグシップ XML プロセッサは Microsoft XML (MSXML) 2.0 といいます。MSXML 2.0 は、Internet Explorer 5 に付属し、Microsoft の MSDN Online にある XML Web サイトからスタンドアロンの再配布可能ファイルとして入手することもできます。

データを記述する普遍的な標準として XML を採用した場合の主な利点の 1 つは、どんな XML プロセッサでも、この目標を達成するために必要な機能を提供できることです。開発者が自分で XML プロセッサを書く必要はほとんどありません。理論的には、開発者は互換性問題を気にせずに、特定のプラットフォーム向けのベストな市販プロセッサを利用することが可能です。

標準的な XML プロセッサでは、任意の XML 文書 (hamburger.xml など) をプログラム的に読み取って、任意の要素名、本体、または属性にアクセスすることができます。Windows ベースのシステム上で XML 文書を作成した場合でも、メインフレーム システムに容易にそれを送り出して、メインフレームの XML プロセッサを使用して同じデータを利用することができます。これが XML の真の長所です。テクノロジとしての XML は、あらゆるソフトウェア問題を解決する銀の銃弾ではありません。しかし、あなた自身のアプリケーションと他のアプリケーションの間で構造化データを交換するための、オープンで効率的なメカニズムです。

XML コア テクノロジ

XML 文書を作成して、完全に単独で使用するのもよいでしょう。しかし、次々と登場してきている多数のサポート テクノロジを調べると、XML の真の可能性が明らかになります。この記事でこれから述べるテクノロジのすべてを使用しなければならないわけではありません。それらが XML 戦略全体の一部としてどのような役目を果たしているのかを理解していただくために説明してあるにすぎません。

検証テクノロジ

すでに述べたように、XML は整形式 (well-formed) の文書を記述するための非常に柔軟な構文を備えています。この柔軟性ゆえに、特定のクラスの XML 文書が、果たして我々が考えている形式に従っているかどうかを検証するための何らかの手段が必要です。たとえば、以下の XML 文書は整形式 (well-formed) であり、妥当です。

<?xml version="1.0"?>
<hamburgers>
  <hamburger lowfat="dream on">
    <hamburger lowfat="maybe">
      <name>CowBurger</name>
      <description>Greasy and good.</description>
      <price>2.99</price>
      <price>3.99</price>
    </hamburger>
  </hamburger>
</hamburgers>

しかし、この文書には、アプリケーション レベルの問題がいくつかあります。hamburger 要素の中に別の hamburger 要素があることに注目してください。この XML 構造には本質的な問題はありませんが、この例の場合は意味をなしません。また、内側の hamburger 要素の中に複数の price 要素があることに注目してください。どの価格が正しいのでしょうか？ これは、おそらくシステムのどこかにバグがあることを示しています。このような問題を捕捉するには、何らかの定義済みルール セットに対して XML 文書を検証するための標準メカニズムがあると便利です。

スキーマ

スキーマは基本的に、特定のクラスの XML 文書を記述する定義済みのルールのセットです。スキーマは、特定の XML 文書の中に現れてもよい要素と、特定の要素に関連付けることができる属性を定義します。また、どの要素が他の要素の子要素か、子要素が現れてもよい順序、および子要素の数など、XML 文書に関する構造情報を定義します。要素が空かどうか、属性のデフォルト値だけでなくテキストも含むことができるかどうかを定義することができます。

文書型定義 (Document Type Definition: DTD) と XML-Data は、どちらも XML 文書スキーマの記述方法を概説する仕様の例です。

文書型定義

DTD 言語は、特に SGML 文書の検証ルールを定義するために作成されました。XML は SGML の単純化されたサブセットなので、DTD は XML 検証ルールを定義するためにも使用することができます。XML プロセッサは実行時に DTD を使用して、定義済みの XML スキーマに対して特定の XML ファイルを検証することができます。

DTD 構文は、やや大げさで、不明瞭なことがあります。DTD は、感嘆符、かっこ、アスタリスク、山かっこなど、さまざまな構文要素を使用して、XML 文書に必要な要素、オプションの要素、特定の要素の出現回数などを定義します。また、DTD は、要素間の関係とさまざまな要素に属性を関連付ける方法を記述します。

以下は、前述の hamburger.xml ファイルの DTD (hamburger.dtd) です。

<!ELEMENT hamburgers (hamburger)*>
<!ELEMENT hamburger (name, description, price)>
<!ATTLIST hamburger lowfat CDATA #IMPLIED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT price (#PCDATA)>

この文書は、hamburgers 要素が多くの hamburger 要素を含むことができることを記述しています。それぞれの hamburger 要素は lowfat 属性と 3 つのサブ要素を含まなければならず、すべて #PCData 型 (Parsed Character Data: 解析済み文字データ) でなければなりません。この DTD に従った文書には、次のような行が追加されます。

<!DOCTYPE hamburgers SYSTEM "hamburger.dtd">

このステートメントは、DTD で記述されたスキーマに対して XML 文書の内容を検証するようにパーサーに指示します。

MSXML 2.0 は DTD をサポートしていますが、DTD を使用するのは楽ではないことがわかるでしょう。構文が醜く、使いにくいからです。DTD の構文は妥当な XML ではないことに注意してください。このため、XML プロセッサは、文書を読み取るための XML 構文とともに、スキーマを記述するための DTD 構文をサポートしなければなりません。しかし、XML を使用してスキーマを記述すれば、XML 文書検証は開発者にとって、特に XML ツール ベンダにとってはるかに扱いやすくなります。W3C は現在、DTD の欠点を軽減して、文法定義プロセスに拡張機能を提供する代わりの仕様をいくつか検討しています。

XML-Data

XML-Data は、XML スキーマ言語の実装案の 1 つです。Microsoft では、DTD スキーマと混同しないように、XML-Data スキーマを大ざっぱに XML スキーマと呼んでいます。XML-Data スキーマは、整形式 (well-formed) の XML 文書です。XML-Data 言語は、XML-Data DTD に基づき、スキーマ定義として予期される形式を指定します。XML-Data スキーマは単なる XML 文書なので、XML 文書を操作するためのツールであればどんなツールでも、XML-Data スキーマ定義の操作に使用することができます。

以下の XML-Data スキーマは、上記の hamburger.dtd によって定義されたスキーマと同様のスキーマを生成します。

<?xml version="1.0"?>
<Schema xmlns="schemas-microsoft-com:xml-data">
  <ElementType name="name" />
  <ElementType name="description" />
  <ElementType name="price" />
  <AttributeType name="lowfat" />
  <ElementType name="hamburger" />
    <element type="name" maxOccurs="1" />
    <element type="description" maxOccurs="1" />
    <element type="price" maxOccurs="1" />
    <attribute type="lowfat" maxOccurs="1" />
  </ElementType>
  <ElementType name="hamburgers" model="closed">
    <element type="hamburger" maxOccurs="*" />
  </ElementType>
</Schema>

要素と属性は、それぞれ <ElementType> と <AttributeType> 要素を指定することによって、XML-Data スキーマで定義されます。これらは、要素または属性の定義とタイプを規定します。要素または属性のインスタンスは、<element> または <attribute> タグを使用して宣言されます。特定の要素の許される出現回数を minOccurs/maxOccurs 属性によって定義することができます。スキーマ XML 構造は、XML 文書の中で要素が存在してもよい場所を定義します (<hamburgers> 要素は <hamburger> 要素を含むなど)。

Microsoft は、MSXML 2.0 によって XML-Data に対するサポートを提供しています。Microsoft XML SDK ドキュメンテーションによれば、Internet Explorer 5 に付属の XML スキーマ実装は主に、1998 年 1 月に W3C によって公表された XML-Data ノート non-ms link と Document Content Description (DCD) ノート non-ms link に基づいています。Internet Explorer 5 の XML スキーマは、XML 文法に少し違いがありますが、DCD で表現された機能に直接一致する XML-Data のサブセットに対するサポートを提供します。

プロセッサ (API) テクノロジ

すでに述べたように、XML で何か有益なことをするには、プログラム的にデータにアクセスできなければなりません。XML 文書を読み取って、その内容と構造へのアクセスを提供できるソフトウェア モジュールは、XML プロセッサまたは XML API と呼ばれます。

開発者は独自の XML API を自由に実装できますが、業界に受け入れられた標準 API を利用するのが最も効率的です。業界標準 API を受け入れることによって、開発者は特定の API 実装のためのコードを書くことができ、そのコードは、修正なしで同じ API の別の準拠実装の下で動作します。

現在、開発者の間で人気があり、業界標準になろうとしている API 仕様は、主に 2 つです。すなわち、Document Object Model (DOM) と Simple API for XML (SAX) です。

DOM

Document Object Model は、XML 文書に含まれる構造とデータにプログラム的にアクセスするための定義済みの標準です。W3C は DOM Level 1 仕様を勧告として承認しました。

DOM は、XML 文書のインメモリ ツリー表現に基づきます。XML ファイルがプロセッサにロードされるときには、文書を正しく表現するインメモリ ツリーを構築しなければなりません (図 1 を参照)。また、DOM は、プログラム的に XML ツリーを走査して、要素、値、および属性を操作するためのプログラム的なインターフェイス (メソッドとプロパティの名前を含めて) を定義します。

図 1. XML インメモリ表現

MSXML 2.0 は、DOM を完全にサポートして、インメモリ ツリーを操作するための使いやすいオブジェクト モデルを提供します。以下に、MSXML を使用してルート文書要素のすべての子要素を走査する方法を示す単純な VB の例を示します。

Set xmlDoc = CreateObject("MSXML.DOMDocument")
bSuccess = xmlDoc.load("hamburger.xml")
If bSuccess Then
   For Each node in xmlDoc.documentElement.childNodes
       val = node.text
   Next
End If

SAX

DOM 標準の主要なデメリットの 1 つは、XML 文書全体をメモリにロードするためにオーバーヘッドが大きいことです。非常に大きいデータ ファイルの場合、これが問題になることがあります。ネットワークまたはインターネット経由で大量の XML データを送信する場合、ファイル全体の送信が終わるまで待たなければファイルの処理を開始できないというのは、望ましいことではありません。この現実を痛感するにつれ、XML 開発者は労力を結集して (XML-DEV メーリング リストから)、SAX と呼ばれる代わりの仕様を形成する努力を始めました。SAX は、まだ準備段階ですが、そのパフォーマンスの高さから早くも人気を得ています。

SAX は、イベント ドリブンの XML 解析を可能にする非常に単純な XML API です (そのため、Simple API for XML という名前が付いています)。DOM 仕様と違って、SAX では XML ファイル全体をメモリにロードする必要がありません。アイデアは非常に単純です。XML プロセッサは XML 要素を読み終えるとすぐに、カスタム イベント ハンドラの 1 つを呼び出して、要素とその関連データをジャスト イン タイムで処理します。このため、パフォーマンスは大幅に向上しますが、開発者はある程度の柔軟性を失います。この最新テクノロジの詳細については、http://www.saxproject.org/ non-ms link をご覧ください。

変換テクノロジ

標準 DOM API を使用して XML データを操作してみると、大きい文書から特定のデータを抽出したり、XML 文書の特定の部分を別の形式 (HTML など) に変換するのが、非常に面倒なことに気づくでしょう。

たとえば、lowfat hamburger price 要素をすべて見つけたいとしましょう。標準 DOM API でこれを行うためには、ツリー全体をトラバースして、条件 (この例では、hamburger 要素内にあり、lowfat=yes である price 要素) に一致する特定の要素を探すコードを手動で書かなければなりません。もう 1 つの例として、すべての hamburger 要素とその関連データを単純な HTML テーブルに変換して、ユーザーが操作できるようにしたいとしましょう。標準 DOM API を使用する場合は、手動でツリーを走査して、HTML テーブルを含んだ出力文字列を作成しなければなりません。

このような作業を単純化し、標準化するために、W3C は XSL (Extensible Stylesheet Language) と呼ばれる XML 変換の仕様と、XSL Patterns と呼ばれる単純なクエリー言語を導入しました。

XSL Patterns

パターンとは文字列であり、XML ツリー内のノードのセットを選択します。その選択は、パターンが適用される現在のノードに対して相対的におこなわれます。最も単純なパターンは、要素名です。これは、現在のノードでその要素名が付いたすべての子要素を選択します。たとえば、パターン hamburger は、カレント ノードのすべての hamburger 子要素を選択します。

パターンの構文は完全です。文書内で特定の要素がある場所のコンテキストを識別することができます (たとえば、hamburger 要素の中にある price 要素)。また、特定の条件 (たとえば、lowfat=yes) に一致する特定のノードの識別に役立つパワフルなフィルタリング構文を備えています。hamburgers 要素の中の lowfat hamburger price 要素をすべて見つけるには、次のようなパターン文字列を使用します。

/hamburgers/hamburger[@lowfat="yes"]/price

パターンを特定のノードに適用すると、指定されたパターンに一致するノードのリストが返されます。このため、探しているものを見つけるために手動でツリーを走査する必要がなくなるので、開発者の作業が単純化されます。

MSXML 2.0 は Extensible Stylesheet Language (12 月 18 日付けワーキング ドラフト) non-ms link のセクション 2.6 で定義されたパターン構文をサポートしています。MSXML 2.0 で実装されている IXMLDOMNode インターフェイスは、SelectNodes と SelectSingleNode という 2 つのメソッドを備え、両方ともパターン文字列をパラメータとして受け入れます。たとえば、次のコード行は特定の条件に一致するすべての price ノードを検索します。

Set nodeList = rootNode.selectNodes("hamburger[@lowfat="yes"]/price")

XSL

XSL Patterns は、特定の XML 文書の、特定のノードを識別するのに役立ちますが、それらの一致したノードで何かおもしろいことができるかどうかは、やはり開発者しだいです。XSL は、最も一般的な XML 作業の 1 つ、すなわち、ノードを XML 形式から別の形式に変換するという作業プロセスを単純化します。このニーズはもともと Web で生まれました。開発者は、XML データを HTML に変換して、ユーザーが表示できるようにする必要があったのです。

しかし、XSL はそれ以上のものになりました。XSL は、特定の XML 形式から別の XML 形式への変換の定義に非常に役立ちます。これは相互運用性をはるかに現実的なものにします。あなたのシステムで予期されている正確な XML ボキャブラリを使用していない XML 文書が誰かから送られてきた場合は、XSL 変換を行えば、望ましいボキャブラリが生成されます。XML の単純さから、開発者は、特定のタイプのデータを記述するために普遍的なボキャブラリについて合意する必要はありません。

XSL ファイルは、変換ルールを定義する説明テンプレートのリストを含んでいます。それぞれのテンプレートは、ソース文書のノードを出力文書のノード (または何か他のタイプのデータ) にどのように変換したいかを正確に定義します。テンプレートの中で XSL Patterns を使用して、テンプレートが文書のどの部分に適用されるかを定義します。

たとえば、次のような hamburger XML ファイル

<?xml version="1.0"?>
<hamburgers>
  <hamburger lowfat="dream on">
    <name>CowBurger</name>
    <description>Greasy and good.</description>
    <price>2.99</price>
  </hamburger>
</hamburgers>

を、次のような HTML ファイルに変換するには:

<html>
<body>
<h1>hamburgers</h1>
<ol>
  <li>CowBurger, $2.99, Greasy and good.</li>
</ol>
</body>
</html>

次のような XSL ファイルを使用します。

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl=" http://www.w3.org/TR/WD-xsl ">
  <xsl:template match="/">
    <html>
    <body>
    <h1>hamburgers</h1>
    <xsl:for-each select="hamburgers[@lowfat="dream on"]>
      <li><xsl:value-of select="name"/>, <xsl:value-of select="price"/>, 
      <xsl:value-of select="description"/></li>
    </xsl:for-each>
    </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

さまざまな XSL 要素の match および select 属性の中で XSL Patterns を利用して、要素のセットを識別する方法に注目してください。<xsl:template> タグの中のテキストは、そのノード セットの変換ルールを定義します。興味深いことに、XSL は標準的な XML ボキャブラリを使用して変換プロセスを定義します。

リンキング テクノロジ

多くの人は、インターネットの真のパワーは HTML のアンカー要素にあると言うかもしれません。

<A HREF="http://www.someserver.com">some link</A>

アンカー要素によって、開発者は、ある HTML ページから別のページへのリンクを確立して、文書間の関係を定義することができます。これは、ユーザーが現在のページと同じテーマに関する追加データを取り出す手段となります。これは、ユーザーが探しているデータを見つける典型的な方法です。ユーザーは、探しているものに一致しそうなページに行きますが、そこには、さらに一致する別の文書へのリンクがあるというわけです。

Web は、個別のデータ ファイル間の関係を (リンクによって) 確立するという、この基本的な原理に基づいています。業界がデータの記述方法として XML に移行するにつれ、個別の XML 文書間、そして、おそらく単一の XML 文書内にある個々の要素間の関係も記述するための同様のメカニズムが必要になるのは当然のように思われます。

XML Linking 1.0 (XLink) は、XML リンクを定義するための構文の概略を定めた新しい W3C イニシアチブです。XLink 1.0 の要件文書によると、XML リンクは、XLink によって定義された記述的な情報だけでなく、リソースまたはリソースの持つ各部分の間の明示的な関係の仕様です。さまざまなタイプのデータ (URI、XPointer、グラフィック座標など) の場所を特定する具体的な識別方法は、XLink の範囲外です。

以下に、単純な XML リンクの例を示します。

<hamburger xml:link="simple" href="http://fastfood.org/hamburger.htm">
</hamburger>

XPointer

前の段落で述べたように、XLink はさまざまなメカニズムに依存して、リンク先のリソースを識別します (Uniform Resource Identifier など)。XPointer というもう 1 つの W3C イニシアチブは、XML 文書の内部構造をアドレス指定するための概念を指定します。特に、明示的な ID 属性を持つかどうかに関係なく、要素、文字列、および XML 文書のその他の部分への特定の参照を提供します。

XPointer は、それぞれが場所を指定する一連のロケーション用語から成り、通常は前のロケーション用語によって指定される場所に相対的です。それぞれのロケーション用語は、キーワードを持ち (id、child、ancestor など)、インスタンス番号、要素タイプ、または属性などの引数を持つことができます。たとえば、次の XPointer は:

child(2,hamburger)

タイプが hamburger である 2 番目の子要素を参照します。

XML 関連のその他のテクノロジとボキャブラリ

今までに述べてきたテクノロジは、XML の中核的テクノロジです。手始めとしてはもう十分だと思われるかもしれませんが、現在人気を得ているいくつかの XML テクノロジとボキャブラリを簡単に紹介しなければ、この資料を終わりにすることはできません。これらのテクノロジの多くは、現在、さまざまな W3C ワーキング グループで作業中です。

Mathematical Markup Language (MathML)

MathML は、数学的な表記法を記述して、その構造と内容の両方を捕捉するための XML アプリケーションです。MathML の目的は、HTML がテキストについて可能にしたのと同じように、Web での数学の提供、受信、および処理を可能にすることです。W3C 仕様から直接引用した下記の MathML の例を見てください。次の数式:

x2 + 4x + 4 =0

は、MathML では、次のような XML ボキャブラリを使用して表されます:

<apply>
   <plus/>
   <apply>
      <power/>
      <ci>x</ci>
      <cn>2</cn>
   </apply>
   <apply>
      <times/>
      <cn>4</cn>
      <ci>x</ci>
   </apply>
   <cn>4</cn>
</apply>

SMIL

Synchronized Multimedia Integration Language (SMIL、"スマイル" と発音します) は、マルチメディア プレゼンテーションを記述するための XML ベースの言語です。SMIL によって、独立したマルチメディア オブジェクトのセットを、同期されたマルチメディア プレゼンテーションに統合することができます。HTML+TIME は、SMIL 機能を利用して HTML ページにマルチメディアの "タイミング" 動作 (タイムライン記述など) を追加するための、もう 1 つの業界イニシアチブです。Internet Explorer 5 では、サンプルのような HTML+TIME 実装を提供しています。以下は、連続的なタイムラインを含んでいる Web ページの例です。タイムライン DIV の中のそれぞれの P 要素は、前の P 要素が消えた後で表示されます。

<HTML>
<HEAD>
<STYLE>
    .time { behavior:url(#default#time); }
</STYLE>
</HEAD>
<BODY>
<DIV CLASS="time" t:timeline="seq"> 
   <P class="time" t:dur="1">
   This appears for one second and goes away
   </P>
   <P class="time" t:dur="1">
   This appears after one second, remains visible for one second 
   and goes away
   </P>
   <P class="time" t:dur="1">
   This appears after two seconds, remains visible for one second 
   and goes away
   </P>
</DIV>
</BODY>
</HTML>

Vector Markup Language (VML)

Vector Markup Language (VML) は、ベクトル情報をエンコードするための形式と、その情報を画面に描画する方法を記述するための追加のマーク付けを定義する XML アプリケーションです。VML は、HTML がテキスト情報のマーク付けをサポートするのと同じように、ベクトル グラフィック情報のマーク付けをサポートします。一部の Microsoft 製品 (Microsoft PowerPoint® 2000 など) は、VML を使用してグラフィック情報を記述するために、HTML へのファイルのエクスポートをサポートしています。以下は、形状を定義する単純な VML の例です。

<v:shape style=‘top: 0; left: 0; width: 250; height: 250’
       stroke="true" strokecolor="red" strokeweight="2" fill="true"
       fillcolor="green" coordorigin="0 0" coordsize="175 175">
<v:path v="m 8,65     
  l 72,65,92,11,112,65,174,65,122,100,142,155,92,121,42,155,60,100
  x e"/>
</v:shape>

Channel Definition Format (CDF)

Channel Definition Format (CDF) は、Web 発行者が、頻繁に更新される情報の集まり、すなわちチャンネルを任意の Web サーバーから提供して、PC またはその他の情報機器の互換性のある受信プログラムに自動配信するためのオープンな仕様です。ユーザーは一度チャンネルを選択するだけでよく、その後はチャンネル情報のスケジュール配信がクライアントに自動的に配信されます。クライアントにダウンロードされるとき、CDF はそのチャンネルの利用可能なコンテンツのローカル インデックスの役目を果たします。Internet Explorer 4.0 のリリースによって、Microsoft はアクティブ チャンネルと呼ばれる CDF テクノロジの実装を導入しました。

XML Fragments

XML 仕様は、複数のエンティティで構成される論理的な文書をサポートしています。文書全体を表示または編集する必要はないが、1 つまたは複数のエンティティ、あるいはエンティティの一部を表示または編集したいことがよくあります。しかし、クライアントが文書全体を操作しなくてもよいように、文書の断片が存在している大きな文書の十分な文脈情報をクライアントに提供する手段が必要です。XML Fragments は、この目標を達成するための標準化されたメカニズムを定義しています。

XHTML

XHTML は、XML に準拠した新しい HTML 文書群です。XHTML 文書は、XML プロセッサと組み合わせて動作するように作られています。現在、Web ブラウザで表示されるほとんどの HTML ファイルは、整形式の XML 文書ではありません。たとえば、開始タグ <LI> だけがあり、終了タグ </LI> がないというのは、ごく一般的なことです。したがって、標準的な XML ツールを使用して HTML を操作するのは、不可能ではないとしても、非常に困難です。

XHTML 文書は整形式 (well-formed) の XML なので、標準の XML プロセッサで容易に表示、編集、および検証することができます。このため、軽量クライアント (Palm-size PC など) でのエラー条件の処理もはるかに容易になります。

XHTML 仕様で述べられているように、XHTML 1.0 に準拠している XHTML 文書は、1 つの XHTML 環境の中でも、そして複数の環境にまたがっても、相互運用できる可能性が高いでしょう。XHTML ファミリは、インターネットの進化における次のステップです。今、XHTML に移行しておくことによって、コンテンツ開発者は、XML の世界に入ってそのすべてのメリットを享受できるだけでなく、コンテンツの後ろ向きの、そして未来の互換性に自信を持ち続けることができます。

まとめ

上に挙げた以外にも多くの XML 関連テクノロジがありますが、それらについては、みなさんがご自分で調べてください。ご存じのように、XML とその関連テクノロジの進化には、業界規模の莫大な努力が傾注されています。

XML は、相互運用可能なソフトウェアの作成方法を変える運命にあります。XML がソフトウェア コンポーネント テクノロジに与える影響については、「コンポーネント戦争から学ぶこと: XML に関しての声明」を参照してください。

この膨大な量の XML 情報を吸収するのは容易ではありません。それぞれが全体図のどこに当てはまるのか、理解するのが難しいからです。この資料では、XML と XML サポート テクノロジ群を紹介しました。コア テクノロジのそれぞれが、全体図のどこに当てはまるのか、どんな XML サポート テクノロジがあるのか、理解していただけたと思います。あなたにとって最も興味ある XML テクノロジを深く追求する準備ができました。楽しんでください！

参考資料

W3C 仕様と勧告

書籍

XML In Action, by William J. Pardi,Microsoft Press

. ISBN:0-7356-0562-9