レベル: 中級 James R. Fuller (jim.fuller@webcomposite.com), Technical Director, FlameDigital Limited & Webcomposite s.r.o.
2008年 6月 24日 2005年10月以来、W3C XML Processing Model ワーキング・グループ (WG) は協力して「XProc: An XML Pipeline Language」という仕様のワーキング・ドラフト (WD) に取り組んできました。初期の実装が姿を見せ始め、W3C WG による 2 回目のラスト・コール (W3C ドラフト勧告への前段階) が期待されることから、過去 12 ヶ月の間に XProc 仕様化作業のスピードを上げていたことが明らかになっています。この記事を読んで、XProc の現状と今後の動向、そして議論を起こしている問題の背景を理解してください。この記事では、いくつかのサンプル・コードも簡単に紹介します。
XProc は、XML 文書に操作を適用する個々のステップで構成された処理パイプラインを記述するマークアップ言語です。仕様の重要性が、その仕様に取り組む各人の能力に関連しているとしたら、XProc は実に重要な仕様と言えます。W3C XML Processing Model WG のメンバーには、Erik Bruchez、Andrew Fang、Paul Grosso、Rui Lopes、Murray Maloney、Alex Milowski、Michael Sperberg-McQueen、Jeni Tennison、Henry Thompson、Richard Tobin、Alessandro Vernet、Norman Walsh (議長)、そして Mohamed Zergaoui など、数名を挙げただけでも現役の XML 実践者と著名人、そして過去の XML 関連の取り組みでの第一人者が名を連ねています。
 |
