知っておくべき 10 の XML スキーマ

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Martin Brown, Developer and writer, Freelance

2008年 7月 01日

この記事で取り上げるのは、Web サービスの基本からデータ記述に至るまで、あらゆる類の問題を解決する選り抜きの XML スキーマです。また、連絡先や請求書が関係するデータベースのようなソリューションについても説明します。ここに記載するスキーマは、その利便性と実用性だけでなく、情報を XML 形式でどのように共有し、どのように交換するかという点で XML コミュニティーに与えている影響も考慮して選択したものです。

SOAP

よく使われる頭字語 Ajax: Asynchronous JavaScript + XML CPU: Central Processing Unit CSS: Cascading Stylesheets HTML: Hypertext Markup Language OASIS: Organization for the Advancement of Structured Information Standards PDF: Portable Document Format W3C: World Wide Web Consortium XHTML: Extensible HyperText Markup Language XML: Extensible Markup Language XSLT: Extensible Stylesheet Language Transformations

SOAP (Simple Object Access Protocol) は実際には Web サービス技術ですが、Web サービスのクライアントとサーバーとの間でのデータ交換フォーマットには、柔軟性の高い XML スキーマが使用されています。

Web サービスの大きな利点の 1 つは、クライアントとサーバーがネットワークを介して交換する情報およびデータの相互運用性レベルです。SOAP 標準は XML を利用して、データの構造化や、アーキテクチャーに依存しないフォーマットでのデータ型および情報の定義を行います。

選択したプログラミング言語によって指定するのは、データ型とリモート・サーバーから呼び出す関数の名前だけです。ホストの言語とフォーマットによるこの情報は、SOAP ライブラリーによって、呼び出された関数と指定された引数が含まれる XML 形式のメッセージに変換されます。

SOAP の構造は、W3 Consortium による例を見れば理解できるはずです。リモート SOAP 関数 GetEndorsingBoarder() を呼び出すと、呼び出し側クライアントはリスト 1 のような XML メッセージを生成します。

                
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
      <manufacturer>K2</manufacturer>
      <model>Fatbob</model>
    </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

このように、SOAP クライアントによって送信されるメッセージ全体が、SOAP エンベロープとして知られるものにエンコードされます。このエンベロープの中身が、メッセージの詳細な内容を構成します。

呼び出されるメソッドは GetEndorsingBoarder として明確に特定され、manufacturer と model という 2 つの引数を受け入れます。このことから、おそらくバイナリーをベースとしたネイティブ・フォーマットのストリングが XML ストリングに変換される仕組みがわかるはずです。XML はプラットフォームに依存しないため、SOAP システムを使用したホストは、複雑なバイナリー・エンコードやバイナリー・デコードを行わなくてもメッセージを交換できるというわけです。

サーバーからのレスポンスは、XML にエンコードされた別の SOAP エンベロープとして送り返されます。この場合のエンベロープに含まれるのは、関数からの戻り値です。SOAP リクエストに対するレスポンスは常に、同じ関数でフォーマット設定され、エンベロープ詳細の最後に Response が追加されます (リスト 2 を参照)。

                
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
      <endorsingBoarder>Chris Englesmann</endorsingBoarder>
    </m:GetEndorsingBoarderResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

一般に、このような SOAP メッセージを自分で作成することはありません。SOAP ライブラリーが自動的に処理してくれるからです。しかし、この SOAP エンベロープの構造と単純さが、SOAP を使用して情報を共有することがいかに簡単かを明らかにしています。

SOAP のおかげで、メッセージを交換し、リモート関数を呼び出す方法は大幅に簡易化されました。RPC (Remote Procedure Call) 標準では、バイナリー・データのシリアライズを処理するには複雑な方法が必要です。さらに、より構造化された情報を送信するには、そのソースとなる情報をそれぞれの方法で詳細に宣言して変換しなければならなくなります。

SOAP を使用すれば、XML にシリアライズすることによって、この複雑な作業の多くが不要になり、プラットフォームにも言語にも依存しない統合とデータ交換が極めて容易になります。

上に戻る

WSDL

WSDL (Web Services Description Language) は、Web サービス (大抵の場合は、SOAP を使用) を記述するのに便利な手段です。WSDL では、SOAP 標準によって使用可能になったサービスとインターフェースを記述することができます。

