JP2002183116A - 文書合成方法および文書合成装置 - Google Patents

Abstract

(57)【要約】 【課題】複数のウェブサイトの情報を１つのウェブ文書
上に合成することが容易にしかも汎用的に行える文書合
成方法および文書合成装置を提供する。 【解決手段】少なくとも、インターネットにおけるＷＷ
Ｗ上のマークアップ言語で記述された第１の文書のイン
ターネット上の所在と、第１の文書から抽出する部分文
書の範囲と、合成用の第２の文書上の前記部分文書の挿
入位置と、前記挿入位置に挿入される前記部分文書を含
む前記第２の文書上の文書構造を変換すべき範囲と、前
記文書構造を所望の文書構造に変換するための変換ルー
ルを記述したファイルの識別情報とをマークアップ言語
により記述した第２の文書に従って、前記第１の文書か
ら前記部分文書を抽出して、その部分文書を前記第２の
文書上の前記指定された合成位置に挿入するとともに、
前記変換ルールを用いて前記第２の文書上の前記指定さ
れた範囲の文書構造を変換する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のウェブ文書
を１つのウェブ文書上に合成するためのウェブ文書合成
方法およびそれを用いたウェブ文書合成装置に関する。

【０００２】

【従来の技術】ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅ
ｂ）は効果的なプレゼンテーションを低コストで構築・
公開できる情報基盤として普及し、世界中のサイトで膨
大な情報資源が公開されている。またＷＷＷはサーバク
ライアントシステムのためのインフラの側面を持ってい
る。特に電子商取引や最近ではＡＳＰ（Ａｐｐｌｉｃａ
ｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｉｎｇ）など
への応用が期待されており、本格的なコマースサイトが
急増しつつある状況にある。電子商取引では、ウェブペ
ージは、商取引を処理する企業内ＬＡＮのバックエンド
システムとユーザとを結ぶ操作パネルとしての役割を果
たす。ＷＷＷはサイトを越えて世界中のコンピュータシ
ステムをつなぐ唯一のインフラであるが、今後もウェブ
トップ指向への流れは続くことが予想される。

【０００３】ＷＷＷで交換される情報資源は増加の一途
をたどり、ウェブシステムに要求される処理はより複雑
で多様なものになるだろう。

【０００４】特に、企業はＷＷＷを積極的に活用してお
り、企業データやニュース・商品カタログ情報など自社
の持つ大量のデータをウェブページを通じて公開してい
るが、各ウェブページを一から作るにはあまりにも人手
がかかりすぎるため、定型的なコンテンツを含むウェブ
ページについては、データベースから静的あるいは動的
に機械生成する技術を導入しており、サイト構築および
運用を効率化している。このようなウェブサイトの構築
・運用ツールは、多くのソフトウェアベンダーから提供
されており、非常に充実している。しかしこれらの技術
はいずれも閉じた単一ウェブサイトの構築や運用の効率
化・高性能化に関するものである。

【０００５】単一ウェブサイトの構築・運用環境が整備
された現在、次にＷＷＷに求められるのはウェブサイト
間連携である。すなわちサーバクライアントシステムか
ら分散システムへの発展である。特に本格的な電子商取
引の時代を迎えるにあたり、各コマースサイトの電子商
取引システムの連携は必須となる。

【０００６】電子商取引システムの連携には、商品プロ
ファイルなどのデータフォーマットや語彙の共通化、そ
して共通のビジネスモデル、それに従った共通のメッセ
ージフォーマットやプロトコルなど多くの取り決めが必
要である。これに対し、ＯＡＳＩＳやＢｉｚＴａｌｋな
ど業界団体が標準化を進めているが、企業間の利害の不
一致や商習慣の違いなど多くの壁があるため、その成果
が実を結ぶには、まだまだ時間を要することは間違いな
い。

【０００７】一方でその火急のニーズに対応するため、
各ソフトウェアベンダーからは、上述のウェブサイト構
築・運用ツールにウェブサイトの連携機構を追加したパ
ッケージが提供されている。

【０００８】しかし、データベースを中心に据えたアプ
リケーションロジック群を核とする従来的なシステム構
築手法は、単一ウェブサイトに対してはウェブページを
単なるユーザインターフェースとして位置付けることで
有効に機能したが、複数ウェブサイトにまたがるシステ
ムに対してはそのままでは適用できない。なぜなら、こ
の構築手法ではシステム連携を実現するためにアプリケ
ーションロジックを接続する必要があるが、サイト間は
ファイアウォールによってさえぎられており、ほとんど
の場合ＨＴＴＰ以外のメッセージが交換できないからで
ある。

【０００９】従って、唯一のメッセージ交換のチャンネ
ルであるＨＴＴＰをベースとしたシステム統合モデルが
必要だが、パッケージの多くは従来のサイト構築技術に
ＨＴＴＰアクセス機能を追加しただけであり、ＨＴＴＰ
およびＷＷＷの機能を生かしきれていない状況にある。

【００１０】このようにサイト間のシステム連携は、そ
れぞれのシステムが持つロジックを接続するために多く
の取り決めが必要であり本質的に難しい課題である。

【００１１】そこで、ロジック接続ではなくコンテンツ
交換を用いたウェブサイト間連携を課題として着目して
みると、ウェブサイト間コンテンツ連携は、ウェブリソ
ースの構造変換程度の調節ですむため、ウェブサイト間
システム連携に比べて解決すべき課題は少ない。

【００１２】しかし、その一方で、コンテンツ連携がも
たらす効果は十分に大きい。先に述べたようにＷＷＷで
はすでに膨大なウェブリソースが公開されている。また
ウェブリソースはマルチメディアであり、あらゆるコン
テンツメディアを包括することができる。このようなウ
ェブリソースをサイト間で合意の下に互いに容易に再利
用できる環境があれば、ＷＷＷは格段に合理的で経済的
なものになり、ＷＷＷの応用に大きな進歩をもたらすだ
ろう。

【００１３】例えば、本の売上情報やＴＶ番組の視聴率
情報など、ウェブサイトを構成する情報資源の一部をア
ウトソーシングするといった、分散管理型のウェブサイ
ト構築スタイルが可能となり、大きなウェブパーツ市場
が生まれる可能性もある。また、各ショッピングサイト
が抱える商品カタログを１つのウェブページ上で比較表
示するショッピングモールや、複数の調達システムやオ
ークションシステムなどが抱える案件を統合したマーケ
ットプレースなどの仲介サービスを行うポータルサイト
が最近次々と登場してきており非常に注目されている。
これはウェブ情報が非常に氾濫してきている情勢におい
てウェブ情報を整理したり案内役を果たすサービスへ必
然的なニーズが高まっているからであり、その要求に応
える一つの形である。ウェブリソースを互いに再利用す
るための環境整備は、このようなポータルサイトの構築
に大きな貢献をするだろう。その視点から、電子商取引
システムなどウェブサイト間システム連携への足がかり
となる着実な技術移行という位置付けとも言える。

【００１４】さて、ウェブページ検索サービスや各種商
品比較サービスなど、複数のウェブサイトの情報を取り
まとめる仲介サービスを行うポータルサイトが次々と登
場し、非常に注目を集めているわけだが、このような仲
介サービスは、さらに画像の収集やＭＰ３の収集など機
能の専門化・多様化への発展を見せている。そのタスク
の本質は、分散したウェブリソースを収集して加工した
結果をウェブページとして提供するウェブサイト間のコ
ンテンツ連携である。

【００１５】ＨＴＭＬ技術では、ハイパーリンク機構を
用いることにより任意のウェブページへジャンプできる
ようにしたり、フレーム機構を用いることにより複数の
ウェブページ全体を独立したウィンドウとして表示する
ことはできるが、商品比較機能や合計値段見積もり機能
の提供といった有機的なコンテンツの連携を行うにはま
ったく不十分である。これらを実現するためには、任意
のウェブページを収集して柔軟に加工する機能が必要で
ある。ＨＴＭＬのこのような機能欠如のため、ＣＧＩ
（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃ
ｅ）やＳｅｒｖｌｅｔなどのプログラム起動機構によっ
て実行される外部プログラムやウェブサーバとは独立し
たデーモンプログラムにそれらの加工処理を行わせると
いう方法が取られている。この加工処理は概して次のよ
うな実行手続きが必要である。またデータベースを用い
ている場合は、さらにデータベースへのデータ登録や取
出しの処理が加わる。

【００１６】 １．外部ウェブサイトのＨＴＭＬページを取得する処理 ２．ＨＴＭＬページから必要なテキストを抽出する処理 ３．抽出されたテキストを所望の形式に変換する処理 ４．テキストをつなぎ合わせて１つのＨＴＭＬを作成す
る処理 このような解決手法には欠点がある。すなわち、これら
の処理の多くは仲介サービス間で内容的に似通っている
にもかかわらず、それぞれサイト構築者が１からプログ
ラムを作成しているというのは生産効率および保守性が
悪い。また、作成されたプログラムはそのサイトの環境
に依存するものであり、必然的にそのサイト専用のプロ
グラム資産となってしまうため、他のサイト環境におい
て再利用することが出来ない。

【００１７】このような欠点は、ＷＷＷ技術においてコ
ンテンツ連携をターゲットに置き、それを容易に実現す
るためのツールあるいはシステムが存在しないことが原
因である。

【００１８】

【発明が解決しようとする課題】このように、従来は、
複数のウェブページから必要とする情報を収集して、そ
れを特定の書式に変換するといった加工を行った後、１
つのウェブページ上に合成するための汎用的な手法がな
いという問題点があった。

【００１９】今後、複数のウェブサイトの情報をとりま
とめるポータルサイトのような仲介サービスがより活発
化する状況下において、コンテンツ連携に特化した共通
のプラットフォームを提供することは、生産効率および
ポータビリティの面で有効な手段の１つである。

【００２０】そこで、本発明は、上記問題点に鑑み、複
数のウェブサイトの情報を１つのウェブ文書上に合成す
ることが容易にしかも汎用的に行える文書合成方法およ
びそれを用いた文書合成装置を提供することを目的とす
る。

【００２１】

【課題を解決するための手段】本発明は、インターネッ
トにおけるＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ ｗｅｂ）上
のマークアップ言語で記述された複数の第１の文書の内
容の一部をＷＷＷ上のマークアップ言語で記述された第
２の文書に合成するためのものであって、前記第１の文
書の該インターネット上の所在と、該第１の文書から抽
出する部分文書の範囲と、前記第２の文書上の前記部分
文書の挿入位置と、前記挿入位置に挿入される前記部分
文書を含む前記第２の文書上の文書構造を変換すべき範
囲と、前記文書構造を所望の文書構造に変換するための
変換ルールを記述したファイルの識別情報とをマークア
ップ言語により記述した第２の文書に従って、前記第１
の文書から前記部分文書を抽出して、その部分文書を前
記第２の文書上の前記指定された挿入位置に挿入すると
ともに、前記変換ルールを用いて前記第２の文書上の前
記指定された範囲の文書構造を変換することを特徴とす
る。

【００２２】本発明によれば、複数のウェブサイトの情
報を１つのウェブ文書上に合成することが容易にしかも
汎用的に行える。

【００２３】好ましくは、前記第２の文書は、前記第２
の文書上の前記部分文書の挿入位置とを指定するととも
に、前記第１の文書の所在と、該第１の文書から抽出す
る部分文書の範囲とを記述するため第１のタグ（挿入命
令タグｐｚ：ｔａｒｇｅｔｓ）と、前記変換ルールを用
いて文書構造を変換すべき範囲を指定するとともに、前
記変換ルールを記述したファイルの識別情報を記述する
ための第２のタグ（変換命令タグｐｚ：ｃｏｎｖｅｒ
ｔ）とを用いて記述されている。

