レベル: 初級 Howard Katz (howardk@fatdog.com), Owner, Fatdog Software
2001年 6月 01日
2006年 1月 06日 更新 W3CのXQuery仕様は、筆者(Howard Katz)により導入され、勧告の位置付けに向かって現在、紆余曲折の検討を重ねています。この複雑な仕様は、現在、15別冊の作業草案からなり、完成するまでには、まだ、もう少し増加するものと考えられます。この記事では、ある程度の歴史的背景、文書化への道筋を解説し、仕様の現在の位置付けを簡単に説明します。補足記事では、XQueryの表面的な構文の一部の重要機能を手短に解説しています。コードの見本では、XQueryとXQueryX間の相違を具体的に説明し、表面的な構文の例を示します。
注：2005年12月のこの記事の改訂部分は、XQuery仕様の最近の変更を盛り込んでいます。作業草案中の8案は、現在、W3Cの「勧告候補」の位置付けに達し、そのため、仕様全体も、最終勧告の位置付けにより一層近づいています。2004年に最初公表された主要文書も全文が最近改訂されました。Update Facility Requirements作業草案だけでなく、 XPath/XQueryトークナイザーの構築用草案も、2005年に最初に公表されています。XQueryの機能の数は、絶えず増加し、また、それに合わせて、XQuery実装者の一覧と開発者が利用できるWebベースのリソース数も増加しています。
W3Cの勧告路線に沿って活動した6年後に、XQuery仕様は、架空のお話のハリウッド長編人気映画の様相を強めています(「スター・ウォーズ」や「ロード・オブ・ザ・リング」シリーズが心に浮かびます)。XQueryの出自は、はるか昔1998年に行われたW3C後援のクエリー言語ワークショップまで遡ります。そこでは、産業界、学界、および研究界の代表者がボストンに集い、XML向きクエリー言語に重要と思われる機能と要件に関する見解の提案を行いました。
2分化の使用者層
66編のプレゼンテーションは、歴史的な視点に興味ある読者の皆さんのためにオンラインで提供されていますが（「参考文献」を参照）、非常に異なる2つの使用者層のユーザー、すなわち、文書としてのXMLの分野で主に作業するユーザー（概して、XMLの元来のルーツがSGMLにあることを反映しています）とデータとしてのXMLを使用して作業するユーザーから主として提供されたものです。後者のユーザーには、ミドルウェア分野、すなわち、フロントエンドの従来のリレーショナル・データベースに存在感を絶えず強めているXMLが大きく反映しています。
特に、あるプレゼンテーション、すなわち、Oregon Graduate InstituteのDavid Maier氏による"Database Desiderata for an XML Query Language"という題名の簡潔かつ明快なプレゼンテーションは、ボストンでのワークショップの後ですぐに設立されたQuery Language Working Groupの思想を伝える上で特に有効です。
メンバー数は、毎年、若干変動しますが、W3Cの基準からすると、Query Language Working Groupは大きい方です(このグループよりメンバー数の大きいグループは、Protocol Working Groupだけと聞いています)。ほぼ30社の種々雑多なメンバー企業の構成は、データとしての使用者層と文書としての使用者層との両方の見解を反映するものです。最終形態に今、(長い間の紆余曲折を経てようやく)まとまりかけているのは、この両方の使用者層のニーズと視点を何とか工夫して表現しようとするXMLクエリー言語規格です。
XMLユーザーに最も愛用されると思われるXQueryの重要コンポーネントは、それ自体がW3Cの仕様であるXPathと考えられます。それ独自のXPathのロケーション・パス(たとえば、"//book/editor"は、「現在のデータセット内に存在する全編集者を検索せよ」という意味)は、紛れもなく有効なXQueryとなります。データ側にとっては、XQueryのSQL風の外観と性能は、リレーショナル・データベース世界出身のユーザーに歓迎され、親しみやすいものと思われます。
つつましい生い立ち
XQueryは、Quiltとして誕生しました。主として、ユーザー・レベル構文のテスト手段であったQuiltでは、ワーキング・グループの3名の特に活動の目覚ましい熱心なメンバーとして、Jonathan Robie、Don Chamberlin、Daniela Florescuが指導的立場にいました。その後、Quiltは、要求、使用ケース、および基底データ・モデルと代数の定義段階では、ワーキング・グループ全体の協調的作業をベースにするようになりました。
RobieとChamberlin、Florescuは、XQL、XML-QL、およびSQLを含め、Quilt設計に影響を及ぼした言語を多数挙げています。コンピュータ言語の発展に興味ある読者は、"XML Query Language: Experiences and Exemplars"（「参考文献」を参照）を一読してください。YaTLとLorelという2言語とともに、XQLとXML-QLの優れた概要比較を記載している有用な記事です。執筆者のMary FernandezとJerome Simeon、Phil Wadlerは、ワーキング・グループのメンバーでもあります。
データとしての使用者層とそれに対する文書としての使用者層とのさまざまな視点、およびワーキング・グループによって構築された基盤の堅実性を考えると、仕様の大部分が公表されるまでに長い時間を要したことは驚くにあたりません。一例を挙げると、W3Cのワーキング・グループの内部手続きは外部非公開であり、2001年2月中旬以前のQuery Language Working Groupの作業の大半は、秘密裏に行われました。
要件文書とデータ・モデル作業草案は、比較的初期に出版されましたが、ワーキング・グループの出版部門が、実際にフル回転に入ったのは、2001年2月であり、その時点から関係文書の大部分が公表され始めました。この動きの続きとして、2001年に2回の主要改訂が行われ、以降、1回しか出版が行われなかった2004年を例外として、1年間に3回から4回改訂が繰り返されてきました。
改訂の仕組に基づき本年追加された最新の要件文書およびXQuery言語実装者用トークナイザー構築方法に関する1編の短編ノートを合わせて、公表文書は合計で16文書になりました（筆者には理由は不明ですが、XML Query WebサイトにはXSLT仕様も列挙されています）。遠からず一揃いの文書体系が完成する見込みです。改訂された言語関連文書も、ある時点で間違いなく公表されるはずです。
新生の出版帝国
全体として、XQueryの記述と定義を行う文書体系は、現在、以下から構成されています。
-
XML Query Requirements
- ワーキング・グループの主要計画文書。XQuery必要条件のリストを網羅しています。
-
XML Query Use Cases
- 数多くの実世界のシナリオと特定の問題解決のXQuery抜粋例を記述しています。
-
XQuery 1.0: An XML Query Language
- 言語自体を紹介し、それ以外のほぼすべての項目を概説する中心的文書です。
-
XQuery 1.0 and XPath 2.0 Data Model
- XML infosetの拡張。クエリー処理系が認識しなければならないデータ項目、および正式なセマンティックスの基礎を記述しています。
-
XQuery 1.0 and XPath 2.0 Formal Semantics
- 言語を正式に定義する基底の代数を記述しています。
-
XML Syntax for XQuery 1.0 (XQueryX)
- XMLが優先される場合のXML代替構文です(主に、コンピュータ向きです)。
-
XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0
- XMLスキーマ・データ型、XMLノード、および両方のシーケンスに対する約225個の関数と演算子を記述しています。
-
XML Path Language (XPath) 2.0
- 別冊にされたXPath文書です。
-
XPath Requirements Version 2.0
- XPath用の要件書です。
-
XSLT 2.0 and XQuery 1.0 Serialization
- XQuery 1.0とXPath 2.0のデータ・モデルから、逐次化された山括弧記法のXMLを出力する場合に関する検討の一考察です。逐次化は、主要な言語仕様自体には含まれていません。
-
XML Query and XPath Full-Text Requirements
- 全文勧告が準拠しなければならない機能要求を記述しています。
-
XML Query and XPath Full-Text Use Cases
- 全文仕様書が処理できるものと見込まれる実世界のシナリオです。
-
XQuery 1.0 and XPath 2.0 Full-Text
- 主要な全文文書であり、XQuery本体に対する全文の言語拡張を詳述しています。
-
XQuery Update Facility Requirements
- XQueryが必要とする機能で、XQueryが既存の文書に新規データを書き込み、既存の文章に対してクエリーを実行できるようにする機能を記述しています。
-
Building a Tokenizer for XPath or XQuery
- 元来、メインXQuery 1.0文書に見出される文法的資料の一部を別に取り出し、さらに詳述した作業ノート草案です。これは、言語実装者のみを対象とするものと考えられます。
上記の文書（すべて「参考文献」で参照可能）は、膨大な量の成果物となります。XQuery 1.0: An XML Query Languageが、一連の文書における根幹的文書であり、他はすべて、XML言語を驚異的なレベルで整然と規定し包括的に補強する方向に向けて貢献するための文書です。筆者の知る限り、この文書体系が、W3Cから発行される中で、最も複雑な仕様書のセットと思われます(XMLスキーマも間違いなく思い浮かびますが、それは、また別問題となります)。
初めてこの膨大な量の文書を眺め、どの文書から読み始めていいのか戸惑う場合、2つの方法から可能な方を試されるようにお勧めします。その1つは中心的なXQuery 1.0文書から読み始める方法です。導入的な概要が優れており、また、言語の数多くの機能のそれぞれが詳しく説明されています。もう1つの方法は、Use Cases作業草案をまず選択することです。同文書では、XQueryの適用可能な実世界のシナリオの概要が多数説明されています。各利用ケースは、特定の適用分野を対象としており、その分野のサンプル・データ向きに設定されたXQueryの実例を一覧にしています。コードの抜粋は、実世界の構文の具体例を求めている読者には、貴重なものと思われます。3番目の方法は、Functions and Operators作業草案に列挙されている多数の組み込み関数に目を通すことで、言語の最小限の知識を持っている読者には最適な方法です。
XQuery仕様の裏表を解説する優れた本も、ここ数年の間に、Addison-Wesleyから2冊出版されています。"XQuery from the Experts"は、ワーキング・グループのメンバーから寄せられたXQuery関連トピックに関する詳細な技術小論を数多く載せ、 "XQuery: The XML Query Language"は、MicrosoftのMichael Brundageによる著作で、必要に迫られたときに読みやすい参考書です（「参考文献」を参照）。
複数言語の翻訳家は必要ありません
XQueryは、次のように実質3言語が1言語になったものです。
-
表面的構文は、3言語の中で最も目立ち、ユーザーが接する可能性も最も高い言語です。普通の場合、このバージョンの言語が、XQueryとなります(補足記事の「構文：クイック見本集」の表面的構文の例を参照)。
-
XMLベースの代替構文が、表面的言語をマシン処理制御に向いている言語で置き換えます(この記事の後述のXQueryXを参照)。
-
正式な代数言語は、XQueryプロセッサの内部構造を相当詳細に記述するものです。
基底の形式
Data ModelとFormal Semanticsの両作業草案がまとまって、XQueryの厳格な理論的土台を記述します。この作業草案の2案は、クエリー代数、XQueryクエリーの操作対象とされるコア・エンティティーを正式に定義する厳格な定義文のセット、さまざま言語演算子がそれらのオペランドを用いて実行できる演算内容の定式化を詳述します。これは、クエリー・エンジンの実装者、特別に時間の余裕や活動の自由の認められている者、複雑で本格的なシステムで作業することが単純に好きな者を除けば、普通、重要になることはありません。
あるマッピングが提供されていて、実装者は、それを使用すると、表面的構文機能を基底の代数に変換することができます。複数のベンダが、XMLトレード・ショーでデモしているように、実際に、基底の代数を直接的に表現するクエリー・プロセッサを実装することも可能です(ただし、筆者には、実際の可能性を示すだけのことのように思われますが)。「参考文献」のリンクを使用すると、こうした代数ベース・エンジンの中の一つのオンライン用デモ・バージョンを試すことができます。
上記の代数には、複雑な式をより単純なものに最適化し変更する方法を詳細に規定するルールも用意されています。筆者としては、(筆者は、言語の理論家ではありませんし、また、Formal Semantics文書は、軽い読み物でもありませんので)、この両方を実行できるのは、優れたことであるとしか言えません。特に、大規模データベースのベンダは、最適化可能性と高い効率性の両方を持つように、積み上げ方式で設計されているクエリー言語アーキテクチャに高い評価を与えることと思われます。
代数では、型情報を設定する場所も用意されています。XQueryは、型指向の強い言語です。すなわち、データとそのデータに関連するW3C XMLスキーマが存在する場合、プロセッサは、スキーマと比較して妥当性検証を行い、文書内のノードのデータ型に関するPost-Schema Validation Infoset (PSVI)情報をクエリー・エンジンに与え、"XML Schema Part 2: Datatypes"とユーザー自身のユーザー定義型で宣言されている両方の型を利用することが可能になります。代数には、静的型チェックと動的型チェックの両方の機能が備わっています。たとえば、クエリー・エンジンは、PSVI派生型情報を使用して、コンパイル時(クエリー構文の妥当性分析の実行時)にクエリー式のデータ型静的チェックを行うことができます。処理サイクルの初期にクエリーの型が無効であることが判別されるため、大規模なデータセットに対する高価かつ無駄になる可能性のある検索の実行が回避されます。XQuery仕様の策定作業の多くは、型に関係する言語の一部の構文とセマンティックスに対する作業に関係するものです。
XPath 2.0への移行
XQueryは、XPath 2.0と共通データ・モデルを共有しています。この事実は、"XQuery 1.0 and XPath 2.0 Data Model"というデータ・モデル文書のややぎこちない書名にも反映されています(このぎこちなさが、このデータ・モデルを称する際にはるかに発音しやすい頭字語のXDMをワーキング・グループが使い始めた理由でもあります)。XPath 2.0は、現在、ほぼ十分に検討が済んだ段階にあります。そのデータ・モデルは、XPathプロセッサに重要なXML文書内のコア情報を記述します。XPath の手順操作の最終構文とセマンティックスは、現在、ほぼ完全に分析が終了しています。全面的な仕様は、Query LanguageとXSLの両ワーキング・グループで共同所有されており、この2つのグループは、XPath 2.0の外観的な面に関して合意する必要があります。時には、政治的、技術的の両面から難航してきました。ただし、合意への道が困難なときもあるでしょうが、両グループは、さほどの苦労もなく、切り抜けていくように思われます(もっとも、これは、外部の目から見た単純な感想かも知れませんが)。
XPathの1.0から2.0への移行がなぜ興味深いのかの理由を示す例を1つだけ挙げ、考察してみます。XPath 1.0は、集合ベースの式言語です。XPath 1.0の4つのデータ型の1つであるNode-setsは、その通りの意味でsets(集合)となります。定義では、集合は、順序付けされておらず、重複した要素を含みません。他方、XPath 2.0は、シーケンス・ベースです。対照的に、XPath 2.0におけるノードのシーケンス(当然のことながら、類推でnode-sequencesと呼ばれます)は、順序があり、重複も許されています。こうした差異の悪影響は、ワーキング・グループ自体とXPath 2.0の調整をともに図りながら、ワーキング・グループによって別々に、しかも心を一つにして解決しなければならない多数の問題の一部であったと業界特有の表現で表されるようです。
現在の進展状態
残りの実質的な問題は現在すべて解決されています。 XQuery仕様を構成する主要文書のうち7文書が、現在W3C用語で言う勧告候補になっています。これは、公式的な表現では、XQueryは、現在、「安定し、実装に適している」状態にあると見なされるということになります。
正式なW3C勧告プロセスの観点からは、前回の最終審査請求時に取り上げられた問題のすべてが対応済みであり、ワーキング・グループは、現在、 XQueryの主要機能が実装可能であると業界ベンダが実世界で検証してくれることを期待しているところです。この検証では、実装者がワーキング・グループの提供した一式のテストを使用して、実装したシステムを実行します。勧告候補段階で、2社以上のベンダに実行されなかった機能は、仕様から除外される危険があります。この危険段階の機能の現行リストには、次の機能が含まれています。
- 静的型指定
- モジュール
- 集積
- 静的型指定
- Trivial XML埋め込み
- 名前空間宣言のコピー
XQueryX
表面的言語用の代替XMLベース構文の仕様であるXQueryXは、XQuery文書体系に初期に追加されたものの中の一文書です。XQueryの要件の一つでは、複数の構文の可能性について記述しています(これはワーキング・グループがやや逃げ道を作っているようにも思われます)。その場合、構文の一つは、人間の読み書きにとって便利なものである必要があります。他方の構文は、XMLで表現可能である必要があるということになります。XQueryXは、後者の要件に対するワーキング・グループの答えです。
XMLベースのクエリー表現を採用すると、当然ながら、XMLの周知の利点をすべて利用できることになります。すなわち、クエリーの内容の構文分析、生成、検査を、標準ツールで行うことが簡単になります。これは、たとえば、ソース・レベルでの最適化や変換を行う場合などに有効になります。次の段階では、特定の文法構造に対するクエリーを簡単に検査できる機能に依存する場合もあります。XMLは、そうした作業を得意とします。
XQueryXは、言語の正式文法のXMLへのほぼ一対一のマッピングです。文法の複雑さを考えると、このマッピングによりXQueryXは相当に冗長になります。その程度は、人間にはほぼ可読不能状態になります。喜ばしいことは、その言語の予定された対象であるマシンは、そうしたことには不平を言わないことです。リスト1とリスト2はそれぞれ、標準的なXQuery構文と対応するXQueryX構文で表された簡単なクエリーで、比較対照できます。筋肉膨張剤ステロイドのような相当な膨張要因に注目してください。
リスト1.標準構文の単純なクエリー
<bib>
{
for $b in doc("http://bstore1.example.com/bib.xml")/bib/book
where $b/publisher = "Addison-Wesley" and $b/@year > 1991
return
<book year="{ $b/@year }">
{ $b/title }
</book>
}
</bib>
|
リスト2は、対応するXQueryXのクエリーを示しています。あまりに長いので、リストの約4分の3を省略しました。XQueryX作業草案から直接引用した全リストは、132行にもなります。
リスト2.XQueryX形式によるリスト1のクエリー(抜粋)
<?xml version="1.0"?>
<xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX" ... >
<xqx:mainModule>
<xqx:queryBody>
<xqx:elementConstructor>
<xqx:tagName>bib</xqx:tagName>
<xqx:elementContent>
<xqx:flworExpr>
<xqx:forClause>
<xqx:forClauseItem>
<xqx:typedVariableBinding>
<xqx:varName>b</xqx:varName>
</xqx:typedVariableBinding>
<xqx:forExpr>
<xqx:pathExpr>
<xqx:argExpr>
<xqx:functionCallExpr>
<xqx:functionName>doc</xqx:functionName>
<xqx:arguments>
<xqx:stringConstantExpr>
<xqx:value>http://bstore1.example.com/bib.xml</xqx:value>
</xqx:stringConstantExpr>
</xqx:arguments>
</xqx:functionCallExpr>
</xqx:argExpr>
<xqx:stepExpr>
<xqx:xpathAxis>child</xqx:xpathAxis>
<xqx:nameTest>bib</xqx:nameTest>
</xqx:stepExpr>
<xqx:stepExpr>
<xqx:xpathAxis>child</xqx:xpathAxis>
<xqx:nameTest>book</xqx:nameTest>
</xqx:stepExpr>
</xqx:pathExpr>
</xqx:forExpr>
</xqx:forClauseItem>
</xqx:forClause>
... |
おめかししてどちらにお出かけ?
第1弾の出版直後の2001年6月に既存のXQuery処理系に対するこの要約を最初に書いた時点では、利用できる処理系は、筆者自身のきわめて初期段階のものとMicrosoftの処理系の2つに過ぎませんでした。ことのついでに、ビル・ゲーツと筆者が市場競争を画策していると冗談を言って自嘲したものです。今回、4年経過し、作業草案が多数になった後では、そうした冗談はもはや通用しません。現在、多数の関連製品とツールも伴って、約48の処理系が使用可能になっています。
現在使用可能なものを確認するには、XML Queryホーム・ページが最適です（「参考文献」を参照）。同ホーム・ページのリストは動きがきわめて活発で、興味と機運が高まり、仕様が、勧告の位置付けに近づくにつれて、新しい処理系が定期的に登場するのが期待されます。
 |