例えば、ある 1 つの サーバーで使用可能になっているサービスを記述する WSDL ファイルを作成し、このファイルをこれらのサービスを使用しなければならない Web サービス・コンシューマーに配布するとします。コンシューマーはこの WSDL ファイルを読み取って解析することで、交換可能なデータ型と引数、そして返される各種エラーやその他の情報を始めとするこれらの Web サービスを使用する方法について知っておかなければならないすべての情報を入手することができます。

ここでも同じく W3 Consortium の例を引用して、さまざまなリモート関数の宣言、そして交換対象のデータがすべて、XML による構造の定義を通じて処理されることを説明します。リスト 3 を見てください。

                
<?xml version="1.0"?>

<!-- root element wsdl:definitions defines set of related services -->
<wsdl:definitions name="EndorsementSearch"
  targetNamespace="http://namespaces.snowboard-info.com"
  xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
  xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

  <!-- wsdl:types encapsulates schema definitions of communication types; 
                                                       here using xsd -->
  <wsdl:types>

    <!-- all type declarations are in a chunk of xsd -->
    <xsd:schema targetNamespace="http://namespaces.snowboard-info.com"
      xmlns:xsd="http://www.w3.org/1999/XMLSchema">

      <!-- xsd definition: GetEndorsingBoarder [manufacturer string, 
                                                        model string] -->
      <xsd:element name="GetEndorsingBoarder">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="manufacturer" type="string"/>
            <xsd:element name="model" type="string"/>
    </xsd:sequence>
  </xsd:complexType>
      </xsd:element>

      <!-- xsd definition: GetEndorsingBoarderResponse 
[... endorsingBoarder string ...] -->
      <xsd:element name="GetEndorsingBoarderResponse">
  <xsd:complexType>
    <xsd:all>
      <xsd:element name="endorsingBoarder" type="string"/>
    </xsd:all>
  </xsd:complexType>
      </xsd:element>

      <!-- xsd definition: GetEndorsingBoarderFault 
[... errorMessage string ...] -->
      <xsd:element name="GetEndorsingBoarderFault">
  <xsd:complexType>
    <xsd:all>
      <xsd:element name="errorMessage" type="string"/>
    </xsd:all>
  </xsd:complexType>
      </xsd:element>

    </xsd:schema>
  </wsdl:types>

  <!-- wsdl:message elements describe potential transactions -->

  <!-- request GetEndorsingBoarderRequest is of type GetEndorsingBoarder -->
  <wsdl:message name="GetEndorsingBoarderRequest">
    <wsdl:part name="body" element="esxsd:GetEndorsingBoarder"/>
  </wsdl:message>

  <!-- response GetEndorsingBoarderResponse is of type 
                                       GetEndorsingBoarderResponse -->
  <wsdl:message name="GetEndorsingBoarderResponse">
    <wsdl:part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
  </wsdl:message>

  <!-- wsdl:portType describes messages in an operation -->
  <wsdl:portType name="GetEndorsingBoarderPortType">

    <!-- the value of wsdl:operation eludes me -->
    <wsdl:operation name="GetEndorsingBoarder">
      <wsdl:input message="es:GetEndorsingBoarderRequest"/>
      <wsdl:output message="es:GetEndorsingBoarderResponse"/>
      <wsdl:fault message="es:GetEndorsingBoarderFault"/>
    </wsdl:operation>
  </wsdl:portType>

  <!-- wsdl:binding states a serialization protocol for this service -->
  <wsdl:binding name="EndorsementSearchSoapBinding"
                type="es:GetEndorsingBoarderPortType">

    <!-- leverage off soap:binding document style ...(no wsdl:foo pointing at 
the soap binding) -->
    <soap:binding style="document"
                  transport="http://schemas.xmlsoap.org/soap/http"/>

    <!-- semi-opaque container of network transport details classed by 
soap:binding above ... -->
    <wsdl:operation name="GetEndorsingBoarder">

      <!-- again bind to SOAP? ... -->
      <soap:operation soapAction="http://www.snowboard-info.com/
EndorsementSearch"/>

      <!-- further specify that the messages in the wsdl:operation 
"GetEndorsingBoarder" use SOAP? ... -->
      <wsdl:input>
        <soap:body use="literal"
       namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"
       namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </wsdl:output>
      <wsdl:fault>
        <soap:body use="literal"
       namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>

  <!-- wsdl:service names a new service "EndorsementSearchService" -->
  <wsdl:service name="EndorsementSearchService">
    <wsdl:documentation>snowboarding-info.com Endorsement Service</