【００２４】また、好ましくは、前記第２の文書は、Ｘ
ＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇ
ｕａｇｅ）で記述されている。

【００２５】さらに、好ましくは、前記第１の文書がＸ
ＭＬで記述されていないときは、まず、ＸＭＬによる記
述型式に変換した後、前記第１の文書から前記部分文書
を抽出して、その部分文書を前記第２の文書上の前記指
定された挿入位置に挿入する。

【００２６】なお、上記手法をインターネット上のウェ
ブサーバに組み込み、クライアント装置（ウェブブラウ
ザ）から前記第２の文書の要求を受けたとき、この第２
の文書にの記述に従って１または複数の部分文書を合成
した第２の文書を要求元のウェブブラウザに提供するサ
ーバ装置を構成することができる。

【００２７】

【発明の実施の形態】以下、本発明の実施形態について
図面を参照して説明する。

【００２８】なお、以下の説明は、次に示す項目の順に
なされている。

【００２９】（Ａ）複数のウェブサイトの情報を１つの
ウェブ文書に合成するために必要とされる機能 （Ｂ）ＸＭＬ−Ｐ’ｚ文書 （Ｂ−１）ＸＭＬ−Ｐ’ｚ言語の仕様 （Ｂ−２）ＸＭＬ−Ｐ’ｚ言語処理系の構成および動作 （Ｃ）複数のウェブ文書を１つのウェブ文書上に合成す
るための一連の動作 （Ｄ）ウェブ文書の合成処理のためのＸＭＬ−Ｐ’ｚサ
ーバ間の協調動作 （Ｅ）追記 （Ａ）複数のウェブサイトの情報を１つのウェブ文書に
合成するために必要とされる機能 まず、実施形態の説明する前に、複数のウェブサイトの
情報（ウェブ文書）を１つのウェブ文書に合成するため
に必要とされる機能について説明する。

【００３０】複数のウェブ文書を１つのウェブ文書上に
合成するために必要な機能は、抽出・挿入・変換の３種
類に絞り込まれる。ただし、ウェブサイトの情報、すな
わち、コンテンツとしてのウェブ文書（例えばＨＴＭＬ
文書）の全てが必要となるわけではなく、そのうちの一
部のみが必要となるのが一般であることから、抽出機能
には任意のウェブ文書のうちの部分文書を取り込むこと
が要求される。また、抽出された複数の部分文書を組み
合わせて合成する際に、たとえば表の中に表を入れると
いうような柔軟な挿入機能が要求される。さらにそれだ
けでは不十分で、抽出してきた部分文書を一覧表型式に
合成する際に、形式が不均一である場合に、それらを同
じ形式に合わせるというように、文書の変換機能が要求
されることもある。

【００３１】この分析に基づき、本発明は、次のような
記述モデルを採用する。まず、ＳＳＩ（Ｓｅｒｖｅｒ
Ｓｉｄｅ Ｉｎｃｌｕｓｉｏｎ）およびその発展系であ
るＡＳＰ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ）
やＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）と同
じように、複数のウェブ文書（部分文書）を合成するた
めの合成用ウェブ文書内の任意位置にコマンドを配置
し、そのコマンド実行結果が当該位置に埋め込まれると
いう、パッチワーク的な文書処理方式を採用する。

【００３２】そして、用意するコマンドとして、どのウ
ェブページのどの部分を抽出してどこに挿入するのかを
示す部分文書の挿入コマンドを用意する。この方法は、
抽出される部分文書の指定とその挿入位置を骨格となる
合成用ウェブ文書を用いて自由にそして感覚的に記述で
きる利点がある。それに加えて、骨格となる合成用ウェ
ブ文書の任意の範囲に対して、変換処理を施すことがで
きる変換コマンドを用意する。この変換コマンドは、範
囲情報と変換ルールを入力とし変換結果の文書を出力と
する。まとめると、合成用ウェブ文書内の任意の位置に
合成ロジックを埋め込むことが出来る記述形式を採用
し、合成ロジック用コマンドとして挿入および変換を用
意した。

【００３３】また、採用した実行モデルの１つはＳＳＩ
と同様であり、この合成用ウェブ文書をウェブサーバに
配置しておき、ブラウザからそのＵＲＬへの要求があっ
た場合に、そのウェブサーバに配置された言語処理系が
その合成用ウェブ文書に含まれるコマンドを解釈実行
し、その結果をブラウザに返すというものである。この
方法では、サイト構築者は、合成用ウェブ文書をウェブ
サーバに配置しておくだけで解釈実行の起動について意
識しなくてよいという利点がある。ただし、そのような
実行方法だけではなく、ユーザが手動で解釈実行を行わ
せることも原理的に可能である。この場合、クライアン
ト側で任意の合成を行うことができる。

【００３４】さて、このような合成用ウェブ文書の記述
においてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ
Ｌａｎｇｕａｇｅ）は最適な言語である。ＸＭＬはタ
グ名や属性名を自由に定義し、それに対してアプリケー
ション側がセマンティクスを与えることが出来る。それ
に加えて、またＸＭＬはツリー型の文書構造を持つこと
が保証されているため、ツリー構造で表現される文書構
造上における１つのノードとして表される特定のエレメ
ントを指し示すだけで部分文書（文書範囲）を指定する
ことができる。

【００３５】また、ＸＭＬ自体はローレベルでの標準の
データ形式としての需要から、ＸＳＬＴ（Ｅｘｔｅｎｓ
ｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅ
Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ）（参考文献：ｈｔｔ
ｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｓｌｔ）など
の変換系技術も整備されているし、今後のＸＭＬ技術の
発展においても上記の合成用ウェブ文書を、このＸＭＬ
言語を応用した言語（本発明に係るＸＭＬ応用言語）で
記述することで拡張性およびツール利用などの利便性が
約束されることになる。

【００３６】また、将来、ＨＴＭＬ文書だけでなくＸＭ
Ｌ文書がよく用いられるようになったときにも、抽出対
象として扱いやすいという利点がある。

【００３７】そこで、本発明では、合成用ウェブ文書の
記述言語をＸＭＬ応用言語として具体的に設計する。

【００３８】本発明では、結合のためのベースとなる合
成用ウェブ文書（合成用ウェブページと呼ぶこともあ
る）をＸＭＬで記述し、指定した他のウェブ文書から指
定した範囲の部分（部分文書）を抽出して、それを合成
用ウェブ文書の指定された位置に挿入し、合成用ウェブ
文書の指定した範囲に変換処理（所望の文書構造への変
換処理）を施す、挿入・変換の２つの合成ロジック命令
をその合成用ウェブ文書内にエレメントとして持たせる
方針を採る。

【００３９】このような合成用ウェブ文書、すなわち、
ＸＭＬ文書（ＸＭＬページ）を、ここでは、ＸＭＬ−
Ｐ’ｚ（ＸＭＬ−Ｐｉｅｃｅｓ）文書（ＸＭＬ−Ｐ’ｚ
ページ）と呼ぶものとする。

【００４０】ＸＭＬ−Ｐ’ｚ言語処理系をウェブサーバ
へ組み込みむことにより、図１に示すような動作が可能
になる。なお、ＸＭＬ−Ｐ’ｚ言語処理系を組み込んだ
ウェブサ―バをＸＭＬ−Ｐ’ｚサーバと呼ぶこともあ
る。具体的には、Ｍｉｃｒｏｓｏｆｔ社のウェブサーバ
であるＩＩＳ（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉ
ｏｎ Ｓｅｒｖｅｒ）への組み込む場合を例にとり説明
する。

【００４１】図１に示した基本的な動作原理において、 （ステップＳ１０１）クライアント端末Ｂ１のウェブブ
ラウザからＸＭＬ−Ｐ’ｚサーバＡ１（以下、簡単にサ
ーバＡ１と呼ぶ）へのＸＭＬ−Ｐ’ｚ文書２の要求（Ｇ
ＥＴ／ＨＴＴＰ）が送信される。

【００４２】（ステップＳ１０２）サーバＡ１は、要求
されたリソースがＸＭＬ−Ｐ’ｚ文書かどうかを判断す
る。

【００４３】（ステップＳ１０３）ＸＭＬ−Ｐ’ｚ文書
と判断した場合、サーバＡ１は、ＸＭＬ−Ｐ’ｚ言語処
理系（図１の合成処理部１）を起動し、ＸＭＬ−Ｐ’ｚ
文書２に記述されている、指定されたウェブサーバ（例
えば、ここでは、ウェブサーバＡ２、Ａ３）のウェブ文
書（ページ）Ｗ２、Ｗ３から指定した範囲の部分（部分
文書）を抽出し、それをＸＭＬ−Ｐ’ｚ文書の指定位置
に挿入するとともに、ＸＭＬ−Ｐ’ｚ文書に記述されて
いる指定された範囲に変換処理を施す。最終的に、ＸＭ
Ｌ−Ｐ’ｚ言語処理系の処理結果としてのＸＭＬ文書
（合成されたウェブ文書）Ｗ１を得る。

【００４４】（ステップＳ１０４）得られたＸＭＬ文書
を要求元への返答としてブラウザに送信する。

【００４５】上記動作は、ウェブサーバの設定によって
実現する。ほとんどのウェブサーバには、ＵＲＬ文字列
のパターン（よくあるのがオブジェクトの拡張子）とそ
れを前処理するのに必要なアドインを対応付ける機能を
持っており、それを利用することにより（ステップＳ１
０２）〜（ステップＳ１０３）を実現できる。

【００４６】また、ウェブブラウザがＸＭＬ文書を表示
できる場合はＸＭＬ文書を、表示できない場合はサーバ
Ａ１側でスタイルシートを処理してＨＴＭＬ文書を返す
という処理があってもよい。

【００４７】（Ｂ）ＸＭＬ−Ｐ’ｚ文書 ＸＭＬ−Ｐ’ｚ文書では、挿入命令エレメント「ｐｚ：
ｔａｒｇｅｔｓ」と変換命令エレメント「ｐｚ：ｃｏｎ
ｖｅｒｔ」とを定義する。

【００４８】挿入命令タグを用いることにより、ＸＭＬ
−Ｐ’ｚ文書のツリー構造で表現される文書構造上にお
ける１つのエレメント下の子文書として他のＸＭＬ文書
またはＨＴＭＬ文書の部分文書を挿入（合成）すること
ができる。挿入対象とする部分文書の指定としては、Ｘ
Ｐｏｉｎｔｅｒ付ＵＲＬ（参考文献：ｈｔｔｐ：／／ｗ
ｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＷＤ−ｘｐｔｒ＃ｕｒｉ−
ｅｓｃａｐｉｎｇ）を採用する。これにより１行で簡潔
に特定ウェブページの部分文書を指定することが出来
る。ただしＸＰｏｉｎｔｅｒ規格はＸＭＬのためのもの
であるため、ＨＴＭＬを直接対象とすることが出来な
い。このことから、抽出する際に、ＨＴＭＬ−ＤＯＭ
（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）およ
びＸＭＬ−ＤＯＭを用いることにより、構造的に等価な
ＨＴＭＬ−ＸＭＬ変換を行う機構を導入する。これによ
りＨＴＭＬ文書はＸＭＬ文書として扱うことが出来るの
で、すべての加工処理はＸＭＬとして行うことが出来る
ようになる。

【００４９】またＸＭＬ−Ｐ’ｚ文書では、変換命令エ
レメントを用いることにより、任意のエレメント（ノー
ド）下の各子文書に対してＸＳＬＴ（Ｅｘｔｅｎｓｉｂ
ｌｅＳｔｙｌｅ Ｌａｎｇｕａｇｅ ｔｒａｎｓｆｏｒ
ｍａｔｉｏｎｓ）を用いた変換操作を実行することがで
きる。すなわち、変換命令エレメントによって指示され
た、変換命令エレメントの子ノードとして配置される各
子文書に対して指定されたＸＳＬＴが適用される。これ
を利用して、挿入命令タグによって挿入されたウェブ文
書を変換命令タグを用いて変換することができる。