構文：クイック見本集
ここで、実例に照らして、XQuery機能をいくつか手短に調べてみます。Use Cases文書内の標準的なサンプル･ファイルの一つに対して動作する非常に単純なクエリーを用意しました。このクエリーは、 XQueryのプロジェクト機能(該当する条件に一致するデータセット内のノードの部分集合を選択する機能)と変換機能(クエリー対象とは異なる出力文書を生成する機能)の両方を具体的に説明するものです。XQueryでは、検索対象の指定とその出力形式の外観の指定とを同じクエリー内で同時に行うことができます。
|
|
リスト3は、このクエリーが動作する対象の文書の抜粋を示しています。
リスト3.クエリーの動作対象の文書の抜粋
<bib>
<book year="1994">
<title>TCP/IP Illustrated</title>
<author><last>Stevens</last><first>W.</first></author>
<publisher>Addison-Wesley</publisher>
<price>65.95</price>
</book>
<book year="1992">
<title>Advanced Programming in the Unix environment</title>
<author><last>Stevens</last><first>W.</first></author>
<publisher>Addison-Wesley</publisher>
<price>65.95</price>
</book>
<book year="2000">
<title>Data on the Web</title>
<author><last>Abiteboul</last><first>Serge</first></author>
<author><last>Buneman</last><first>Peter</first></author>
<author><last>Suciu</last><first>Dan</first></author>
</book>
...
</bib>
|
結果の出力文書(やや見かけを良くした文書)は、リスト4のような外観を取るものとします。
リスト4.結果の出力文書
<results>
<book authorCount="1">
<author>Stevens</author>
</book>
<book authorCount="1">
<author>Stevens</author>
</book>
<book authorCount="3">
<author>Abiteboul</author>
<author>Buneman</author>
<author>Suciu</author>
</book>
...
</results>
|
以下が、問題のクエリー自体です。その目的は、クエリー対象文書内のすべての書籍をスキャンして、上記の結果文書を生成することです。結果では、出力される新規の各<book>タグに算出されたauthorCount属性が含まれ、残りの情報の大半は元の文書から捨て去って、各作者の姓のみが維持されます。
(上記の「クエリー対象文書」は、単一文書を意味していることに注意してください。これは説明を単純にするためのもので、XQueryのデータ･モデルは、複数の文書の集まりだけでなく部分的な抜粋の処理も可能です)。
リスト5.クエリー対象文書内の全書スキャン用クエリー
<results>
{
for $book in doc( "http://uri-for-book-dataset" )//book
let $authors := $book/author
return
<book authorCount="{ count($authors) }">
{
for $author in $authors
return
<author>{ $author/last/text() }</author>
}
</book>
}
</results>
|
リスト5では、doc()関数は、検索対象の XML文書にクエリーを方向付けるために使用されています。同関数は、文書ノードをXQueryとXPath Data Model (XDM)の用語で返します。
クエリーの分析
このクエリーには、以下のような興味深い機能があります。
for/let式
この例には、2つのネスト化されたforループと1つのletが含まれています。外側のforは、パス式のdoc(...)//bookの展開結果である各ノードを繰り返し処理し、次に、各<book>ノードを$bookという名前の変数内に分離します。次に、let式は、$authorsという名前の変数に、各書籍の<author>サブノードをすべて選択します。$authors変数は、ノードのシーケンスを保持します。$bookと$authorの両変数は、単一のノードを保持します。
$bookと$authorの両変数は、値の代入がなく、結合状態にあるということは、重要な留意点です。この区別は微妙ですが、重要です。変数は一度結合されると、その値は不変となります。これにより、変数の値を動作中に再代入することから起こり得る、扱いにくい副作用が防止されます。潜在的な別の利点は、変数を含む行を(ある程度まで)処理中に再配置して、高機能エンジンによるクエリーの最適化を可能にすることです。
for式とlet式は、FLWOR(英語のflowerと同じ発音)式の下位コンポーネントです。この頭字語は、その5つの主要なコンポーネントの節(for-let-while-order by-return)を表しています。リスト6は、FLWOR式の正式な文法を示しています。
リスト6.forとletの下位コンポーネントを含むFLWOR式
FLWORExpr ::= (ForClause | LetClause)+ WhereClause? "return" Expr
|
上記のFLWOR式は、変幻自在の式型であり、きわめて多数の使用可能なクエリー・インスタンスを生成できることを示します。このリストが示すように、"return"キーワードの後に続くExpr項は、それ自体を別のFLWOR式で置き換えることができるので、LEGOブロックを限りなくつないで行くように複数のFLWORを無限に連結することができます。別の式型でExpr項を置き換えると、XQueryが合成可能となり、表現力が豊かになります。XQueryには多数の式型が存在し、より汎用的なExprが必要とされるところであればどこにでもそれぞれの式型を文法の中に挿入することができます。
ところで、FLWORシーケンスは最終的にはreturnステートメントにより終了します。上記のクエリーの場合には、追加の内部returnが、出力される各<book>に対する要素コンストラクタの都合の良い挿入点として使用されます。
要素コンストラクタ
このクエリーには、3つの要素コンストラクタが含まれています。要素の<results>、<book>、および<author>は、クエリー自体の本文に直接リテラルの山括弧XMLを書き込むことにより、実行中に生成されます。
大括弧（{ と }）は、評価を必要とする要素コンストラクタの内部の下位式から、リテラルのテキスト内容を区別する必要のある場所で使用されます。たとえば、リスト7でリテラル式を省略した場合、外側と内側のタグを区切るための大括弧は不要になります。
リスト7.外側と内側のタグを区切る大括弧を必要としないコード例
ところで、大括弧は、表面的言語構文の2001年6月版で導入されました。それより前のバージョンの文法では大括弧は要求されていません。大括弧は、言語が勧告に向かって進むときにどのように変化、発展するかを示す良い実例です。
属性コンストラクタ
リスト8のコードはインライン属性コンストラクタの使用法を示しています。count()関数は各書籍に含まれる<author>要素の個数を返します。この例でも大括弧の使用に注意してください。評価を必要とする式をその周囲のリテラルXMLから分離するために使用されています。属性コンストラクタ内の属性値を区切る二重引用符の使用は、言語の発展とともに、仕様に行われた別の変更の例を示します。
リスト8.インライン属性コンストラクタの使用法
<book authorCount="{ count($authors) }" >
|
組み込み関数と演算子
count()は、組み込み関数の一例です。"Functions and Operators"草案には、ほぼ225個の関数と演算子が数十のグループにまとめられ一覧されています。これらはnumber、string、boolean、date and time、qname、node、およびsequenceなどのさまざまなデータ型を生成し、生成されたデータ型に対して動作します。
リスト9の式は、text()演算子を使用して、それを包む<last>要素から抽出した姓のテキストを、各<author>要素の内容として設定します。直接$author/lastだけを使用すると囲んでいるタグも返されるので、この場合は適切ではありません。
リスト9.組み込み演算子text()の使用法
<author>{ $author/last/text() }</author>
|
参考文献 学ぶために
製品や技術を入手するために
- Jerome SimeonによってBell Labで行われたGalax は、formal semanticsに基づくクエリー・エンジンのデモです。「formal semantics」は、今や正式な用語となりましたが、これは2001年7月のリリースまで「代数（algebra）」と呼ばれていたものです。
-
XQEngine は、著者による独自のオープンソース、そしてJavaベースのクエリー・エンジンです。ただし著者は（少なくとも当面は）最近の仕様変更に追いつくのを諦めているため、少し古くなっています。
-
Mark Logic Content Server は、（誰よりも）主な出版社が使っているパッケージです。50 MBの内容を無料で保存し、クエリーすることができます。
-
Berkeley DB XML は、SleepycatによるオープンソースのネイティブXMLデータベースであり、古めかしい、そして非常にスケーラブルなBerkeley DBデータベース・エンジンに基づいています。
- IBMのDB2 Extender pageは、DB2がXMLをどう扱うかに関する基本的な概要を解説しています。またXMLを使ってのクエリーに関する詳細なホワイトペーパー（PDFファイル）へのリンクや、DB2 Extender downloadsへのリンクがあります。
著者について | | | Howard Katzは、カナダのバンクーバー在住で、XML文書を検索するソフトウェアを専門とするFatdog Software社を経営しています。彼は35年近くの間 (中断をはさんで) 熱心にプログラマーとして仕事をし、コンピューター関係の出版物に長い間技術記事を寄稿してきました。彼はVancouver XML Developer's Associationの共同ホストです。また彼は、Addison Wesleyから近々出版されるThe Experts on XQuery という本の編集者です。この本は、W3CのQueryワーキング・グループのメンバーによるXQueryに関する技術的展望をまとめたものです。彼は愛妻とともに、夏はシー・カヤックを楽しみ、冬はカントリー・スキーをしています。Howardの連絡先はhowardk@fatdog.com です。 |
記事の評価
| 