wsdl:documentation> 

    <!-- connect it to the binding "EndorsementSearchSoapBinding" above -->
    <wsdl:port name="GetEndorsingBoarderPort"
               binding="es:EndorsementSearchSoapBinding">

      <!-- give the binding an network address -->
      <soap:address location="http://www.snowboard-info.com/EndorsementSearch"/>
    </wsdl:port>
  </wsdl:service>

 </wsdl:definitions>

上記のように、WSDL はメッセージ・タイプ、障害タイプとコンテンツ、そして交換されるデータの構造を宣言します。

SOAP インターフェースを使ってサーバーにアクセスするために必要なものはすべて、WSDL に揃っています。このような WSDL を読み込んで解析し、どんな関数を使用でき、どんなデータ交換を行えるのかを判断するメカニズムは、ほとんどの言語と環境に備わっています。

WSDL は情報を交換するための SOAP インターフェースを定義するだけではありません。適切な WSDL 生成プログラムを使用すれば、リクエストの送信に加え、レスポンスの生成、フォーマット設定を行うために必要なコードを WSDL で作成することもできます。

WSDL と SOAP を組み合わせることで、強力なリモート・プロシージャー・コール・システムが実現します。

上に戻る

RDF

セマンティック Web 技術とセマンティック・グリッド技術は、どちらも RDF (Resource Description Framework) が提供する柔軟な記述言語に依存しています。RDF 形式は実際には標準群であり、システムは RDF 形式を利用して情報およびリソースを記述すると、異なるリソース同士を容易に結び付けて関連付けられるようになります。

RDF も同じく W3C に承認された標準で、情報およびリソース定義の標準となっています。RDF には XML は必須でありませんが、情報を記述するために用いるシリアライズ・フォーマットの 1 つには XML を使用します。

リソースを定義するには、主語、述語、目的語で構成された表現を指定します。例えば Web サイトのコンテンツを記述する場合、主語には Web サイト、述語には「～に関する情報を含む」、目的語にはコンテンツ・タイプを指定するといった具合です。Web サイトを別のリソースに関連付ける場合は、FOAF (Friend of a Friend) 表記で 2 つのリソース間のリンクを作成します。

RDF の目的は、自然言語の文で表したリソースと情報についての内容を、コンピューターが解析できる形式にマッピングすることです。一例として、The MCSLP.com Website is authored by Martin C Brown という文は、リスト 4 のような RDF XML にリライトすることができます。

                 
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
xmlns:si="http://www.recshop.fake/siteinfo#">
  <rdf:Description rdf:about="http://www.mcslp.com/ ">
    <si:author>Martin C Brown</si:author>
</rdf:Description>
</rdf:RDF>

RDF 標準の実用性は、ニュース・サイトやブログの初期の配信システムでは、フィードの内容と個々のニュースやブログ・エントリーを定義するために RDF 仕様を採用したという事実にも示されています。リスト 5 に、定義の一例を記載します。

                
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/">

  <channel>
    <title>MCslp</title>
    <link>http://www.mcslp.com</link>
    <description>MCslp Projects</description>
  </channel>


  <item>
    <title>Voice enabling XMLtitle>
    <link>http://mcslp.com/?p=295link>
  </item>

...

</rdf:RDF>

RDF 標準は元々、Web 上のリソース、コンテンツ、関係を記述するという特定の目的で設計されたものですが、今では一般的な情報、リソース、関係を記述するための標準として RDF が使用されるようになっています。

セマンティック Web 技術とセマンティック・グリッド技術ではいずれもリソースと関係の定義に依存して、アプリケーションが情報のさまざまな部分を使用し、そのデータを結合することを可能にしています。

上に戻る

vCard

連絡先情報の記録は、ほとんど例外なく、あらゆるビジネス・アプリケーションに不可欠の部分です。この情報を効率的な XML 構造で取り込むことで、データの操作は極めて容易になります。

連絡先情報に XML を使用するのが明らかに適している理由は、連絡先情報には大幅な多様性があるためです。例えば、会社や個人が複数の住所、電話番号、E メール・アカウントを持っている場合もありますが、このような複数の情報フラグメントでも、XML 構造のなかでなら簡単に宣言することができます。