【００５０】以下は、挿入命令エレメントと変換命令エ
レメントとを用いた、挿入機能と変換機能を有するＸＭ
Ｌ−Ｐ’ｚ文書の単純な例である。

【００５１】（ＸＭＬ−Ｐ’ｚ文書の第１の例） １．<?xml version=”1.0”?> ２．<root xmlns:pz=”http://www.shiba.co.jp/xmlp
z”> ３． <category>xxx</category> ４． <item_holder> ５． <pz:convert href=”xxx.xsl”> ６． <pz:targets href=”http://www.yyy.com/inde
x.xml#xpointer(//item)”/> ７． </pz:convert> ８． </item_holder> ９．</root> 図１１（ａ）は、上記第１の例の文書構造を模式的に示
したもので、図１１（ｂ）は、上記第１の例を解釈した
後のＸＭＬ文書の文書構造を模式的に示したものであ
る。

【００５２】上記第１の例において、６行目の挿入命令
エレメント「ｐｚ：ｔａｒｇｅｔｓ」で指定された挿入
対象の各ＸＭＬ部分文書（ｈｔｔｐ：／／ｗｗｗ．ｙｙ
ｙ．ｃｏｍ／ｉｎｄｅｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ
（／／ｉｔｅｍ）で、以下、簡単に部分文書ＰＤ１と呼
ぶ）が、５行目の変換命令エレメント「ｐｚ：ｃｏｎｖ
ｅｒｔ」で指定されたＸＳＬＴの変換ルールが適用され
て変換され、４行目〜８行目にある「ｉｔｅｍ＿ｈｏｌ
ｄｅｒ」エレメントの子エレメントとして、図１１
（ｂ）に示すように、挿入される。ただし、６行目の
「ｐｚ：ｔａｒｇｅｔｓ」で指定されているウェブ文書
はＸＰｏｉｎｔｅｒにマッチするすべての部分文書であ
り（上記第１の例の場合は、「ｉｔｅｍ」タグがルート
となる部分文書すべて）、一般的には複数のウェブ文書
となる。

【００５３】上記の分散ウェブリソースのウェブ文書合
成手法は以下の優位性がある。

【００５４】優位点の一つは構築容易性である。本手法
は、データベースを中心とした従来の方式と異なり、情
報資源の合成ロジックをプログラミング言語なしで簡潔
に記述できるので、ウェブ文書統合の構築・構成変更が
容易である。またブラウザからの要求時に解釈処理され
るインタプリタ型の実行モデルが採用されているので、
合成ロジックの変更はただちに反映される。

【００５５】もう一つの優位点は高い再利用性にある。
ＸＭＬ−Ｐ’ｚのフレームワークでは、コンテンツ・変
換ルール・合成ロジックなどすべての構成要素がウェブ
リソースとして提供される。ウェブ文書の外にプログラ
ムとして合成ロジックを持たせていた従来の方法と異な
り、本方式ではＵＲＬを介してこれらすべての構成要素
にアクセスすることができるので、原理的に世界中のウ
ェブシステムから再利用することができる。このことは
ウェブサイトを越えた分散システムに必要な各リソース
を自由に配置することを意味し、運用に応じた柔軟なシ
ステム構築および変更が可能となる。

【００５６】さらにＸＭＬ−Ｐ’ｚ文書が別サイトのＸ
ＭＬ−Ｐ’ｚ文書を合成対象とすることでウェブサイト
間で合成ロジックを分業（連携）することができる。

【００５７】またＨＴＴＰ以外の特別なプロトコルをま
ったく用いておらず、ウェブリソースを提供する側ウェ
ブサイトは特別な処理システムを導入する必要がない。
したがってあらゆるウェブサイトの情報資源を再利用対
象とすることができる。言い換えれば、既存のウェブサ
イトはシステム資源をそのまま生かすことが出来、ＸＭ
Ｌ−Ｐ’ｚ資源を別途作成するだけで合成することが出
来る。

【００５８】ただし、このような高いアクセシビリティ
については、著作権問題など利用に関する実運用上の問
題がからむ。たとえば、ＸＭＬ−Ｐ’ｚ技術を用いれ
ば、ウェブ検索サービスを行っている複数のウェブサイ
トの検索結果を合成するメタ検索ページを提供すること
が簡単にできるが、著作権問題に抵触する。このような
問題は、現在のＷＷＷにおいてもハイパーリンクの許可
をめぐって問題となっており運用で乗り切っている現状
がある。これに対して、 Ｅｘｔｒａｎｅｔ構築技術な
どアクセスコントロールに関するＷＷＷ技術が提供され
ている一方、ＷＷＷで公開された著作物の取り扱いに関
する法整備が急ピッチで行われているところである。ま
たＸＭＬ−Ｐ’ｚフレームワークにおいても、将来の課
題として著作権問題を包括的に取り扱うモデルを導入し
たいと考えている。

【００５９】次に、以上、説明した分散ウェブリソース
のウェブ文書合成手法を次の２つのパートに分けて説明
する。

【００６０】（Ｂ−１） ＸＭＬ−Ｐ’ｚ言語の仕様 （Ｂ−２） ＸＭＬ−Ｐ’ｚ言語処理系の構成および動
作 ＸＭＬ−Ｐ’ｚ言語とは、合成ロジックを含むウェブペ
ージ記述言語であり本システムの中核をなす。まずその
言語仕様について（Ｂ−１）で説明する。次にＸＭＬ−
Ｐ’ｚ言語で記述されたＸＭＬ−Ｐ’ｚ文書を解釈処理
し、その結果を返す言語エンジンとしての言語処理系の
構成およびその動作について（Ｂ−２）で説明する。

【００６１】（Ｂ−１）ＸＭＬ−Ｐ’ｚ言語の仕様 ＸＭＬ−Ｐ’ｚ言語とは、特定のタグ名に対してセマン
ティクスが与えられたＸＭＬ応用言語の１つであり、分
散ウェブリソースの合成を目的としたウェブ文書記述言
語である。通常のＸＭＬ文書と同様、コンテンツを記述
することができるのに加え、任意のエレメントに対し
て、ウェブリソースを操作する命令用のタグ名を記述す
ることにより、合成ロジックを内部に含めることができ
る。この合成ロジックの記述はＨＴＭＬのハイパーリン
クのように簡潔である。

【００６２】このように合成ロジックを含むＸＭＬ−
Ｐ’ｚ言語にて記述されたＸＭＬ−Ｐ’ｚ文書は、その
合成ロジックに従い仮想的に分散リソースを統合・合成
したウェブ文書へと解釈される。

【００６３】ウェブリソース操作に関する命令エレメン
トとして「ｔａｒｇｅｔｓ」および「ｃｏｎｖｅｒｔ」
の２つが用意されており、ＸＭＬネームスペースとして
「ｐｚ」を予約している。これらの命令エレメントを組
み合わせ用いることにより、他のウェブ文書を含めた任
意の部分文書の抽出および自文書の挿入やＸＳＬＴを用
いた構造変換を行うことができる。以下に各命令エレメ
ント（ｐｚ：ｃｏｎｖｅｒｔエレメント、ｐｚ：ｔａｒ
ｇｅｔｓエレメント）について説明する。

【００６４】また、これらの命令エレメントは深さ優先
の探索順序で解釈されなければならない。たとえば、図
１２に示すＸＭＬ−Ｐ’ｚ文書の文書構造において、ｐ
ｚ：ｃｏｎｖｅｒｔエレメントの子エレメントとして、
ｐｚ：ｔａｒｇｅｔｓエレメントが複数ある場合、各ｐ
ｚ：ｔａｒｇｅｔｓエレメントが兄から弟へ順に解釈さ
れた後、ｐｚ：ｃｏｎｖｅｒｔエレメントが解釈され
る。

【００６５】また、各命令タグの項でも説明していると
おり、挿入命令エレメントによって挿入されるウェブ文
書および変換命令エレメントによって変換するウェブ文
書は、合成、変換する前にＸＭＬ−Ｐ’ｚ文書として解
釈されなければならない。すなわち、命令エレメントに
よって挿入、変換するウェブ文書内に命令エレメント
（挿入、変換命令エレメント）が含まれている場合、そ
れらが優先的に上述の順序で解釈されたのち、挿入先で
ある本ＸＭＬ−Ｐ’ｚ文書の解釈実行が続行されるとい
う再帰的な解釈処理の流れとなる。

【００６６】また、ウェブリソースの指定子としてＸＰ
ｏｉｎｔｅｒ付ＵＲＬを導入している。これはＸＰｏｉ
ｎｔｅｒ規格（参考文献：ｈｔｔｐ：／／ｗｗｗ．ｗ
３．ｏｒｇ／ＴＲ／ＷＤ−ｘｐｔｒ）に準拠するもので
あるが、本規格ではＸＰｏｉｎｔｅｒ付ＵＲＬの相対指
定について未定義であるので、ＸＭＬ−Ｐ’ｚ言語では
独自に規格を定めている。

【００６７】以下にその規格を示す。

【００６８】（ＸＭＬネームスペース）ＸＭＬ−Ｐ’ｚ
の各命令タグを利用するためには、以下のネームスペー
スを宣言しなければならない。

【００６９】・ネームスペース名 ｐｚ ・ネームスペースＵＲＩ ｈｔｔｐ：／／ｓｈｉｂａ．ｃｏ．ｊｐ／ｘｍｌｐｚ （ｐｚ：ｔａｒｇｅｔｓエレメント）任意のウェブリソ
ースを抽出・挿入する 文法 ＜ｐｚ：ｔａｒｇｅｔｓｈｒｅｆ＝”ｗｅｂ−ｒｅｓｏ
ｕｒｃｅｓ−ｕｒｌ”＞ ＜／ｐｚ：ｔａｒｇｅｔｓ＞ ・属性 ｈｒｅｆ 挿入対象となる複数のウェブリソースへのＵＲＬ。ＵＲ
ＬがＸＰｏｉｎｔｅｒ付である場合、ＵＲＬのボディ部
のウェブ文書においてＸＰｏｉｎｔｅｒパターンにマッ
チするすべての部分文書が指定される。

【００７０】・構造制約 親エレメント： 任意 子エレメント： なし ・注釈 ｐｚ：ｔａｒｇｅｔｓエレメントは、ｈｒｅｆ属性によ
って指定された単数あるいは複数のウェブリソースをＸ
ＭＬ−Ｐ’ｚ文書として解釈したのち当該エレメントの
コンテクストに対して挿入し、ｐｚ：ｔａｒｇｅｔｓエ
レメント自身は消滅する。ｈｒｅｆ属性によって示され
るＵＲＬがＸＰｏｉｎｔｅｒ付である場合、ＵＲＬのボ
ディ部のウェブ文書においてＸＰｏｉｎｔｅｒパターン
にマッチするすべての部分文書が指定される。

【００７１】・サンプル 以下の例は、自文書内に含まれている本のデータに加
え、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏｍ／ｂｏｏ
ｋｌｉｓｔ．ｘｍｌ」ページ内に含まれる本データをす
べて取り込むＸＭＬ−Ｐ’ｚ文書である。

