最近、W3CはXLinkという仕様のステータスを勧告に格上げしました。この記事では、XLinkを取り上げ、これをデータの表現と伝送を単純化するために使用する方法を説明します。

ところで、XLinkとは何か

W3CのXLink仕様を引用すると次のようになります。「XML Linking Language (XLink) は、リソース同士のリンクを作成および記述する目的で、XML文書に要素を挿入することを可能にする」。次いで仕様は、XLinkを使って定義されるリンクはHTMLのハイパーリンクに類似していると述べています。この主張のために、多くのプログラマーは、これが仕様の唯一の目的であると結論してしまいます。しかし、XLinkには大きな利益をもたらす別の使い方があります。すなわち、データ・リソース同士の関係を示すということです。

上に戻る

XLinkの使用例

大規模な製造会社で使用するような、典型的な注文追跡アプリケーションを考慮してみましょう。通常、注文を記述するXML文書には、注文した顧客、注文の状況、注文中の個々の品目、およびその数量と価格に関する情報が含まれているものです。消費者がこの文書を使用する方法は多岐に渡ることでしょう。会計課の担当者が注文データを要求する場合、関心があるのは顧客に請求する合計価格だけかもしれません。送り状に記載されている個々の品目の詳細は (数量と価格を別にすれば)、無関係でしょう。それとは対照的に、自分の注文を (おそらくはオンラインで表示しようとして) 要求する顧客は、より多くの情報を見たいと思うかもしれません。たとえば、品目に上の部品の、人間が理解できる名前などです。各顧客に全詳細を記した文書を伝送することは、必ずしも理にかなっているとは限りません。理想的なのは、注文の要点と (基本的な点だけに関心を持つ消費者向け)、より詳細な情報を入手するためのポインターだけを伝送することでしょう。XLinkは、これを達成するための優れた方法となります。

全詳細を記した文書はリスト1に示すようなものとなるかもしれません。

                
<?xml version="1.0"?>
<order>
  <orderDate>7/23/2001</orderDate>
  <shipDate>7/26/2001</shipDate>
  <customer>
    <customerID>18273</customerID>
    <customerName>Fred Q. Customer</customerName>
    <billingAddress>
      <address1>100 Main St.</address1>
      <city>Anywhere</city>
      <state>AZ</state>
      <zip>12345</zip>
    </billingAddress>
    <shippingAddress>
      <address1>800 Corporate Dr.</address1>
      <address2>Suite 314</address2>
      <city>Anywhere</city>
      <state>AZ</state>
      <zip>12345</zip>
    </shippingAddress>
  </customer>
  <lineItem>
    <part>
      <partID>W-127</partID>
      <partName>Widget</partName>
      <partSize>2-inch</partSize>
      <partColor>Blue</partColor>
    </part>
    <quantity>17</quantity>
    <unitPrice>0.20</unitPrice>
  </lineItem>  <lineItem>
    <part>
      <partID>S-387</partID>
      <partName>Sprocket</partName>
      <partSize>1-inch</partSize>
      <partColor>Red</partColor>
    </part>
    <quantity>31</quantity>
    <unitPrice>0.40</unitPrice>
  </lineItem>  
</order>

リスト1に示した完全な送り状は、消費者にとって不要な情報が含まれているだけでなく (消費者はそうした情報を単に破棄するだけでしょう)、データを保管するためにXMLをそのまま使った場合、問題を引き起こす可能性もあります。つまり、各文書に各部品の詳細を組み込むなら、部品の情報の繰り返しでディスク・スペースが無駄になってしまうということです。しかし、ここでは、情報をオンデマンドでリレーショナル・データベースから引き出すものとします。この種の情報を保持するデータベースは、次の3つの主な表を持つように設計されているのが一般的です。すなわち、製造業者のすべての顧客を定義するCustomer表、製造業者が販売するすべての部品を記述するPart表、上記の2つの表を関連付けて、どの顧客がどの部品をいつ、どれほどの数量注文したかを示す、Order表です。ここから、上の文書を制御可能な部分に分割する方法に関するヒントが得られます。

これに従い、リスト2では、構造体の中のcustomer とpart を置き換えて、これらの要素だけを含んだ文書へのXLink参照としています。結果として作成される文書は、リスト2、3、4、5のようになるでしょう。

                
<?xml version="1.0"?>
<order xmlns:xlink="http://www.w3.org/1999/xlink">
  <orderDate>7/23/2001</orderDate>
  <shipDate>7/26/2001</shipDate>
  <customer xlink:href="customers/18273.xml">18273</part>
  <lineItem>
    <part xlink:href="parts/W-127.xml">W-127</part>
    <quantity>17</quantity>
    <unitPrice>0.20</unitPrice>
  </lineItem>
  <lineItem>
    <part xlink:href="parts/S-387.xml">S-387</part>
    <quantity>31</quantity>
    <unitPrice>0.40</unitPrice>
  </lineItem>  