よく使われる頭字語
- DTD: Document Type Definition
- HTTP: Hypertext Transfer Protocol
- W3C: World Wide Web Consortium
- XML: Extensible Markup Language
- XSL: Extensible Stylesheet Language
- XSLT: Extensible Stylesheet Language Transformations
|
|
W3C が XML 処理パイプラインの標準を確立しようと試みたのは、XProc が初めてではありません。2002年、Sun Microsystems、Alis Technologies、Arbortext、Cisco Systems、Fujitsu、Markup Technology、そして Oracle が、XML Processing Model Workshop の一環として「XML Pipeline Definition Language Submission」を提出しました。こうして提出されたものは 2002年2月28日に「XML Pipeline Definition Language Version 1.0」として公開されています。
2004年には、W3C Note が XML 処理モデル要件を設定しようとしました。それが、2004年4月5日付 W3C ワーキング・グループのノート、「XML Processing Model Requirements」です。2005年3月11日には別の W3C メンバー・サブミッション、「XML Pipeline Language (XPL) Version 1.0」 (ドラフト) がOrbeon, Inc. によって提出され、翌月 4月11日に公開されています。
|
使用事例
XProc の目標は、XML 文書を処理する相互運用可能な標準的手法を普及させることです。その要件は、一連の使用事例に正式に記述されていました。そのうちのいくつかを以下に記載します。
- 一連の操作を XML 文書に適用する。
- XML を構文解析し、スキーマに照らし合わせて妥当性検証してから、XSLT 変換を適用する。
- 複数の XML 文書を結合する (文書の集約)。
- Web サービスと相互作用する。
- メタデータの検索を使用する
|
|
これまで XProc の必要性について言及している具体的な資料は目にしたことがないので、ここでは私自身の独断的意見をいくつか言わせてもらいます。
- パイプラインの観点で考えるという単純さと結びついた XProc の宣言型フォーマットは、技術の知識がない人でも処理ワークフローの作成と保守に関われることを意味します。
- XProc は多くの構成においてストリーミングに従いやすい一方、他の XML プロセス制御手法はその限りではありません (例えば、XSLT)。
- XProc のステップは特定の操作を実行することに重点が置かれるため、私たちが作成するような (そして少数の人にしか使われないような) 1 度限りのコードとは違い、時が経つにつれて (多くの人々が使用する XProc プロセッサーで) ますます最適化されていくはずです。
- XProc の標準ステップ・ライブラリーと拡張性メカニズムは、XProc をあらゆるものを包含したソリューションとして位置づけます。
- 構造化データ (XProc マークアップなど) は一般に、構造化コードよりも再利用するのが簡単です。
- おそらく全員に同意してもらえると思いますが、XProc の素晴しい発想の 1 つは、UNIX® パイプラインです。
XML 文書を扱ったり、作成したりしているグループの間では、当然、XProc はかなりの好評を得ることになるでしょう。ビジネス・ワークフローのなかで XML 文書をやり取りする人々にとっても、XProc パイプラインでワークフローをモデル化してから XML 文書上でモデル化されたワークフローを実行するという可能性には期待が持てるはずです。
XProc の語彙
XProc は、限られた数の語彙からなります。これらの語彙は、コア要素、補助要素、標準ステップ・ライブラリーという 3 つのカテゴリーに分けられます。まず、コア要素が提供するのは最近の計算言語構文です (条件付きの繰り返し処理、try/catch エラー処理メカニズムなど)。
-
<p:for-each>: 繰り返し処理の命令
-
<p:choose>: 条件分岐の論理命令 (XSLT の <xsl:choose> と同様)
-
<p:group>: 一連のステップを名前付きサブパイプラインにグループ化します。
-
<p:try>: 動的エラーを処理するための try/catch メカニズムを提供します。
-
<p:viewport>: 単一の XML 文書に含まれるサブツリーにサブパイプライン・プロセスを適用します。
ステップの宣言と定義で使用する要素は、XProc の拡張性と再利用性の基礎を提供します。
-
<p:library>: 再利用可能なステップ・ライブラリーを指定するステップ宣言が含まれます。
-
<p:declare-step>: ステップとその機能シグニチャーを定義します。通常、この要素は <p:library> 要素に含まれます。
-
<p:import>: URI (Uniform Resource Identifier) を使用して、宣言されたパイプラインまたはライブラリーを現行のパイプラインに組み込みます。
XProc 補助要素の大部分は、XProc ステップの子ノードとなります。これらの要素は、ステップ・バインディングなどのタスクを処理して、ステップを容易に構成できるようにします。補助要素の構成内容は以下のとおりです。
-
入力および出力: 他のステップの入力または出力にバインド可能なポートを定義して、XML 文書のフローを定義します。さらに、XML文書を (XProc 文書に直接) インラインで定義したり、外部 URI を使用して文書を取り込んだりすることもできます。
-
オプション: オプションはステップを構成するための主要なメカニズムで、<p:with-option> 要素を伴うか、またはステップ・インスタンスでの名前と値の属性として使用されます。オプションはステップの機能シグニチャーの一部であり、その名前は不変であることに注意してください。
-
変数: 変数は複合ステップで使用され、複合ステップのサブパイプライン内で使用する XPath 変数を定義します。
-
パラメーター: オプションや変数とは異なり、パラメーターには実行時に計算される名前があり、機能シグニチャーとは関連付けられません。パラメーターは <p:declare-step> によって定義されます。XProc のおそらく最も重要な側面は、標準 XProc ライブラリーに定義された 30 から 40 のステップで、これらのステップは必須ステップとオプション・ステップに分けられています。
XProc の真の威力は、必須ステップとオプション・ステップからなる標準ライブラリーに具現化されています。これらのステップが、以下をはじめとする多種多様なタスクを実行します。
- XSLT、XQuery、XInclude 処理
- スキーマ検証 (DTD、RelaxNG、Schematron、XML スキーマ)
- XML 更新操作 (XML 要素および属性の挿入、削除など)
- XML の保存と取得
- XML のラップ、アンラップ、エスケープ、アンエスケープ
- HTTP リクエスト
- ネイティブ・コマンドの実行
以下に、XProc 標準ライブラリーに含まれる各ステップについて簡単に説明します。
- 必須ステップ:
-
<p:add-attribute>: 属性を一連の一致する要素に追加します。
-
<p:add-xml-base>: 要素の xml:base 属性を追加または修正します。
-
<p:compare>: 2 つの文書の等価性を比較します。
-
<p:count>: ソース入力の文書数をカウントします。
-
<p:delete>: マッチング・パターンによって指定された項目をソース入力から削除します。
-
<p:directory-list>: ディレクトリーのリストを結果出力に列挙します。
-
<p:error>: 動的エラーを生成します。
-
<p:escape-markup>: ソース入力をエスケープします。
-
<p:http-request>: IRI (Internationalized Resource Identifier) で識別されたリソースと HTTP 上で相互作用します。
-
<p:identity>: 入力されたソースを結果出力に正確にコピーします。
-
<p:insert>: XML 選択項目をソース入力に挿入します。
-
<p:label-elements>: 一致する要素ごとにラベルを作成し、ラベルの値を属性に保存します。
-
<p:load>: IRI が指定する XML リソースをロードし、結果出力として提供します。
-
<p:make-absolute-uris>: ソース入力の要素または属性の値を、結果出力で絶対 IRI 値にします。
-
<p:namespace-rename>: 名前空間宣言の名前を変更します。
-
<p:pack>: 2 つの文書シーケンスをマージします。
-
<p:parameters>: 一連のパラメーターを、c:param-set XML 文書として結果出力で利用できるようにします。
-
<p:rename>: 要素、属性、または処理命令の名前を変更します。
-
<p:replace>: 一致する要素を置換します。
-
<p:set-attributes>: 一致する要素に属性を設定します。
-
<p:sink>: ソース入力を受け入れ、結果出力を生成しません。
-
<p:split-sequence>: 単一のシーケンスを 2 つに分割します。
-
<p:store>: ソース入力をシリアライズしたものを URI に格納します。
-
<p:string-replace>: ソース入力でストリング置換を実行します。
-
<p:unescape-markup>: ソース入力をアンエスケープします。
-
<p:unwrap>: 一致した要素をその子要素と置き換えます。
-
<p:wrap>: ソース文書の一致するノードを新しい親要素でラップします。
-
<p:wrap-sequence>: 新しい文書シーケンスを生成します。
-
<p:xinclude>: XInclude 処理を入力されたソースに適用します。
-
<p:xslt>: XSLT バージョン 1.0 または XSLT バージョン 2.0 のスタイルシートを入力されたソースに適用します。
- オプション・ステップ:
-
<p:exec>: 入力されたソースに外部コマンドを適用します。
-
<p:hash>: メッセージ要約、または値のデジタル・フィンガープリントを生成します。
-
<p:uuid>: UUID (Universally Unique Identifier) を生成します。
-
<p:validate-with-relax-ng>: 入力 XML の妥当性を RelaxNG スキーマで検証します。
-
<p:validate-with-schematron>: 入力 XML の妥当性を Schematron スキーマで検証します。
-
<p:validate-with-xml-schema>: 入力 XML の妥当性を XML スキーマで検証します。
-
<p:www-form-urldecode>: x-www-form-urlencoded ストリングを一連の XProc パラメーターにデコードします。
-
<p:www-form-urlencode>: 一連の XProc パラメーター値を x-www-form-urlencoded ストリングにエンコードします。
-
<p:xquery>: XQuery バージョン 1.0 のクエリーを適用します。
-
<p:xsl-formatter>: XSL バージョン 1.1 の文書をレンダリングします (XSL-FO と同様の機能です)
既存のパイプラインから新しいステップを作成するのは簡単です。お望みとあらば、拡張ステップでサード・パーティーのライブラリーを作成して、XProc プロセッサー自体を強化することもできます。
注: 仕様プロセスは現在進行中で、標準ライブラリーは引き続き多少の変更が加えられる領域の 1 つとなっています。具体的な詳細については、現行の WD (「参考文献」を参照) で最新の定義を確認することをお勧めします。
パイプラインの例
リスト 1 に XProc パイプラインの一例を記載します。このパイプラインには、XSLT 操作を XML 文書に適用するステップが 1 つあるだけです。
リスト 1. 単純な暗黙的パイプライン
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc" name="xslt-example">
<p:xslt>
<p:input port="stylesheet">
<p:document href="mystylesheet.xslt"/>
</p:input>
</p:xslt>
</p:pipeline>
|
XProc パイプラインが入力として受け入れる XML 文書は、1 つもない場合もあれば、1 つ以上ある場合もあります。それに応じて、ゼロまたは 1 つ以上の XML を出力として生成します。リスト 1 の XProc コードを構成しているのは、最上位の <p:pipeline> 要素と 1 つの <p:xslt> ステップだけで、それ以外はありません。XProc プロセッサーの標準入力に入力された XML 文書は <p:xslt> ステップに渡され、このステップが mystylesheet.xslt (mystylesheet は <p:input>/<p:document> 要素によって定義) を使用して XML 文書で XSLT プロセスを適用します。
ステップは 1 つしかないため、このステップの実行結果はパイプライン全体の結果ポートに配置されます。結果ポートは通常 (この場合はたまたま)、XML 文書を標準出力に出力します。このプロセス (つまりソース・ポートから結果ポートへの XML文書の流れの概略) を図 1 に示します。
図 1. 単純なパイプラインのロジック・フロー
ポート間の接続はステップ・バインディングとして知られています。XML 文書の処理フローを制御するのは、これらのステップ・バインディングです。ステップ・バインディングは暗黙的に定義することも、明示的に定義することもできます。リスト 1 は暗黙的なバインディングの例で、プロセス・フローは XProc の通常のデフォルト設定メカニズムによって決まります。
リスト 2 に、今度は明示的ステップ・バインティングを使用したパイプラインを示します。このパイプラインは、機能的にはリスト 1 と同じです。
リスト 2. 単純な明示的パイプライン
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" name="xslt-example">
<p:input port="my-source" primary="true" sequence="false"/>
<p:output port="my-result" primary="true" sequence="false">
<p:pipe step="step1" port="result"/>
</p:output>
<p:xslt name="step1">
<p:input port="source">
<p:pipe step="xslt-example" port="my-source"/>
</p:input>
<p:input port="stylesheet">
<p:document href="mystylesheet.xslt"/>
</p:input>
</p:xslt>
</p:declare-step>
|
リスト 1 では、<p:pipeline> を使用して暗黙的にソース入力と結果出力ポートを宣言していましたが、今回使用しているのは <p:declare-step> です。この場合、ポートを明示的に定義するだけではなく、連続した兄弟ステップ間のステップ・バインディングも宣言しなければなりません。これらのバインディングとポートについて、以下に要約します。
- 最上位の my-source 入力ポートは、あらゆる標準入力を受け取ります。
- 最上位の my-result 出力ポートは、step1 結果ポートの結果を受け取って標準出力に配置します。
-
step1 ソース入力は、my-source 入力ポートにバインドされています。
ステップが 1 つしかないパイプラインを使ってステップ間のステップ・バインディングを説明するのは難しいので、単純ではない例を作成しました。この例で、複数の XProc ステップとロジック構造を説明します。リスト 3 に記載するのは、複数のステップと条件付きロジック・ステップが含まれる代表的な XProc の例です。
リスト 3. 複雑なパイプライン
<p:pipeline name="mypipeline" type="myexample" xmlns:p="http://www.w3.org/ns/xproc">
<p:xinclude name="step1"/>
<p:choose name="step2">
<p:when test="/*[@version < 2.0]">
<!-- subpipeline //-->
<p:validate-with-xml-schema name="step2a1">
<p:input port="schema">
<p:document href="newer-schema.xsd"/>
</p:input>
</p:validate-with-xml-schema>
</p:when>
<p:otherwise>
<!-- subpipeline //-->
<p:validate-with-xml-schema name="step2b1">
<p:input port="schema">
<p:document href="older-schema.xsd"/>
</p:input>
</p:validate-with-xml-schema>
</p:otherwise>
</p:choose>
<p:for-each name="step3">
<p:iteration-source select="//div"/>
<!-- subpipeline //-->
<p:string-replace name="step3a1">
<p:option name="match" value="//span[@class=’css1’]"/>
<p:option name="replace" value=""/>
</p:string-replace>
</p:for-each>
<p:wrap-sequence name="step4">
<p:option name="wrapper" value="document"/>
</p:wrap-sequence>
</p:pipeline>
|
このパイプラインの概要は、以下のとおりです。
- 標準入力に XML 文書を入力します。
-
<xinclude> 処理を適用します (step1)。
- 新しいスキーマ (step2a1) か古いスキーマ (step2b1) のいずれかを選択して (step2)、妥当性を検証します。
- ストリング置換操作 (step3a1) を適用して、それぞれの HTML
<div> 要素を抽出します (step3)。
-
<div> 要素の最後のシーケンスを <document> 要素でラップします (step4)。
- 標準出力に XML 文書を出力します。
ステップには、XML 以外の文書を扱う他の入力ポートや出力ポートを定義することもできますが、主要入力ポートから主要出力ポートへのフローに適用できるのは XML 文書のみです (XML infoset の場合と同様です)。
上記の例では、3 種類すべての XProc ステップを使用しました。図 2 に、ステップのタイプを四角で表したワークフローを示します。
図 2. 複雑なパイプラインのロジック・フロー
p:pipeline 複合ステップ
一番大きな四角は <p:pipeline> 全体を表し、それ自体を 1 つのステップとして呼び出すことができます。このステップはサブパイプラインを含むため、複合ステップとなります。
p:choose マルチコンテナー・ステップ
<p:choose> ステップには 2 つのサブパイプラインがあるため、マルチコンテナー・ステップとなります。このステップは、<p:when> XPath 式の評価に基づいて、どのサブパイプラインを適用するかを選択します。
p:for-each 複合ステップ
<p:for-each> ステップには 1 つのステップからなる単一のサブパイプラインが含まれるため、複合ステップとなります。
アトミック・ステップ
大半の XProc ステップはアトミック・ステップです。これらのステップは、特定の操作を XML 文書に適用します。例えば <p:xinclude>、<p:validate->、<p:string-replace>、<p:wrap> などがアトミック・ステップに該当します。
XProc の開発における検討事項
XProc 仕様プロセス全体をとおして、WG では以下の問題を解決しなければなりませんでした。
-
名前空間: XProc で扱うのは XML 文書です。これはつまり、多くの操作で、プロセッサーが文書内で名前空間を追跡しなければならないことを意味します。XProc の
p:unwrap ステップを例に挙げると、このステップは文書の最上位の要素を削除します。このステップが削除する最上位の要素に、たまたま名前空間 xmlns の宣言があったとしたらどうなるでしょう。その場合には、他の有効な名前空間宣言を上書きしないように注意しながら、削除された名前空間の宣言を最終的な XML 文書の子要素にコピーするための修正を XProc が確実に適用するようにしなければなりません。
WD には、標準とは別の「Section E. Guidance on Namespace Fixup」が含まれています。このセクションで、プロセッサーが処理しなければならないことを概説しています。
-
XSLT と XPath のバージョン: XProc 仕様化作業のタイミングは、XPath および XSLT のバージョン切り替え期間の合間となります。XPath と XSLT の複数バージョンをサポートするという厄介な問題に XProc がどれだけ上手く対処できるかは、私たちが XProc を使用するようになれば明らかになると思います。
-
オプション、変数、パラメーター: オプション、変数、そしてパラメーターについては、多くのことを詰め込み過ぎだという観があります。大半の人が同意してくれると思いますが、単一の構成要素でも十分に対応できるはずです。
-
ストリーミング: 私の印象としては、WG は XProc の初期の決定で、この要件に重きを置き過ぎたようです。XProc が優勢を左右することになる XML 技術自体が 100% 標準化されたストリーミングというわけではないことを考えると、私には時期尚早な最適化のように思えます。特に、MapReduce および並列化技術が優勢と思われる世界ではなおさらのことです。
現状
あらゆる W3C 仕様と同じく、XProc も構文とセマンティクスという点でさまざまな変更を経験してきました (「参考文献」を参照)。2008年5月1日時点での最新 WD は、XPath および XSLT のバージョン 1 とバージョン 2 の両方を許可するという前のドラフトでの決定によって持ち上がった騒動の詳細を解決していることから、革新的なものとなっています。
現行の WD は、<p:option> 要素のさまざまな解釈の一部を解決するために仕様が完全に書き直されたという点でも革新的です。例えば、<p:option> は現在、ステップの機能シグニチャー (<p:declare-step> のなか) でのみ使用されるようになり、オプションの値を設定するにはステップ・インスタンス自体で <p:with-option> を使用するようになっています。さらに、複合ステップで使用する場合をはじめ、計算された値を保持するための <p:variable/> 要素が追加されました。
オプション、パラメーター、変数での最も興味深い変更は、value 属性が除去されたことです。今や、選択した属性によって定義された XPath 式の評価結果が値となります。これがどのように機能するのか、リスト 4 に p:with-option を例に用いて説明します。
リスト 4. XPath 式での p:with-option の使用例
<ex:someStep>
<p:with-option name="some-option-name" select="'some value'"/>
</ex:someStep>
|
オプションに単純な値を定義するのに XPath 式を使用するとなると、例えば二重引用符 (") と引用符 (') をネストして使わなければならないなど、作業が厄介になります。そこで、構文省略 (リスト 5 を参照) が優先メソッドとして保持され、名前と値の属性でオプションをステップ要素自体に定義できるようになっています。
リスト 5. 構文省略によるオプションの設定
<ex:stepType option-name="some value"/>
|
このような変更すべてによって、仕様は大幅に簡潔になっています。しかしそれには、XProc 語彙が増える (<p:variable>、<p:with-option>、<p:with-param> など) という犠牲が伴います。
最後に言っておくべき大きな変更は、新しいステップを宣言するには、一貫して<p:declare-step/> を使用しなければならなくなったことです。この変更により、ステップのインスタンスとその宣言 (ライブラリーまたはパイプライン内) について考える必要が出てくるため、ユーザーにとっては多少わずらわしい負担となります。XProc における単一のステップ要素とは何であるかという見解にあまりにも多くの概念を詰め込みすぎると、それが XProc での制約になってしまう恐れがあります。WG が概念を分割したことは、実際に即した決断だったと思います。
まとめ
XML 技術者にとって重要なこととして、一部の開発者集団は XML を操作しないことを自覚しなければなりません。XML を操作しない集団の開発者に「何故、XProcが必要なのか」と聞かれたら、私はまず、XProc はプラットフォームに依存しないように設計されているからだと答えます。つまり XProc は、仕様に準拠した XProc プロセッサーが実行可能なところであれば、どこででも実行できると説明するわけです。一方、XML 文書と XML 技術をすでに扱っている開発者は、XProc で実現するような処理を他の手法 (XSLT、Apache Ant、Apache Cocoon サイト・マップ、Jelly など) で行った経験があるかもしれません。そんな開発者にとっては、XProc プロセッサーの登場は喜ばしいはずです。
注: production-ready となっている XProc の実装はまだありませんが、いくつかの XProc 実装が開発中です。詳細は、「参考文献」を参照してください。
XML はコンピューティングのあらゆる側面、そしてあらゆる階層に浸透しているため、拡大する XML エコシステムを XProc のような単一の理解しやすい処理手法で調整するというのは、画期的な技術になると考えられます。サード・パーティーのステップ・ライブラリーを独自に作成する拡張性を兼ね備えた XProc 標準ライブラリーは、既存の、そして将来の XML プロセッサーの強力なファサードです。したがって、特定の技術の変化にワークフローを合わせるのではなく、XML 文書での一連の操作として処理そのものを定義できるようになっています。
XProc の 2 回目のラスト・コールは、今後数ヶ月の間に開始される見込みです。このことから、2008年中には W3C 勧告として目にできると思います。
参考文献 学ぶために
製品や技術を入手するために
-
XProc 実装のリスト: 現在開発が進められている XProc 実装を参照してください。
-
Smallx: Smallx について調べてください。Smallx の開発者たちによると、これは「XML infoset を処理するために開発中のライブラリーおよび一連のツール」です。infoset 実装が文書のストリーミングを許可するという点、そしてパイプラインと呼ばれる概念を使用して infoset を実現できるという点で注目の 2 つの機能が備わっています。
-
Sxpipe: 単純な XML 文書の処理モデルを構築してコンポーネントの評価順を選ぶための sxpipe (Simple XML Pipelines) を試してみてください。
-
Apache Ant: この Java™ ベースのビルド・ツールの詳細を調べて、ダウンロードしてください。
-
Apache Cocoon: 問題の分離というコンセプトを中心にビルドされた Web 開発フレームワークをダウンロードして、詳細を調べてください。
-
Jelly: XML コードを実行可能ファイルに変換するツールを入手してください。
-
IBM 製品評価用トライアル・ソフトウェア: developerWorks から直接ダウンロードできるトライアル・ソフトウェアで、次のプロジェクトを構築してください。DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® によるアプリケーション開発ツールおよびミドルウェア製品のトライアル版が揃っています。
議論するために
著者について
記事の評価
| 