【００７２】１．<?xml version=”1.0”?> ２．<bookstore specialty=”novel” ３． xmlns:pz=”http://www.shiba.co.jp/x
mlpz”> ４． <book style=”textbook”> ５． <author> ６． <first-name>Shinichiro</first-name> ７． <last-name>Hamada</last-name> ８． <publication>Selected Short Stories of ９． <first-name>Shinichiro</first-name> １０． <last-name>Hamada</last-name> １１． </publication> １２． </author> １３． <price>55</price> １４， </book> １５． <pz:targets href=”http://www.xxx.com/bookl
ist.xml#xpointer(//book)”/> １６．</bookstore> （ｐｚ：ｃｏｎｖｅｒｔエレメント）任意の部分文書群
をＸＳＬＴ文書を用いて変換する 文法 ＜ｐｚ：ｃｏｎｖｅｒｔｈｒｅｆ＝”ｘｓｌｔ−ｕｒ
ｌ”＞ ＜／ｐｚ：ｔａｒｇｅｔｓ＞ 属性 ｈｒｅｆ 変換ルールを定義するＸＳＬＴ文書へのＵＲＬ。ＵＲＬ
がＸＰｏｉｎｔｅｒ付である場合、ＵＲＬのボディ部の
ウェブ文書においてＸＰｏｉｎｔｅｒパターンにマッチ
する部分文書のうち、文書順で先頭の部分文書が指定さ
れる。

【００７３】構造制約 親エレメント： 任意 子エレメント： 任意 注釈 ｐｚ：ｃｏｎｖｅｒｔエレメントは、当該エレメント下
の各子文書それぞれに対して、ｈｒｅｆ属性によって指
定されたＸＳＬＴ文書を適用して変換する。変換された
各子文書は、ＸＭＬ−Ｐ’ｚ文書として解釈した後ｐ
ｚ：ｃｏｎｖｅｒｔエレメントのコンテクストに挿入さ
れ、ｐｚ：ｃｏｎｖｅｒｔエレメント自身は消滅する。
ｈｒｅｆ属性によって示されるＵＲＬがＸＰｏｉｎｔｅ
ｒ付である場合、ＵＲＬのボディ部のウェブ文書におい
てＸＰｏｉｎｔｅｒパターンにマッチする部分文書のう
ち、文書順で先頭の部分文書が指定される。

【００７４】サンプル 以下の例は、「ｔｅｘｔｂｏｏｋ」エレメントで表現さ
れている自文書内に含まれている教科書データに加え、
「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏｍ／ｂｏｏｋｌ
ｉｓｔ．ｘｍｌ」ページ内に含まれるすべての教科書デ
ータを「ｔｅｘｔｂｏｏｋ−ｂｏｏｋ．ｘｓｌ」という
ＸＳＬＴ文書に記述された変換ルールに従って、共通書
籍形式へ変換し、また、「ｈｔｔｐ：／／ｗｗｗ．ｙｙ
ｙ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」ページで公開され
ている本データを共通書籍形式へ変換したものをすべて
取り込むＸＭＬ−Ｐ’ｚ文書である。

【００７５】１．<?xml version=”1.0”?> ２．<bookstore specialty=”novel”xmlns:pz=”http:
//www.shiba.co.jp/xmlpz”> ３． <pz:convert href=”textbook-book.xsl”> ４． <textbook> ５． <author> ６． <first-name>Shinichiro</first-name> ７． <last-name>Hamada</last-name> ８． <publication>Selected Short Stories of ９． <first-name>Shinichiro</first-name> １０． <last-name>Hamada</last-name> １１． </publication> １２． </author> １３． <price>55</price> １４． </textbook> １５． <pz:targets href=”http://www.xxx.com/bo
oklist.xml#xpointer(//textbook)”/> １６． </pz:convert> １７． <pz:convert href=”html-book.xsl”> １８． <pz:targets href=”http://www.yyy.com/in
dex.html#xpointer(//TABLE[2]//TR)”/> １９． </pz:convert> ２０．</bookstore> （ＸＰｏｉｎｔｅｒ付ＵＲＬの相対指定）ウェブリソー
スが他のウェブリソースを参照指定する際に、自ウェブ
リソースの持つＵＲＬをベースとして相対的なＵＲＬを
用いることができる。これを相対ＵＲＬと言う。資源を
一意に区別するためには、処理系が相対ＵＲＬを絶対Ｕ
ＲＬへ展開しなければならない。その解決方法を以下に
示す。ただし以下の説明において、用語はＩＥＴＦ（ｈ
ｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆ
ｃ１７３８．ｔｘｔ）に基づくものとする。

【００７６】１．）ベースＵＲＬのオブジェクトと相対
ＵＲＬのオブジェクトが異なる場合 ベースＵＲＬから（もしあれば）ＸＰｏｉｎｔｅｒフラ
グメントを取り除いたボディ部と、相対ＵＲＬから（も
しあれば）ＸＰｏｉｎｔｅｒフラグメントを取り除いた
ボディ部との間で、ＩＥＴＦ（ｈｔｔｐ：／／ｗｗｗ．
ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１８０８．ｔｘｔ）
に基づいた相対ＵＲＬの解決を行った結果に対して、
（もしあれば）相対ＵＲＬのＸＰｏｉｎｔｅｒフラグメ
ントを与える。なお、ＸＰｏｉｎｔｅｒフラグメントと
は、例えば、以下のサンプルの記述における「＃ｘｐｏ
ｉｎｔｅｒ」以下の部分で、「＃ｘｐｏｉｎｔｅｒ（／
ｎｏｄｅ１／ｎｏｄｅ２）」や、「＃ｘｐｏｉｎｔｅｒ
（．／ｎｏｄｅ３／／ｎｏｄｅ４）」である。

【００７７】・サンプル （ベースＵＲＬ） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄ
ｉｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（／ｎｏｄ
ｅ１／ｎｏｄｅ２） （相対ＵＲＬ） ．／ｄｉｒ２／ｙｙｙ．ｘｍｌ＃
ｘｐｏｉｎｔｅｒ（．／ｎｏｄｅ３／／ｎｏｄｅ４） （解決結果） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄｉ
ｒ１／ｄｉｒ２／ｙｙｙ．ｘｍｌ＃ｘｐｏｉｎｔｅ
ｒ（．／ｎｏｄｅ３／／ｎｏｄｅ４） ２．）ベースＵＲＬのオブジェクトと相対ＵＲＬのオブ
ジェクトが同じ場合 ベースＵＲＬがＸＰｏｉｎｔｅｒフラグメントを含んで
いる場合はＸＰｏｉｎｔｅｒが示す文書ノード、ＸＰｏ
ｉｎｔｅｒフラグメントを含んでいない場合はルート文
書ノードを起点として、（もしあれば）相対ＵＲＬのＸ
Ｐｏｉｎｔｅｒの示すノードを決定し、そのノードパス
を示すＸＰｏｉｎｔｅｒフラグメントを当該オブジェク
トのＵＲＬに与える。

【００７８】・サンプル （ベースＵＲＬ） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄ
ｉｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（／ｎｏｄ
ｅ１／ｎｏｄｅ２） （相対ＵＲＬ） ｈｔｔｐ：／／ａａａ．ｃｏｍ／
ｄｉｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（．／ｎ
ｏｄｅ３／／ｎｏｄｅ４） （解決結果） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄｉ
ｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（／ｎｏｄｅ
１／ｎｏｄｅ２／ｎｏｄｅ３／／ｎｏｄｅ４） ３．）相対ＵＲＬにおいてオブジェクトが無指定である
場合 ベースＵＲＬがＸＰｏｉｎｔｅｒフラグメントを含んで
いる場合はＸＰｏｉｎｔｅｒが示す文書ノード、ＸＰｏ
ｉｎｔｅｒフラグメントを含んでいない場合はルート文
書ノードを起点として、（もしあれば）相対ＵＲＬのＸ
Ｐｏｉｎｔｅｒの示すノードを決定し、そのノードパス
を示すＸＰｏｉｎｔｅｒフラグメントをベースＵＲＬの
オブジェクトのＵＲＬに与える。

【００７９】サンプル （ベースＵＲＬ） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄ
ｉｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（／ｎｏｄ
ｅ１／ｎｏｄｅ２） （相対ＵＲＬ） ＃ｘｐｏｉｎｔｅｒ（．／ｎｏｄ
ｅ３／／ｎｏｄｅ４） （解決結果） ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｄｉ
ｒ１／ｘｘｘ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ（／ｎｏｄｅ
１／ｎｏｄｅ２／ｎｏｄｅ３／／ｎｏｄｅ４） （Ｂ−２）ＸＭＬ−Ｐ’ｚ言語処理系の構成および動作 次に、ＸＭＬ−Ｐ’ｚ言語の解釈処理系について説明す
る。

【００８０】ＸＭＬ−Ｐ’ｚ言語処理系は、ＸＭＬ−
Ｐ’ｚ文書の所在を示すＵＲＬまたはソースを入力と
し、その解釈結果のＸＭＬ文書ソースを出力とするソフ
トウェアコンポーネントである。本処理系ではＸＭＬ−
Ｐ’ｚ言語の解釈処理を２パスで行う方式を取ってお
り、１パス目でＸＭＬとして構文解析を行ってＸＭＬ−
ＤＯＭツリーを作成し、続いて２パス目でＸＭＬ−ＤＯ
Ｍツリーを深さ優先でたどりながら、ＸＭＬ−Ｐ’ｚ言
語特有の命令エレメント（挿入、変換命令タグで囲まれ
た部分）の解釈処理を行う。この言語処理に際して、文
法逸脱を発見した場合やネットワークトラブルなどのラ
ンタイムエラーが発生した場合でも、解釈処理をそのま
ま続行することにより、可能な最良の結果を出力する処
理方針をとる。

【００８１】またＸＭＬ−Ｐ’ｚ言語ではＸＰｏｉｎｔ
ｅｒ付ＵＲＬを用いたウェブリソース指定が可能である
が、本処理系では、ＵＲＬで示される文書全体をダウン
ロードした上で、ＸＰｏｉｎｔｅｒで指定された部分文
書を切り出すという２段階の処理を行う方式を取る。こ
れにより、ＸＰｏｉｎｔｅｒ付ＵＲＬに対応していない
ほとんどのウェブサーバに対しても、ウェブリソースを
要求することが出来る。

【００８２】以上が基本的な処理方針である。この処理
方針に基づいた本処理系のシステム構成例について説明
する。

【００８３】図２は、ＸＭＬ−Ｐ’ｚ言語処理系１００
（図１の合成処理部１に相当）の全体の構成例である。
図２において、この言語処理系１００は、大きく分け
て、ＸＭＬ−Ｐ’ｚ文書読込に関する処理モジュールで
ある、解釈バッファファクトリ１０１と、読み込まれた
文書を解釈した結果のＸＭＬを返す処理モジュールであ
る、インタプリタ１０２の２つから構成されている。こ
れらは基本的に独立に動作する。なお、図２中の２つの
解釈バッファファクトリ１０１は同一物であるが見やす
くするため分けて書いている。

【００８４】解釈バッファファクトリ１０１は、ＸＭＬ
−Ｐ’ｚ文書の所在を示すＵＲＬまたはソースの入力を
トリガとして動作を開始し、まず、ＸＭＬノーマライザ
１１１において、入力文書がＸＭＬならばそのまま、Ｈ
ＴＭＬならば同等の構造を持つＸＭＬへの等価変換処理
を行った上で、ＸＭＬ−ＤＯＭパーサ１１４を用いてＸ
ＭＬ−ＤＯＭツリーを作成し、さらに、ＸＰｏｉｎｔｅ
ｒプロセッサ１１５において、ＵＲＬ内に含まれるＸＰ
ｏｉｎｔｅｒフラグメントにしたがって部分文書を抽出
した結果をもとに、解釈バッファイニシャライザ１１６
は、解釈バッファ１０３，１０４を生成する。

【００８５】さらに、ＵＲＬまたはソースの入力が処理
系１００外部からであった場合、生成する解釈バッファ
を、デフォルト解釈バッファ１０３として登録する。こ
こで解釈バッファとはＸＭＬ−Ｐ’ｚ言語解釈処理の状
態記憶でありインタプリタ１０２の解釈処理中に繁茂に
更新される。

