JP2000357083A - 文書処理方法及び装置並びに記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 文書と、それに関連付けられた処理とが構造
によって結合される、改良された文書処理方法及び装置
を提供する。 【解決手段】 クライアント４０２とサーバの間に置か
れたエージェンシー４００が、クライアント４０２とサ
ーバの間でやり取りされる文書を処理するエージェント
４０１を操作する。エージェント４０１はアクティブ文
書の集合であり、アクティブ文書はテキスト及び／又は
振る舞いを含む構造化文書である。アクティブ文書は、
ネットワーク上で、文字列、ストリーム及びパース木の
文脈に応じて動作し、プログラムを埋め込み可能であ
り、また、構造化文書であるので、そのプログラムは文
書と同じ構文を持つ。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は文書処理の分野に関
する。より詳細には、本発明の一態様は、文書、テキス
ト及びプログラムを同一のかつ保守が容易なやり方で処
理するための改良した方法及び装置を提供する。

【０００２】

【従来の技術】本発明は文書処理の分野に関する。より
詳細には、本発明の一態様は、文書、テキスト及びプロ
グラムを同一のかつ保守が容易なやり方で処理するため
の改良した方法及び装置を提供する。

【０００３】多数の小さなコンピュータ・ネットワーク
及び個々のコンピュータを相互に接続するグローバルな
ネットワークであるインターネットの発展により、ソフ
トウェアの開発・配布計画の多くで、大勢の人々が相互
に接続されていることを利用する。例えば、Sun Micros
ystems社（米国カリフォルニア州マウンテン・ヴュー）
により開発されたＪａｖａ（登録商標）プログラム言語
で記述したプログラムを用いることにより、ソフトウェ
ア・プロバイダがプログラムのコピーをインターネット
に載せ、多くのインターネット・クライアントが、その
プログラムを、あたかもクライアント・マシン上に存在
しているかのように走らせることができる。

【０００４】ここで使用されるように、”インターネッ
ト・サーバ”とは、インターネットに接続され、与えら
れた要求に応答する、１台のコンピュータ又は１団のコ
ンピュータのことである。”インターネット・クライア
ント”とは、インターネットに接続され、インターネッ
ト・サーバへ要求を送る、１台のコンピュータ又は１団
のコンピュータのことである。１台のコンピュータ又は
１団のコンピュータが、ある要求セットに対してはクラ
イアントとして働き、別の要求セットに対してはサーバ
として働く場合もある。

【０００５】要求と、それに対する応答の処理に一般的
に使用されるプロトコルは、要求の性質に応じていくつ
か存在する。例えば、ＦＴＰ（File Transfer Protoco
l）は、クライアントがサーバにファイルを要求するた
めに用いるプロトコルである。ＨＴＴＰ（HyperText Tr
ansport Protocol）は、クライアントがハイパーテキス
ト文書を要求するため、また、サーバが要求された文書
を返したり起動したオブジェクトを転送するために用い
るプロトコルである。ＨＴＴＰブラウザを使用して見え
る、他のハイパーテキスト文書とリンクされたハイパー
テキスト文書は、”World Wide Web”又は”Web”と総
称されてきた。これらのプロトコルは、通常、TCP/IP
（Transport Control Protocol/Internet Protocol）と
して知られている、より低レベルのプロトコルの上位で
動作する。これらのプロトコルはそれぞれ既存の文献に
詳しく記述されているので、これ以上説明しない。

【０００６】ＨＴＴＰプロトコルは、静的な従前のハイ
パーテキスト文書の転送のためのプロトコルから発展し
たプロトコルであり、このプロトコルによって、サーバ
は、クライアントからの要求の性質及びパラメータ、サ
ーバ自体が管理している、そのクライアントに対するセ
ッション”状態”、その他種々の要因に基づいて迅速に
ハイパーテキスト文書を生成することができる。例え
ば、あるサーバに格納されている静的な従前のハイパー
テキスト・ページに対して要求を出す代わりに、ＣＧＩ
（Common Gateway Interface）スクリプトのようなスク
リプトに対して要求を出すことができるであろう。その
ようなスクリプトがあるならば、クライアントがサーバ
に対し要求を送り、その要求が静的文書とスクリプトの
どちらも指定可能であっても、サーバはあるスクリプト
に対する要求と判断し、応答するために、そのスクリプ
トを実行し、同スクリプトの出力を要求に対する結果と
して返送する。

【０００７】図１は、そのようなスクリプト・ステムの
動作の仕組みを説明するものである。図１にブラウザ１
２とサーバ１４が示されているが、このサーバ１４上で
サーバ・スーパバイザ２０が実行される。サーバ・スー
パバイザ２０は、ブラウザ１２（この例ではクライアン
ト）との入出力を処理し、１つ以上のフォーム２２、ス
クリプト２４などのＣＧＩスクリプトをアクセスし、ス
クリプト２４の出力２６をブラウザに送信するために蓄
積する。なお、図示しないが、ブラウザ１２とサーバ１
４の間にネットワーク又はインターネットが介在しても
よい。

【０００８】図１中のフォーム２２とスクリプト２４の
例を図２と図３にそれぞれ示す。動作を説明すると、ブ
ラウザ１２はサーバ１４に対し参照を要求し、この参照
はサーバ１４によってフォーム２２に対する要求である
と解釈される。図２に見られるように、フォーム２２は
ブラウザ１２のユーザに名前と電話番号を要求するため
のフォームである。フォーム２２はブラウザ１２へ送ら
れ、ブラウザ１２はユーザに対し記入すべき適切なフォ
ームを提示する。ブラウザ１２は、フォーム２２を、そ
れに含まれている命令に従って表示する。本例では、こ
れら命令はＨＴＭＬ（HyperText Markup Language；Sta
ndard Generalized Markup Language"SGML"のサブセッ
ト）のタグ付けテキストの形式である。

【０００９】サーバ１４は、記入済みフォームを与えら
れると、その記入済みフォームをスクリプト２４に渡
す。この例では、スクリプト２４は"phone.cgi"と呼ば
れ、フォーム２２中で参照される。スクリプト２４は、
図３から理解されるように、ＰＥＲＬとして知られてい
るスクリプト言語で記述されている。入力されたあるフ
ォームに対するスクリプト２４の出力２６は、ＰＥＲＬ
であるという認識のもとで決定できるものであって、"T
hank you. Your entry was:"の後に入力された名前と電
話番号が続く。このスクリプトはまた、入力データを"p
honebook.txt"と呼ばれるファイルに追加する。

【００１０】

【発明が解決しようとする課題】このような方法の１つ
の問題点は、フォームの作成とスクリプトの作成を調整
するために、２つの異スキルの組合せが、そして多くの
場合、２つの別の製品開発者の組合せが必要となること
である。フォーム開発者は、ＨＴＭＬに精通したテクニ
カル・ライターかもしれないが、フォーム中の変数の名
前及びフィールドがスクリプト中の変数名及び入力と一
致するように、ＰＥＲＬコードを書くプログラマと調整
する必要がある。ＪａｖａやＣなどの他言語について
も、調整が必要である。

【００１１】このように、文書と、それに関連付けられ
た振る舞い（プログラム）を統合する、改良した方法及
び装置が必要とされていることが分かる。本発明は、そ
のような改良した方法及び装置を提供しようとするもの
である。

【００１２】

【課題を解決するための手段】本発明によれば、文書と
それに関連付けられる処理とが、文書それ自体及びそれ
に施される処理の両方に適用可能な共通の構造に従って
文書を構造化することにより結合される。

【００１３】本発明の一実施態様であるクライアント・
サーバ文書処理システムでは、クライアントとサーバの
間にエージェンシーが介在し、このエージェンシーがク
ライアントとサーバ間でやり取りされる文書を処理する
１つ以上のエージェントを操作する。各エージェントは
アクティブ文書の集合であり、アクティブ文書はテキス
ト及び／又は振る舞いを含む構造化文書である。エージ
ェントは、アクティブ文書によって指定された振る舞い
を持つソフトウェア・オブジェクトとみなすこともでき
る。

【００１４】アクティブ文書は、ネットワーク上で、文
字列、ストリーム及びパース木の文脈に応じて動作し、
プログラムの埋め込みが可能であり、また、構造化文書
であるので、そのプログラムは文書と同じ構文を有す
る。さらに、文書は構造化されるので、その要素をデー
タ構造として利用できる。