vCard 構造は、プラットフォームに依存することなく簡単に生成して異なるアプリケーションにインポートできる連絡先情報を表現するための手段として、インターネットでよく使用されています。この構造は XML 構造の柔軟性をある程度サポートしますが、実際には単純なテキスト・ベースの形式であり、宣言されたフィールドとその拡張を使用して情報を提供します。XML とは異なり、vCard 形式はフラット・ファイルであるため、異なる要素に情報を直接追加することはできません。その好例は、電話番号です。住所と明示的に関連付けることのできない電話番号は、そのレコードのもう 1 つの電話番号として識別されるだけです。

W3 Consortium が提案する vCard 形式の XML 表現は、実際には RDF XML 標準をベースとしているため、連絡先情報を簡単にフォーマット設定して交換することができます。RDF をフレームワークとして使用することで、宣言のなかで一部の構造情報を保持できるようにしているからです。例えば、RDF 標準ではデータ宣言での Bag、Sequence、Alternative の使用をサポートします。Bag はオブジェクトに対する複数の宣言 (複数の役割など) をサポートし、シーケンスが重要でない場合に使用することができます。Sequence がサポートするのは、オブジェクトに定義されたシーケンス (組織内での個人の役割階層など) です。Alternative は、リスト (複数の E メール・アドレスなど) から 1 つの項目を選択できるようにします。

リスト 6 は、架空の人物、Charles Perston の標準的な vCard です。

                
BEGIN:VCARD
VERSION:3.0
N:Perston;Charles;;;
FN:Charles Perston
ORG:Perston Technology;
EMAIL;type=INTERNET;type=WORK;type=pref:null@perston.co.uk
TEL;type=WORK;type=pref:01234 567890
item1.ADR;type=WORK;type=pref:;;Perston House;Perston;Perstonshire;P1 0NS;UK
item1.X-ABADR:gb
X-ABUID:5AE47BB6-4E0F-4558-980C-BD3066FA6154\:ABPerson
END:VCARD

一方、vCard XML 標準を使用すると、上記と同じ情報をリスト 7 の構造で表現することができます。

                
<vCard:vCard xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
  xmlns:foaf="http://xmlns.com/foaf/0.1/" vCard:version="3.0"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" vCard:class="PUBLIC"
  xmlns:vCard="x-urn:cpan:ascope:xml-generator-vcard#">
  <vCard:fn>Charles Perston</vCard:fn>
  <vCard:n>
    <vCard:family>Perston</vCard:family>
    <vCard:given>Charles</vCard:given>
  </vCard:n>
  <vCard:adr vCard:del.type="pref;work">
    <vCard:street>Perston House</vCard:street>
    <vCard:locality>Perston</vCard:locality>
    <vCard:region>Perstonshire</vCard:region>
    <vCard:pcode>P1 0NS</vCard:pcode>
    <vCard:country>UK</vCard:country>
  </vCard:adr>
  <vCard:email vCard:email.type="internet;pref;work">null@perston.co.uk
                                                         </vCard:email>
  <vCard:org>
    <vCard:orgnam>Perston Technology</vCard:orgnam>
  </vCard:org>
</vCard:vCard>

XML フォーマットの場合は冗長になりますが、目にしている内容、そしてコンポーネント相互の関係がどのように機能しているのかが理解しやすくなります。さらに、XML のフォーマットではより具体的な情報と詳細がわかります。例えば、住所を見れば容易にどの国かが特定できますが、これは、標準 vCard 出力では比較的わかりにくかったデータです。

XPath または SAX イベントを使用すると簡単に国のリストを抽出できるので、そのリストから場所ごとの連絡先の数を調べることもできます。

上に戻る

DocBook XML

多くの組織にとって、文書を作成し、それからその文書をさまざまなフォーマットで出力できるようにすることは長年の夢でしたが、この夢を現実にするのが DocBook XML です。しかも DocBook XML では、今までと同じくセマンティック・マークアップを維持することも、文書のフォーマット設定および出力を制御することもできます。

セマンティックな制御をするためには、文書を構成するさまざまなチャプター、セクション、パラグラフを指定して文書を作成します。パラグラフ内に含める項目については、さらに具体的にすることができます。例えば、コマンド名と関数名をそれぞれ独自のタグにカプセル化することが可能です (リスト 8 を参照)。

                
<para>The <command>compile</command> takes the source code of the 
material and builds a new class based on the filename. For example, if the filename is
<filename>HelloWorld</filename> then the name of the class generated will be
<classname>HelloWorld</classname>.

生成された個々の要素については、それぞれに異なる出力スタイルとフォーマットを選択することも、共通した出力スタイルとフォーマットを使用することもできます。さらに重要なことは、セマンティック情報が返されるため (文書にクラス名の参照が含まれるなど)、索引を作成するときにこのセマンティック情報を使用して、文書で詳説されているすべてのクラス名のリストを作成できるという点です。