【００８６】一方、インタプリタ１０２は処理系１００
外部からの解釈結果の要求があった場合に動作を開始
し、デフォルト解釈バッファ１０３の解釈用ＸＭＬ−Ｄ
ＯＭツリー１３１を深さ優先でたどりながら、ｐｚ：ｔ
ａｒｇｅｔｓエレメントおよびｐｚ：ｃｏｎｖｅｒｔエ
レメントの２つの命令エレメントの解釈実行を行い、最
終的に得られた解釈結果のＸＭＬ文書を出力する。

【００８７】ただし、命令エレメントの解釈中に一時的
に生成される部分文書をＸＭＬ−Ｐ’ｚ解釈処理するた
め、解釈バッファファクトリ１０１を用いて、一時解釈
バッファ１０４を生成する。

【００８８】次に、解釈バッファファクトリ１０１を構
成する各構成部（モジュール）の処理動作を説明する。

【００８９】解釈バッファファクトリ１０１を構成す
る、ＸＭＬノーマライザ１１１は、ＨＴＭＬ判定器１１
２、および、ＨＴＭＬ−ＸＭＬコンバータ１１３から構
成される。

【００９０】ＨＴＭＬ判定器１１２は、与えられたＵＲ
Ｌが指し示すウェブリソース（ウェブ文書）がＨＴＭＬ
文書かＸＭＬ文書かを判定する。その判定にはＨＴＴＰ
ヘッダの「Ｃｏｎｔｅｎｔ−ｔｙｐｅ」を用いる方法と
ＵＲＬ内に含まれる拡張子を用いる方法の２段階のテス
トを行う。この処理動作を図３に示す。

【００９１】図３において、まず、「Ｃｏｎｔｅｎｔ−
Ｔｙｐｅ」を取得する（ステップＳ１）。この取得の方
法として当該ＵＲＬに対して、ＨＥＡＤ要求を行うのが
もっとも直接的である。しかしＨＥＡＤ要求を理解でき
ないウェブサーバも世の中にたくさんある。代用として
ＧＥＴ要求を用いることもできる。次に、当該ＵＲＬに
対してＨＴＴＰ接続できたかどうか判定する（ステップ
Ｓ２）。もし接続に成功した場合は、ステップＳ３へ進
み、失敗した場合はステップＳ５に進む。

【００９２】ステップＳ３では、「Ｃｏｎｔｅｎｔ−Ｔ
ｙｐｅ」ヘッダを取り出し、その中に「ｔｅｘｔ／ｈｔ
ｍｌ」という文字列が含まれているか判定する。もし含
まれていればＨＴＭＬと判定して終了し（ステップＳ
６）、そうでなければ、ＸＭＬと仮判定して終了する
（ステップＳ４）。

【００９３】ステップＳ５では、ＵＲＬ内のオブジェク
トフィールドの拡張子が「ｈｔｍｌ」または「ｈｔｍ」
であるかどうか判定する。もしそうであればＨＴＭＬと
判定して終了し（ステップＳ６）、そうでなければＸＭ
Ｌと仮判定して終了する（ステップＳ７）。

【００９４】ＨＴＭＬ−ＸＭＬコンバータ１１３は、Ｈ
ＴＭＬ判定器１１２によってＨＴＭＬ文書と判断された
ウェブリソースを構造的に等価なＸＭＬ文書へ変換す
る。これはＨＴＭＬ−ＤＯＭツリーからＸＭＬ−ＤＯＭ
ツリーへと各ＤＯＭのメソッドを用いて順次移していく
ことで実現できる。ＨＴＭＬ−ＸＭＬコンバータ１１３
の処理動作を図４に示す。

【００９５】まず、ステップＳ１１において、与えられ
たＨＴＭＬ文書をＨＴＭＬパーサへ読み込ませ、ＨＴＭ
Ｌ−ＤＯＭツリーを構築する。ＨＴＭＬパーサはウェブ
ブラウザが内部的に用いているものが望ましい。なぜな
らウェブブラウザが使用するＨＴＭＬパーサは、ＨＴＭ
Ｌ文法逸脱に対するエラーリカバリー機能がついている
からである。

【００９６】次に、ステップＳ１２において、ＸＭＬ−
ＤＯＭパーサを用いて空のＸＭＬ−ＤＯＭツリーを構築
する。そして、ステップＳ１３において、ＨＴＭＬ−Ｄ
ＯＭツリーを全探索しながら、立ち寄ったノードの値な
どを取り出しＸＭＬ−ＤＯＭツリーにノードとして挿入
する。

【００９７】以上の処理により、ＸＭＬノーマライザ１
１１は、解釈バッファファクトリ１０１にＵＲＬとして
入力されたウェブリソースをすべてＸＭＬ文書として出
力する。一方、ソースとして入力されたウェブリソース
はすべてＸＭＬ文書と仮定して取り扱われる。

【００９８】ＸＭＬノーマライザ１１１を通過したＸＭ
Ｌ文書またはソースとして入力されたＸＭＬ文書は、Ｘ
ＭＬ−ＤＯＭパーサ１１４に入力され、ＸＭＬ−ＤＯＭ
ツリー化される。さらに、ＸＰｏｉｎｔｅｒプロセッサ
１１５を用いて、ＵＲＬのＸＰｏｉｎｔｅｒフラグメン
トで示されているＸＭＬ文書内の部分文書のＸＭＬ−Ｄ
ＯＭツリーを得る。ＸＰｏｉｎｔｅｒプロセッサ１１５
のＸＰｏｉｎｔｅｒフラグメントに対する処理動作を図
５に示す。

【００９９】まず、ステップＳ２１で、与えられたウェ
ブリソースがＵＲＬによるものだったのか、ソースによ
るものだったのかを判定する。ソースによるものであっ
た場合ＵＲＬは存在しないので、この時点で終了する。

【０１００】次に、ステップＳ２２において、ＵＲＬの
フラグメントからＸＰｏｉｎｔｅｒフラグメントを取り
出す。ただしＸＰｏｉｎｔｅｒが指定されていなかった
場合は空の文字列とする。続いて、ステップＳ２３にお
いてＸＭＬ−ＤＯＭツリーのルートエレメントを基点と
してＸＰｏｉｎｔｅｒが指し示すノードを同定する。こ
れには一般的なＸＰｏｉｎｔｅｒ処理系を用いればよ
い。

【０１０１】次に、ステップＳ２４において指し示され
たノードがエレメントであるかどうかを判定する。もし
エレメントでなければ異常終了する。続いて、ステップ
Ｓ２５において、得られたエレメントをルートエレメン
トとした部分文書のＸＭＬ−ＤＯＭツリーを切り出す。
さらに、ステップＳ２６において、その切り出されたＸ
ＭＬ−ＤＯＭツリーを新しいＸＭＬ文書のＸＭＬ−ＤＯ
Ｍツリーとする。

【０１０２】さて、得られたＸＭＬ−ＤＯＭツリーを基
に、解釈バッファイニシャライザ１１６は解釈バッファ
を生成する。このとき与えられたウェブリソースが言語
処理系１００外部からの入力によるものであった場合、
その解釈バッファを、デフォルト解釈バッファ１０３と
して登録する。この解釈バッファ（メモリで構成されて
いる）の初期化処理動作を図６に示す。なお、部分文書
のＸＭＬ−ＤＯＭツリーの場合は、一時解釈バッファ１
０４を図６と同様にして初期化する。

【０１０３】まず、ステップＳ３１では、与えられたＸ
ＭＬ−ＤＯＭツリーをソースＸＭＬ−ＤＯＭツリー１３
４にコピーする。なお、ソースＸＭＬ−ＤＯＭツリー１
３４は、以後のＸＭＬ−Ｐ’ｚ言語の解釈処理によって
変更される前のＸＭＬ−ＤＯＭツリーの初期状態を記憶
するバッファであり、ＸＭＬ−Ｐ’ｚ言語のソース提供
などの用途を想定しているが、本実施形態では利用され
ない。

【０１０４】次に、ステップＳ３２では、与えられたＸ
ＭＬ−ＤＯＭツリーを解釈用ＸＭＬ−ＤＯＭツリー１３
１へコピーする。解釈用ＸＭＬ−ＤＯＭツリー１３１
は、インタプリタ１０２が解釈処理において構造の読み
込みおよび解釈結果の書き込みに用いる。

【０１０５】ステップＳ３３では、プログラムカウンタ
１３２を解釈用ＸＭＬ−ＤＯＭツリー１３１のルートエ
レメントにセットする。プログラムカウンタ１３２は、
インタプリタ１０２の解釈処理の進捗を記憶するポイン
タである。

【０１０６】最後に、ステップＳ３４では、ロードフラ
グ１３３を「ｆａｌｓｅ」にセットする。ロードフラグ
１３３とは、当該解釈バッファ１０３がすでに解釈処理
済みかどうかを示すフラグである。インタプリタ１０２
は、このフラグ１３３を利用して過去に解釈処理を施し
た解釈バッファについて解釈処理をし直さないようにな
っている。

【０１０７】以上が、解釈バッファファクトリ１０１の
処理動作の説明である。

【０１０８】次に、インタプリタ１０２の処理動作につ
いて説明する。

【０１０９】インタプリタ１０２を構成するコンテクス
トマネージャ１２１は、解釈処理において中心的役割を
果たす。解釈バッファ１０３，１０４のプログラムカウ
ンタ１３２，１４２に従い、解釈用ＸＭＬ−ＤＯＭツリ
ー１３１，１４１の各ノードを深さ優先で立ち寄る際
に、命令エレメントを発見すると該当する処理モジュー
ル（ｔａｒｇｅｔｓコマンドプロセッサ１２２，ｃｏｎ
ｖｅｒｔコマンドプロセッサ１２３）へ解釈処理を依頼
する。命令エレメントの解釈処理が終了すると立ち寄り
処理を続行する。すべての処理が終わると解釈結果とし
てＸＭＬ文書を出力する。この処理動作を図７に示す。
以下、デフォルト解釈バッファ１０３を用いた解釈処理
の場合を説明するが、一時解釈バッファ１０４の場合も
同様である。

【０１１０】まず、ステップＳ４１において、解釈バッ
ファ１０３のロードフラグ１３３を調べる。ロードフラ
グが「ｔｒｕｅ」であればすでに解釈済みであり「ｆａ
ｌｓｅ」ならば、まだ解釈処理が行われていない状態で
あることを意味する。「ｔｒｕｅ」ならば、ステップＳ
４９へ進み、「ｆａｌｓｅ」ならば、ステップＳ４２へ
進む。

【０１１１】ステップＳ４２では、プログラムカウンタ
１３２を読み込んで解釈処理対象とするエレメント（こ
れをカレントエレメントと呼ぶ）を決定する。

【０１１２】ステップＳ４３では、カレントエレメント
のエレメント名が「ｐｚ：ｔａｒｇｅｔｓ」かどうかを
チェックし、「ｐｚ：ｔａｒｇｅｔｓ」だった場合は、
ステップＳ４へ進み、ｐｚ：ｔａｒｇｅｔｓエレメント
の解釈処理をｔａｒｇｅｔｓコマンドプロセッサ１２２
へ依頼する。

【０１１３】続いて、ステップＳ４５では、カレントエ
レメントのエレメント名が「ｐｚ：ｃｏｎｖｅｒｔ」か
どうかチェックし、「ｐｚ：ｃｏｎｖｅｒｔ」だった場
合は、ステップＳ４６へ進み、ｐｚ：ｃｏｎｖｅｒｔエ
レメントの解釈処理をｃｏｎｖｅｒｔコマンドプロセッ
サ１２３へ依頼する。

