(57)【要約】【課題】  構造化文書の妥当性の検証を行う際、スキーマをすべて読み込むためメモリを多量に使用するという問題があった。【解決手段】  検証対象の構造化文書を１ノード読み取り、そのノードを検証するのに必要な分だけのスキーマを読み込んで検証を行う。１ノードの検証が終わったら、保持しているスキーマ情報が今後必要かを判断し、必要でなければ破棄する。以後、構造化文書をすべて読み終えるまでこれらをくり返す。【選択図】  図２
2008146178.tif 000002
【特許請求の範囲】
【請求項１】
構造化文書及び、構造化文書で記述されたスキーマを、ノードごとに逐次解析する構造化文書逐次解析手段と、
前記構造化文書逐次解析手段がスキーマを解析することにより得られたスキーマのノード情報から、スキーマの制約情報であるスキーマ情報を得るスキーマ情報解析手段と、
前記スキーマ情報解析手段によって得られた前記スキーマ情報を保持する保持手段と、
前記スキーマ情報の構造制約の情報から、構造化文書の現在のノードを検証するのに必要なスキーマ情報を有しているかを判断するスキーマ情報量判断手段と、
前記構造化文書逐次解析手段が前記構造化文書を解析することにより得られたノードに対して、前記スキーマ情報を用いて妥当性の検証を行う妥当性検証手段と、
前記スキーマ情報の構造制約の情報から、前記保持手段により保持されているスキーマ情報が以後の検証に必要かどうかを判断するスキーマ情報必要性判断手段と、
前記スキーマ必要性判断手段によって不要と判断されたスキーマ情報を破棄する破棄手段と、
を有することを特徴とする構造化文書処理装置。
【請求項２】
構造化文書のノード情報を受け取り、構造化文書を逐次生成する構造化文書逐次生成手段と、
構造化文書で記述されたスキーマをノードごとに逐次解析する構造化文書逐次解析手段と、
前記構造化文書逐次解析手段がスキーマを解析することにより得られたスキーマのノード情報から、スキーマの制約情報であるスキーマ情報を得るスキーマ情報解析手段と、
前記スキーマ情報解析手段によって得られた前記スキーマ情報を保持する保持手段と、
前記スキーマ情報の構造制約の情報から、現在のノードを検証するのに必要なスキーマ情報を有しているかを判断するスキーマ情報量判断手段と、
前記構造化文書のノード情報に対して、前記スキーマ情報を用いて妥当性の検証を行う妥当性検証手段と、
前記スキーマ情報の構造制約の情報から、前記保持手段により保持されているスキーマ情報が以後の検証に必要かどうかを判断するスキーマ情報必要性判断手段と、
前記スキーマ必要性判断手段によって不要と判断されたスキーマ情報を破棄する破棄手段と、
を有することを特徴とする構造化文書処理装置。
【請求項３】
前記スキーマ情報解析手段によって得られた前記スキーマ情報に他の箇所から参照される可能性がある部分を、別のファイルに出力する参照先ファイル作成手段と、
前記スキーマ情報解析手段によって得られた前記スキーマ情報に他の箇所を参照する記述がある場合に、前記参照先ファイル作成手段によって作成されたファイルの内容を読み込んで出力し、他の箇所への参照でない部分はそのまま出力する出力手段と、
更に有することを特徴とする請求項１又は２に記載の構造化文書処理装置。
【請求項４】
構造化文書及び、構造化文書で記述されたスキーマを、ノードごとに逐次解析する構造化文書逐次解析ステップと、
前記構造化文書逐次解析ステップでのスキーマの解析により得られたスキーマのノード情報から、スキーマの制約情報であるスキーマ情報を得るスキーマ情報解析ステップと、
前記スキーマ情報解析ステップで得られた前記スキーマ情報をメモリに格納する格納ステップと、
前記スキーマ情報の構造制約の情報から、構造化文書の現在のノードを検証するのに必要なスキーマ情報を有しているかを判断するスキーマ情報量判断ステップと、
前記構造化文書逐次解析ステップでの前記構造化文書の解析により得られたノードに対して、前記スキーマ情報を用いて妥当性の検証を行う妥当性検証ステップと、
前記スキーマ情報の構造制約の情報から、前記メモリに格納されているスキーマ情報が以後の検証に必要かどうかを判断するスキーマ情報必要性判断ステップと、
前記スキーマ必要性判断ステップで不要と判断されたスキーマ情報を前記メモリから削除する削除ステップと、
を有することを特徴とする構造化文書処理方法。
【請求項５】
構造化文書のノード情報を受け取り、構造化文書を逐次生成する構造化文書逐次生成ステップと、
構造化文書で記述されたスキーマをノードごとに逐次解析する構造化文書逐次解析ステップと、
前記構造化文書逐次解析ステップでのスキーマの解析により得られたスキーマのノード情報から、スキーマの制約情報であるスキーマ情報を得るスキーマ情報解析ステップと、
前記スキーマ情報解析ステップで得られた前記スキーマ情報をメモリに格納する格納ステップと、
前記スキーマ情報の構造制約の情報から、現在のノードを検証するのに必要なスキーマ情報を有しているかを判断するスキーマ情報量判断ステップと、
前記構造化文書のノード情報に対して、前記スキーマ情報を用いて妥当性の検証を行う妥当性検証ステップと、
前記スキーマ情報の構造制約の情報から、前記メモリに格納されているスキーマ情報が以後の検証に必要かどうかを判断するスキーマ情報必要性判断ステップと、
前記スキーマ必要性判断ステップで不要と判断されたスキーマ情報を前記メモリから削除する削除ステップと、
を有することを特徴とする構造化文書処理方法。
【請求項６】
前記スキーマ情報解析ステップで得られた前記スキーマ情報に他の箇所から参照される可能性がある部分を、別のファイルに出力する参照先ファイル作成ステップと、
前記スキーマ情報解析ステップで得られた前記スキーマ情報に他の箇所を参照する記述がある場合に、前記参照先ファイル作成ステップで作成されたファイルの内容を読み込んで出力し、他の箇所への参照でない部分はそのまま出力する出力ステップと、
更に有することを特徴とする請求項４又は５に記載の構造化文書処理方法。
【請求項７】
請求項４から６までのいずれか1項に記載の構造化文書処理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は構造化文書の検証技術に関する。
【背景技術】
【０００２】
近年、コンピュータ上で扱う文書やアプリケーションの設定ファイル、データ通信時のフォーマットとしてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が普及している。ＸＭＬは開始タグ（'＜'タグ名'＞'）と終了タグ（'＜/'タグ名'＞'）によってテキストに意味付けを行うための規格である。ＸＭＬではタグの名前は任意であり、またある名前のタグが具体的にどのような意味を持つかは、ＸＭＬを基に作られたそれぞれのフォーマットによる。
【０００３】
例えばＸＨＴＭＬは他の文書へのリンクを含む文書を画面に表示するための規格である。この規格において、ｂというタグは文字を太字にすることを意味する。つまり「これはとても＜ｂ＞重要＜／ｂ＞です」という記述があれば「これはとても重要です」となり、「重要」の部分が太字で表示される。
【０００４】
ＸＭＬを基にした言語は誰でも自由に作成することができるため、標準化団体が定めたものや個人が独自で定めたものなど、数多くのＸＭＬを基にしたフォーマットが存在する。
【０００５】
ＸＭＬの文書を処理するときは通常ＸＭＬ専用の解析器（ＸＭＬパーサ）を使用する。ＸＭＬパーサはＸＭＬ文書を読み込んで解析を行い、要素や文字データなどのＸＭＬを構成する単位（ノード）に切り分けてアプリケーションに渡すものである。
【０００６】
ここで、ＸＭＬを処理するときのエラーには２種類存在することになる。つまりＸＭＬとしての文法違反（整形式エラー）とＸＭＬを用いた各フォーマットの文法のエラー（妥当性エラー）である。
【０００７】
例えば「＜Ａ＞Ｈｅｌｌｏ＜／Ｂ＞」という文書は、開始タグと終了タグの名前が異なっている。これはＸＭＬの文法に違反した文書である。一方、「＜ＸＹＺ＞Ｈｅｌｌｏ＜／ＸＹＺ＞」という文書はＸＭＬの文法は満たしている。しかしＸＨＴＭＬには＜ＸＹＺ＞というタグは存在しないためエラーとなる。このような各フォーマット固有の文法に対するエラーを妥当性エラーと呼び、妥当性エラーがないかを検証することを妥当性検証と呼ぶ。
【０００８】
妥当性検証を行うためには、各フォーマットの文法を規定した文書（スキーマ）が必要である。スキーマとＸＭＬ文書を読み込み、そのＸＭＬ文書が妥当かの検証を行う検証器は以前から存在していた。例えばＪＡＶＡ（登録商標）に付属しているＸＭＬパーサはその一例である。また、ＸＭＬ文書のそれぞれのノードに対して、そのノードを検証するのに必要な代理を特定するためのテーブルを用意し、そのテーブルによって特定された代理が検証を行う、という方式が提案されている。
【０００９】
【特許文献１】特開２００５−６３４１６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、ＪＡＶＡ（登録商標）の検証器では一度スキーマをすべて読み込んでメモリ上に保持し、保持したスキーマ情報を利用してＸＭＬ文書の検証を行うものである。特許文献１の方式も同様に、代理を特定するためのテーブルを作成するためにあらかじめスキーマをすべて読み込む必要がある。このため、スキーマのデータサイズが大きい場合には多量のメモリが必要となり、特にメモリの少ない機器では検証を行うことができないという問題があった。
【００１１】
本発明の目的は、多量のメモリを消費することなく構造化文書の妥当性を検証することが可能な構造化文書処理装置を提供することである。
【課題を解決するための手段】
【００１２】
本発明の一側面に係る構造化文書処理装置は、構造化文書及び、構造化文書で記述されたスキーマを、ノードごとに逐次解析する構造化文書逐次解析手段と、前記構造化文書逐次解析手段がスキーマを解析することにより得られたスキーマのノード情報から、スキーマの制約情報であるスキーマ情報を得るスキーマ情報解析手段と、前記スキーマ情報解析手段によって得られた前記スキーマ情報を保持する保持手段と、前記スキーマ情報の構造制約の情報から、構造化文書の現在のノードを検証するのに必要なスキーマ情報を有しているかを判断するスキーマ情報量判断手段と、前記構造化文書逐次解析手段が前記構造化文書を解析することにより得られたノードに対して、前記スキーマ情報を用いて妥当性の検証を行う妥当性検証手段と、前記スキーマ情報の構造制約の情報から、前記保持手段により保持されているスキーマ情報が以後の検証に必要かどうかを判断するスキーマ情報必要性判断手段と、前記スキーマ必要性判断手段によって不要と判断されたスキーマ情報を破棄する破棄手段とを有することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、スキーマを用いて構造化文書の妥当性を検証する際に、スキーマの情報をすべて保持することなく検証を行うため省メモリで実現することが可能となり、小型の機器でもエラー処理の信頼性を向上させることができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。なお、本発明は以下の実施形態に限定されるものではなく、本発明の実施に有利な具体例を示すにすぎない。また、以下の実施形態の中で説明されている特徴の組み合わせの全てが本発明の課題解決手段として必須のものであるとは限らない。
【００１５】
＜実施形態１＞
本発明の第一の実施形態における構造化文書処理装置の構成を図１に示す。
【００１６】
同図において、ＣＰＵ１０１はシステム制御部であり装置全体を制御する。ＲＯＭ１０２はＣＰＵの制御プログラムや各種固定データを格納する。ＲＡＭ１０３はＳＲＡＭ、ＤＲＡＭなどで構成され、プログラム制御変数などを格納する。また、各種設定パラメータ、各種ワークバッファなどもＲＡＭ１０３に格納される。記憶部１０４はハードディスクなどであり、ファイルデータを格納する。
【００１７】
構造化文書逐次解析部１０５は構造化文書及び構造化文書で記述されたスキーマを解析し、ノード情報をＲＡＭ１０３に格納する。スキーマ情報解析部１０６は、スキーマを構造化文書逐次解析部１０５によって解析して得られたノード情報を、スキーマの制約情報として解析し、構造化文書検証部１０８が使用できるスキーマ情報としてＲＡＭ１０３に格納する。
【００１８】
なお構造化文書逐次解析部１０５は逐次処理が可能となっている。逐次処理とは、対象となる文書を一度にすべて読み込むのではなく、文書の先頭から一部ずつ読み込んで使用し、また必要のなくなった情報を適宜破棄していくことが可能であることを意味する。
【００１９】
スキーマ情報量判断部１０７は、構造化文書逐次解析部１０５が読み込んだノードを、現在保持しているスキーマ情報で検証を行うことが可能かを判断する。構造化文書検証部１０８は、ＲＡＭ１０３に保持しているスキーマ情報を用いて、ＲＡＭ１０３に保持しているノードが妥当なものかどうかを検証する。スキーマ情報必要性判断部１０９は、ＲＡＭ１０３に保持しているスキーマ情報が以後も使用されるかどうかを判断する。
【００２０】
この構造化文書処理装置が、記憶部１０４に保存されている構造化文書を、同じく記憶部１０４に保存されているスキーマを用いて検証を行う。なお、本実施形態では構造化文書はＸＭＬを基とするフォーマットで書かれており、スキーマはＲＥＬＡＸ  ＮＧ（http://www.relaxng.org/）で記述されているものとする。ただし、本実施形態中にある記述は説明の簡略化のため、本発明の本質から外れる部分は除外している。
【００２１】
スキーマの例を図３に示す。ＲＥＬＡＸ  ＮＧのスキーマでは、ｅｌｅｍｅｎｔ要素によってＸＭＬ文書中に存在するべき要素を表し、ｎａｍｅ属性でその要素の名前を記述する。また、ｅｌｅｍｅｎｔ要素の内容として、さらにｅｌｅｍｅｎｔ要素がある場合は、その外側にある要素の内容として内側にある要素が存在しなくてはならないことを示す。ｅｌｅｍｅｎｔ要素の内容がｔｅｘｔ要素のときは、その要素の内容として任意の文字列を持つことを意味する。ｉｎｔｅｒｌｅａｖｅ要素は、その中に記述された要素が存在しなければならないが、順番は問わないことを意味する。ｚｅｒｏＯｒＭｏｒｅ要素は、その中に記述された要素が繰り返し存在することが可能で、一つもなくてもよいことを意味する。またその他に、複数の要素のうちのいずれか一つが存在すればよいことを示すｃｈｏｉｃｅ要素などがある。
【００２２】
つまり図３のスキーマは、ｐｅｒｓｏｎという要素が存在し、その内容としてはまずｆａｍｉｌｙＮａｍｅとｇｉｖｅｎＮａｍｅ要素が順不同で存在しなければならない。さらにその後に、ｃｅｒｔｉｆｉｃａｔｉｏｎ要素が０回以上繰り返して存在する、ということを意味する。また、ｆａｍｉｌｙＮａｍｅ、ｇｉｖｅｎＮａｍｅ、ｃｅｒｔｉｆｉｃａｔｉｏｎ要素の内容は任意の文字列が可能である。
【００２３】
このスキーマに対して妥当な文書の例を図４及び図５に示す。いずれもｐｅｒｓｏｎ要素があり、その中にｆａｍｉｌｙＮａｍｅ及びｇｉｖｅｎＮａｍｅがあり、その後にｃｅｒｔｉｆｉｃａｔｉｏｎ要素が繰り返し存在している。
【００２４】
これに対して図６は、上記スキーマに対して妥当でない文書の例である。この文書はａｇｅという要素を含んでいるが（６０４）、この要素はスキーマには存在しないため妥当でないとみなされる。
【００２５】
第一の実施形態の構造化文書処理装置の処理の流れを図２に示す。ここでは、例として使用するスキーマは図３、解析する文書は図５を用いる。まず検証対象の文書をすべて読み込んだかを確認する（ステップＳ２０２）。まだすべてを読み込んでいない場合は検証対象の文書を１ノード読み取る（ステップＳ２０３）。ノードとは、ＸＭＬの開始タグ、終了タグ、文字データなど、構造化文書を構成する単位となるべきものである。この例の場合は、＜ｐｅｒｓｏｎ＞タグ（５０１）が読み込まれる。
【００２６】
次に、読み込んだノードを検証するのに必要なスキーマ情報を有しているかを確認する（ステップＳ２０４）。最初の段階ではスキーマは何も読んでおらず、必要なスキーマ情報を保持していないため、スキーマを１ノード読み込み（ステップＳ２０５）、スキーマ情報として解析してＲＡＭ１０３に保存する（ステップＳ２０６）。スキーマの最初のノード（３０１）はｅｌｅｍｅｎｔタグであり、ｎａｍｅ属性にｐｅｒｓｏｎがあることから、最初の要素がｐｅｒｓｏｎでなければならないことがわかる。
【００２７】
次にもう一度、読み込んだノードを検証するのに必要なスキーマ情報を有しているかの判断を行う（ステップＳ２０４）。この判断は、スキーマ情報の構造制約の情報から判断できる。ＲＥＬＡＸＮＧによるスキーマの構成は主に順次、選択、順不同、反復の４種類の構成からなる。順次構造はｅｌｅｍｅｎｔ要素が連続する場合など、指定された要素がその順で存在しなければならないことを表すものである。選択構造は、複数の候補のうちの一つが存在すればよいことを示すものである。順不同構造は、指定された複数の要素が存在しなければならないがその順序は問わないものである。反復構造は与えられた要素が繰り返し存在可能であることを表すものである。選択、順不同、反復は、ＲＥＬＡＸＮＧではそれぞれｃｈｏｉｃｅ、ｉｎｔｅｒｌｅａｖｅ、ｚｅｒｏＯｒＭｏｒｅなどで表す。
【００２８】
これら４つの構成のうち選択構造と順不同構造の場合は、その内容をすべて保持していないと検証を行うことはできない。なぜなら、ノードに対する制約の候補が複数存在することになり、それらのすべてに対応する必要があるからである。一方順次構造や反復構造の場合は、存在できるノードの候補が一つしかないため、その一つの制約のみを読み込めば検証を行うことが可能である。また、順不同構造内の検証の途中である場合は、保持しているスキーマ情報で検証が可能であるため読み込む必要がないと判断される。つまり、ＲＥＬＡＸ  ＮＧの場合は、読み込んだスキーマがｅｌｅｍｅｎｔ、ｔｅｘｔ要素などの場合はその段階で検証を行うことが可能だと判断できる。一方、ｃｈｏｉｃｅやｉｎｔｅｒｌｅａｖｅ要素のときは、その終わりまでを読む必要があると判断する。また、ｉｎｔｅｒｌｅａｖｅ要素内の要素の検証中は、そのｉｎｔｅｒｌｅａｖｅ要素をはじめに読んだときに最後まで読み込んでいるため、それ以上スキーマを読み込む必要がないと判断できる。
【００２９】
このような判断の結果、最初に読み込んだときはｅｌｅｍｅｎｔ要素（３０１）であるため、この段階で検証可能と判断し、検証を行う（ステップＳ２０７）。スキーマで指定された要素と保持しているノードとが一致しているため、妥当であると判断される。もしそれ以外のノードであれば妥当ではないとみなされエラーとなる（ステップＳ２０８、２０９）。
【００３０】
次に、現在保持しているスキーマ情報が今後も必要かどうかの判断を行う（ステップＳ２１０）。この判断もスキーマ情報の構造制約の情報から判断できる。前述の４種類の構造のうち、反復構造では同じ構成が連続する可能性があるため、スキーマ情報を保持する必要があると判断できる。反復構造は、その反復構造の次の要素が現れ、確実に反復構造が終了したと判断できる場合にのみ不要と判断することができる。逆に、その他３つの構造の場合は、再び使われることはないと判断できる。この判断によって不要と判断された場合は、ＲＡＭ１０３に保持されているスキーマ情報は破棄される（ステップＳ２１１）。
【００３１】
図３の３０１におけるスキーマ要素は反復構造ではないため不要と判断され、この情報は破棄される。
【００３２】
この段階では検証対象文書をまだすべて読み終えていないため次のノードを読み取る（ステップＳ２０２，２０３）。次に読み込む検証対処文書のノードはｆａｍｉｌｙＮａｍｅ要素（５０２）である。また読み込むスキーマはｉｎｔｅｒｌｅａｖｅ要素（３０２）である。ｉｎｔｅｒｌｅａｖｅ要素は、内部の構造が順不同であるため、検証を行うにはｉｎｔｅｒｌｅａｖｅの終わり（３０５）まで必要と判断され、そこまでをすべて読み込む。その結果５０２が妥当であると判断できる。次のｇｉｖｅｎＮａｍｅ要素（５０３）のときは、ｉｎｔｅｒｌｅａｖｅ要素内であるため、スキーマを読み込む必要がないことを除けば同様に検証できる。
【００３３】
同様に、ｃｅｒｔｉｆｉｃａｔｉｏｎ要素（５０４）を読み込んだときは、ｚｅｒｏＯｒＭｏｒｅ要素（３０６）を読み込むが、これは反復構造であるため、最初の制約であるｅｌｅｍｅｎｔ要素（３０７）までを読み込めば検証可能と判断して検証を行う。検証後、保持しているスキーマ情報が必要かを判断するが、ｚｅｒｏＯｒＭｏｒｅ要素のような反復構造の場合は保持しておく、そのスキーマ情報を使用してｃｅｒｔｉｆｉｃａｔｉｏｎ要素５０５も検証を行うことができる。
【００３４】
以上の処理を繰り返し、検証対象文書を最後まで読み込み、妥当性エラーが起きなければその文書がスキーマに対して妥当であると判断することができる。
【００３５】
＜実施形態２＞
本発明の第二の実施形態における構造化文書処理装置の構成を図７に示す。これは、ネットワーク上などの外部の機器から、逐次処理を行うことができないスキーマを受信したときに、スキーマを変換して保存することにより、逐次処理を行うものである。
【００３６】
図７において、７０１から７０９まではそれぞれ、図１の１０１から１０９までと同じものである。図７では、更に、スキーマ変換部７１０及びネットワークインタフェース７１１が付加されている。スキーマ変換部７１０は、スキーマ逐次解析部７０６によって読み込んだスキーマ情報を、逐次処理が可能となるように変換して出力する。ネットワークインタフェース７１１は、ＬＡＮボードやモデムといったネットワークインタフェースであり、ネットワーク上の他の機器との通信を可能とする。
【００３７】
この構造化文書処理装置は、図８に示すネットワークに接続されている。図８において、８０１はプロバイダと呼ばれ、ネットワーク上の他の機器に対して何らかのサービスを提供するものである。また、８０２はリクエスタと呼ばれ、プロバイダに対してサービスの依頼をするものである。これらの機器はネットワーク８０３で接続されており、相互に通信が可能である。本実施形態における構造化文書処理装置はこのうちのリクエスタにあたるものである。
【００３８】
この構造化文書処理装置（リクエスタ）が新たにプロバイダのサービスを利用するためには、まずプロバイダに送信又は受信するメッセージのフォーマット、つまりスキーマを知る必要がある。スキーマの追加は、人手で行う方法や、プロバイダから取得するなどの方法で行う。
【００３９】
一般的にスキーマは人間が見たときの見やすさや、保守及び拡張性のためにモジュール化されていることが多く、そのままでは逐次処理が不可能であることが多い。
【００４０】
逐次処理が不可能なスキーマの例を図９に示す。この例もＲＥＬＡＸ  ＮＧを簡略化した書式で記述している。ここでｓｔａｒｔという要素が、このスキーマ全体の開始点となるべき場所を示している。つまり、ｓｔａｒｔ要素の中の最初のｅｌｅｍｅｎｔ要素（９０３）が、このスキーマに従ったＸＭＬ文書の先頭の要素の制約を表している。この例ではａｄｄｒｅｓｓＢｏｏｋとなっている。さらにその中にｅｌｅｍｅｎｔ要素（９０４）によって、次にｎａｍｅという要素が必要であることがわかる。９０５にあるｒｅｆという要素は、他の場所で定義されたものを使用することを表すものである。定義はｄｅｆｉｎｅという要素で記述し、ｒｅｆ要素のｎａｍｅ属性によって参照先を特定する。つまりｒｅｆ要素（９０５）は、文書の後方にある９１０から９１３の箇所を参照することを意味している。
【００４１】
このように特定の部分を別の箇所に置き、そこを参照することで、スキーマ全体構成の把握が容易になり、また他のスキーマで再利用が可能になるという利点がある。しかし、文書の後方を参照しているスキーマの場合には、参照先まで読み込まなければ検証を行うことができず、逐次処理を行うことが出来ない。そこで、図１４の流れに従って、スキーマを変換することが必要となる。
【００４２】
まずスキーマ内にある、参照先となり得る部分と、それ以外の部分にわけた複数のファイルとして記憶装置７０４に保存する（ステップＳ１４０２）。次にもう一度参照先以外の部分のファイルを読みながら、参照先を保存したファイルと組み合わせることで新たな逐次処理用スキーマを生成する（ステップＳ１４０３）。その後、ネットワークインタフェースでＸＭＬを受信し（ステップＳ１４０４）、解析及び検証を行う（ステップＳ１４０５）。
【００４３】
ステップＳ１４０２におけるファイル保存処理の詳細を図１５に示す。
【００４４】
まず、スキーマを１ノード読み込む（ステップＳ１５０２）。そのノードがｄｅｆｉｎｅ要素であるかを確認し（ステップＳ１５０３）、ｄｅｆｉｎｅ要素以外のノードはそのまま出力する（ステップＳ１５０４、１５１０）。ｄｅｆｉｎｅ要素であれば、それを別のファイルに保存をする（ステップＳ１５０５）。このときファイル名は他の同一のものがなければ任意のものでよく、保存したファイル名と参照名（ｄｅｆｉｎｅ要素のｎａｍｅ属性の値）を保存するテーブルに追加する（ステップＳ１５０６）。ここではｎａｍｅＤａｔａ．ｒｎｇという名前で保存されたとする。そしてｄｅｆｉｎｅ要素の終わりまでのノードをすべて新たに作成したファイルに出力する（ステップＳ１５０７、１５０８、１５０９）。このようにしてスキーマのすべてのノードを別のファイルに出力する。
【００４５】
図９のスキーマに対しては結果として、参照先以外の情報を持つファイル（図１０）、ｎａｍｅＤａｔａという参照名で参照される情報を持つファイル（図１１）、及び参照名とファイル名のテーブル（図１２）が生成される。
【００４６】
次に、ステップＳ１４０３における逐次処理用スキーマの作成処理の詳細を図１６に示す。
【００４７】
まず参照先以外の情報を持つスキーマを１ノードずつ読み込み（ステップＳ１６０２）、ｒｅｆ要素の内容以外はそのまま出力する（ステップＳ１６０４）。ｒｅｆ要素の場合はテーブルから参照名に対するファイル名を調べ（ステップＳ１６０５）、そのファイルのｄｅｆｉｎｅタグ以外の部分をすべてそのまま出力する（ステップＳ１６０６）。以上の処理をすべてのノードに対して行う（ステップＳ１６０７）。その結果として図１３のスキーマが出力される。このスキーマは参照の記述が解決されており、スキーマ先頭から順に処理を行う逐次処理が可能となっている。実際にＸＭＬ文書を検証する際の処理の流れは第一の実施形態のときと同様である。
【００４８】
本実施形態において、構造化文書のフォーマットとしてＸＭＬ、スキーマ言語としてＲＥＬＡＸ  ＮＧを例に用いたが、その他の構造化文書フォーマットやスキーマ言語を使用することも可能である。例えばＷ３Ｃ  ＸＭＬ  Ｓｃｈｅｍａの場合は、順次、選択、順不同、反復構造をそれぞれｓｅｑｕｅｎｃｅ、ｃｈｏｉｃｅ、ａｌｌ、ｍａｘＯｃｃｕｒｅｓ要素などに当てはめ、ｒｅｆ要素を参照構造とみなすことで、同様の処理が可能である。
【００４９】
また、実施形態はＸＭＬの解析時に検証を行うものであったが、検証を行った後にＸＭＬを生成する構成にすることで、ＸＭＬの生成時の検証にも活用することが可能である。
【００５０】
また本実施形態では、スキーマ情報量の判断の際、ｃｈｏｉｃｅ要素内の要素をすべて読み込んでから検証を行っていたが、これをｃｈｏｉｃｅ内の要素を順次読み込んで検証を行うことも可能である。例えば、ｃｈｏｉｃｅ要素内にｅｌｅｍｅｎｔ要素が３つあるとき、一つずつ読み込んで検証を行い、妥当であった時点でそのノードは妥当であると判断し、３つすべてが妥当でないときに妥当性違反と判断することで、より省メモリ化を実現することができる。
【００５１】
（他の実施形態）
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【００５２】
なお、本発明は、前述した実施形態の各機能を実現するプログラムを、システム又は装置に直接又は遠隔から供給し、そのシステム又は装置に含まれるコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。
【００５３】
従って、本発明の機能・処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、上記機能・処理を実現するためのコンピュータプログラム自体も本発明の一つである。
【００５４】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００５５】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、記録媒体としては、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【００５６】
また、プログラムは、クライアントコンピュータのブラウザを用いてインターネットのホームページからダウンロードしてもよい。すなわち、ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードしてもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードする形態も考えられる。つまり、本発明の機能・処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の構成要件となる場合がある。
【００５７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布してもよい。この場合、所定条件をクリアしたユーザにのみ、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報で暗号化されたプログラムを復号して実行し、プログラムをコンピュータにインストールしてもよい。
【００５８】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現されてもよい。なお、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行ってもよい。もちろん、この場合も、前述した実施形態の機能が実現され得る。
【００５９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれてもよい。そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行ってもよい。このようにして、前述した実施形態の機能が実現されることもある。
【図面の簡単な説明】
【００６０】
【図１】本発明の第一の実施形態における構造化文書処理装置の構成を示すブロック図である。
【図２】本発明の第一の実施形態における構造化文書処理装置の検証処理を示すフローチャートである。
【図３】スキーマの例を示す図である。
【図４】、
【図５】図３のスキーマに対して妥当な文書の例を示す図である。
【図６】図３のスキーマに対して妥当でない文書の例を示す図である。
【図７】本発明の第二の実施形態における構造化文書処理装置の構成を示すブロック図である。
【図８】本発明の第二の実施形態における構造化文書処理装置と他機器との関係を示す図である。
【図９】スキーマ内での参照の記述を含むスキーマの例を示す図である。
【図１０】参照の記述を省いたスキーマの例を示す図である。
【図１１】参照される箇所のみを出力した結果の例を示す図である。
【図１２】参照名とファイル名との関係を示すテーブルの例を示す図である。
【図１３】逐次処理が可能なように変換した結果のスキーマの例を示す図である。
【図１４】本発明の第二の実施形態における構造化文書処理装置の処理の概要を示すフローチャートである。
【図１５】スキーマ変換の一次処理の詳細を示すフローチャートである。
【図１６】スキーマ変換の二次処理の詳細を示すフローチャートである。
【図１】
2008146178.tif 000003
【図２】
2008146178.tif 000004
【図３】
2008146178.tif 000005
【図４】
2008146178.tif 000006
【図５】
2008146178.tif 000007
【図６】
2008146178.tif 000008
【図７】
2008146178.tif 000009
【図８】
2008146178.tif 000010
【図９】
2008146178.tif 000011
【図１０】
2008146178.tif 000012
【図１１】
2008146178.tif 000013
【図１２】
2008146178.tif 000014
【図１３】
2008146178.tif 000015
【図１４】
2008146178.tif 000016
【図１５】
2008146178.tif 000017
【図１６】
2008146178.tif 000018