【００１５】本文書処理システムの応用分野として、標
準プロトコルと、クライアント、サーバ及びプロキシの
機能を結合するソフトウェア・エージェンシーとを利用
するウェブ上のネットワーク・オフィス機器がある。

【００１６】アクティブ文書とエージェンシー・システ
ムの１つの利点は、高水準の機能をアクティブ文書とし
て実装できるため、クライアント用ソフトウェアとサー
バ用ソフトウェアが低水準の機能するだけでよいことで
ある。アクティブ文書言語により開発を行う場合、文書
の内容（データ）と処理（振る舞い)を特定するために
１つの統一された言語が使用されるので、文書向けコン
ピュータ処理を容易に実装することができる。

【００１７】このようなアクティブ文書ベースの文書処
理システムのもう１つの利点は、エージェント自体をア
クティブ文書として記述できることである。

【００１８】本発明の本質及び利点は、実施の形態に関
連した説明によって、より完全に理解できるであろう
が、その理解を容易にするため以下に本発明に包含され
る方法などを列挙する。

【００１９】（１） 入力構造化文書を処理して処理結
果である出力文書を生成する方法であって： a) パーサ・カーソルを前記入力構造化文書の最初の要
素を指すように初期化することを含む、入力パーサを初
期化するステップ； b) 前記入力パーサからカレント要素を受け取るため要
素プロセッサの要素入力を前記入力パーサと結合し、か
つ、前記要素プロセッサの要素出力を出力ジェネレータ
に結合する、前記要素プロセッサの初期化のステップ; c) 前記要素プロセッサに結合された定義テーブルを初
期化するステップ； d) 前記入力パーサから要素系列を受け取って、各要素
を次の1)から6)のステップによって処理するステップ： 1) 前記要素プロセッサの要素入力から要素を入力する
ステップ； 2) 前記要素がアクティブ要素であるかパッシブ要素で
あるか判定するステップ； 3) 前記要素がパッシブ要素の場合に、前記定義テーブ
ルから得られる適用可能な定義を用いて、前記パッシブ
要素を評価し、その結果を前記要素出力へ渡すステッ
プ； 4) 前記要素がアクティブ要素の場合に、次の1)と2)の
ステップを実行するステップ： i) 前記要素出力をアクティブ要素キューの入力に結合
するステップ；及び ii)前記定義テーブルから得られる適用可能な定義を用
いて、前記アクティブ要素を評価し、その結果を前記要
素出力へ渡すステップ； 5) 前記アクティブ要素キューが空でない場合に、前記
要素入力を前記アクティブ要素キューの出力に結合する
ステップ；及び 6) 前記アクティブ要素キューが空であり、かつ、前記
要素入力が前記入力パーサに結合されていない場合に、
前記要素入力を前記入力パーサに結合するステップ；及
び e) 前記出力ジェネレータを利用して前記出力文書を生
成するステップ、からなることを特徴とする文書処理方
法。

【００２０】（２） 前記（１）の文書処理方法におい
て、出力文書は処理された各要素がヌル文字列と評価さ
れる時にはヌル文書であることを特徴とする文書処理方
法。

【００２１】（３） 前記（１）の文書処理方法におい
て、入力構造化文書、出力文書及び定義テーブルはそれ
ぞれ共通の構造化文書フォーマットで表現されることを
特徴とする文書処理方法。

【００２２】（４） 前記（３）の文書処理方法におい
て、共通の構造化文書フォーマットはＳＧＭＬであるこ
とを特徴とする文書処理方法。

【００２３】（５） 前記１の文書処理方法において、
要素がアクティブ要素であるかパッシブ要素であるか判
定するステップは： a) 要素識別子をアクティブ・タグ・テーブルと比較す
るステップ； b) 一致するアクティブ・タグが前記アクティブ・タグ
・テーブル内に見つかったときに、前記要素をアクティ
ブ要素と認定するステップ；及び c) 一致するアクティブタグが前記アクティブ・タグ・
テーブル内に見つからないないときに、前記要素をパッ
シブ要素と認定するステップ、からなることを特徴とす
る文書処理方法。

【００２４】（６） 前記（５）の文書処理方法におい
て、比較のステップは、要素識別子を定義テーブル内に
見つかるアクティブ・タグと比較するステップであるこ
とを特徴とする文書処理方法。

【００２５】（７） パッシブ要素を評価するステップ
は： a) 前記パッシブ要素内のトークンを、定義テーブルよ
り得られる適用可能な定義で置き換えるステップ；及び b) 前記パッシブ要素内にプリミティブ表現があるな
ば、そのプリミティブ表現を評価するステップ、からな
ることを特徴とする文書処理方法。

【００２６】（８） パッシブ要素を評価するステップ
は： a) 前記要素をパッシブ・アクター基準の集合と照合す
るステップ；及び b) 前記要素があるパッシブ・アクターの基準と一致し
たときに、一致した各パッシブ・アクターのためのパッ
シブ・アクター・メソッドを呼び出すステップ、からな
ることを特徴とする文書処理方法。

【００２７】（９） 前記（１）の文書処理方法におい
て、アクティブ要素を処理するステップは： a) 少なくとも前記アクティブ要素内のパッシブ・トー
クンを、前記定義テーブルから得られる適用可能な定義
で置き換えるステップ； b) 前記アクティプ要素内にプリミティブ表現があるな
らば、そのプリミティブ表現を評価するステップ；及び c) 前記アクティブ要素をパラメータとしてアクティブ
・アクター・アクション・メソッドを呼び出すステッ
プ、からなることを特徴する文書処理方法。

【００２８】（10） アクティブ文書インタプリタによ
って入力構造化文書を処理して出力文書を生成する方法
であって： a) 前記入力文書を解析して、開始タグ、終了タグ及び
エンティティ参照を含む要素の系列からなるパース・シ
ーケンスを得るステップ； b) 前記パース・シーケンス内で遭遇する各要素につい
て、次の1)から6)のステップを実行するステップ： 1) 前記要素がパッシブ要素であるかアクティブ要素で
あるか判定するステップ、ここでアクティブ要素は前記
アクティブ文書インタプリタによって管理されているハ
ンドラ・データベース内に関連付けられたハンドラがあ
る要素である； 2) 前記要素の子要素が前記パース・シーケンス内にあ
るか判定するステップ； 3) 前記要素がパッシブ要素であって子要素を持たない
ときに、前記パッシブ要素を出力プロセスへ渡すステッ
プ； 4) 前記要素がパッシブ要素であって子要素を持つとき
に、その子要素をステップb)によって処理し、その処理
を必要に応じて繰り返すステップ； 5) 前記要素がアクティブ要素であって子要素を持つと
きに、その子要素を次のi)とii)のステップによって処
理するステップ： i) 前記子要素をステップb)により処理し、その処理を
必要に応じて繰り返すステップ；及び ii) ステップa)5)iで出力された要素を、記憶キューへ
送るステップ；及び 6) 前記記憶キューが空でなければ、前記記憶キューが
空になるまで、解析された入力文書の代わりに、前記記
憶キューを前記パース・シーケンスのソースとして利用
するステップ；及び c) 前記出力プロセスで、前記出力プロセスへ出力され
た各要素を定義された出力規則集合に従って処理するス
テップ、からなる文書処理方法。

【００２９】（11） 前記（10）の文書処理方法におい
て、パッシブ要素を前記出力プロセスへ与えるステップ
はさらに： a) 前記パッシブ要素のためのエンティティ参照がエン
ティティ定義集合中に定義されているか判定するステッ
プ；及び b) 前記エンティティ参照が前記エンティティ定義集合
中に定義されているときに、その定義されたエンティテ
ィ参照の対応エンティティ値を出力するステップ、を含
むことを特徴とする文書処理方法。

【００３０】（12） 前記（10）の文書処理方法におい
て、入力構造化文書の全体を参照することなく、前記入
力構造化文書を少なくとも部分的に処理することができ
るように、ステップa),b)及びc)はほぼ同時に実行され
ることを特徴とする文書処理方法。

【００３１】（13） 前記（10）の文書処理方法におい
て、ステップa),b)及びc)は逐次的に実行されることを
特徴とする文書処理方法。