【０１１４】続いて、ステップＳ４７で、深さ優先で移
動先エレメントを決定しプログラムカウンタにセットす
る。カレントエレメントの子エレメントのうち、まだ解
釈処理を行っていないエレメントがあれば、そのうちの
長兄エレメントをプログラムカウンタへセットする。す
べての子エレメントの解釈処理が行われているならば、
親エレメントにプログラムカウンタへセットする。ただ
し親エレメントがいない場合は、プログラムカウンタを
「ＮＵＬＬ」にセットする。

【０１１５】ステップＳ８では、プログラムカウンタ１
３２が「ＮＵＬＬ」かどうかをチェックし、「ＮＵＬ
Ｌ」でなければ、ステップＳ４２へ戻る。「ＮＵＬＬ」
であれば、解釈用ＸＭＬ−ＤＯＭツリー１３１の解釈は
終了したので、ステップＳ４９へ進む。

【０１１６】ステップＳ４９では、ＸＭＬ−ＤＯＭパー
サ１５１を用いて解釈バッファ１０３のＸＭＬ−ＤＯＭ
ツリー１３１を基にＸＭＬ文書を生成し出力し、終了す
る。

【０１１７】インタプリタ１０２を構成するｔａｒｇｅ
ｔｓコマンドプロセッサ１２２は、ｐｚ：ｔａｒｇｅｔ
ｓエレメントを解釈し、その結果をカレントエレメント
に書き込む。この処理動作を図８に示す。

【０１１８】まず、ステップＳ５１では、カレントエレ
メントであるｐｚ：ｔａｒｇｅｔｓエレメントのｈｒｅ
ｆ属性値を取り出し、ステップＳ５２で、その属性値を
解釈バッファファクトリ１０１の入力ＵＲＬとして、前
述したＸＭＬノーマライザ１１１から解釈バッファイニ
シャライザ１１６による処理を経由して、一時解釈バッ
ファ１０４を生成する。ただし、対象とするＵＲＬが相
対ＵＲＬであった場合は、前述の「ＸＰｏｉｎｔｅｒ付
ＵＲＬの相対指定」の説明に基づき、挿入先の解釈バッ
ファのＵＲＬをベースとして絶対ＵＲＬへ変換する。

【０１１９】次に、ステップＳ５３へ進み、生成された
一時解釈バッファ１０４を、インタプリタ１０２を用い
て解釈処理し、その結果としてのＸＭＬ文書を得る。

【０１２０】最後に、ステップＳ５４では、ＤＯＭパー
サ１５２を用いて、得られたＸＭＬ文書をＸＭＬ−ＤＯ
Ｍツリーに変換して、カレントエレメントである「ｐ
ｚ：ｔａｒｇｅｔｓ」エレメントと入れ替える。また、
生成した一時解釈バッファ１０４は破棄する。

【０１２１】インタプリタ１０２を構成するｃｏｎｖｅ
ｒｔコマンドプロセッサ１２３は、ｃｏｎｖｅｒｔエレ
メントを解釈し、その結果をカレントエレメントに書き
込む。この処理動作を図９に示す。

【０１２２】まず、ステップＳ６１では、カレントエレ
メントであるｐｚ：ｃｏｎｖｅｒｔエレメントのｈｒｅ
ｆ属性値を取り出し、ステップＳ６２で、その属性値を
解釈バッファファクトリ１０１の入力ＵＲＬとして、前
述したＸＭＬノーマライザ１１１から解釈バッファイニ
シャライザ１１６による処理を経由して、一時解釈バッ
ファ１０４を生成する。ただし、対象とするＵＲＬが相
対ＵＲＬであった場合は、前述の（ＸＰｏｉｎｔｅｒ付
ＵＲＬの相対指定）の説明に基づき、挿入先の解釈バッ
ファのＵＲＬをベースとして絶対ＵＲＬへ変換する。

【０１２３】次に、ステップＳ６３へ進み、生成された
一時解釈バッファ１０４を、インタプリタ１０２を用い
て解釈処理し、その結果としてＸＳＬＴ文書を得る。な
お、このような処理を行うのは、ＸＳＬＴ文書自体がＸ
ＭＬ−Ｐ’ｚ言語でかかれている可能性があるからであ
る（すなわち合成結果としてＸＳＬＴ文書が構成されて
いる可能性があるからである）。

【０１２４】続いて、ステップＳ６４へ進み、ＸＳＬＴ
プロセッサ１２４により、カレントエレメントである
「ｐｚ：ｃｏｎｖｅｒｔ」エレメントの子エレメントの
うち、まだＸＬＳＴを適用していない長兄エレメント
（およびその子孫エレメントを含む部分文書）に、得ら
れたＸＳＬＴ文書を用いて、当該部分文書の文書構造を
ＸＳＬＴ文書に記述された変換ルールを用いて変換し、
その変換して得られたＸＭＬ−ＤＯＭツリーを、ステッ
プＳ６５では、合成用ウェブ文書上の変換前の子エレメ
ント（およびその子孫エレメントを含む部分文書）と入
れ替える。

【０１２５】ステップＳ６６において、もし未処理の子
エレメントがあるならば、ステップＳ６４に戻る。すべ
ての子エレメントが処理済ならば、ステップＳ６７へ進
み、ｐｚ：ｃｏｎｖｅｒｔエレメントをｐｚ：ｃｏｎｖ
ｅｒｔエレメントの各子部分文書である文書構造の変換
されたものと入れ替える。

【０１２６】以上が、インタプリタ１０２の処理動作で
あり、以上をもってＸＭＬ−Ｐ’ｚ言語処理系の各構成
部についての説明は終了した。

【０１２７】（Ｃ）複数のウェブ文書を１つのウェブ文
書上に合成するための一連の動作 次に、図２に示した構成のＸＭＬ−Ｐ’ｚ言語処理系１
００をウェブサーバへ組み込み、図１に示した基本的な
動作を行って、実際に、ウェブサーバＡ２のウェブ文書
Ｗ２からその一部を抽出し、その抽出された各部分文書
を１つのウェブ文書上に合成し、合成されたウェブ文書
（ＸＭＬ文書）Ｗ１を出力するための一連の動作を図１
３〜図１５に示すフローチャートを参照して説明する。

【０１２８】ここで、合成用ウェブ文書としてのＸＭＬ
−Ｐ‘ｚ文書２は、図１６に示すものであるとする。な
お、図１６に示すＸＭＬ−Ｐ’ｚ文書は、図１のＸＭＬ
−Ｐ‘ｚ文書２のうちの一部分を抜粋したものを示して
いる。

【０１２９】図１６に示すＸＭＬ−Ｐ‘ｚ文書は、「ｔ
ｅｘｔｂｏｏｋ」エレメントＥ１で表現されている自文
書内に含まれている教科書データと、ｐｚ：ｔａｒｇｅ
ｔｓエレメントＥ２にて挿入される「ｈｔｔｐ：／／ｗ
ｗｗ．ｘｘｘ．ｃｏｍ／ｂｏｏｋｌｉｓｔ．ｘｍｌ」の
ウェブ文書内に含まれるすべての教科書データとを、
「ｔｅｘｔｂｏｏｋ−ｂｏｏｋ．ｘｓｌ」というＸＳＬ
Ｔ文書に記述された変換ルールに従って、共通書籍形式
へ変換して、合成されたウェブ文書（ＸＭＬ文書）Ｗ１
を出力するためのものである。

【０１３０】図１において、クライアント端末Ｂ１のウ
ェブブラウザからＸＭＬ−Ｐ’ｚサーバＡ１（以下、簡
単にサーバＡ１と呼ぶ）へのＸＭＬ−Ｐ’ｚ文書２の要
求がなされたとする（ステップＳ２０１）。

【０１３１】サーバＡ１の言語処理系１００は、要求さ
れた文書が自身が持つ合成用ウェブ文書（ＸＭＬ−Ｐ
‘ｚ文書）２であるので、ＸＭＬ−ＤＯＭパーサ１１４
を用いて当該ＸＭＬ−Ｐ‘ｚ文書のＸＭＬ−ＤＯＭツリ
ーを作成する（ステップＳ２０２）。この作成されたＸ
ＭＬ−ＤＯＭツリーの図１６に対応する部分は、例え
ば、図１７に示すものである。なお、図１７では、説明
の簡単のために概略的に示している。

【０１３２】この作成されたＸＭＬ−ＤＯＭツリーをデ
フォルト解釈バッファ１０３のソースおよび解釈用ＤＯ
Ｍツリー１３４，１３１にコピーし、その他、図６に示
したようにして、デフォルト解釈バッファ１０３を初期
化する（ステップＳ２０３）。

【０１３３】次に、このデフォルト解釈バッファ１０３
の解釈処理をインタプリタ１０２にて行う。ここで、例
えば、図１７に示したようなＸＭＬ−ＤＯＭツリーを解
釈するものとする。

【０１３４】インタプリタ１０２は、前述したように、
命令エレメントを深さ優先で移動先のエレメントを決定
していくので、図１７に示すＤＯＭツリーにおいては、
まず、ｐｚ：ｔａｒｇｅｔｓエレメントＥ２を解釈処理
する（ステップＳ２０４〜ステップＳ２０５）。その
後、エレメントＥ１，Ｅ２の親エレメントであるｐｚ：
ｃｏｎｖｅｒｔエレメントＥ３を解釈処理する（ステッ
プＳ２０６〜ステップＳ２０７）。その後、図１７には
示していないが、ｐｚ：ｃｏｎｖｅｒｔエレメントＥ３
の弟エレメント、あるいは、親エレメントへ、プログラ
ムカウンタ１３２を移動させて、プログラムカウンタが
「ＮＵＬＬ」になるまで、このデフォルト解釈バッファ
１０３の解釈処理を進めていく（ステップＳ２０８）。

【０１３５】さて、ステップＳ２０５では、ｐｚ：ｔａ
ｒｇｅｔｓエレメントＥ２の解釈処理を行うわけだが、
ここでの処理動作を図１４に示す。

【０１３６】ｔａｒｇｅｔｓコマンドプロセッサ１２２
は、ｐｚ：ｔａｒｇｅｔｓエレメントＥ３のｈｒｅｆ属
性値、すなわち、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃ
ｏｍ／ｂｏｏｋｌｉｓｔ．ｘｍｌ＃ｘｐｏｉｎｔｅｒ
（／／ｔｅｘｔｂｏｏｋ）」を取り出し、その属性値を
解釈バッファファクトリ１０１の入力ＵＲＬとする。Ｘ
ＭＬノーマライザ１１１は、この入力ＵＲＬにて指定さ
れた文書がＸＭＬ文書でないならそれをＸＭＬ文書に変
換した後（ステップＳ２１２）、ＸＭＬ−ＤＯＭパーサ
１１４にて、このＸＭＬ文書のＸＭＬ−ＤＯＭツリーを
作成する（ステップＳ２１３）。なお、ここでは、当該
指定された文書はＸＭＬ文書であるので、そのまま、Ｘ
ＭＬ−ＤＯＭパーサ１１４にて、このＸＭＬ文書のＸＭ
Ｌ−ＤＯＭツリーを作成する。

【０１３７】この場合、上記入力ＵＲＬが、サーバＡ２
のウェブ文書Ｗ２を示すＸＰｏｉｎｔｅｒ付ＵＲＬであ
るので、ＸＰｏｉｎｔｅｒプロセッサ１１５が、ＸＰｏ
ｉｎｔｅｒフラグメント、すなわち、「＃ｘｐｏｉｎｔ
ｅｒ（／／ｔｅｘｔｂｏｏｋ）」を取り出し、ステップ
Ｓ２１３で作成されたＸＭＬ−ＤＯＭツリーから当該Ｘ
Ｐｏｉｎｔｅｒが指し示す「ｔｅｘｔｂｏｏｋ」エレメ
ント（その子孫エレメントを含む部分文書）のＸＭＬ−
ＤＯＭツリーを切り出す。「ｔｅｘｔｂｏｏｋ」エレメ
ントが複数ある場合は、それぞれに対して行う。この切
り出されたＸＭＬ−ＤＯＭツリーが挿入すべき部分文書
のＸＭＬ−ＤＯＭツリーである（ステップＳ２１４）。