このようなセマンティック・マークアップに加え、文書を構成する個別のセクションとコンポーネントに固有の ID でマークを付け、これらの ID を使って文書のさまざまな部分の間にリンクを設定することもできます。特定の構成要素のタイプ (最終的に目次を生成するセクション、チャプター、パートなどのタイプ) には自動的にリンクが設定されますが、その他のタイプについては必要に応じて他のセクションへの明示的リンクを作成することができます。

対象のフォーマットへの変換が行われるときに、これらのリンクは自動的にそのターゲットに適したフォーマットに変換されます。例えば生成するのが HTML であれば、リンクは該当する HTML ページへのリンク、あるいはそのページ内のアンカーに変換されます。PDF を生成する場合には、対象セクションのページ番号を組み込むことができます。

このような変換は、XSLT スタイルシートによって処理されます。XML に使用できる標準 DocBook XSLT スタイルシートは、すでに情報を標準 HTML、XHTML、PDF (FO 標準を使用)、Texinfo、Java™ ヘルプ、そしてマニュアル・ページに変換できるようになっています。この標準スタイルシートは、原文書をブックから A4、さらにはスライドに至るまでの各種のサイズとスタイルで出力する場合にも使用できます。

このさまざまな出力フォーマットとマークアップに対応した柔軟性は、文書を作成する際に、同じ文書ソースから印刷版マニュアル、組み込みヘルプ、マニュアル・ページ、コンテキストに応じたオンライン情報を作成できることを意味します。従来のモデルを使用して、これらの要素をそれぞれ個別に作成することもできます。

DocBook XML は技術文書コミュニティーで幅広く支持されており、さまざまな企業で DocBook XML 標準 (あるいはそのサブセット) を使用して、すべての文書を作成しています。

上に戻る

FIXML

FIX は、金融機関相互の情報交換を可能にする数ある B2B の情報交換フォーマットのうちの 1 つです。金融機関の間で行われる情報交換の多くは、口座間取引での送金から、株価および売買情報の単純な交換に至るまで、極めて重要なものです。

転送を必要とするこうした情報は、比較的小さな不連続のパケットでしかないことも、あるいはそれより遥かに大きなデータ・ブロックであることもあります。このような情報を交換する際に従来使われていたのは、データの単純なキーと値のペアでしたが、この形式では交換される情報のサイズによっては非効率的です。そこで、複合データの場合をはじめ、XML を使用することによってデータ構造の単純化が実現されました。

XML によるデータ交換で最適化されたバージョン、FIXML を使用することで、開発者はデータ・ファイルのサイズを劇的に減らすと同時に、人間が読みやすいファイルにすることができました。株価データの交換の場合、サイズは旧フォーマットを使用した場合の約 4分の1 にまで縮小されます。

典型的な金融機関でなければ、FIXML はほとんど関係しませんが、FIXML の使用によって一層効率的な情報のやり取りが可能になれば、最終的には誰もがそのメリットを享受することになります。

上に戻る

SVG

SVG (Scalable Vector Graphics) は、イラストを記述するための XML 標準です。SVG では、線、形状、位置、そしてこれらの要素間の関係を記述することができます。とりわけ大きな利点となっているのは、この情報を拡大縮小可能な図形などの必要に応じた形式で出力したり、固定サイズの図形として出力したりできることです。

SVG は、イラストを対象とした従来の稼動プロセスにおける重大な問題の数々を解決します。通常、イラストは専用に作られたイラスト作成プログラムを使って作成されます。そのため、異なるプログラム間で情報およびイラストを共有するのが極めて難しい場合がよくあります。ファイルを SVG で保存するということは、SVG に対応するあらゆるアプリケーションがファイルを読み取って操作できることを意味します。

イラストに関するもう 1 つの問題は、イラストのほとんどの出力形式 (特に Web) では、イラストをビットマップ・ベースの形式 (JPEG、PNG など) で描画してからでないと、表示したり、別の文書に組み込んだりすることができないという点です。この従来の手法には、いくつもの問題があります。まず、オリジナルのイラストに対する変更は、明示的に (そして大抵は手動で) ビットマップ形式にエクスポートしなければなりません。