【００３２】（14） 前記（10）の文書処理方法におい
て、ステップa),b)及びc)の処理操作は前記入力構造化
文書と同じ構文で表現されることを特徴とする文書処理
方法。

【００３３】（15） 前記（10）の文書処理方法におい
て、ハンドラ・データベースは入力構造化文書と同じ構
文で表現されることを特徴とする文書処理方法。

【００３４】（16） パース木によって表現された入力
構造化文書を処理し、出力文書を生成する文書処理装置
（アクティブ文書インタプリタ）であって： a) 要求された時に前記パース木をトラバースしてカレ
ント要素を出力する入力文書木トラバーサ、ここで前記
カレント要素は前記パース木内のカーソルで指示される
要素である； b) 前記入力文書木トラバーサにより出力される要素を
処理するための、前記入力文書木トラバーサと結合され
た要素プロセッサ； c) 前記要素プロセッサにより出力される要素で出力文
書木を構築するための、前記要素プロセッサと結合され
た出力文書木コンストラクタ； d) 入力要素がアクティブ要素であるかパッシブ要素で
あるか判定するための、前記要素プロセッサ内部の第１
の要素エバリュエータ； e) パッシブ要素を前記要素プロセッサの出力ステージ
へ送り、アクティブ要素を要素キューへ送るための、前
記要素プロセッサ内部の第１のルータ； f) 前記入力要素のための対応エンティティ置換値を定
義テーブルより見つけだすための、前記要素プロセッサ
内部の第２の要素エバリュエータ；及び g) 前記要素キューが空でない時に前記要素キューから
前記第２の要素エバリュエータ及び前記要素プロセッサ
の出力へ要素を送り、前記要素プロセッサが空の時に前
記入力から前記要素プロセッサへ要素を送るための、前
記要素プロセッサ内部の第２のルータ、からなることを
特徴とする文書処理装置。

【００３５】（17） 入力文書を処理して出力文書を得
る方法であって： a) 前記入力文書を解析して、要素開始タグ、要素終了
タグ、エンティティ参照及び文字列からなるシーケンス
を得るステップ； b) 前記入力文書を 1) 定義された各エンティティ参照を、実行された時に
定義された置換値を出力する命令シーケンスで置き換
え； 2) アクティブ要素と認識された各要素を、実行された
時に、当該要素の属性及び内容に対応した命令の出力を
入力として取り込み、それを当該アクティブ要素の定義
から本方法によって導き出された命令シーケンスへ渡す
命令シーケンスで置き換え、 3) プリミティブ操作を表していると認識された各要素
を、実行された時に、当該要素の属性及び内容に対応し
た命令の出力を入力として取り込み、それらに対し指示
されたプリミティブ操作を実行する命令シーケンスで置
き換え、かつ、 d) 認識されなかった各々の要素開始タグ、要素終了タ
グ、エンティティ参照及び文字列を、それを出力する命
令シーケンスで置き換える、ことによって、命令シーケ
ンスに変換するステップ：及び c) 得られた命令シーケンスを実行して出力文書を作成
するステップ、からなることを特徴とする文書処理方
法。

【００３６】（18） 前記（１）乃至（15）のいずれか
又は前記（17）の文書処理方法のための処理をコンピュ
ータに実行させるためのプログラムが記録されたことを
特徴とするコンピュータ読み取り可能な記憶媒体。

【００３７】（19） 前記（16）の文書処理装置の機能
をコンピュータに実現させるためのプログラムが記録さ
れたことを特徴とするコンピュータ読み取り可能な記憶
媒体。

【００３８】

【発明の実施の形態】以下、添付図面を参照して、本発
明の好適な実施例といくつかの変形例について説明す
る。当業者には、以下に説明する実施例の詳細事項の多
くを本発明の範囲から逸脱することなく変更可能である
ことは明らかであろう。

【００３９】文書向けコンピュータ処理システムは、文
書を相互にやり取りするエージェンシーのネットワーク
のように見える。その一例は、１９９６年９月２４日付
出願の米国特許出願第08/718,858号（以下"Savitzky"と
呼ぶ）に説明されているパーソナル・インフォメーショ
ン・エージェンシー（ＰＩＡ）である。

【００４０】このようなシステムでは、入力デバイス、
出力デバイス及び記憶デバイスは、すべて複合文書にす
ぎないので取り扱いが簡単になる。入力デバイスは文書
のソースであるので、入力デバイスに文書を要求するエ
ージェントの立場で見ると、入力デバイスは、絶えず更
新される１つの文書、拡大し続ける文書の集合、あるい
は、１つ以上のデスティネーションへ文書を絶えず送り
続けるクライアントであるかのように見えるかもしれな
い。出力デバイスは文書のシンクであり、更新可能な文
書、例えば拡大する文書の集合、あるいは、１つ以上の
ソースに絶えず文書を要求するクライアントのように見
えるかもしれない。記憶デバイスは入力デバイスと出力
デバイスの両方の側面を持ち、文書を記憶デバイスへ送
り、その後に取り出すことができる。

【００４１】Savitzkyに開示されたＰＩＡ装置は以下に
説明するように文書処理の実装のために使用できるが、
SavitzkyのＰＩＡ装置に代えて他の装置を使用し得るこ
とを理解すべきである。さらに、Savitzkyに開示された
ＰＩＡに含まれるコンポーネント又は機能の全部は持た
ない文書処理エージェンシーでも、後述の文書処理も利
用できる。

【００４２】図４は、アクティブ文書を処理するパーソ
ナル・インフォメーション・エージェンシー（ＰＩＡ）
のブロック図である。図示のように、ＰＩＡ４００は、
クライアント４０２とサーバ（不図示）又はネットワー
ク上の他のノード（不図示）との間でやり取りされるア
クティブ文書を処理する、いくつかのエージェントを含
んでいる。ここで用いられるクライアント４０２は例え
ばブラウザなどで、クライアント４０２から渡されるア
クティブ文書は、通常、文書の要求又は入力された結果
の形をとる。

【００４３】さて図４を参照すると、図２及び図３にそ
れぞれ示したフォーム２２及びスクリプト２４に代え
て、アクティブ文書４０４を使用する方法が示されてい
る。アクティブ文書４０４の内容を図６に示す。

【００４４】このアクティブ文書４０４は、エージェン
ト４０１によって、受け取った時にその情報を処理する
ために使用されるだけでなく、ブラウザ４０２でユーザ
入力用フォームを表示するためにも利用される文書であ
る。図７と図８に、２つのブラウザ表示６０２，６０４
を示す。ブラウザ表示６０２はユーザ入力のために現れ
るであろうフォームであり、ブラウザ表示６０４はフォ
ーム６０２を与えた結果としてブラウザ画面に現れるで
あろうアクティブ文書処理結果である。両表示は、同一
のアクティブ文書４０４によって生成されるものであ
る。

【００４５】アクティブ文書によれば、振る舞いを文書
中に埋め込むことができるため、得られる単一コンポー
ネント文書は管理が容易であり、フォームはそれ自体で
解釈できる形とすることができ、表と他のデータは、そ
の保守のために必要とされるコードと同じ文書中にまと
められているので自己保守形式とすることができる。こ
れを次の段階に進めることにより、システム全体（例え
ばエージェント全体）を、ほかに何も必要としない、ア
クティブ文書の集合として実装可能である。

【００４６】好適な実施例では、アクティブ文書は、Ｓ
ＧＭＬの構文規約に従った、追加タグを含み得るＨＴＭ
Ｌ文書である。こうすることにより、普通のテキスト・
エディタで文書を編集可能となる。このような”文書の
コンピュータ処理”の手法では、データとメソッドはＨ
ＴＭＬ文書の部品にすぎない。例えば、ＨＴＭＬのリス
ト（＜ｕｌ＞タグと＜ｏｌ＞タグで示される）は、プロ
グラムによってリスト又は配列として用いられる。定義
リスト（＜ｄl＞タグ）は、（＜ｄｔ＞タグ付きテキス
ト）という用語が（＜ｄｄ＞タグ付きテキスト）という
データに相当するという点で、結合配列を兼ねる。同様
に、表（＜table＞タグ）はデータベース表として使用
できる。このようにしているのは、既存のテキスト構造
をプログラム・データとして利用することを考慮したか
らである。