【０１３８】次に、解釈バッファイニシャライザ１１６
により、一時解釈バッファ１０４を初期化し、この部分
文書にｐｚ：ｔａｒｇｅｔｓエレメントや、ｐｚ：ｃｏ
ｎｖｅｒｔエレメントが記述されているときは、それら
の解釈処理を行って、当該部分文書のＸＭＬ文書を得
る。

【０１３９】記述されていないときは、そのまま一時解
釈バッファ１０４の解釈処理を終了し、コンテクストマ
ネージャ１２１は、ＤＯＭパーサ１５１を用いて、当該
部分文書のＸＭＬ−ＤＯＭツリーからＸＭＬ文書を生成
し（ステップＳ２２１）、ｔａｒｇｅｔｓコマンドプロ
セッサ１２２は、ＤＯＭパーサ１５２を用いて、当該部
分文書のＸＭＬ文書のＸＭＬ−ＤＯＭツリーを作成し
て、これを部分文書郡Ｅ２´として、デフォルト解釈バ
ッファ１０３の解釈用ＸＭＬ−ＤＯＭツリー１３１のカ
レントエレメントであるｐｚ：ｔａｒｇｅｔｓエレメン
トＥ２と入れ替える。その結果、図１８に示すように、
この部分文書郡Ｅ２´が、ｐｚ：ｃｏｎｖｅｒｔエレメ
ントＥ３の子エレメントとなり、ＸＭＬ−ＤＯＭツリー
が更新される。生成した一時解釈バッファ１０４は破棄
する（ステップＳ２２２）。その後、図１３のステップ
Ｓ２０８へ戻る。

【０１４０】図１８に示すように、「ｈｔｔｐ：／／ｗ
ｗｗ．ｘｘｘ．ｃｏｍ／ｂｏｏｋｌｉｓｔ．ｘｍｌ」の
ウェブ文書内には複数の教科書データが存在するので、
その全てが当該ウェブ文書の部分文書のＸＭＬ−ＤＯＭ
ツリーとして挿入されている。

【０１４１】一方、ステップＳ２０７では、ｐｚ：ｃｏ
ｎｖｅｒｔエレメントＥ３の解釈処理を行うわけだが、
ここでの処理動作を図１５に示す。

【０１４２】ｃｏｎｖｅｒｔコマンドプロセッサ１２３
は、ｐｚ：ｃｏｎｖｅｒｔエレメントＥ３のｈｒｅｆ属
性値、すなわち、ＸＳＬＴ文書へのＵＲＬ、「ｔｅｘｔ
ｂｏｏｋ−ｂｏｏｋ．ｘｓｌ」取り出し、その属性値を
解釈バッファファクトリ１０１の入力ＵＲＬとする。以
下のステップＳ２３２〜ステップＳ２４０は、ＸＬＭ文
書としてのＸＳＬＴ文書を得るための処理であって、図
１４のステップＳ２１２〜ステップＳ２２０と同様にし
て、図１５のステップＳ２４１にて、図１９に示したよ
うなＸＭＬ文書としてのＸＳＬＴ文書を得る。

【０１４３】図１９に示すＸＳＬＴ文書は、現在の部分
文書の「ｐｕｂｌｉｃａｔｉｏｎ」エレメント、「ｐｒ
ｉｃｅ」エレメント、「ａｕｔｈｏｒ」エレメントを、
それぞれ「ｔｉｔｌｅ」エレメント、「ｐｒｉｃｅ」エ
レメント、「ａｕｔｈｏｒ」エレメントへ変換するため
の変換ルールを記述したものである。

【０１４４】図１９に示したようなＸＳＬＴ文書を用い
て、ＸＳＬＴプロセッサ１２４は、デフォルト解釈バッ
ファ１０３の解釈用ＸＭＬ−ＤＯＭツリー１３１のカレ
ントエレメントである、ｐｚ：ｃｏｎｖｅｒｔエレメン
トに含まれる部分文書（子部分文書とも呼ぶ）のＸＭＬ
−ＤＯＭツリー上の各子エレメントを変換する（ステッ
プＳ２４２）。

【０１４５】ここでは、自文書内に含まれている教科書
データと、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏｍ／
ｂｏｏｋｌｉｓｔ．ｘｍｌ」のウェブ文書から抽出した
教科書データは同じ構造のデータであるので、エレメン
トＥ１の自文書内含まれていた教科書データの場合を例
にとり、図１９のＸＳＬＴ文書を用いて、その構造を変
換する場合を説明する。

【０１４６】図１６に示すように、エレメントＥ１の子
エレメントである「ｐｕｂｌｉｃａｔｉｏｎ」エレメン
トの値は、「Ｓｅｌｅｃｔｅｄ Ｓｈｏｒｔ Ｓｔｏｒ
ｉｅｓ ｏｆ Ｓｈｉｎｉｃｈｉｒｏ Ｈａｍａｄａ」
であるが、これは、変換後では、「ｔｉｔｌｅ」エレメ
ントの値となる。また、図１６において、エレメントＥ
１の子エレメントである「ａｕｔｈｏｒ」エレメントの
値は「Ｓｈｉｎｉｃｈｉｒｏ Ｈａｍａｄａ」である
が、これは変換後では、「ａｕｔｈｏｒ」エレメントと
なる。さらに、図１６に示すように、エレメントＥ１の
子エレメントである「ｐｒｉｃｅ」エレメントの値は、
「５５」であるが、これは変換後も同じである。

【０１４７】ｃｏｎｖｅｒｔコマンドプロセッサ１２３
は、変換後の部分文書のＸＭＬ−ＤＯＭツリーを、新た
なエレメントＥ３´として、デフォルト解釈バッファ１
０３の解釈用ＸＭＬ−ＤＯＭツリー１３１のカレントエ
レメントであるｐｚ：ｃｏｎｖｅｒｔエレメントＥ３と
入れ替えて、図２０に示したような文書構造のＸＭＬ−
ＤＯＭツリーが生成される。

【０１４８】なお、生成した一時解釈バッファ１０４は
破棄する（ステップＳ２４３）。その後、図１３のステ
ップＳ２０８へ戻る。

【０１４９】以上のようにして、デフォルト解釈バッフ
ァ１０３のプログラムカウンタ１３２が「ＮＵＬＬ」と
なり、ＸＭＬ−ＤＯＭツリー１３１の解釈が終了する
と、コンテクストマネージャ１２１は、ＸＭＬ−ＤＯＭ
パーサ１５１を用いて、図２０に示したＸＭＬ−ＤＯＭ
ツリーを含む解釈バッファ１０３のＸＭＬ−ＤＯＭツリ
ー１３１を基に、目的とするウェブ文書Ｗ１としてのＸ
ＭＬ文書を生成し出力する。

【０１５０】なお、クライアント端末Ｂ１のウェブブラ
ウザがＸＭＬ文書を表示できる場合は、ＸＭＬ文書のウ
ェブ文書Ｗ１をそのままクライアント端末Ｂ１のウェブ
ブラウザに返すが、表示できない場合は、サーバＡ１側
でスタイルシートを処理して、ウェブ文書Ｗ１をＨＴＭ
Ｌ文書に変換してからクライアント端末Ｂ１のウェブブ
ラウザへ返す（図１３のステップＳ２０９）。

【０１５１】（Ｄ）ウェブ文書の合成処理のためのＸＭ
Ｌ−Ｐ’ｚサーバ間の協調動作 次に、ウェブ文書の合成処理をＸＭＬ−Ｐ’ｚサーバ間
で協調して行う場合について説明する。

【０１５２】例えば、あるＸＭＬ−Ｐ’ｚサーバ上のＸ
ＭＬ−Ｐ’ｚ文書を解釈処理中に他のＸＭＬ−Ｐ’ｚサ
ーバのＸＭＬ−Ｐ’ｚ文書を挿入する場合に、その挿入
されるＸＭＬ−Ｐ’ｚ文書は、どちらのサーバが解釈す
るのかという問題がある。すなわち、ＧＥＴコマンドに
よる要求があった場合に、ＸＭＬ−Ｐ’ｚ文書そのもの
を返すのか、解釈処理した結果のＸＭＬ文書を返すのか
という判断を行う必要があるということである。

【０１５３】ＨＴＴＰサーバ（ＸＭＬ−Ｐ’ｚ文書を要
求される側）とＨＴＴＰクライアント（ＸＭＬ−Ｐ’ｚ
文書を要求する側）との間で、ＨＴＴＰクライアントが
ＸＭＬ−Ｐ’ｚ文書を解釈処理できない場合は、ＨＴＴ
Ｐサーバ側でＸＭＬ−Ｐ’ｚ文書を解釈処理しなければ
ならないという制約がある。

【０１５４】この制約を判断の材料に導入するため、Ｘ
ＭＬ−Ｐ’ｚ言語処理系１００の解釈バッファファクト
リ１０１が、ＸＭＬ−Ｐ’ｚ文書を要求する際に、ＧＥ
Ｔコマンドによる要求のヘッダに「ＸＭＬ−Ｐ’ｚ：
ｅｎａｂｌｅ」をつけるものとする。

【０１５５】また、ＨＴＴＰサーバとしては、ＸＭＬ−
Ｐ’ｚ文書の解釈処理をＨＴＴＰクライアントに委譲す
ることにより、サーバの負荷を下げることができる利点
もあるが、ＸＭＬ−Ｐ’ｚ文書を公開したくない何らか
の理由があるかもしれない（含まれている合成ロジック
を公開したくないなど）ので、サーバ側でＸＭＬ−Ｐ’
ｚ言語を解釈処理するかどうかは設定次第である。

【０１５６】以上を踏まえて、ＨＴＴＰサーバが解釈実
行するかどうかの判断処理動作について、図１０の示す
フローチャートを参照して説明する。

【０１５７】まず、ステップＳ７１では、ＧＥＴ要求の
ヘッダに「ＸＭＬ−Ｐ’ｚ：ｅｎａｂｌｅ」が含まれて
いるかどうかを調べ、含まれていないならば、ステップ
Ｓ７２へ進み、ＨＴＴＰサーバ上でＸＭＬ−Ｐ’ｚ文書
を解釈処理して終了する。含まれているならば、ステッ
プＳ７３へ進み、ＨＴＴＰサーバがＸＭＬ−Ｐ’ｚ文書
を処理する設定になっているかどうかをチェックし、そ
うであれば、ステップＳ７４へ進み、ＨＴＴＰサーバで
ＸＭＬ−Ｐ’ｚ文書を解釈処理して終了し、そうでなけ
れば、ステップＳ７５へ進み、解釈処理をしないでＨＴ
ＴＰクライアントにＸＭＬ−Ｐ’ｚ文書をそのまま送信
して終了する。

【０１５８】（Ｅ）追記 以上説明したように、上記実施形態によれば、合成のた
めのベースとなる合成用ウェブ文書をＸＭＬで記述し、
指定した他のウェブ文書から指定した範囲の部分（部分
文書）を抽出して、それを合成用ウェブ文書の指定され
た位置に挿入し、合成用ウェブ文書の指定した範囲に変
換処理を施す、挿入・変換の２つの合成ロジック命令を
その合成用ウェブ文書内にエレメントとして持たせたＸ
ＭＬ−Ｐ’ｚ（ＸＭＬ−Ｐｉｅｃｅｓ）文書を定義す
る。言語処理系１００は、ＸＭＬ−Ｐ’ｚ文書に記述さ
れている、指定されたウェブサーバ（例えば、ここで
は、ウェブサーバＡ２、Ａ３）のウェブ文書（ページ）
Ｗ２、Ｗ３から指定した範囲の部分（部分文書）を抽出
し、それをＸＭＬ−Ｐ’ｚ文書の指定位置に挿入すると
ともに、ＸＭＬ−Ｐ’ｚ文書に記述されている指定され
た範囲に変換処理を施す。最終的に、ＸＭＬ−Ｐ’ｚ言
語処理系１００の処理結果としてのＸＭＬ文書（合成さ
れたウェブ文書）Ｗ１を得ることにより、複数のウェブ
サイトの情報を１つのウェブ文書上に合成することが容
易にしかも汎用的に行える。