さらに、ビットマップ形式はオリジナルの描画を縦横のピクセル値で示した表現に基づくため、生成後の画像の品質を確実にするためには、生成されたファイルのサイズと解像度を出力ターゲットと一致するように慎重に選択しなければなりません。例えば、ほとんどのモニターの標準解像度と合わせるには、画面上の解像度を 72dpi (or 96dpi) にする必要があります。印刷出力の場合には、ビットマップ・バージョンを 300 から 2400 dpi にします。その結果、画像を生成すると、ソース記述に比べて遥かに大きなファイルが生成されてしまう可能性があります。

ベクトル・ベースの形式は、PostScript や Encapsulated PostScript 以前からありましたが、この形式は CPU を酷使するため、画面上の表現には非効率的だとされていました。

ベクトル・グラフィックス形式の例に漏れず、SVG では縦横のピクセル値による表現を作成する代わりに、異なる形状のリストをベースに画像の内容を記述します。例えば SVG で四角形を記述するには、左上の角の開始点を指定してから、2 つの辺の長さを指定します。SVG での画像の記述は、XML で表現されます。線、四角形、多角形、円などの記述にはそれぞれ専用のタグが用意されていて、さまざまな要素のスタイルとフォーマット設定を完全に制御できるようになっています。

リスト 9 に、その一例を記載します。ここで描画されているのは、単純な正方形と、透明な円と三角形です。

                
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">

<polygon
points="200,100 300,200 150,250"
style="fill:#cccccc;
stroke:#000000;stroke-width:1"/>

<rect x="20" y="20" width="250" height="250"
style="fill:blue;stroke:black;stroke-width:1;
fill-opacity:0.1;stroke-opacity:0.9"/>

<circle cx="100" cy="50" r="40" stroke="red"
fill="red" style="fill-opacity:0.5"/>

</svg>

図 1 は、ビットマップ形式で描画された図形です。

SVG ファイルとしては、画像の記述がわずか 500 バイト余りで済むのに対し、PNG の場合は約 9KB となっています。

SVG を使用することで、イラストのサイズが縮小されて使いやすくなり、より広範なアプリケーションに対応できるようになります。

上に戻る

Dublin Core

Dublin Core 標準は、ライブラリーで最も一般的に使用される情報を分類するための手段です。Dublin Core 標準と連動して、このような一般情報を XML で定義するための XML スキーマもあります。Dublin Core を使用してあらゆる類の情報を効率的にカタログ化すると、更新するのも、照会を行って使用するのも簡単な情報になります。

セマンティック Web が実現しているのは、情報の記述と定義のなかで現在 Dublin Core が使われているおかげです。普遍的な標準に従ってデータを記述し、さらに重要なことには明確に定義された実証済みのソリューションを適用することで、別の XML 文書にデータを詳細に記述し、その情報をさまざまなソースの間で効率的に交換、比較することが可能になるからです。

Dublin Core 仕様には独自のスキーマがありますが、これは大規模な XML 文書の一部となるように設計されており、XML 名前空間を使って、残りの文書のデータを記述するのに必要な DC 要素を定義します。その一例として、Web サイトなどの RDF エンティティーのコンテンツを記述するために、RDF XML スキーマ内で DC 分類システムがどのように使用されているかを見てください (リスト 10 を参照)。RDF エンティティーのコンテンツは、RDF スキーマの例で使用した構造を拡張することによって記述することができます。

                
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rss:channel rdf:about="http://www.xml.com/xml/news.rss">
    <rss:title>MCSLP</rss:title>
    <rss:link>http://mcslp.com/rss </rss:link>
    <dc:description>
      MCSLP features information, projects and articles from members of the MCSLP team.
    </dc:description>
    <dc:subject>MCSLP, Grids, XML, Databases, Programming </dc:subject>
    <dc:identifier>http://www.mcslp.com</dc:identifier>
    <dc:publisher>MCSLP</dc:publisher>
    <dc:rights>Copyright 2008, MCSLP</dc:rights>


</rdf:RDF>

リスト 10 では DC 要素で記述、主題、公開者、権利、そして識別情報を追加して、RSS フィードのコンテンツを分類できるようにしています。

Dublin Core Metadata Elements Set は、全部で 15 のメタデータ要素からなります。

1. タイトル (Title)
2. 作成者 (Creator)
3. 主題 (Subject)
4. 記述 (Description)
5. 公開者 (Publisher)
6. 寄与者 (Contributor)
7. 日付 (Date)
8. タイプ (Type)
9. 形式 (Format)
10. 識別子 (Identifier)
11. 出処 (Source)
12. 言語 (Language)
13. 関係 (Relation)
14. 対象範囲 (Coverage)
15. 権利 (Rights)