【００４７】一般に、アクティブ文書中の全てのデータ
はＳＧＭＬの”要素”の形式であって、要素は、（１）
１つの文字列、（２）開始タグ、（３）終了タグ又は
（４）エンティティ参照である。ここに示した例では、
開始タグは、”＜”文字と、識別子（”タグ”）と、可
変数の”属性＝値”の対と、”＞”文字とからなる。終
了タグは、”＜”文字と、タグと、”＞”文字とからな
る。エンティティは、”＆”文字と、識別子と、”；”
文字とからなる。開始タグと対応した終了タグ、それら
に囲まれた内容とからなる構造は、”要素”と呼ばれ
る。タグとテキストは”トークン”と総称される。普通
文字の文字列はテキストと呼ばれるが、タグとエンティ
ティはマークアップと呼ばれる。操作の中には、テキス
トだけに作用するもの、あるいはマークアップだけに作
用するものがある。エンティティは、著作権記号を表す
ＨＴＭＬの”＆ｃｏｐｙ；”のような、特殊な記法であ
り、変数又はマクロとして使用できる。そのようなもの
であるから、エンティティは定義可能であり、再定義可
能であり、また展開可能である（すなわち、エンティテ
ィは、その現在の定義によって置き換えることができ
る）。エンティティは、”反復変数”としても使用でき
る。反復変数を使用する一例は、リストの各項目をテキ
スト・ブロックに埋め込みたい場合である。

【００４８】好適な実施例では、文書中のトークンのど
のサブセットも、アクティブにしたい”アクター”と呼
ばれるソフトウェア・オブジェクトに関連付けることが
できる。各アクターは、ＳＧＭＬの内容、プリミティブ
・ハンドル（サブルーチン）の参照のどちらかを含む。
内容によって置換される要素が文書中に現れた時に、ア
クターが展開され、すなわちハンドル・サブルーチンが
呼び出され、エンティティがその要素の属性及び内容と
結合される。アクターは、”タグセット”と呼ばれるグ
ループにまとめることができる。

【００４９】アクターは２通りの方法でトークンと関連
付けられる。”アクティブ”アクターは、それを対応要
素のタグ識別子と関連づけするハッシュ・テーブルのエ
ントリーを有する。どのアクティブ・アクターも要素と
合致しない場合には、トークンの特徴（通常は属性）を
検査する一致基準のリストに関し”パッシブ”アクター
集合の各アクターが順に調べられる。例えば、”if”ア
クターはアクティブで開始タグ＜if＞と一致する。”_f
oreach”アクターはパッシブで、”foreach”属性を含
む開始タグのどれとも一致する。もう１つの可能なアク
ターは”_eval_perl_”アクターであり、これもパッシ
ブで、”perl”の値を持つ”language”属性を含むどの
開始タグとも一致する。

【００５０】ＰＩＡはアクティブ文書で使用するための
標準タグセットを定義しているが、一部のエージェント
は、この標準タグセットとともにロードするための特殊
なタグセットを定義し得る。ＨＴＭＬの構文解析（パー
シング）、フォーマッティング、さらには他の文書型の
ＳＧＭＬ文書のＨＴＭＬへの翻訳といった異種の文書処
理のために、全く異なったタグセットも定義できる。

【００５１】上述の概念は、プログラム言語の解釈及び
文書のフォーマッティングの両方と密接に関連してい
る。アクティブ文書は２つの性格を持つため、テクニカ
ル・ライターはアクターをマクロに関連付け、エンティ
ティを略語及びフォーマッティング又は活字組処理とし
ての文書評価処理と関連付け、他方、プログラマはそう
ではなく、アクターを機能に関連付け、エンティティを
変数に関連付けるかもしれない。

【００５２】図９は、アクティブ文書を解釈するために
利用可能な一般化した処理のフローチャートである。ア
クティブ文書を解釈するオブジェクトは、アクティブ文
書インタプリタ（ＡＤＩ）と呼ばれる。ＡＤＩは、ほと
んどのエージェントのためのアクション及びハンドル・
メソッドを実装している。ＡＤＩは、入力文書を処理し
て出力文書を作成し、また、場合によっては、ファイル
の読み書きといった、出力文書生成以外の付随的な動作
を行わせる。

【００５３】ＡＤＩは、入力スタック、パース・スタッ
ク、出力キュー、それと、カレント・トークンＴ、”ス
トリーミング／パーシング”フラグ、”処理／引用”フ
ラグ、カレント・タグセット及び”ハンドラ”アクター
のリストのための値を保持する状態メモリから構成され
る。入力スタック上の各項目は、トークンか、トークン
・シーケンス中の次トークンを返すオブジェクトであ
る。トークンが要求されるとに、ＡＤＩは入力スタック
のトップの項目を調べる。そのスタックに使用できるト
ークンがあれば次のトークンが要求されるが、使用でき
るトークンがなければ、スタックはポップされ、次項目
が調べられる。

【００５４】入力スタックは、通常、”スキャナ”オブ
ジェクトという１つのトークンを保持するように初期化
される。スキャナ・オブジェクトは、入力されたファィ
ル又は文字ストリームをトークンに分割する。入力スタ
ックもまた、要素のソフトウェア表現をトラバースして
（すなわち、辿って）、その要素の開始タグ、内容及び
終了タグを返すオブジェクトを保持するように初期化さ
れるであろう。

【００５５】ＡＤＩは、入力スタックから１度に１つの
トークンを読み込む。トークンは、開始タグであること
も、終了タグであることも、あるいは、文字列、空タ
グ、エンティティ参照、パース木のような完全なトーク
ンであることもある。最初、処理はストリーミング状態
であり、トークンは受け取られるとすぐに処理される。
これと別の処理状態は、パーシング状態である。読み込
まれたトークンが開始タグであるときには、そのトーク
ンは、パーシング／ストリーミング・フラグ及び引用フ
ラグとともにパース・スタックにプッシュされる。読み
込まれたトークンがパース・スタックのトップにある開
始タグと一致する終了タグであるときには、パース・ス
タックのトップのものがポップされ、そして、状態が”
パーシング”ならばカレント・トークンが入れ替えられ
る。そのトークンがパース・スタックのトップにあるも
のと一致しない終了タグであるときには、そのトークン
は入力スタックにプッシュされ、その省かれた終了タグ
はあたかも省略されなかったかのように生成される。処
理はストリーミング状態に戻り、”ストリーミング”フ
ラグがポップされる。

【００５６】そして、カレント・トークンＴは次のよう
に処理される。そのトークンがエンティティ参照であ
り、かつ、その値がカレント・エンティティ・テーブル
に定義されているならば、そのトークンはその値（テキ
スト、要素又はトークン・リスト）で置き換えられる。
次に、カレント・トークンＴがトークン・リスト又は内
容を持つ要素であるならば、そのトークンは、その開始
タグ、内容及び終了タグを個別に処理できるようにする
ため入力スタックにプッシュされる。カレント・トーク
ンがそのようなものでなく、エンティティ参照でもトー
クン・リストでもなければ、カレント・トークンは開始
タグ、終了タグ、空タグ、テキストのいずれかである。
カレント・トークンが開始タグか空タグならば、その属
性中のどのエンティティも展開される（すなわち、それ
らの値で置き換えられる）。

【００５７】次に、そのトークンのタグ識別子が、アク
ティブ・タグのカレント・タグセット・テーブルにおい
て検索される。一致するアクターが見つかったときに
は、カレント・トークンとＡＤＩ自体をパラメータとし
て、そのアクターのact_on()メソッドが呼び出される。
一致するアクターが見つからない場合には、トークンＴ
と一致する基準を持つアクターがないかカレント・タグ
セットのパッシブ・アクター・リストが調べられ、ま
た、そのような各アクターのact_on()メソッドが呼び出
される。

【００５８】act_on()メソッドは、ＡＤＩのパーシング
／ストリーミング・フラグと処理／引用フラグを変更
し、あるいは、カレント・トークンＴを別のトークン又
はヌル値（トークンの削除）で置き換えるであろう。こ
のメソッドはまた、”ハンドラ”リストに１つ以上のア
クターをプッシュするであろう。act_on()メソッドの処
理後、ハンドラ・リストが空でなく、かつ、処理／引用
フラグが処理を指示しているときには、ハンドラ・リス
ト中の各アクターのハンドル・メソッドが呼び出され
る。この時点でもトークンＴがヌルでなければ、パーシ
ング／ストリーミング・フラグが調べられる。パーシン
グの状態ならば、パース・スタックのトップにあるトー
クン（要素）の内容にＴが追加される。ストリーミング
の状態ならば、Ｔは出力キューに追加される。