【０１５９】なお、上記実施形態に記載した手法は、コ
ンピュータに実行させることのできるプログラムとし
て、ＤＶＤ、ＣＤ−ＲＯＭ、フロッピディスク、個体メ
モリ、光ディスクなどの記録媒体に格納して頒布するこ
ともできる。

【０１６０】

【発明の効果】以上説明したように、本発明によれば、
複数のウェブサイトの情報を１つのウェブ文書上に合成
することが容易にしかも汎用的に行える。

【図面の簡単な説明】

【図１】本発明のＸＭＬ−Ｐ’ｚ言語処理系を組み込ん
だウェブサ―バ（ＸＭＬ−Ｐ’ｚサーバ）の基本的な動
作を説明するための図。

【図２】ＸＭＬ−Ｐ’ｚ言語処理系の全体の構成例を示
した図。

【図３】ＨＴＭＬ判定器において、与えられたＵＲＬに
て指定されるウェブ文書がＨＴＭＬ文書かＸＭＬ文書か
を判定するための処理動作を示したフローチャート。

【図４】ＨＴＭＬ−ＸＭＬコンバータのＨＴＭＬ文書か
らＸＭＬ文書への変換処理動作を説明するためのフロー
チャート。

【図５】ＸＰｏｉｎｔｅｒプロセッサのＸＰｏｉｎｔｅ
ｒフラグメントに対する処理動作を説明するためのフロ
ーチャート。

【図６】解釈バッファイニシャライザの解釈バッファの
初期化処理動作を説明するためのフローチャート。

【図７】コンテクストマネージャの処理動作を説明する
ためのフローチャート。

【図８】ｔａｒｇｅｔｓコマンドプロセッサのｔａｒｇ
ｅｔｓエレメントの解釈処理動作を説明するためのフロ
ーチャート。

【図９】ｃｏｎｖｅｒｔコマンドプロセッサのｃｏｎｖ
ｅｒｔエレメントの解釈処理動作を説明するためのフロ
ーチャート。

【図１０】ＸＭＬ−Ｐ’ｚ文書の解釈処理をサーバ側で
行うかクライアント側で行うかを判断する判断処理動作
について説明するためのフローチャート。、

【図１１】（ａ）図は、ＸＭＬ−Ｐ’ｚ文書の第１の例
の文書構造を模式的に示した図で、（ｂ）図は、ＸＭＬ
−Ｐ’ｚ文書の解釈後のＸＭＬ文書の文書構造を示した
図。

【図１２】ＸＭＬ−Ｐ‘ｚ文書の解釈順序について説明
するための図。

【図１３】図２に示した構成の言語処理系が、複数のウ
ェブ文書を１つのウェブ文書上に合成するための連の動
作を説明するためのフローチャート。

【図１４】図２に示した構成の言語処理系が、複数のウ
ェブ文書を１つのウェブ文書上に合成するための連の動
作を説明するためのフローチャート。

【図１５】図２に示した構成の言語処理系が、複数のウ
ェブ文書を１つのウェブ文書上に合成するための連の動
作を説明するためのフローチャート。

【図１６】合成用ウェブ文書としてのＸＭＬ−Ｐ‘ｚ文
書の一例であって、ＸＭＬ−Ｐ‘ｚ文書の一部を示した
図。

【図１７】図１６のＸＭＬ−Ｐ‘ｚ文書に対応するＸＭ
Ｌ−ＤＯＭツリーを概略的に示した図。

【図１８】図１６のｐｚ：ｔａｒｇｅｔｓエレメントを
解釈した結果のＸＭＬ−ＤＯＭツリーを概略的に示した
図。

【図１９】図１６のＸＭＬ−Ｐ‘ｚ文書に記述されてい
るＸＳＬＴ文書の一例を示した図。

【図２０】図１６のｐｚ：ｔａｒｇｅｔｓエレメントと
ｐｚ：ｃｏｎｖｅｒｔエレメントを解釈した結果のＸＭ
Ｌ−ＤＯＭツリーを概略的に示した図。

【符号の説明】

Ａ１、Ａ２、Ａ３…サーバ Ｂ１…クライアント端末 Ｗ１…合成されたウェブ文書（ＸＭＬ文書） Ｗ２〜Ｗ３…ウェブ文書 １…ＸＭＬ−Ｐ’ｚ言語処理系（合成処理部） ２…ＸＭＬ−Ｐ’ｚ文書 １００…ＸＭＬ−Ｐ’ｚ言語処理系 １０１…解釈バッファファクトリ １０２…インタプリタ １０３…デフォルト解釈バッファ １０４…一時解釈バッファ １１１…ＸＭＬノーマライザ １１２…ＨＴＭＬ判定器 １１３…ＨＴＭＬ−ＸＭＬコンバータ １１４…ＸＭＬ−ＤＯＭパーサ １１５…ＸＰｏｉｎｔｅｒプロセッサ １１６…解釈バッファイニシャライザ １２１…コンテクストマネージャ １２２…ｔａｒｇｅｔｓコマンドマネージャ １２３…ｃｏｎｖｅｒｔコマンドマネージャ １２４…ＸＳＬＴプロセッサ １３１…解釈用ＸＭＬ−ＤＯＭツリー １３２…プログラムカウンタ １３３…ロードフラグ １３４…ソースＸＭＬ−ＤＯＭツリー １４１…解釈用ＸＭＬ−ＤＯＭツリー １４２…プログラムカウンタ １４３…ロードフラグ １４４…ソースＸＭＬ−ＤＯＭツリー １５１〜１５３…ＤＯＭパーサ

Claims (8)

【特許請求の範囲】
1. 【請求項１】 インターネットにおけるＷＷＷ（Ｗｏｒ
   ｌｄ Ｗｉｄｅ ｗｅｂ）上のマークアップ言語で記述
   された複数の第１の文書の内容の一部をＷＷＷ上のマー
   クアップ言語で記述された第２の文書に合成するための
   文書合成方法であって、 少なくとも、前記第１の文書の該インターネット上の所
   在と、該第１の文書から抽出する部分文書の範囲と、前
   記第２の文書上の前記部分文書の挿入位置と、前記挿入
   位置に挿入される前記部分文書を含む前記第２の文書上
   の文書構造を変換すべき範囲と、前記文書構造を所望の
   文書構造に変換するための変換ルールを記述したファイ
   ルの識別情報とをマークアップ言語により記述した第２
   の文書に従って、 前記第１の文書から前記部分文書を抽出して、その部分
   文書を前記第２の文書上の前記指定された合成位置に挿
   入するとともに、前記変換ルールを用いて前記第２の文
   書上の前記指定された範囲の文書構造を変換すること
   で、前記第２の文書上に１または複数の前記部分文書を
   合成することを特徴とする文書合成方法。
2. 【請求項２】 前記第２の文書は、少なくとも、前記第
   ２の文書上の前記部分文書の挿入位置とを指定するとと
   もに、前記第１の文書の所在と、該第１の文書から抽出
   する部分文書の範囲とを記述するため第１のタグと、 前記変換ルールを用いて文書構造を変換すべき範囲を指
   定するとともに、前記変換ルールを記述したファイルの
   識別情報を記述するための第２のタグと、 を用いて記述されていることを特徴とする請求項１記載
   の文書合成方法。
3. 【請求項３】 前記第２の文書は、ＸＭＬ（Ｅｘｔｅｎ
   ｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述
   され、前記第１の文書がＸＭＬで記述されていないとき
   は、まず、ＸＭＬによる記述型式に変換した後、前記第
   １の文書から前記部分文書を抽出して、その部分文書を
   前記第２の文書上の前記指定された挿入位置に挿入する
   ことを特徴とする請求項１記載の文書合成方法。
4. 【請求項４】 インターネットにおけるＷＷＷ（Ｗｏｒ
   ｌｄ Ｗｉｄｅ ｗｅｂ）上のマークアップ言語で記述
   された複数の第１の文書の内容の一部をＷＷＷ上のマー
   クアップ言語で記述された第２の文書に合成する文書合
   成装置であって、 少なくとも、前記第１の文書の該インターネット上の所
   在と、該第１の文書から抽出する部分文書の範囲と、前
   記第２の文書上の前記部分文書の挿入位置と、前記挿入
   位置に挿入される前記部分文書を含む前記第２の文書上
   の文書構造を変換すべき範囲と、前記文書構造を所望の
   文書構造に変換するための変換ルールを記述したファイ
   ルの識別情報とをマークアップ言語により記述した第２
   の文書に従って、前記第１の文書から前記部分文書を抽
   出して、その部分文書を前記第２の文書上の前記指定さ
   れた挿入位置に挿入する挿入手段と、 前記第２の文書に従って、該第２の文書上の前記指定さ
   れた範囲の文書構造を、前記変換ルールを用いて所望の
   文書構造に変換する変換手段と、 を具備し、 前記第２の文書上に１または複数の前記部分文書を合成
   することを特徴とする文書合成装置。
5. 【請求項５】 前記第２の文書は、少なくとも、前記第
   ２の文書上の前記部分文書の挿入位置とを指定するとと
   もに、前記第１の文書の所在と、該第１の文書から抽出
   する部分文書の範囲とを記述するため第１のタグと、 前記変換ルールを用いて文書構造を変換すべき範囲を指
   定するとともに、前記変換ルールを記述したファイルの
   識別情報を記述するための第２のタグと、 を用いて記述されていることを特徴とする請求項４記載
   の文書合成装置。
6. 【請求項６】 前記第２の文書は、ＸＭＬ（Ｅｘｔｅｎ
   ｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述
   されていることを特徴とする請求項４記載の文書合成装
   置。
7. 【請求項７】 前記第１の文書がＸＭＬで記述されてい
   ないとき、該第１の文書をＸＭＬによる記述型式に変換
   する第２の変換手段をさらに具備し、 前記挿入手段は、ＸＭＬ文書の前記第１の文書から前記
   部分文書を抽出して、その部分文書を前記第２の文書上
   の前記指定された挿入位置に挿入することを特徴とする
   請求項４記載の文書合成装置。
8. 【請求項８】 インターネットにおけるＷＷＷ（Ｗｏｒ
   ｌｄ Ｗｉｄｅ ｗｅｂ）上のマークアップ言語で記述
   された複数の第１の文書の内容の一部をマークアップ言
   語で記述された第２の文書に合成するための処理をコン
   ピュータに実行させるためのプログラムであって、 少なくとも、前記第１の文書の該インターネット上の所
   在と、該第１の文書から抽出する部分文書の範囲と、前
   記第２の文書上の前記部分文書の挿入位置と、前記挿入
   位置に挿入される前記部分文書を含む前記第２の文書上
   の文書構造を変換すべき範囲と、前記文書構造を所望の
   文書構造に変換するための変換ルールを記述したファイ
   ルの識別情報とをマークアップ言語により記述した第２
   の文書に従って、前記第１の文書から前記部分文書を抽
   出して、その部分文書を前記第２の文書上の前記指定さ
   れた挿入位置に挿入するための処理と、 前記第２の文書に基づき、該第２の文書上の前記指定さ
   れた範囲の文書構造を、前記変換ルールを用いて所望の
   文書構造に変換するための処理と、 をコンピュータに実行させるためのプログラム。