上記の要素によって、情報を自由に記述することができます。

上に戻る

XForms

XForms XML 標準を使用することによって、フォームを構成するさまざまなコンポーネント (フィールド、データ入力タイプ (ラジオ・ボタンなど)、リスト) と、そのフォームに指定されなければならない情報の妥当性検査を定義することができます。

XForms XML 標準は、多くの Web 開発者にはすでにお馴染みの HTML および XHTML フォームのマークアップに非常によく似ているため、XHTML 2.0 標準に統合されることになるはずです。

XForms XML がベースとしているのは単純なモデル・ビュー・コントローラー形式で、この形式では、モデルがフォーム、フォームのフィールド、入力の制約、および該当するデータの送信モードをすべて記述します。ビューはフォームに表示されるコントロール、そのグループ分け、そして参照するモデル内のフィールドを定義します。フォーム上のコントロールごとのフォーマット設定、レンダリングは、CSS によって処理します。

XForms 標準は、フォームに一層具体的な情報の分類を指定することで、通常の HTML フォーム定義を拡張しています。フォームのデータ設定中に動的要素を使用することもできます (現在は、JavaScript または Ajax 要素によってのみサポートされるのが通常です)。

リスト 11 に、単純なテキスト・エントリーとポップアップ選択ボックスの例を記載します。

                
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xforms="http://www.w3.org/2002/xforms">
   <head>
    <title>XForms Sample</title>
    <xforms:model>
  <xforms:instance>
    <Name xmlns="">
      <FName />
      <LName />
      <Title />
    </Name>
  </xforms:instance>
    </xforms:model>
   </head>
   <body>
<xforms:select1 ref="Title">
  <xforms:label>Title:</xforms:label>
  <xforms:item>
    <xforms:label>Mr</xforms:label>
    <xforms:value>Mr</xforms:value>
  </xforms:item>
  <xforms:item>
    <xforms:label>Mrs</xforms:label>
    <xforms:value>Mrs</xforms:value>
  </xforms:item>
</xforms:select1>
    <xforms:input ref="FName">
      <xforms:label>First name: </xforms:label>
    </xforms:input>
    <xforms:input ref="LName">
      <xforms:label>Last name: </xforms:label>
    </xforms:input>
    <hr />
    <xforms:output value="concat('Hello ',Title,' ',FName,' ',LName)">
      <xforms:label>Output: </xforms:label>
    </xforms:output>
   </body>
</html>

Firefox XForms 拡張機能を使用すると、XForms フォームを HTML で表示することができます。図 2 は、その一例です。

上に戻る

カスタマーへの請求書送付

多くのビジネス・プロセスにとって古くから問題になっているのは、カスタマーへの請求書送付システムを紙ベースの構造からコンピューター・プロセスに移行することです。適切に機能する請求書構造を作成するには、さまざまなタイプと繰り返しの要素を慎重に検討しなければなりません。

かつて、請求書のようなビジネス情報を交換するために、非常に大規模な構造と定義を作成していました。請求書情報の交換を対象とした国際標準には、数百もの考えられる情報分野が含まれているからです。このような情報の場合、効率的な交換手段がなければ、請求書や注文書、そしてその他のデータの共有は難しくなります。

広く受け入れられている標準がなかったため、多くの組織ではコアとなる請求書標準のさまざまなバージョンを作成し、推奨することとなりました。これらのバージョンのうち、おそらく最も知名度が高いのは OASIS グループが開発したものです。多くの企業と組織では、このバージョンを支持しています。

この構造は、OASIS が開発した UBL (Universal Business Logic) という大規模なフレームワークの一部となっており、これにはスキーマと併せ、注文処理から請求書送付、支払いに至るまでのすべてを対象としたワークフローが組み込まれています。このシステムはこの記事のなかだけで説明するにはあまりにも複雑ですが、柔軟性に優れた相互運用可能なシステムが必要な場合には、UBL が最適な出発点となります。

上に戻る

まとめ

この記事では、単純な記述フレームワーク (RDF) から、グラフィックス形式 (SVG)、さらにはビジネス・ワークフローの全体的構造 (UBL) に至るまでの、あらゆる機能と構造を提供する多種多様な XML スキーマを取り上げました。それぞれのケースで説明したように、XML 標準の柔軟な構造とコンテンツは、システム開発を極めて容易にします。さらに、XML はプラットフォームに束縛されない優れた互換性により、異なるプラットフォーム間や環境間でデータを共有するには理想的な手段です。WSDL および SOAP では、XML が最も重要な機能の 1 つとなっています。