【００５９】以上の手順の重要な点は、パッシブ文書で
ある文書をアクティブ文書と同じ方法で処理できるが、
パッシブ文書は、単に処理されて出力され（パーシング
／ストリーミング・フラグがストリーミングに設定され
ているとき）、あるいは、解析されてパース木が生成さ
れ（パーシング／ストリーミング・フラグがパーシング
に設定されているとき）、一方、アクティブ文書はそれ
に含まれているメソッドを実行させるということであ
る。アクターを含むアクティブ文書の場合、処理はもっ
と複雑である。

【００６０】次に、アクティブ文書インタプリタの別の
実装について説明する。この実装においては、ＡＩＤに
対する入力はパース木のイテレータ（iterator）であ
る。ここで、パース木はノードの集合であり、入力文書
を表している。パース木の一例は、ＷＷＷコンソーシア
ムの文書オブジェクト・モデルに記述されている（例え
ば、＜http://www.w3.org/TR/PR-DOM-Level-1/＞を参
照）。

【００６１】イテレータは文書のパース木のルート・ノ
ードに初期設定され、ＡＤＩは、その入力イテレータを
カレント入力ノードの次の兄弟ノード又は最初の子ノー
ドへ進めることができる。カレント入力ノードは前記第
１実施例におけるカレント・トークンと全く同様に扱わ
れる。次の兄弟ノードが存在しないことで、”終了タ
グ”条件がわかる。

【００６２】ＡＩＤの出力はパース木コンストラクタで
ある。かかるコンストラクタに対する処理は、新たな子
ノードをカレント・ノードに追加すること、新たな子ノ
ードをカレント・ノードに追加して、その子ノードをカ
レント・ノードにすること、及びカレント・ノードの親
ノードを新たなカレント・ノードにすることである。Ａ
ＤＩは、その入力木を再帰的にトラバースすることによ
って動作する。通常の（非アクティブの）ノードは、出
力木にコピーされる。アクティブ・ノードは、新たなＡ
ＤＩをインスタンス化することによって展開される。こ
の新たなＡＤＩの出力は、その”文脈”と同じである
が、入力はそれらアクティブ・ノードの定義のイテレー
タである。元のアクティブ・ノードの属性及び内容は、
その展開結果の範囲内でアクセス可能なエンティティ名
と結合される。

【００６３】入力イテレータと出力コンストラクは前向
きにしか働かないため、木全体をＡＤＩに常駐させるこ
となく、そのようなトラバースをエミュレートするパー
サによってファイルを処理することが可能である。同様
に、出力コンストラクタは、実パース木を構築すること
なく、通過した各ノードの内部表現を出力することがで
きる。

【００６４】フィルタ処理のような特定の文書処理タス
クのために、他の特化した入力イテレータと出力コンス
トラクタを利用することができる。他の多くの等価な実
装、例えば、アクティブ文書のパース木中の各ノードを
所望の展開結果を出力するプログラム言語による等価な
命令シーケンスに変換するような実装が可能であること
は、当業者には明白であろう。このような実装では、最
初のパスでアクティブ文書がプログラムに変換され、次
のパスで、このプログラムが実行されて処理操作が遂行
される。

【００６５】ここで、以下で使用されるいくつかの用語
を理解するため、発明者等が開発したアクティブ文書処
理用のInterForm言語の詳細を説明する。

【００６６】入力するトークンを変換することを”パー
シング”と言う。パーシングの結果として、ＡＤＩは、
開始タグとその内容からなり完全な要素を形成する複合
オブジェクトを作成する。要素、属性又はエンティティ
を新たなデータで置換する処理は、その結果が常にでは
ないが多くの場合に元のものより大きいことから、”展
開”と呼ぶ。アクターに要素に対する処理を実行させる
ことを、要素に対するアクターの”適用”と言う。ま
た、エンティティ名又は属性名と値を関連付けること
を、名前の値への”結合”と言う。値は、１文字からマ
ークアップ付きの文書全体まで、何でもよい。入力トー
クンのストリームを処理すること（アクターのパーシン
グ、展開及び適用）を、ストリームの”評価”と言う。

【００６７】ここで説明する好適実施例において、Inte
rForm（登録商標）言語の構文はＳＧＭＬ標準構文から
派生したＨＴＭＬをベースにして出発しているため、In
terForm文書は、適切な文書型定義（ＤＴＤ）を有する
ＳＧＭＬパーサによって解析できる。ＨＴＭＬエディタ
が非標準的なエンティティと要素タグを考慮しているな
らば、そのＨＴＭＬエディタはInterForm文書を処理で
きるであろう。ＳＧＭＬバリデイタ（validator）を、
適切なＤＴＤとともに、InterForm文書の構文構造の検
証のために用いることができる。

【００６８】少し異なった２種類の名前（識別子）がIn
terFormシステムで用いられる。第１の種類の名前は要
素タグと属性のためのものであり、第２の種類の名前は
エンティティのためのものである。要素タグと属性の名
前は、大文字と小文字の区別がなく、１つの文字（lett
er）で始まり、文字（letter）、数字、”．”（ピリオ
ド）及び”-”（ハイフン）の任意の並びからなる。エ
ンティティの名前は、同様の文字セットを使うが、大文
字と小文字が区別される。名前がＵＲＬ（Uniform Reso
urce Locator）の参照であるかファイル名である場合、
その名前の文字セットと形式は、例えばＵＲＬ又はファ
イル名に適用可能な外部ルールセットによって決めら
れ、InterForm言語には拘束されない。

【００６９】”if”アクターや”set”アクターのよう
な一部のアクターは、タグと直接対応する。慣例とし
て、タグと直接対応しないアクターは、ダッシュ（”
-”）で始まり、かつ、好ましくはダッシュで終わる名
前を付けるべきである。ダッシュは、アクターの名前の
中で語の区切りのためにも用いられる。多くの場合、あ
る名前を持つエージェントが実行中であるか調べる”ag
ent-running”に見られるように、最初の語は作用を受
けるＰＩＡデータ構造の名前を表す。

【００７０】”get”アクターなどの多くのアクター
は、”＜get entity＞”や”＜getactor＞”といった、
振る舞いを修正する非常に多様な特殊な属性を許容す
る。タグと属性が”．”で区切られた”get.entity”の
ような名前を持つ、多くの特化されたアクターのバージ
ョンが存在する。この”.”を使用すると、ＡＤＩがと
るべきアクションを決定するための作業量が少なくて済
も、いくぶん効率が良い。要するに、この”get”アク
ターはデータ構造を指定できるということである。

【００７１】エンティティ参照は以下のように定義され
る： エンティティ : := ’&’ パス ’i’? パス : := 識別子 [’.’ パス] ? 識別子 := [文字 | 数字 | ’-’]+ すなわち、エンティティ参照は、アンパサンド（”
＆”）を含み、その後に名前が続き、さらにセミコロン
（”；”）が続く。このセミコロンは、名前の中では許
されない文字がエンティティ名の後に続いている場合に
は省略可能であるが、いずれにしてもセミコロンを含め
るのが好ましいやり方である。このことは、エンティテ
ィ名において重要である。エンティティ名は、ピリオド
で区切られたいくつかのサブネームからなる。これらの
サブネームは、”名前空間”のシーケンス（エージェン
ト、＜table＞要素又は＜dl＞要素、フォームなど）へ
のパス（ファイルのパスに類似したもの）を構成する。
名前空間がまったく与えられない場合には、ＡＤＩは、
ローカル定義エンティティ（例えば、＜repeat＞タグで
定義されたリスト要素エレメント・エンティティ）と、
解釈対象のアクティブ文書に関連付けられた最上位（グ
ローバル）エンティティ・テーブルを探索する。ある名
前空間でパスが終わった場合、その名前空間が、文脈に
よって記述リスト又は照会文字列として返される。