</order>

                
<?xml version="1.0"?>
<customer>
  <customerID<18273</customerID>
  <customerName>Fred Q. Customer</customerName>
  <billingAddress>
    <address1>100 Main St.</address1>
    <city>Anywhere</city>
    <state>AZ</state>
    <zip>12345</zip>
  </billingAddress>
  <shippingAddress>
    <address1>800 Corporate Dr.</address1>
    <address2>Suite 314</address2>
    <city>Anywhere</city>
    <state>AZ</state>
    <zip>12345</zip>
  </shippingAddress>
</customer>

                
<?xml version="1.0"?>
<part>
  <partID>W-127</partID>
  <partName>Widget</partName>
  <partSize>2-inch</partSize>
  <partColor>Blue</partColor>
</part>

                
<?xml version="1.0"?>
<part>
  <partID>S-387</partID>
  <partName>Sprocket</partName>
  <partSize>1-inch</partSize>
  <partColor>Red</partColor>
</part>

この方法で情報を構造化することの明らかな利点をご理解いただけることでしょう。会計課が単に顧客18273に請求書を送付するに過ぎないのなら (それとともに、そのIDが会計ソフトウェアに含まれているなら)、必要な情報を入手するためにしなければならないのは、注文文書を検索することだけです。この情報が記載される文書は、余分の情報がすべて組み込まれていた元の文書 (リスト1) に比べて著しく小さくなります。アプリケーションをセットアップすることにより、送り状をオンラインで検索する顧客に対して自動的に生成された情報が表示されるようにしたり (ページをレンダリングするスタイル・シートは、初期レンダリング時に顧客と部品に関する詳細情報を入手できるでしょう)、詳細情報をハイパーリンクで表示して、顧客が横断できるようにしたりすることができるでしょう。ハイパーリンクで構造化された文書は、より柔軟で、よりアトミックなものとなります。消費者は関係のある部分だけを検索することができます。

この戦略は自分のシステムにとってどんな益があるだろうと考えられるかもしれません。第一に、データはリレーショナル・データベースに保管されることになるでしょう。データを、必要に応じてオンザフライで生成されるXML文書と一緒に、ネイティブのXMLデータベースに保管することはなくなります。このアプローチの利点を2つの方法で活用できます。顧客情報および部品情報が頻繁に更新されないのならば、顧客または部品が作成または生成された時点でそれらを表わすXML文書を生成できます。そうすれば、このデータが要求された場合に、コストのかかる余分なデータベース呼び出しを実行しないで済みます。これにより、リレーショナル・データベースにまったくアクセスせずに、顧客と部品のカタログを作成することもできます。ご使用のリレーショナル・データベースがURLアドレスでアクセス可能なら (大部分のリレーショナル・データベースはすでにこの機能を備えているか、近日中に備える予定です)、アクセス機構 (ストアード・プロシージャーなど) を作成し、オンザフライで情報の検索が可能になります。この点は、リスト6 の架空の例で示します。

上に戻る

結論

この記事は、XLinkの基本機能を使って文書構造を単純化したり、ネットワークの伝送オーバーヘッドを削減したりする方法を明らかにするものです。ここに示したのは単純リンクの使用法に過ぎません。XLinkには高度なリンク機能も備わっており、それを使えば多数のリソースを一緒に関連付けることができます (たとえば、XLinkのリンクベースを作成して、顧客とその注文すべてを関連付けることができるかもしれません)。XMLとそれを支援するテクノロジーが成熟するにつれ、プログラマーが情報システムのインプリメント方法を決定する際の柔軟性は広がり、クライアントの必要に最も合致する方法でソリューションを調整できるようになるでしょう。

参考文献

• XLinkについてさらに調べるには、W3C Recommendation をご覧ください。
  
  
• XLinkをハイパーリングまたは外部参照のために使用する方法について簡単に調べるには、Brett McLaughlinが最近記したヒントをご覧ください。
  
  
• 以下に挙げるKevin Williamsの以前の記事に精通してください。
  • データ用のXML:XMLスキーマのアーキタイプを使用する
  • データ用のXML:スキーマによるスタイリング
  • Soapbox:データ記述においてXML SchemaがDTDよりも優れている理由
  
  
  
• DB2 XML Extender と、DB2に組み込まれているXMLサポートについて調べてください。
  
  
• Solutions 2001 developer conference が8月13日から16日までサンフランシスコで開かれました。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ところで、XLinkとは何か
• XLinkの使用例
• 結論
• 参考文献
• 著者について
• コメント