参考文献

• XML.org: SOAP、WSDL、SVG をはじめ、広範な XML スキーマおよび標準に関する情報を参照するには、このサイトにアクセスしてください。
  
  
• OASIS Universal Business Logic (UBL): XML を使用した完全な注文処理システムとワーフクローについて学んでください。
  
  
• XForms 標準: W3 Consortium が扱っているこの XML 標準について学んでください。
  
  
• Dublin Core Metadata Initiative (DCMI): XML 文書内で情報を記述する Dublin Core システムを開発し、仕様を作成している組織のホーム・ページにアクセスしてください。
  
  
• Scalable Vector Graphics (SVG): このベクトル形式でグラフィックスを記述するための標準に関する情報を入手してください。
  
  
• vCard XML: XML を使用して相互運用可能な連絡先情報を表現するための標準について学んでください。
  
  
• 「Introduction to XML」(Doug Tidwell 著、developerWorks、2002年8月): この古典的チュートリアルで、XML 形式の基礎知識を身につけてください。
  
  
• 「SOAPアプリケーションでWSDLを活用する方法」(Uche Ogbuji 著、developerWorks、2000年11月): SOAP プログラマーを対象とした、この優れた WSDL 入門書を読んでください。
  
  
• 「Introduction to Scalable Vector Graphics」(Nicholas Chase 著、developerWorks、2004年3月): 基本形状、パス、テキスト、モデルの色付け、そしてアニメーションとスクリプト作成をはじめ、SVG 文書を作成するために必要となるコンセプトを学んでください。
  
  
• 「XForms を理解する」(Kurt Cagle 著、developerWorks、2007年6月): XForms の背景について詳しく調べてください。
  
  
• 「An introduction to RDF」(Uche Ogbuji 著、developerWorks、2000年12月): RDF の由来、そしてスキーマから使用シナリオに至るまでの RDF の特徴を学んでください。
  
  
• 「SVGとXForms: 入門」(Antoine Quint 著、developerWorks、2003年11月): この 2 つの技術について、考えられる相乗効果に重点を置いて概説しています。
  
  
• IBM XML 認定: XML や関連技術の IBM 認定技術者になる方法について調べてください。
  
  
• XML Technical library: 広範な技術に関する記事とヒント、チュートリアル、標準、そして IBM Redbooks については、developerWorks XML ゾーンを参照してください。
  
  
• developerWorks technical events and webcasts: これらのセッションで最新情報を入手してください。
  
  
• technology bookstore: この記事で紹介した技術やその他の技術に関する本を参照してください。
  
  
• developerWorks podcasts: ソフトウェア開発者向けの興味深いインタービューとディスカッションを聞いてください。
  
  

• IBM 製品評価用トライアル・ソフトウェア: developerWorks から直接ダウンロードできるトライアル・ソフトウェアで、次のプロジェクトを構築してください。DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® によるアプリケーション開発ツールおよびミドルウェア製品のトライアル版が揃っています。
  
  

• XML ゾーンのディスカッション・フォーラム: XML 関連のフォーラムに参加してください。
  
  
• developerWorks XML zone: Share your thoughts: この記事についてのご意見、ご感想をお寄せください。このフォーラムを管理する XML ゾーンの編集チームは、読者からの投稿をお待ちしています。
  
  
• developerWorks blogs: developerWorks blogs から developerWorks コミュニティーに加わってください。

著者について

		Martin Brown は過去 8 年以上プロのライターとして活躍してきました。彼はさまざまな話題に関して数多くの本や記事を執筆しています。専門領域は広く、無数の開発言語やプラットフォーム (Perl、Python、Java、JavaScript、Basic、Pascal、Modula-2、C、C++、Rebol、Gawk、Shellscript、Windows、Solaris、Linux、BeOS、Mac OS/X その他) から、Web プログラミング、システム管理やシステム統合にまでわたります。彼は ServerWatch.com と LinuxToday.com、そして IBM developerWorks に頻繁に寄稿しており、また Computerworld や The Apple Blog などのサイトの他、Microsoftの SME (Subject Matter Expert) にもブロガーとして頻繁に寄稿しています。彼の連絡先は、彼の Web サイトhttp://www.mcslp.com です。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る