【００７２】デフォルトでは、ローカル定義エンティテ
ィとして、図１３に示すエンティティのほか、現在日、
日付、時刻や、カレント・エージェント、カレントＰＩ
Ａ及びカレント・ユーザを識別するための変数がある。
図１４に示したような、いくつかの名前空間が予め定義
されている。

【００７３】開始タグだけの要素は”空”要素と呼ばれ
る。したがって、空要素は、そのタグによって識別でき
る。一般的に、属性と識別子とは、空白を介在させず”
＝”で区切られる。

【００７４】高度な実装では、”entity-style hierarc
hical lookup on actor”タグが用意される。このタグ
は、＜dl＞リストをオブジェクトとして機能させること
ができる。開始タグ中の属性の順番は、処理のあいだ保
持されるけれども、予め定義されたアクターや標準ＨＴ
ＭＬタグのどれにとっても重要な意味はない。

【００７５】以下に述べる＜repeat＞アクターなど、い
くつかのアクターはリストを処理する。リストは項目の
並びであり、通常、＜li＞要素で表現される。リスト
は、普通のプログラム言語の配列やデータベース言語の
集合に非常に似た働きをする。次の要素は単純リストと
して取り扱われる： ＜ul＞,＜o1＞, ＜table＞, ＜tr＞ ＜table＞は、実はリストのリストである。また、記述
リスト（＜dl＞）は、２要素（＜dt＞，＜dd＞）リスト
のリスト、又は、名前と値が交互に並んだ単純、フラッ
トなリストとして扱うことができる。テキスト文字列、
特に属性は、＜split＞アクターを用いてホワイトスペ
ースで分割することによりリストとして扱うこともでき
る。要するに、どのようなトークン・シーケンスも、ホ
ワイトスペースかトークン境界で分割することによって
リストとして扱うことができる。

【００７６】アクティブ文書に関連付け情報を持たせる
こともできる。関連付けによって、＜dt＞要素と＜tabl
e＞要素はキー＝値で関連付けされたものとして扱われ
る。表のキーは通常、行の先頭項目にすぎないが、その
前の行に空白の先頭要素（通常、＜th＞タグ）を持つ行
が追加されている。ラベル付けされた列（通常、先頭の
＜th＞要素行で示される）を持つ表は、関連付けされた
リストに変換することができる。

【００７７】また、適当な形式の文字列はどれも関連付
け情報として用いることができる。対になったものは
（照会文字列におけるように）ホワイトスペース又は”
＆”文字によって区切られるが、名前と値は通常、”
＝”文字で区切られる。普通のリストは、項目を関連付
けして対にする＜associate＞アクターを用いることに
より、関連付け情報として用いることもできる。どのよ
うな要素も（属性及び値の）関連付け情報に変換するこ
とができ、その際、必要に応じそのタグと内容は特殊キ
ー（通常、”-tag-”及び”-content-”）と関連付けさ
れるが、これは属性と間違われることはない。これも＜
associate＞アクターを使用して行われる。

【００７８】各アクターは、その定義時に（結局は、そ
のアクターの本文の内部の要素を利用する時に）、図１
５に示すような属性として認定可能なオンライン文書文
字列を持ってもよい。アクターの文書をアクセスするた
めに用いられるアクターの例を図１６に示す。

【００７９】ここで、上に述べた概念の具体例について
図１０の（ａ）乃至（ｅ）を参照して説明する。図１０
の（ａ）は、文書中に現れた時に、あるアクターをイン
スタンス化するテキスト部分８０２である。このテキス
ト部分８０２は、開始タグ８０４と命令群８０６と終了
タグ８０８からなっている。

【００８０】開始タグ８０４は、あるアクター（本例で
は”demo”）をアクティブにするとともに、そのquoted
属性及びdscr属性を定義する。命令群８０６は要素８０
２の内容（図１０（ａ））を構成し、”demo”アクター
の定義を含む。この命令群は、”demo”アクターの”ha
ndle”メソッドによって実行（展開）される。図示のよ
うに、命令群８０６は、（＜protect-result markup＞
＜/protect-result＞タグによって）内容をマーク付け
を変更することなく出力し、それに続けてボールド体
の”＝”と内容の展開結果を出力するものである。

【００８１】図１０の（ｂ）は処理対象の入力文書８１
０を示す。ＡＤＩは、入力文書８１０の処理時に、開始
タグ＜demo＞に出会うと、同タグをそのパース・スタッ
クにプッシュすることは前述した通りである。＜demo＞
要素内の要素も終了タグ＜/demo＞に出会うまでパース
・スタックにプッシュされ、その後に、＜demo＞要素は
その”handle”メソッドの呼び出しによって展開され
る。

【００８２】＜demo＞要素の処理の場合、同要素の定義
の内容はそれ自体が＜repeat＞要素であるので、ＡＤＩ
はその入力スタックに同内容をプッシュし、また名前”
content”を＜demo＞要素の内容に結合することによっ
て、＜demo＞要素の定義内容を処理する。そして、そこ
から処理が継続する。＜demo＞要素の内容を処理する場
合、その内容が出力され、次に図１０の（ａ）に関連し
て説明したように同内容が評価される。その結果、図１
０の（ｃ）に示すような出力文書が得られる。同内容は
＜repeat＞要素であるので、同要素は、まず変更される
ことなく出力され、ついで展開される。＜repeat＞要素
はｌｉｓｔ属性”a b c”を持ち、＜repeat＞要素の内
容は”&li; &li”であるから、”&li; &li;”の展開結
果はリスト項目の後に空白が続き、さらにその後にリス
ト項目が続いたものであり、したがって、＜repeat＞要
素の展開結果は”a ab bc c”である。この展開の再帰
性に注意されたい。図１０の（ａ）から（ｃ）の文書は
いずれも同一フォーマットであることにも留意された
い。例えば、図１０の（ｃ）に示した出力文書は、その
ままＡＤＩに入力文書として渡すことも可能である。

【００８３】図１０の（ｄ）と（ｅ）は、demoアクター
のもう１つの使用例を説明するものである。図１０の
（ｄ）は、リスト項目の参照を内容とする＜ｏｌ＞（順
序リスト）要素を持った入力文書を表す。これら要素の
再帰的展開の場合、”＜li＞&li;”は、”＜li＞”の後
に＜ol＞要素の属性から選択された、”a b c”なる値
を持つリスト項目が続いたものに展開される。これらト
ークンは次に標準のＨＴＭＬマークアップとして処理さ
れ、図１０の（ｅ）に示す出力文書が作成され。図１０
の（ｅ）は、list属性の値から見つかったトークンの順
序リストを示している。

【００８４】さて、アクティブ文書プロセッサの別の実
施例もしくは考え方を図１１に示す。このアクティブ文
書プロセッサは入力文書９００を受け取り、それを入力
パーサ９０２に与えるが、この入力文書９００は好まし
くはアクティブ文書であるが解析可能などのような文書
でもよい。入力パーサ９０２は、入力文書９００のカレ
ント・ノード９０６（ａ）をノード・プロセッサ９０４
に与えるように接続されている。入力プロセッサ９０２
はまた、以下に述べる様々なコマンドをノード・プロセ
ッサ９０４より受け取るように接続されている。ノード
・プロセッサ９０４は、接続ジェネレータ９１２と接続
され、カレント・ノード９０６（ａ）又はその処理結果
であるノード９０６（ｂ）を、その処理のための命令群
９１０とともに与える。出力ジェネレータ９１２は、こ
れらノード９０６（ｂ）を受け取ると、入力文書９００
を処理することにより得られる出力文書の部分部分を出
力する。この出力は、文字列構造体へ（文字列変数、固
定長記憶要素など）、又は、フィルタへ（パイプ入力、
ストリーミング入力など）送られるであろう。

【００８５】ノード・プロセッサ９０４が入力パーサ９
０２に対し発行するコマンドとしては、次のものがあ
る。 move to next sibling node（兄弟ノードへの移動） move to first child node（最初の子ノードへの移動） move to parent node（親ノードへの移動） tell whether a next sibling exists（次の兄弟ノード
の有無判定） tell whether a child exists（子の有無判定） tell whether a parent exists（親の有無判定） get current node's type（カレント・ノードの型の取
得） get current node's tag（カレント・ノードのタグの取
得） get current node's atributes（カレント・ノードの属
性の取得）

【００８６】入力パーサ９０２は、”move”コマンドに
対しては、入力文書の木をトラバースして新たなカレン
ト・ノードを出力が、ノード・プロセッサ９０４は”te
ll”コマンド又は”get”コマンドに対しては、問い合
わせの回答を返す。このパーシング方法では、入力文書
は、その全体を解析する必要がないので、どのような大
きさであってよい。それどころか、木を作成する必要さ
えない。

【００８７】ここに説明したことから明らかなよう
に、”move to next sibling”コマンド、”move to fi
rst child”コマンド及び”move to parent”コマンド
を用いることによって、文書の一部しか利用できない場
合でも、文書木の全体をトラバースすることができる。
図１２は、構造化文書から木が構築される様子を説明す
るものである。図１２を見れば、”move right”、”mo
ve down”及び”move up”の３つのmoveコマンドを思い
つくであろう。これらコマンドが正しい順序で発行され
るならば、ノード・プロセッサは、渡されたノードを全
て受け取ることができる。たとえ、その入力が終わりの
ない（例えばストリーミング）入力文書であったとして
も同様である。これは、文書木の全体はノード・プロセ
ッサのローカル記憶に格納する必要がないからである。
図１２に示されるように、構造化文書９００は、その中
に出現する様々な要素をノードとするパース木に変換で
きる。この例では、パース木の葉は入力文書９００のテ
キスト要素である。

【００８８】再び図１１を参照する。命令群９１０には
次の命令を含めることができる。 output node（ノードを出力） start (open) a new node（新たなノードを開始させる
（開く）） end a currently open node（現在開かれているノード
を終了させる） これらの命令を使用すれば、入力文書と同じフォーマッ
トの出力文書を生成することができる。図１１に示すア
ーキテクチャは同一フォーマット（同一の条件と規約に
従う）の出力文書に対応できるので、ノード・プロセッ
サをネストさせ又は連鎖させることができることに留意
されたい。例えば、１つのパーサ−プロセッサ−ジェネ
レータの出力を、別のパーサ−プロセッサ−ジェネレー
タの入力としてもよいであろう。これは、単一のパーサ
−プロセッサ−ジェネレータで、中間処理後のアクティ
ブ文書のデータ構造を格納するような、中間的な非処理
ステップが必要な場合に好適かもしれない。入力文書が
プログラムを表す場合、そのプログラムは、出力がそれ
自体と同じフォーマットのプログラムであろう。

【００８９】以上に述べたことは、説明のためのもので
あって限定を意図したものではない。以上の説明から、
当業者には本発明の多くの変形が明白となろう。１例に
過ぎないが、ＡＤＩは、単純な文書処理タスクのための
スタンドアロン形式と、ＰＩＡ（personal information
agency）システムに埋め込まれた形式の両方をとる。
後者の形式では、ＡＤＩは、インターネットやその他の
ソースから検索された文書の解析及び修正、並びにユー
ザに直接提示するための文書の生成のために利用され
る。スタンドアロンのＡＤＩは、例えば、最新の文書と
それ自体のアクター及びタグセットの例を生成するため
に用いられるであろう。

【００９０】

【発明の効果】以上に詳細に説明したように、本発明に
よれば、その実現が望まれていた、文書と、それに関連
付けられた振る舞い（プログラム）を統合できる、改良
した方法及び装置を実現可能である。特に、アクティブ
文書とエージェンシー・システムの組合せにより、高水
準の機能をアクティブ文書として実装できるため、クラ
イアント用ソフトウェアとサーバ用ソフトウェアでは低
水準の機能に対応するだけでよく、また、アクティブ文
書言語により開発を行う場合、文書の内容（データ）と
処理（振る舞い)を特定するために１つの統一された言
語が使用されるので、文書向けコンピュータ処理を容易
に実装することができ、さらに、エージェント自体をア
クティブ文書として記述できる、等々の効果を得られ
る。

【図面の簡単な説明】

【図１】文書とプログラムに別々の構文を用いる文書シ
ステムのブロック図である。

【図２】図１中のフォーム２２の内容を示す図である。

【図３】図１中のＣＧＩスクリプトの内容を示す図であ
る。

【図４】パーソナル・インフォメーション・エージェン
シーのブロック図である。

【図５】パーソナル・インフォメーション・エージェン
シーの動作説明のための図である。

【図６】図５中のアクティブ文書の内容を示す図であ
る。

【図７】ユーザ入力のためのブラウザ表示の一例を示す
図である。

【図８】ユーザ入力後のブラウザ表示の一例を示す図で
ある。

【図９】一般化したアクティブ文書の解釈処理のフロー
チャートである。

【図１０】アクティブ文書インタプリタにより処理され
る入出力文書の説明図である。

【図１１】本発明による他の実施例のブロック図であ
る。

【図１２】図１１中の入力パーサによるトラバースのた
めに生成されるパース木の説明図である。

【図１３】ローカル定義エンティティの説明図である。

【図１４】予め定義される名前空間の説明図である。

【図１５】アクターの属性の説明図である。

【図１６】文書アクセスのためのアクターの説明図であ
る。

【符号の説明】

１２ ブラウザ（クライアント） １４ サーバ ２０ サーバ・スーパバイザ ２２ フォーム ２４ スクリプト ４００ ＰＩＡ（パーソナル・インフォメーション・エ
ージェンシー） ４０１ エージェント ４０２ クライアント（ブラウザ） ４０４ アクティブ文書

───────────────────────────────────────────────────── フロントページの続き (72)発明者 グレゴリー ウォルフ アメリカ合衆国 カリフォルニア州 94025 メンローパーク スィート 115 サンド ヒル ロード 2882 リコーコー ポレーション内

Claims (19)

【特許請求の範囲】
1. 【請求項１】 入力構造化文書を処理し、処理結果であ
   る出力文書を生成する方法であって： a) パーサ・カーソルを前記入力構造化文書の最初の要
   素を指すように初期化することを含む、入力パーサを初
   期化するステップ； b) 前記入力パーサからカレント要素を受け取るため要
   素プロセッサの要素入力を前記入力パーサと結合し、か
   つ、前記要素プロセッサの要素出力を出力ジェネレータ
   に結合する、前記要素プロセッサの初期化のステップ; c) 前記要素プロセッサに結合された定義テーブルを初
   期化するステップ； d) 前記入力パーサから要素系列を受け取って、各要素
   を次の1)から6)のステップによって処理するステップ： 1) 前記要素プロセッサの要素入力から要素を入力する
   ステップ； 2) 前記要素がアクティブ要素であるかパッシブ要素で
   あるか判定するステップ； 3) 前記要素がパッシブ要素の場合に、前記定義テーブ
   ルから得られる適用可能な定義を用いて、前記パッシブ
   要素を評価し、その結果を前記要素出力へ渡すステッ
   プ； 4) 前記要素がアクティブ要素の場合に、次の1)と2)の
   ステップを実行するステップ： i) 前記要素出力をアクティブ要素キューの入力に結合
   するステップ；及び ii)前記定義テーブルから得られる適用可能な定義を用
   いて、前記アクティブ要素を評価し、その結果を前記要
   素出力へ渡すステップ； 5) 前記アクティブ要素キューが空でない場合に、前記
   要素入力を前記アクティブ要素キューの出力に結合する
   ステップ；及び 6) 前記アクティブ要素キューが空であり、かつ、前記
   要素入力が前記入力パーサに結合されていない場合に、
   前記要素入力を前記入力パーサに結合するステップ；及
   び e) 前記出力ジェネレータを利用して前記出力文書を生
   成するステップ、からなることを特徴とする文書処理方
   法。
2. 【請求項２】 前記出力文書は処理された各要素がヌル
   文字列と評価される時にはヌル文書であることを特徴す
   る請求項１記載の文書処理方法。
3. 【請求項３】 前記の入力構造化文書、出力文書及び定
   義テーブルはそれぞれ共通の構造化文書フォーマットで
   表現されることを特徴とする請求項１記載の文書処理方
   法。
4. 【請求項４】 前記共通の構造化文書フォーマットはＳ
   ＧＭＬであることを特徴とする請求項３記載の文書処理
   方法。
5. 【請求項５】 前記の要素がアクティブ要素であるかパ
   ッシブ要素であるか判定するステップは： a) 要素識別子をアクティブ・タグ・テーブルと比較す
   るステップ； b) 一致するアクティブ・タグが前記アクティブ・タグ
   ・テーブル内に見つかったときに、前記要素をアクティ
   ブ要素と認定するステップ；及び c) 一致するアクティブタグが前記アクティブ・タグ・
   テーブル内に見つからないないときに、前記要素をパッ
   シブ要素と認定するステップ、からなることを特徴とす
   る請求項１記載の文書処理方法
6. 【請求項６】 前記の比較のステップは、要素識別子を
   前記定義テーブル内に見つかるアクティブ・タグと比較
   するステップであることを特徴とする請求項５記載の文
   書処理方法。
7. 【請求項７】 前記のパッシブ要素を評価するステップ
   は： a) 前記パッシブ要素内のトークンを、前記定義テーブ
   ルより得られる適用可能な定義で置き換えるステップ；
   及び b) 前記パッシブ要素内にプリミティブ表現があるな
   ば、そのプリミティブ表現を評価するステップ、からな
   ることを特徴とする請求項１記載の文書処理方法。
8. 【請求項８】 前記のパッシブ要素を評価するステップ
   は： a) 前記要素をパッシブ・アクター基準の集合と照合す
   るステップ；及び b) 前記要素があるパッシブ・アクターの基準と一致し
   たときに、一致した各パッシブ・アクターのためのパッ
   シブ・アクター・メソッドを呼び出すステップ、からな
   ることを特徴とする請求項１記載の文書処理方法。
9. 【請求項９】 前記のアクティブ要素を処理するステッ
   プは： a) 少なくとも前記アクティブ要素内のパッシブ・トー
   クンを、前記定義テーブルから得られる適用可能な定義
   で置き換えるステップ； b) 前記アクティプ要素内にプリミティブ表現があるな
   らば、そのプリミティブ表現を評価するステップ；及び c) 前記アクティブ要素をパラメータとしてアクティブ
   ・アクター・アクション・メソッドを呼び出すステッ
   プ、からなることを特徴する請求項１記載の文書処理方
   法。
10. 【請求項１０】 アクティブ文書インタプリタによって
    入力構造化文書を処理して出力文書を生成する方法であ
    って： a) 前記入力文書を解析して、開始タグ、終了タグ及び
    エンティティ参照を含む要素の系列からなるパース・シ
    ーケンスを得るステップ； b) 前記パース・シーケンス内で遭遇する各要素につい
    て、次の1)から6)のステップを実行するステップ： 1) 前記要素がパッシブ要素であるかアクティブ要素で
    あるか判定するステップ、ここでアクティブ要素は前記
    アクティブ文書インタプリタによって管理されているハ
    ンドラ・データベース内に関連付けられたハンドラがあ
    る要素である； 2) 前記要素の子要素が前記パース・シーケンス内にあ
    るか判定するステップ； 3) 前記要素がパッシブ要素であって子要素を持たない
    ときに、前記パッシブ要素を出力プロセスへ渡すステッ
    プ； 4) 前記要素がパッシブ要素であって子要素を持つとき
    に、その子要素をステップb)によって処理し、その処理
    を必要に応じて繰り返すステップ； 5) 前記要素がアクティブ要素であって子要素を持つと
    きに、その子要素を次のi)とii)のステップによって処
    理するステップ： i) 前記子要素をステップb)により処理し、その処理を
    必要に応じて繰り返すステップ；及び ii) ステップa)5)iで出力された要素を、記憶キューへ
    送るステップ；及び 6) 前記記憶キューが空でなければ、前記記憶キューが
    空になるまで、解析された入力文書の代わりに、前記記
    憶キューを前記パース・シーケンスのソースとして利用
    するステップ；及び c) 前記出力プロセスで、前記出力プロセスへ出力され
    た各要素を定義された出力規則集合に従って処理するス
    テップ、からなることを特徴とする文書処理方法。
11. 【請求項１１】 前記のパッシブ要素を前記出力プロセ
    スへ与えるステップはさらに： a) 前記パッシブ要素のためのエンティティ参照がエン
    ティティ定義集合中に定義されているか判定するステッ
    プ；及び b) 前記エンティティ参照が前記エンティティ定義集合
    中に定義されているときに、その定義されたエンティテ
    ィ参照の対応エンティティ値を出力するステップ、を含
    むことを特徴とする請求項１０記載の文書処理方法。
12. 【請求項１２】 前記入力構造化文書の全体を参照す
    ることなく、前記入力構造化文書を少なくとも部分的に
    処理することができるように、ステップa),b)及びc)は
    ほぼ同時に実行されることを特徴とする請求項１０記載
    の文書処理方法。
13. 【請求項１３】 ステップa),b)及びc)は逐次的に実行
    されることを特徴とする請求項１０記載の文書処理方
    法。
14. 【請求項１４】 ステップa),b)及びc)の処理操作は前
    記入力構造化文書と同じ構文で表現されることを特徴と
    する請求項１０記載の文書処理方法。
15. 【請求項１５】 前記ハンドラ・データベースは前記入
    力構造化文書と同じ構文で表現されることを特徴とする
    請求項１０記載の文書処理方法。
16. 【請求項１６】 パース木によって表現された入力構造
    化文書を処理し、出力文書を生成する装置であって： a) 要求された時に前記パース木をトラバースしてカレ
    ント要素を出力する入力文書木トラバーサ、ここで前記
    カレント要素は前記パース木内のカーソルで指示される
    要素である； b) 前記入力文書木トラバーサにより出力される要素を
    処理するための、前記入力文書木トラバーサと結合され
    た要素プロセッサ； c) 前記要素プロセッサにより出力される要素で出力文
    書木を構築するための、前記要素プロセッサと結合され
    た出力文書木コンストラクタ； d) 入力要素がアクティブ要素であるかパッシブ要素で
    あるか判定するための、前記要素プロセッサ内部の第１
    の要素エバリュエータ； e) パッシブ要素を前記要素プロセッサの出力ステージ
    へ送り、アクティブ要素を要素キューへ送るための、前
    記要素プロセッサ内部の第１のルータ； f) 前記入力要素のための対応エンティティ置換値を定
    義テーブルより見つけだすための、前記要素プロセッサ
    内部の第２の要素エバリュエータ；及び g) 前記要素キューが空でない時に前記要素キューから
    前記第２の要素エバリュエータ及び前記要素プロセッサ
    の出力へ要素を送り、前記要素プロセッサが空の時に前
    記入力から前記要素プロセッサへ要素を送るための、前
    記要素プロセッサ内部の第２のルータ、からなることを
    特徴とする文書処理装置。
17. 【請求項１７】 入力文書を処理して出力文書を得る方
    法であって： a) 前記入力文書を解析して、要素開始タグ、要素終了
    タグ、エンティティ参照及び文字列からなるシーケンス
    を得るステップ； b) 前記入力文書を 1) 定義された各エンティティ参照を、実行された時に
    定義された置換値を出力する命令シーケンスで置き換
    え； 2) アクティブ要素と認識された各要素を、実行された
    時に、当該要素の属性及び内容に対応した命令の出力を
    入力として取り込み、それを当該アクティブ要素の定義
    から本方法によって導き出された命令シーケンスへ渡す
    命令シーケンスで置き換え、 3) プリミティブ操作を表していると認識された各要素
    を、実行された時に、当該要素の属性及び内容に対応し
    た命令の出力を入力として取り込み、それらに対し指示
    されたプリミティブ操作を実行する命令シーケンスで置
    き換え、かつ、 d) 認識されなかった各々の要素開始タグ、要素終了タ
    グ、エンティティ参照及び文字列を、それを出力する命
    令シーケンスで置き換える、 ことによって、命令シーケンスに変換するステップ：及
    び c) 得られた命令シーケンスを実行して出力文書を作成
    するステップ、からなることを特徴とする文書処理方
    法。
18. 【請求項１８】 請求項１乃至１５のいずれか１項又は
    請求項１７記載の文書処理方法のための処理をコンピュ
    ータに実行させるためのプログラムが記録されたことを
    特徴とするコンピュータ読み取り可能な記憶媒体。
19. 【請求項１９】 請求項１６記載の文書処理装置の機能
    をコンピュータに実現させるためのプログラムが記録さ
    れたことを特徴とするコンピュータ読み取り可能な記憶
    媒体。