(57)【要約】図１（ｂ）に示すように、先出願では、レコード内の各要素を、応用ソフトのデータ処理の対象項目（キー要素）と、非対象項目（非キー要素）に分けて、キー要素はそのままにし、非キー要素の要素内容をＣＳＶ形式で各新要素に纏めたＸＭＬ文書に変換する。本発明では、図１（ｃ）に示すように、新要素をレコード内の第１階層に複数配置し、各非キー要素は、自由に任意の新要素に要素内容を纏める。また、ヘッダに付加情報を記述することで、自己記述性を維持できるようにする。
2004061713.tif 000002
【特許請求の範囲】
【請求項１】
定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内の各要素について、レコード内で出現する順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である各非キー要素を、前記複数の新要素の何れに割り当てるかを定義した変換仕様定義手段と、
該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段と、
を有することを特徴とする構造化文書の構造変換装置。
【請求項２】
前記変換仕様定義手段で定義される変換仕様に基づいて前記変換後の構造化文書を元の構造化文書に戻すために、該変換仕様定義手段において前記出現順に定義されている各要素について、順次、その要素に該当する新要素を求め、該新要素について前記ＣＳＶ形式でまとめた各要素内容の中から、その順番に応じて該要素に対応する要素内容を求めて前記元の構造化文書に記述する逆変換手段、
を更に有することを特徴とする請求項１記載の構造化文書の構造変換装置。
【請求項３】
前記構造変換手段は、更に、前記新要素毎に、前記ＣＳＶ形式でまとめた各要素内容に対応する要素名を、ＣＳＶ形式でまとめたものを、付加情報として変換後の構造化文書に記述することを特徴とする請求項１記載の構造化文書の構造変換装置。
【請求項４】
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、該複数の新要素の何れに割り当てるかを定義した変換仕様定義手段と、
該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、前記変換対象の構造化文書に出現する要素はその要素内容を、前記変換対象の構造化文書に出現しない要素の要素内容は空要素として、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段と、
を有することを特徴とする構造化文書の構造変換装置。
【請求項５】
前記変換仕様定義手段で定義される変換仕様に基づいて前記変換後の構造化文書を元の構造化文書に戻すために、該変換仕様定義手段において前記出現順に定義されている各要素について、順次、その要素に該当する新要素を求め、該新要素について前記ＣＳＶ形式でまとめた各要素内容の中から、その順番に応じて該要素に対応する要素内容を求めて前記元の構造化文書に記述する際に、該要素内容が前記空要素である要素は記述しない逆変換手段、
を更に有することを特徴とする請求項４記載の構造化文書の構造変換装置。
【請求項６】
変換仕様定義手段は、更に、前記各要素毎に、前記変換対象の構造化文書内で必ず出現するとは限らない要素である非定型要素であるか否かを指定し、
前記キー要素は、該非定型要素であって且つ前記変換対象の構造化文書内に記述されていない場合には、変換後の構造化文書に何も記述しないことを特徴とする請求項４記載の構造化文書の構造変換装置。
【請求項７】
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義すると共に、該各新要素毎にその新要素が非定型要素であるか否かを指定し、変換対象の構造化文書内の各要素について、該構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、前記複数の新要素の何れに割り当てるかを定義する変換仕様定義手段と、
該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、前記新要素毎に、該新要素が前記非定型要素ではない場合には出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容として変換後の構造化文書に記述し、該新要素が前記非定型要素である場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容とすると共に該出現順番をＣＳＶ形式でまとめたものを該新要素のタグの属性値として変換後の構造化文書に記述する構造変換手段と、
を有することを特徴とする構造化文書の構造変換装置。
【請求項８】
前記変換仕様定義手段で定義される変換仕様に基づいて前記変換後の構造化文書から任意の構造化文書に変換するために、該変換仕様定義手段における前記出現順に各要素について、該要素に該当する新要素を求め、該新要素が前記非定型要素である場合には、該新要素の前記属性値として該要素の出現順番が記述されている場合に、該要素に対応する要素内容を前記元の構造化文書に記述する逆変換手段、
を更に有することを特徴とする請求項７記載の構造化文書の構造変換装置。
【請求項９】
前記構造変換手段は、更に、前記新要素毎に、その新要素内に要素内容を記述し得る全ての要素の要素名をＣＳＶ形式でまとめたものを、付加情報として変換後の構造化文書に記述することを特徴とする請求項４または８記載の構造化文書の構造変換装置。
【請求項１０】
前記変換仕様定義手段は、更に、変換対象の構造化文書における任意の階層の任意の要素名に関して、該階層の指定まで含めた要素名に対応付けた別名を与える定義を行い、
前記構造変換手段は、前記付加情報として記述する要素名を該別名とすることを特徴とする請求項９記載の構造化文書の構造変換装置。
【請求項１１】
前記変換仕様定義手段によって定義される変換仕様を反映した変換用スタイルシートを生成し、
前記構造変換手段は、該変換用スタイルシートを用いて前記変換を実行することを特徴とする請求項１〜１０の何れかに記載の構造化文書の構造変換装置。
【請求項１２】
前記変換仕様定義手段によって定義される変換仕様を逆に反映した逆変換用スタイルシートを生成し、
前記逆変換手段は、該逆変換用スタイルシートを用いて前記逆変換を実行することを特徴とする請求項２，５，８の何れかに記載の構造化文書の構造変換装置。
【請求項１３】
定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、該変換対象の構造化文書内の各要素について、レコード内で出現する順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である各非キー要素を、前記複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を有することを特徴とする構造化文書の構造変換方法。
【請求項１４】
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、該複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記変換対象の構造化文書に出現する要素はその要素内容を、前記変換対象の構造化文書に出現しない要素の要素内容は空要素として、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を有することを特徴とする構造化文書の構造変換方法。
【請求項１５】
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義すると共に、該各新要素毎にその新要素が非定型要素であるか否かを指定し、変換対象の構造化文書内の各要素について、該構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、前記複数の新要素の何れに割り当てるかを定義する変換仕様定義文書に基づいて、
該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記新要素毎に、
該新要素が前記非定型要素ではない場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容として変換後の構造化文書に記述するステップと、
該新要素が前記非定型要素である場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容とすると共に該出現順番をＣＳＶ形式でまとめたものを該新要素のタグの属性値として変換後の構造化文書に記述するステップと、
を有することを特徴とする構造化文書の構造変換方法。
【請求項１６】
コンピュータに、
定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、該変換対象の構造化文書内の各要素について、レコード内で出現する順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である各非キー要素を、前記複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるためのプログラム。
【請求項１７】
コンピュータに、
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、該複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記変換対象の構造化文書に出現する要素はその要素内容を、前記変換対象の構造化文書に出現しない要素の要素内容は空要素として、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるためのプログラム。
【請求項１８】
コンピュータに、
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義すると共に、該各新要素毎にその新要素が非定型要素であるか否かを指定し、変換対象の構造化文書内の各要素について、該構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、前記複数の新要素の何れに割り当てるかを定義する変換仕様定義文書に基づいて、
該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記新要素毎に、
該新要素が前記非定型要素ではない場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容として変換後の構造化文書に記述するステップと、
該新要素が前記非定型要素である場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容とすると共に該出現順番をＣＳＶ形式でまとめたものを該新要素のタグの属性値として変換後の構造化文書に記述するステップと、
を実現させるためのプログラム。
【請求項１９】
コンピュータに、
定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、該変換対象の構造化文書内の各要素について、レコード内で出現する順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である各非キー要素を、前記複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。
【請求項２０】
コンピュータに、
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、該複数の新要素の何れに割り当てるかを定義した変換仕様定義文書に基づいて、
変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記変換対象の構造化文書に出現する要素はその要素内容を、前記変換対象の構造化文書に出現しない要素の要素内容は空要素として、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。
【請求項２１】
コンピュータに、
非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義すると共に、該各新要素毎にその新要素が非定型要素であるか否かを指定し、変換対象の構造化文書内の各要素について、該構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、前記複数の新要素の何れに割り当てるかを定義する変換仕様定義文書に基づいて、
該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、
前記キー要素はそのまま変換後の構造化文書に記述するステップと、
前記各非キー要素に関しては、前記新要素毎に、
該新要素が前記非定型要素ではない場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容として変換後の構造化文書に記述するステップと、
該新要素が前記非定型要素である場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容とすると共に該出現順番をＣＳＶ形式でまとめたものを該新要素のタグの属性値として変換後の構造化文書に記述するステップと、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。
【請求項２２】
レコードの種類毎にそのレコードを構成する要素が異なる非定型の構造化文書に対応して、レコードの種類毎にレコード項目リストを定義するものであって、該各レコード項目リストは、そのレコード種類に出現し得る全ての要素について、データ処理の対象となるキー要素であるか否かを指定すると共に、変換後の構造化文書における新要素を１以上定義して、前記キー要素以外の要素である非キー要素を、どの新要素に割り当てるかを指定する変換仕様定義手段と、
該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書中の各レコード毎に、そのレコードの種類に応じたレコード項目リストを前記変換仕様定義手段から選択し、該選択したレコード項目リストに基づいて、前記レコード内の各要素をレコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段と、
を有することを特徴とする構造化文書の構造変換装置。
【請求項２３】
前記各レコード項目リストには、そのレコード項目リストを選択させる為の切り替え条件が更に記述され、
前記構造変換手段は、該切り替え条件を用いて、処理対象のレコードの種類に応じたレコード項目リストを選択することを特徴とする請求項２２記載の構造変換装置。
【請求項２４】
レコードの種類毎にそのレコードを構成する要素が異なる非定型の構造化文書に対応して、レコードの種類毎にレコード項目リストを定義するものであって、該各レコード項目リストは、そのレコード種類に出現し得る全ての要素について、データ処理の対象となるキー要素であるか否かを指定すると共に、変換後の構造化文書における新要素を１以上定義して、前記キー要素以外の要素である非キー要素を、どの新要素に割り当てるかを指定する変換仕様定義文書に基づいて、
該変換仕様定義文書によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書中の各レコード毎に、そのレコードの種類に応じたレコード項目リストを前記変換仕様定義文書から選択するステップと、
該選択したレコード項目リストに基づいて、前記レコード内の各要素をレコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を有することを特徴とする構造化文書の構造変換方法。
【請求項２５】
コンピュータに、
レコードの種類毎にそのレコードを構成する要素が異なる非定型の構造化文書に対応して、レコードの種類毎にレコード項目リストを定義するものであって、該各レコード項目リストは、そのレコード種類に出現し得る全ての要素について、データ処理の対象となるキー要素であるか否かを指定すると共に、変換後の構造化文書における新要素を１以上定義して、前記キー要素以外の要素である非キー要素を、どの新要素に割り当てるかを指定する変換仕様定義文書に基づいて、  該変換仕様定義文書によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書中の各レコード毎に、そのレコードの種類に応じたレコード項目リストを前記変換仕様定義文書から選択するステップと、
該選択したレコード項目リストに基づいて、前記レコード内の各要素をレコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるためのプログラム。
【請求項２６】
コンピュータに、
レコードの種類毎にそのレコードを構成する要素が異なる非定型の構造化文書に対応して、レコードの種類毎にレコード項目リストを定義するものであって、該各レコード項目リストは、そのレコード種類に出現し得る全ての要素について、データ処理の対象となるキー要素であるか否かを指定すると共に、変換後の構造化文書における新要素を１以上定義して、前記キー要素以外の要素である非キー要素を、どの新要素に割り当てるかを指定する変換仕様定義文書に基づいて、
該変換仕様定義文書によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書中の各レコード毎に、そのレコードの種類に応じたレコード項目リストを前記変換仕様定義文書から選択するステップと、
該選択したレコード項目リストに基づいて、前記レコード内の各要素をレコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述するステップと、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】  本発明は、ＸＭＬ文書からＸＭＬ文書への構造変換／逆変換を行なう方法、装置等に関する。
【背景技術】  近年、インターネットを通して、個人、企業、自治体など、あらゆる種類のシステムが相互に通信可能に接続されており、これらのシステムが相互に連携して、Ｗｅｂサービスが提供されたり、ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ）が行われつつある。このために、幅広い情報交換が必要になってきている。
このような状況下において、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、データを構造化する柔軟な表現能力を有し、コンピュータによる処理に適しているので、上記のシステム間のデータ交換や各システムでのデータ処理を行う際の、共通基盤のフォーマットとして注目されている。
ＸＭＬは、１９８６年にＩＳＯで標準化されたＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を、インターネットで活用し易くするために、１９９８年２月にその基本仕様ＸＭＬ１．０がＷ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）において策定されたものである。
従来より用いられているＷｅｂページ作成言語であるＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、タグが固定で表示に特化したものとなっており、タグ情報を基にコンピュータで情報を処理したいという要件に対応できない問題があった。
これに対して、ＸＭＬは、利用者が自由にタグを定義でき、文書中の文字列に意味付けができる言語構造を有している。このようなＸＭＬで文書を記述した場合、その文書を、タグ情報に基づいてコンピュータで情報処理できる。
尚、ＸＭＬ文書は、その特徴によって、次の２種類の型に大きく分類される。
・データ型ＸＭＬ文書：伝票、予定表など、タグ数が多く、要素内容短いもの
・文書型ＸＭＬ文書：雑誌、マニュアル、辞典など、要素内容が長い文章になるもの
ここでは、主に、データ型ＸＭＬ文書を対象にするものとする。
ここで、以下の説明で使用される用語について、ＸＭＬ規格に基づき説明しておく。よく知られていることであるが、一対の”〈”と”〉”で囲まれた文字列を「タグ」、”〈文字列〉”を「開始タグ」、”〈／文字列〉”を「終了タグ」、開始タグから終了タグまでの文字列全体を「要素」、開始タグと終了タグで挟まれた文字列を「要素内容」、タグ内に記述される要素の名前を「タグ名」（あるいは「要素名」）、要素に対する付加情報を「属性」と呼ぶ。
構造化文書では、その文書中にタグを埋め込む形でデータ構造が記述される。このようにデータ構造をタグとして文書中に埋め込んだ構成を採ることにより、データ項目の追加・削除・変更に対して柔軟性と拡張性が得られるほか、タグ名に、人が読んで意味のある名前を付けることにより、データに視認性を持たせることができる。
ところで、ＸＭＬ文書に対する処理の高速化やメモリ使用量の削減等を図って、ＸＭＬ文書に対する処理能力を向上させる為には、一般に、基盤ソフトウェアの実装の高性能化を図ることが主流になっている。しかし、このような手法のほかに、ＸＭＬ文書自体に予め加工を施しておくことによっても、ＸＭＬ文書に対する処理性能を向上させることが可能である。本発明は、後者の手法（ＸＭＬ文書を加工して処理性能の向上を図る手法）に関連するものであり、ここで、後者の手法に係わる従来技術について説明する。
例えば、非特許文献１には、ＸＭＬ導入時に処理速度が遅くなる問題が発生し、データ構造を変更することにより、問題に対処する事例が開示されている。例えば、住友電工システムズの例（同誌のｐ．６４−６５参照）では、同種のデータを、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）形式で１つにまとめて記述し、まとめられたデータを、ＸＭＬ文書中の１つのタグ中に埋め込むことが開示されている。つまり、「ＸＭＬデータの中に、ＣＳＶ形式のデータを埋め込むようなもの」とした。例えば、ＸＭＬデータの定義情報を変更し、１カ月分のＸＭＬデータを日付順にコンマで区切ってまとめている。
具体的には、
〈ＫＯＵＳＵ  ｄａｙ＝”０１”〉８．０〈／ＫＯＵＳＵ〉〈ＫＯＵＳＵ  ｄａｙ＝”０２”〉５．５〈／ＫＯＵＳＵ〉…〈ＫＯＵＳＵ  ｄａｙ＝”３１”〉１２．８〈／ＫＯＵＳＵ〉
というように、別々のタグに記述されていた毎日の実績に関するデータを、
〈ＫＯＵＳＵ  ｄａｙ＝”０１、０２、…、  ３１”  ｄａｔａ＝”８．０、５．５、…、  １２．８”〉〈／ＫＯＵＳＵ〉
といった形式で、月単位にまとめるように、元の文書を書き換えている。
このような変更により、１ヶ月分のデータを参照する際には、データベース・サーバーへの照会は１回で済むようになり、ＸＭＬの定義情報の送信も１回送信するだけなので、データ容量も１０分の１に減ったとしている。
また、非特許文献２には、データ量を減らすことを目的とし、レコード形式のＸＭＬ文書を、ＸＭＬ文書の規格を保ったまま、ＸＳＬ変換を用いて、レコード単位にレコード内の全要素をＣＳＶ形式で繋いだＸＭＬ文書に変換することが開示されている。データ処理の負荷を減らすためには、レコード内全要素を１個のＣＳＶ形式に纏めた文書を、専用のＡＰＩによって扱うことを意図している。
具体的には、非特許文献２の手法による変換前・後のＸＭＬ文書は、例えば、図４６（ａ）、（ｂ）に示すようになる。図４６（ａ）は、変換前の元のＸＭＬ文書であり、図４６（ｂ）は、変換後のＸＭＬ文書である。
図示の通り、変換後のＸＭＬ文書は、２つの部分に分けられる。１つは、元のＸＭＬ文書の各タグ名を記述する部分、もう１つは、各要素の内容（１，２，３，４等）をＣＳＶ形式で繋いで記述した部分である。
ところで、ここで、代表的な構造化文書であるＸＭＬ文書では、何らかの応用ソフトがＸＭＬ文書を扱えるようにするために（検索・更新・削除などの操作を施す）、ＤＯＭ（Ｄｏｃｕｍｅｎｔ  ｏｂｊｅｃｔ  Ｍｏｄｅｌ）と、ＳＡＸ（Ｓｉｍｐｌｅ  ＡＰＩ  ｆｏｒ  ＸＭＬ）と呼ばれる二つの標準的なインターフェイス（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）規格が定められている。ＳＡＸは、メモリ消費が小さく、一般に高速だが、時系列出力で、参照するだけの簡単な処理に向くという特徴を持つ。一方、ＤＯＭは、一般に低速で、メモリ消費が大きいが、文書の要素を階層的なツリー構造に展開するため、複雑な処理内容でもプログラムが組み易いという特徴を持つ。
一般に、ＸＭＬ文書に対して検索・更新・削除などの操作を施す場合、操作対象のＸＭＬ文書を標準ＡＰＩ（ＤＯＭ）でＤＯＭツリーに展開してから、その操作を施すことになる。しかし、ＸＭＬ文書をＤＯＭツリーに展開する際には、元のデータ量の６倍もの膨大な動作メモリ容量が必要となるうえ、使用されない項目（操作対象外の項目）も一緒に展開されてしまうため、展開処理に多大な時間を要している（処理速度、メモリ消費量は、ＸＭＬ文書の要素数に比例する）。
上記非特許文献１，２のような、ＸＭＬ文書を加工して処理性能の向上を図る手法が存在するのは、このような事情があるからである。
しかしながら、上記非特許文献１，２には、以下の問題点があった。
まず、非特許文献１に記載の手法は、データ依存の個別の方法であり、組織的な汎用の方法ではない。すなわち、非特許文献１記載の手法は、データ処理に用いる同種のデータを一つにまとめるものであって、同種のデータを持つ特定のデータに適用する方法であり、改善の効果はデータに依存する。つまり、汎用の方法ではない。
また、非特許文献２に記載の手法は、ＸＭＬ文書のタグを外すことによって、データ量は削減できるが、この方法によって既存の応用ソフトのデータ処理の負荷を軽減することはできない。
非特許文献２では、変換文書を扱える特別なＡＰＩソフトを作って、データ処理の負荷を軽減することを想定している。これは、既存のＤＯＭソフトと同様の機能のソフトを別途作成しなければならないことを意味する。この為、この作業は多大の工数を要する。よって、既存のＤＯＭと同様に使われる状況にはなり難い。
また、非特許文献２に記載の手法は、定型（表形式）のＸＭＬ文書のみを想定している。
このような従来技術に対して、本出願の発明者は、非特許文献３の手法を提案している。
非特許文献３に記載の手法は、まず、レコード構成のＸＭＬ文書に対してＤＯＭ応用ソフトでのデータ処理性能を改善するためであって、応用ソフトにわずかな修正で適用できて（特別なソフトを書かずに変換が実行できる）、変換後に基本的に元のＸＭＬ文書と同様（トランスペアレント）に扱える形式を目指している。そして、レコード毎に、応用ソフトで処理対象とする要素はそのままにして、処理対象外の複数の要素は、その要素内容をＣＳＶ形式で１つにまとめたＸＭＬ文書に変換することを特徴としている。また、非表形式のデータを表現したＸＭＬ文書に関しては、レコード内に出現する要素が不定であるため、変換ＸＭＬ文書上に、処理非対象の要素名を保持して、要素内容と対応付ける必要があるために、ＣＳＶ形式の要素内容と同じ並び順で、処理非対象要素名をＣＳＶ形式で繋いで、変換先ＣＳＶ形式の要素の属性として置くことを提案している。
【非特許文献１】  「見えてきた万能幻想の真実ＸＭＬの″常識″を覆す」、日経コンピュータ誌２００１．３．１２号、ｐ５２−ｐ７１
【非特許文献２】  “Ｂｕｉｌｄｉｎｇ  ａｎ  ＸＭＬ  Ｂｌｏａｔ  Ｂｕｓｔｅｒ  ｕｓｉｎｇ  ＺＸＭＬ  ＸＭＬ  Ｃｏｍｐｒｅｓｓｉｏｎ  Ｍｅｔｈｏｄ”ｂｙ  Ａｌａｉｎ  Ｔｒｏｔｔｅｒ；［平成１４年２月１８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ＡＳＰＴｏｄａｙ．ｃｏｍ／＞  または、概要として＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ＸＭＬ．ｃｏｍ／ｐｕｂ／ｒ／９０４＞
【非特許文献３】  「ＸＭＬ文書の事前形式変換によるデータ処理性能改善の検討」、吉田茂、他；第１回情報科学技術フォーラム（ＦＩＴ２００２）Ｄ−２９、２００２．０９．２７
ここで、本出願人は、非特許文献３に関連して、既に、特願平１３−４０１９３４号（以下、先出願と呼ぶ）を出願している。
先出願においても、非特許文献３と同様に、レコード形式のＸＭＬ文書においてレコード内要素が、応用ソフトのデータ処理の対象項目（キー要素）と、非対象項目（非キー要素）に分けられて、変換の際には、キー要素はそのままにし、非キー要素の内容をＣＳＶ形式で纏めて新たな一つの要素（ＣＳＶ要素と呼ぶ）とするＸＭＬ文書に変換することを提案している。ＸＭＬ文書が非定型の場合は、新要素に纏めた要素の要素名をＣＳＶ形式にしたものを属性に付ける。この変換（以下では、ＣＳＶ圧縮変換と呼ぶ）は、ＸＳＬ変換として実行する。
このＣＳＶ圧縮変換は、データ処理の対象項目であるキー要素は、ＣＳＶ形式にはしないで、そのままとするので、応用ソフトに僅かな修正を施すだけで適用可能となる。また、非キー要素のタグを削除して、その要素内容を一つの新要素に纏めることで、元文書のタグを減らした要素数に応じて、ＸＭＬ文書処理のメモリ使用量の削減、メモリ展開時間、処理時間を短縮することができる。
例えば、図４７には定型ＸＭＬ文書の場合、図４８に非定型ＸＭＬ文書の場合の変換前／後のＸＭＬ文書、及び変換仕様の一例を示す。
図４７（ａ）には変換前の定型ＸＭＬ文書の例、図４７（ｂ）にはその変換結果、図４７（ｃ）にはこの変換に用いる変換仕様の一例を示す。
この例では、「名前」と「会社」をキー要素とし、それ以外の非キー要素の要素内容は、変換後の文書では、新要素「情報」にＣＳＶ形式で纏めている。
また、図４８（ａ）には変換前の非定型ＸＭＬ文書の例、図４８（ｂ）にはその変換結果、図４８（ｃ）にはこの変換に用いる変換仕様の一例を示す。
この例では、変換後の文書では、各レコード毎（Ａさん、Ｂさん）に、そのレコードに記述されている非キー要素の要素名を、新要素のタグにおいて属性ｔａｇｓによって指定している。これによって、変換後のＸＭＬ文書を用いて、応用ソフトウェアが何らかの処理を実行する際にも、要素名と要素内容との対応関係が分かる。
上記のように、非特許文献３、先出願では、特に応用ソフトウェアが変換後のＸＭＬ文書を処理することに関して、従来に比べて優れた手法を提案している。また、従来では、非定型のＸＭＬ文書に対応する手法は、全く考えられていなかった。
しかしながら、先出願に記載の手法には、未だ、以下に記す（ａ）〜（ｃ）の改良の余地が残っている。
（ａ）応用ソフトにおける扱い易さについて
先出願では、非キー要素は、応用ソフトで使わない要素を想定していた。しかし、キー要素／非キー要素を明確に区別できない応用ソフトも多く、非キー要素と定義した場合であっても、変換後に、この非キー要素の要素内容を応用ソフトで読出し／書込みしたいことが起こる。ＣＳＶ要素の内容が読出せれば、どのＳｃｒｉｐｔ言語でも、ＣＳＶを分離／合併する標準関数（“ｓｐｌｉｔ”、“ｊｏｉｎ”）が用意されているため、展開は容易に行なえる。
しかし、先出願の手法では、このような状況は想定していなかった為、多くの非キー要素をまとめた場合、非キー要素の中の使う要素以外に、不要な要素も一緒に展開して取り出す必要があり、オーバーヘッドが大きくなるという課題が残った。これは、ＣＳＶ形式で纏めた非キー要素の数が多ければ多いほど、オーバーヘッドが大きくなる。これを解決するには、新要素を複数定義し、新要素１つ当りに割り当てる非キー要素を減らすことが考えられる。この点については、先出願においても、例えば先出願の図６〜図８に示すように、２つの新要素「情報１」、「情報２」に、それぞれ、非キー要素をＣＳＶ形式で纏めている。
しかしながら、これは、上記問題を想定したものではなく、タグ名「勤務先」の要素内にある要素は、タグ名「勤務先」の要素内に作成した新要素「情報１」に纏め、それ以外の非キー要素は、レコード内の第１階層に作成した新要素「情報２」に纏めるようにしている。応用ソフトが非キー要素を扱う場合が生じ得ることを想定していないので、「情報１」は元のＸＭＬ文書の階層構造に従って「勤務先」要素の下、すなわちレコード内の第２階層に作成され、「情報２」はレコード内の第１階層に作成される。この為、応用ソフトが非キー要素を扱う場合に、扱い難くなる場合がある。
また、この例では、２つの新要素、すなわち複数の新要素が存在するが、非キー要素の数が非常に多い場合に、その数に応じて、新要素の数を、３つ、４つ、・・・１０以上等とする発想は、先出願にはない。
（ｂ）変換／逆変換後のレコード内の要素順序
先出願に限らず、従来では、変換の際、レコード内の要素の順序は保存されない。この為、変換前の元のＸＭＬ文書と、これを変換後に更に逆変換したＸＭＬ文書とを比較すると、内容的には同一だが、要素の並びが変わってしまって、ユーザから見れば文書が変質したように見え、使い難いという問題があった。
（ｃ）ＸＭＬ文書としての自己記述性の欠如に対応する手法の改善
ＸＭＬ文書は、要素名でデータの意味付けがなされ、それ自身だけで自己記述性を備えている。しかし、従来では、非定型のＸＭＬ文書内にＣＳＶ形式を持ち込むと、この自己記述性が失われてしまい、ＣＳＶ形式で繋いだデータの意味を得るには他のファイルの参照が必要になるという問題があった。
これに対して、先出願では、要素名と要素内容を対応付けるため、ＣＳＶ形式で纏める非キー要素名を含むＰａｔｈを属性で与える非定型文書向けの手法を提案している。つまり、例えば図４８（ｂ）や先出願の図３（Ｂ）に示すように、属性ｔａｇｓによって、非キー要素の要素名を記述している。この方法によれば、非定型文書にも対応可能である。しかしながら、各レコード毎に、それぞれ、非キー要素の全ての要素名を記述するので、特に、レコード数が多い場合、非キー要素の要素数が多い場合、冗長過ぎるという問題がある。
これを回避するため、先出願では非定型文書で用いている非キー要素名を含むＰａｔｈの記述を任意の短縮文字列で表すことも提案している。つまり、先出願の図３（Ｃ）に示すように、各非キー要素に任意の短縮文字列Ａ，Ｂ，Ｃ，・・・を割り当てておき、属性ｔａｇｓによって短縮文字列を記述している。
しかしながら、この方法では、変換文書を応用ソフトで扱えるようにする為には、各非キー要素名と短縮文字列との対応関係を別ファイルに記録しておき、応用ソフトがこの別ファイルを参照しつつ処理を行なう必要がある。
また、逐一対応関係を指定しなければならないので、非キー要素の数が多くなるに従って、指定が煩雑になり、手間が掛かるようになる。
更に、先出願では、そもそも、変換後のＸＭＬ文書に記述する要素名（または短縮文字列）は、逆変換処理の際に必要なものであった。
本発明の課題は、レコード内の要素を、応用ソフトで扱うキー要素と、それ以外の非キー要素に分けて、キー要素はそのままとし、非キー要素はＣＳＶ形式で繋ぐように変換することで、変換後のＸＭＬ文書を既存の応用ソフトで利用可能とすると共に、汎用の方法としてデータ処理のメモリ使用量、処理時間を削減することができると共に、更に、応用ソフトで非キー要素を扱う事態が生じた場合でもオーバーヘッドが大きくなることなく、あるいは逆変換結果が、並び順までも元のＸＭＬ文書の通りに戻すことができ、あるいは非定型文書においてレコード数が多い場合／非キー要素の要素数が多い場合でも、冗長になることなく、変換後でも自己記述性を維持できるようにする構造化文書変換／逆変換方法、その装置、プログラム等を提供することである。
【発明の開示】
本発明による第１の構造化文書の構造変換装置は、定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内の各要素について、レコード内で出現する順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である各非キー要素を、前記複数の新要素の何れに割り当てるかを定義した変換仕様定義手段と、該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段とを有するように構成する。
上記構成において、変換対象の構造化文書内の各要素を、キー要素／非キー要素に分けて、非キー要素の要素内容はＣＳＶ形式、すなわち要素内容を区切り記号を介して繋げてまとめることにより、汎用の方法としてデータ処理のメモリ使用量、処理時間を削減することができると共に、応用ソフトウェアがキー要素を用いて検索等の処理を行なえる点は、先出願と同様である。
上記第１の構造化文書の構造変換装置では、更に、新要素を複数定義して、各非キー要素を、各新要素の何れかに自由に割り当てている。新要素の数は、非キー要素の数に応じたものとすればよい。これによって、新要素１つ当りに割り当てられる非キー要素の数を抑制し、もし応用ソフトウェアが非キー要素を扱う事態が生じても、オーバーヘッドが大きくなることを抑止できる。また、変換対象の構造化文書内の階層構造に関係なく自由に変換できるので、応用ソフトウェアの処理内容に合わせて、変換後の構造化文書が応用ソフトウェアで扱い易いように定義すればよい。更に、変換仕様定義手段における変換対象の構造化文書内の各要素の定義は、レコード内で各要素が出現する順に定義しているので、逆変換の際に、この変換仕様定義手段を参照して、定義されている順番通りに処理を行なえば、要素の並びが変わってしまうことなく、完全に元通りに復元することができる。
本発明による第２の構造化文書の構造変換装置は、非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義し、変換対象の構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、該複数の新要素の何れに割り当てるかを定義した変換仕様定義手段と、該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、前記変換対象の構造化文書に出現する要素はその要素内容を、前記変換対象の構造化文書に出現しない要素の要素内容は空要素として、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段とを有するように構成する。
また、上記第２の構造化文書の構造変換装置において、例えば、前記変換仕様定義手段で定義される変換仕様に基づいて前記変換後の構造化文書を元の構造化文書に戻すために、該変換仕様定義手段において前記出現順に定義されている各要素について、順次、その要素に該当する新要素を求め、該新要素について前記ＣＳＶ形式でまとめた各要素内容の中から、その順番に応じて該要素に対応する要素内容を求めて前記元の構造化文書に記述する際に、該要素内容が前記空要素である要素は記述しない逆変換手段を更に有するように構成してもよい。
上記第２の構造化文書の構造変換装置によれば、変換対象の構造化文書が、非定型の構造化文書である場合でも、第１の構造化文書の構造変換装置と同様の効果が得られるようにできる。更に、変換対象の構造化文書が、非定型の構造化文書であるにも係わらず、変換後の構造化文書に非キー要素の要素名を記述しなくても、問題なく、逆変換できる。その為に、上記構成では、変換仕様定義手段における変換対象の構造化文書のレコード内の各要素の定義は、レコード内に出現し得る全ての要素について、レコード内で各要素が出現する順に定義し、この順番通りに変換／逆変換処理すると共に、各レコード毎に、そのレコードでは出現しなかった要素は、変換の際には要素内容を空要素として出力し、逆変換時には空要素である要素は出力しないようにする。
更に、上記第２の構造化文書の構造変換装置において、前記構造変換手段は、更に、前記新要素毎に、その新要素内に要素内容を記述し得る全ての要素の要素名をＣＳＶ形式でまとめたものを、付加情報として変換後の構造化文書に記述するように構成してもよい。
これによって、応用ソフトウェアで非キー要素を処理対象とする事態が生じた場合でも、付加情報を参照することで、要素内容と要素名との対応関係が分かると共に、上記空要素の要素は、そのレコードには記述されていないことが分かる。先出願では、各レコード毎に、要素名または短縮文字列を記述していたが、本発明では、例えばヘッダ等に一度、付加情報を記述しておけばよく、各レコード毎に逐一記述する必要なく、上記対応関係が分かるようにしている。
本発明による第３の構造化文書の構造変換装置は、非定型の構造化文書に対応して、変換後の構造化文書における新要素を複数定義すると共に、該各新要素毎にその新要素が非定型要素であるか否かを指定し、変換対象の構造化文書内の各要素について、該構造化文書内に出現し得る全ての要素について、全て出現する場合の出現順に、データ処理の対象となるキー要素であるか否かを指定すると共に、該キー要素以外の要素である非キー要素を、前記複数の新要素の何れに割り当てるかを定義する変換仕様定義手段と、該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書内の各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、前記新要素毎に、該新要素が前記非定型要素ではない場合には出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容として変換後の構造化文書に記述し、該新要素が前記非定型要素である場合には、出現した要素の要素内容を出現順にＣＳＶ形式でまとめたものを該新要素の要素内容とすると共に該出現順番をＣＳＶ形式でまとめたものを該新要素のタグの属性値として変換後の構造化文書に記述する構造変換手段とを有するように構成する。
また、例えば、上記第３の構造化文書の構造変換装置において、前記構造変換手段は、更に、前記新要素毎に、その新要素内に要素内容を記述し得る全ての要素の要素名をＣＳＶ形式でまとめたものを、付加情報として変換後の構造化文書に記述するように構成してもよい。
上記構成の第３の構造化文書の構造変換装置によれば、上記第２の構造化文書の構造変換装置とほぼ同様の効果が得られる。手法として異なる点は、その要素がレコード内に出現するか否かを、出現しなかった場合は空要素とするのではなく、実際に出現した要素の出現順番を記述する点である。出現順番が記述されていない要素は、そのレコード内に出現しなかったことを意味する。
本発明による第４の構造化文書の構造変換装置は、レコードの種類毎にそのレコードを構成する要素が異なる非定型の構造化文書に対応して、レコードの種類毎にレコード項目リストを定義するものであって、該各レコード項目リストは、そのレコード種類に出現し得る全ての要素について、データ処理の対象となるキー要素であるか否かを指定すると共に、変換後の構造化文書における新要素を１以上定義して、前記キー要素以外の要素である非キー要素を、どの新要素に割り当てるかを指定する変換仕様定義手段と、該変換仕様定義手段によって定義される変換仕様に基づいて前記変換対象の構造化文書から変換後の構造化文書を作成するために、該変換対象の構造化文書中の各レコード毎に、そのレコードの種類に応じたレコード項目リストを前記変換仕様定義手段から選択し、該選択したレコード項目リストに基づいて、前記レコード内の各要素をレコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述する構造変換手段とを有するように構成する。
上記構成の第４の構造化文書の構造変換装置によれば、変換仕様定義手段において、レコードの種類ごとに入れ替わるレコード項目（要素）をそれぞれ分けて定義すると共に、切り替え条件を付けることによって、変換／逆変換時にその条件によって要素並びを切り替えることで、変換後の構造化文書には無駄な記述が含まれないようになると共に、非定型要素の無駄な有無チェックを行わなくて済む為、変換／逆変換処理の高速化を図れる。
なお、上述した本発明の各構成により行なわれる機能と同様の制御をコンピュータに行なわせるプログラムを記憶したコンピュータ読み取り可能な記憶媒体から、そのプログラムをコンピュータに読み出させて実行させることによっても、前述した課題を解決することができる。つまり、本発明は、このようなプログラム自体としても構成することができるし、当該プログラムを記録した記録媒体（特に可搬型記録媒体）として構成することもできる。
【図面の簡単な説明】  本発明は、後述する詳細な説明を、下記の添付図面と共に参照すればより明らかになるであろう。
図１（ａ）〜（ｃ）は、ＤＯＭ上でのメモリ展開形式を、本発明と従来とを比較して説明する為の図である。
図２は、本例の構造化文書変換方法をコンピュータ等で実行する処理全体の概略的な流れを示す図である。
図３は、第１の実施例で変換対象となる定型ＸＭＬ文書の一例を示す図である。
図４は、第１の実施例で用いる変換仕様ＸＭＬ文書の一例を示す図である。
図５は、第１の実施例における変換ＸＭＬ文書の一例を示す図である。
図６は、定型ＸＭＬ文書に対する構造変換処理の基本的な処理フローチャート図である。
図７は、ＸＭＬ文書に対する構造変換処理の基本的な処理フローチャート図である。
図８は、変換処理における図６のステップＳ１７または図７のステップＳ２８の処理の詳細フローチャート図である。
図９は、逆変換処理におけるステップＳ１７の詳細フローチャート図である。
図１０は、第２、第３の実施例において入力ＸＭＬ文書となる非定型ＸＭＬ文書の一例を示す図である。
図１１は、第２の実施例における変換仕様ＸＭＬ文書の一例を示す図である。
図１２は、図１０の非定型ＸＭＬ文書を、図１１に変換仕様ＸＭＬ文書を用いて構造変換して成る変換ＸＭＬ文書の一例を示す図である。
図１３は、第２の実施例の構造変換処理における「レコード内の要素の処理」の詳細フローチャート図である。
図１４は、第２の実施例の逆変換処理における「レコード内の要素の処理」の詳細フローチャート図である。
図１５は、第３の実施例における変換仕様ＸＭＬ文書の一例を示す図である。
図１６は、図１０の非定型ＸＭＬ文書を、図１５に変換仕様ＸＭＬ文書を用いて構造変換して成る変換ＸＭＬ文書の一例を示す図である。
図１７は、第３の実施例の構造変換処理における「レコード内の要素の処理」の詳細フローチャート図である。
図１８は、第３の実施例の逆変換処理における「レコード内の要素の処理」の詳細フローチャート図である。
図１９（ａ）〜（ｄ）は、第１の実施例において、変換／逆変換ＸＳＬシートを用いる場合の概略的な処理手順を示す図である。
図２０は、図４に示す例の変換仕様ＸＭＬ文書を読み込んだ場合に生成される変換ＸＳＬシートの一例を示す図である。
図２１は、図４に示す例の変換仕様ＸＭＬ文書を読み込んだ場合に生成される逆変換ＸＳＬシートの一例を示す図である。
図２２は、変換仕様ＸＭＬ文書を作成する手順を説明する為の図である。
図２３は、応用ソフトウェアのプログラムの一例を示す図である。
図２４は、応用ソフトウェアのプログラムの一例を示す図である。
図２５は、レコードの種類によってレコード項目が異なるタイプの非定型ＸＭＬ文書の一例を示す図である。
図２６は、図２５の非定型ＸＭＬ文書に対して第２の実施例を適用した場合の変換仕様ＸＭＬ文書の例を示す図である。
図２７は、図２５と図２６の例に対応する変換ＸＭＬ文書を示す図である。
図２８は、第４の実施例（その１）による変換仕様ＸＭＬ文書の例を示す図である。
図２９は、図２８の変換仕様ＸＭＬ文書を用いて作成する変換ＸＳＬシートの一例を示す図（その１）である。
図３０は、図２８の変換仕様ＸＭＬ文書を用いて作成する変換ＸＳＬシートの一例を示す図（その２）である。
図３１は、第４の実施例（その１）による変換ＸＭＬ文書の例を示す図である。
図３２は、図２８の変換仕様ＸＭＬ文書を用いて作成する逆変換ＸＳＬシートの一例を示す図（その１）である。
図３３は、図２８の変換仕様ＸＭＬ文書を用いて作成する逆変換ＸＳＬシートの一例を示す図（その２）である。
図３４は、第４の実施例（その２）による変換仕様ＸＭＬ文書の例を示す図である。
図３５は、図３４の変換仕様に基づく変換／逆変換処理を示すフローチャート図である。
図３６は、変換処理における図３５のステップＳ３０２の詳細フローチャート図（その１）である。
図３７は、変換処理における図３５のステップＳ３０２の詳細フローチャート図（その２）である。
図３８は、逆変換処理における図３５のステップＳ３０２の詳細フローチャート図（その１）である。
図３９は、逆変換処理における図３５のステップＳ３０２の詳細フローチャート図（その２）である。
図４０（ａ）、（ｂ）は、図３４の変換仕様に基づく変換／逆変換ＸＳＬシートの作成処理フローチャート図である。
図４０（ｃ）、（ｄ）は、これら変換／逆変換ＸＳＬシートを用いた変換／逆変換処理フローチャート図である。
図４１は、図４０（ａ）によって作成される変換ＸＳＬシートの一例を示す図である。
図４２は、図４０（ｂ）によって作成される逆変換ＸＳＬシートの一例を示す図である。
図４３は、図３４の変換仕様ＸＭＬ文書の作成方法を説明する為の図である。
図４４は、構造化文書変換方法を実現するコンピュータのハードウェア構成の一例を示す図である。
図４５は、プログラム等を記録した記録媒体、ダウンロードの一例を示す図である。
図４６（ａ）は、従来例における変換前の元のＸＭＬ文書であり、図４６（ｂ）はその変換後のＸＭＬ文書である。
図４７（ａ）は、先出願における変換前の定型ＸＭＬ文書の例、図４７（ｂ）はその変換結果、図４７（ｃ）はこの変換に用いる変換仕様の一例を示す図である。
図４８（ａ）は、先出願における変換前の非定型ＸＭＬ文書の例、図４８（ｂ）はその変換結果、図４８（ｃ）はこの変換に用いる変換仕様の一例を示す。
【発明を実施するための最良の形態】  以下、図面を参照して、本発明の実施の形態について説明する。
以下、本発明の実施の形態について詳細に説明する。
まず、図１（ａ）〜（ｃ）は、本発明の特徴の１つを、従来技術、先出願と比較して説明する為の図である。
図１（ａ）〜（ｃ）には、ＸＭＬ文書をメモリ上にＤＯＭツリーとして展開した例を示す。
図１（ｃ）には、本例による構造化文書変換方法によるＤＯＭ上でのメモリ展開形式を示す。また、比較のために、図１（ａ）には従来のＤＯＭ展開形式を示し、図１（ｂ）には先出願のＤＯＭ展開形式を示す。尚、図１（ａ）〜（ｃ）には、１つのレコード（タグ名“個人”）のみ示しているが、実際には、多数のレコードが存在する。
図１（ａ）に示すように、従来では、異種のデータを扱う場合には、データ処理に使わない要素も含め全要素をメモリ上に展開する。この為、大量に動作メモリを消費し、処理速度も遅くなる。
これに対して、上記非特許文献１のように同種のデータを一つにまとめてＣＳＶ形式で繋ぐ方法や、上記非特許文献２のように、定型ＸＭＬ文書を想定して、そのレコード内全要素を１個のＣＳＶ形式に纏める方法等も提案されている。
しかしながら、上述してある通り、従来では、変換後のＸＭＬ文書を用いて、応用ソフトウェアが何らかの処理を行なう場合については、何ら対応していない。また、非定型のＸＭＬ文書には、何ら対応していない。
一方、図１（ｂ）に示すように、先出願では、レコード内の各要素を、応用ソフトのデータ処理の対象項目（キー要素）と、非対象項目（非キー要素）に分けて、キー要素はそのままにし、非キー要素の要素内容をＣＳＶ形式で各新要素に纏めたＸＭＬ文書に変換する。尚、図１（ｂ）、（ｃ）に示す例では、タグ名“名前”、“会社”の要素がキー要素であったものとする。
この方法によれば、非キー要素は、全て、タグを外して、その要素内容をＣＳＶ形式で纏めて各新要素にまとめているので、メモリ上に展開されるツリーの子要素の数を大幅に減らすことができ、展開時やデータ処理時に非キー要素を一括して扱うことができる。ツリーの子要素とは、例えば図１（ａ）における“部署”、“電話”、“ｅｍａｉｌ”、“自宅住所”、“Ｆａｘ”等のタグ名である。
そして、更に、応用ソフトウェアが、この変換後のＸＭＬ文書を用いて何らかの処理を行なう際には、キー要素を用いて、例えば検索処理等を実行することができる。
しかしながら、先出願では、上記の通り、「非キー要素は、応用ソフトで使わない要素である」という前提が崩れる状況を想定していなかったので、応用ソフトウェアが非キー要素を扱い易いようにはなっていない。つまり、既に説明してあるが、図１（ｂ）に示すように、ＣＳＶ要素「情報１」は元のＸＭＬ文書の階層構造に従って「勤務先」要素の下、すなわちレコード内の第２階層に作成され、ＣＳＶ要素「情報２」はレコード内の第１階層に作成される。そして、各ＣＳＶ要素に含まれる非キー要素も、元のＸＭＬ文書の構造通りとなっている。この為、応用ソフトが非キー要素を扱う場合に、扱い難くなる場合がある。少なくとも、応用ソフトウェアで非キー要素を扱い易い構造とすることは想定していない。
また、任意の非キー要素を処理対象とする際に、ＣＳＶ要素を展開する場合、非キー要素の数が多いと、オーバーヘッドが大きくなることに、十分に対応してはいなかった。
これに対して、図１（ｃ）に示すように、本例の構造変換／逆変換手法では、複数のＣＳＶ要素を定義すると共に、元のＸＭＬ文書の階層構造に関係なく、複数のＣＳＶ要素を全てレコード内の第１階層に配置する。更に、図には表われていないが、各非キー要素を、どのＣＳＶ要素に含めるのかを、元のＸＭＬ文書に関係なく、自由に定義することができる。但し、自由にできるにしても、応用ソフトウェアの内容に準じて、応用ソフトウェアが扱い易い形とすることが望ましい。また、これも図には表われていないが、ＣＳＶ要素の数は、非キー要素の数に応じて、非キー要素数が多い場合には、ＣＳＶ要素の数も多くすることが望ましい。
このように、本発明では、非キー要素を処理対象とする場合でも、応用ソフトウェアが扱い易い形にすることができ、また、非キー要素数が多い場合でも、該当するＣＳＶ要素を展開する際のオーバーヘッドが大きくなることはない。
尚、これは、本例の構造化文書変換方法の特徴の１つであり、本例による構造化文書変換方法には、他にも、後述するように、様々な特徴がある。
例えば、変換対象のＸＭＬ文書が、非定型ＸＭＬ文書である場合、先出願では図１（ｂ）に示すように、属性ｔａｇｓによって、各ＣＳＶ要素にＣＳＶ形式で纏めた各要素内容に対応するタグ名を記述していたが、これは各レコード毎に逐一記述するので、特にレコード数が多い場合、問題となる。これに対して、本発明では、図１（ｃ）に示すように、出現し得る全ての要素のタグ名を、まとめてヘッダに付加情報として記述することで、この問題に対応できるが、詳しくは後に説明する。
図２に、本例の構造化文書変換方法をコンピュータ等で実行する処理全体の概略的な流れ及びその構成を示す図である。
本例の構造化文書変換方法は、後述するように、定型ＸＭＬ文書の場合と、非定型ＸＭＬ文書の場合（これは、２つのタイプについてそれぞれ２つの手法を提案する）について、第１〜第４の実施例として説明しているが、図２に示す処理全体の概略的な流れ及び構成は、共通である。
図２において、データ構造変換／逆変換機構１０は、構造変換部１１、逆変換部１２、ＸＳＬ変換部１３を有する。データ構造変換／逆変換機構１０は、入力ＸＭＬ文書２１と、変換仕様ＸＭＬ文書２２を入力して、変換ＸＭＬ文書２３を出力する（変換）。また、抽出ＸＭＬ文書２４を入力して、結果ＸＭＬ文書２５を出力する（逆変換）。
入力ＸＭＬ文書２１は、変換対象のＸＭＬ文書である。
変換仕様ＸＭＬ文書２２は、変換／逆変換の為の変換仕様を与えるＸＭＬ文書である。すなわち、多様な種類のＸＭＬ文書に対して、各ＸＭＬ文書に応じたスタイルシート、すなわちＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）シートをいちいち作成するのは、極めて面倒で手間が掛かるものである。そこで、この手間を省く為に、本例では（先出願と同様）、ＸＭＬ文書のデータ構造を変換するための仕様を記述したＸＭＬ文書、すなわち変換仕様ＸＭＬ文書２２を作成しておく。
構造変換部１１は、この変換仕様ＸＭＬ文書２２によって与えられる変換仕様に基づいて、入力ＸＭＬ文書２１を、変換ＸＭＬ文書２３へと変換し、逆変換部１２は、抽出ＸＭＬ文書２４を、結果ＸＭＬ文書２５へと逆変換する。また、このように変換仕様に基づいて、直接、変換／逆変換処理を実行する方法でもよいが、特に、大量のデータを変換するときに、レコードごとに変換仕様を読み取って判断する処理が必要となる。
これに対して、ＸＳＬ変換部１３が、変換仕様ＸＭＬ文書２２と、変換ＸＳＬシート生成ＸＳＬシート１４（先出願における自動変換スタイルシート）とに基づいて、変換実行手順を指示する変換ＸＳＬシート１５（データ構造変換用スタイルシート）と、逆変換実行手順を指示する逆変換ＸＳＬシート１６（逆変換用スタイルシート）を生成する。尚、変換ＸＳＬシート生成ＸＳＬシート１４は、厳密には、変換ＸＳＬシート１５生成用のものと、逆変換ＸＳＬシート１６生成用のものとがあるが、ここでは特に区別せずに扱うものとする。
そして、構造変換部１１または逆変換部１２が、これら生成したＸＳＬシート１５または１６を用いて、変換処理または逆変換処理を実行するようにしてもよい。一度、ＸＳＬシート１５、１６を生成してから変換／逆変換をすることによって、大量のデータを変換するときにレコードごとに変換仕様を読み取って判断する操作が不要になるため、高速で実行することができるようになる。
また、このように変換／逆変換の実行手順をスタイルシートで与えるようにすれば、標準のＸＳＬＴプロセッサで変換／逆変換を実行することができ、ほとんどあらゆる種類のＸＭＬ文書システムにおいて、本例による変換／逆変換処理を実行できる。この場合、データ構造変換／逆変換機構１０（構造変換部１１、逆変換部１２、ＸＳＬ変換部１３）は、実際には、例えば１つの標準のＸＳＬＴプロセッサ（構造化文書変換プロセッサ）によって実現される。
また、変換ＸＭＬ文書２３が、応用ソフト３０によって、メモリ上でＤＯＭツリーに展開されて、何らかの処理、例えばタグ検索によって、変換ＸＭＬ文書３０の一部分のレコードが取り出され、ＸＭＬ文書に直された結果が、抽出ＸＭＬ文書２４である。そして、抽出ＸＭＬ文書２４を逆変換して元の状態に戻したものが、結果ＸＭＬ文書２５である。
上述してある通り、図２に示す処理全体の概略的な流れ、構成自体は共通であるが、本例では４つの実施例の処理を提案している。以下、変換対象が定型ＸＭＬ文書の場合を第１の実施例、非定型ＸＭＬ文書の場合であって、１つめの手法を第２の実施例、２つめの手法を第３の実施例として説明する。また、他のタイプの非定型ＸＭＬ文書に係わる２つの手法を、第４の実施例として説明する。
以下、まず、第１の実施例について説明する。
第１の実施例で変換対象となる定型ＸＭＬ文書とは、例えば表形式のデータのように、レコード内の要素数、タグ名が固定であるＸＭＬ文書であり、その一例を図３に示す。これが、入力ＸＭＬ文書２１に相当する。また、図３に示す定型ＸＭＬ文書に対応する変換仕様ＸＭＬ文書２２の一例を、図４に示す。また、図３に示す定型ＸＭＬ文書を、図４に示す変換仕様ＸＭＬ文書２２を用いて、構造変換部１１によって変換してなる変換ＸＭＬ文書２３の一例を、図５に示す。
定型ＸＭＬ文書は、図３に示す例では２つのレコードのみ示しているが、通常はもっと多くのレコードが存在している。また、図３に示す例では、各レコード（タグ名“個人”）は、レコード内が２階層から成っており、会社情報と個人情報とに分けているが、この例に限るわけではない。１階層であってよいし、３階層以上であってもよい。
図３において、各レコードは、タグ名“名前”、“会社情報”、“個人情報”の要素を１つずつ有している。更に、タグ名“会社情報”の要素は、タグ名“会社”、“部署”、“電話”、“ｅｍａｉｌ”の要素を有する階層構造となっている。同様に、タグ名“個人情報”の要素は、タグ名“自宅住所”、“自宅電話”、“携帯電話”の要素を有する階層構造となっている。定型ＸＭＬ文書であるので、図示の２つのレコードに限らず、全てのレコードは、同じ構造となっている。
また、図４に示す変換仕様ＸＭＬ文書２２の一例では、まず、タグ名「ｒｅｃｏｒｄ」の要素の要素内容として、変換対象とするレコード名を記述する。その次には、タグ名「ｉｔｅｍｓ」内の要素として、タグ名「ｍｅｒｇｉｎｇ＿ｔａｇ」の要素と、タグ名「ｉｔｅｍ」の要素を記述している。
タグ名「ｍｅｒｇｉｎｇ＿ｔａｇ」の要素の要素内容には、ＣＳＶ要素名（ＣＳＶ要素のタグ名）を記述する。タグ名「ｍｅｒｇｉｎｇ＿ｔａｇ」の要素内容、すなわちＣＳＶ要素名は、入力ＸＭＬ文書２１の構造に関係なく、自由に、複数定義できる。
本例では、先出願と同様に、変換の際には、キー要素はそのままにし、非キー要素の内容をＣＳＶ形式で纏めて新たな要素（これをＣＳＶ要素と呼ぶ）として変換ＸＭＬ文書を作成するが、本例においては、入力ＸＭＬ文書２１の構造に関係なく、自由に複数のＣＳＶ要素を定義できるので、応用ソフト３０で扱い易いように定義できる。また、ＣＳＶ要素の数には、特に上限を設けないので、非キー要素の数が多い場合には、これに応じて、ＣＳＶ要素の数を増やすことで、１つのＣＳＶ要素当りにＣＳＶ形式で纏める非キー要素の数を抑制できるので、応用ソフト３０が任意の非キー要素を処理対象とする場合でも、該当するＣＳＶ要素のみを展開する際に、その非キー要素の数は多くないので、オーバーヘッドが大きくなることはない。
図示の例では、２つのＣＳＶ要素のタグ名、すなわち「情報１」と「情報２」を定義しているが、これは、この例では、非キー要素の数がそれほど多くない為であり、非キー要素の数が多ければ、ＣＳＶ要素の数を増やせばよい。
次に、タグ名「ｉｔｅｍ」の要素は、変換対象のＸＭＬ文書においてレコードに記述される各要素のタグ名を、要素内容として記述している。
尚、紛らわしいので、以下、“タグ名「ｉｔｅｍ」の要素”等という表現は、“「ｉｔｅｍ」要素”または“要素「ｉｔｅｍ」”という表現に改める。
また、“「ｉｔｅｍ」要素”の要素内容である“変換対象のＸＭＬ文書においてレコードに記述される各要素のタグ名”を、特に“要素名”と呼ぶものとする。
各「ｉｔｅｍ」要素は、図上の上から順に、レコード内で出現する要素の順番通りに、その要素の変換仕様を定義している。
まず、図示の通り、要素名は、レコード内で出現する要素の順番通りのタグ名となっている。例えば最初の「ｉｔｅｍ」要素の要素名は、変換対象のＸＭＬ文書のレコード内で最初に出現する要素のタグ名である「名前」となっている。これによって、逆変換時に当該変換仕様に基づいて、変換後のＸＭＬ文書の内容を元に戻す際に、各要素を元の文書と同じ順番に並べて出力するようになる。
また、各「ｉｔｅｍ」要素には、そのタグ内に所定の属性「ｍｔａｇ」を付与している。これは、各「ｉｔｅｍ」要素が、その要素内容、すなわち上記“要素名”を、どのＣＳＶ要素に格納するのかを、属性「ｍｔａｇ」で指定する。但し、ｍｔａｇ＝“＿ＯＲＧ”と指定されている場合には、その要素名の要素がキー要素であることを意味する。図示の例では、応用ソフト３０において変換後のＸＭＬ文書を用いて検索処理をする際に、要素「名前」と要素「会社名」をキーにして検索する場合を想定して、変換仕様の「ｉｔｅｍ」要素において要素名“名前”と“会社名”の要素がキー要素である旨を属性「ｍｔａｇ」“＿ＯＲＧ”によって指定している。また、各要素名の要素のレコード内の階層を「ｐａｔｈ」属性で指定する。
また、上記キー要素以外の要素である非キー要素に関しては、図示の例では、ＣＳＶ要素「情報１」については、非キー要素“部署”、“電話”、“ｅｍａｉｌ”（何れも「ｐａｔｈ」属性は“会社情報”が指定されているが、これに限るわけではない）。ＣＳＶ要素「情報２」については、非キー要素“自宅住所”、“自宅電話”、“携帯電話”（これも、何れも「ｐａｔｈ」属性は“個人情報”が指定されているが、これに限るわけではない。つまり、変換元の文書の階層構造に従ってＣＳＶ要素を割り当てる必要があるわけではない）。
尚、図４に示す変換仕様ＸＭＬ文書２２のファイル名は、「ｓｐｅｃｌ．ｘｍｌ」であるものとする。
構造変換部１１が、上記図３に示す定型ＸＭＬ文書を、図４に示す変換仕様ＸＭＬ文書２２を用いて、図７に示す処理を実行することによって、図５に示す変換ＸＭＬ文書２３が作成される。尚、図５には、Ａ氏に関するレコードの変換結果のみを示すが、特に図示しないだけであり、他のレコード（Ｂ氏）等も同様に変換される。
以下、図５、図７を参照して、本例による構造変換処理について説明する。
尚、図７は、第１〜第３に共通のＸＭＬ文書に対する構造変換処理の基本的な処理フローチャート図である。但し、応用ソフト３０での非キー要素の利用を考えない場合には、図６に示す処理であってもよい。図６は、ＸＭＬ文書に対する構造変換処理の基本的な処理フローチャート図である。図７に示す処理と、図６の処理の違いは、図７ではステップＳ２３の処理が加わっており、また図６のステップＳ１３の処理の代わりにステップＳ２４の処理を行なう点のみであり、他の処理は同じである。よって、ここでは図６の説明は省略する。
図６、図７は、直接、変換仕様を読み取って行う変換処理のフローチャート図であり、図８は、図６のステップＳ１７または図７のステップＳ２８の処理の詳細フローチャート図である。
尚、図６〜図９は、データ構造変換／逆変換機構１０によって実行される処理を示すものである。
図７において、データ構造変換／逆変換機構１０は、まず、変換仕様ＸＭＬ文書２２を読み込んで、その記述内容から変換仕様を解析する（ステップＳ２１）。続いて、変換対象である入力ＸＭＬ文書２１を入力する（ステップＳ２２）。そして、この入力ＸＭＬ文書２１と、解析した変換仕様とに基づいて、ステップＳ２３以降の処理を実行する。
まず、変換ＸＭＬ文書２３（この時点では、何も記述されていない）に対して、ヘッダ（〈ｃｓｖ−ｄｅｆ〉）に、付加情報を記述する（ステップＳ２３）。つまり、変換仕様ＸＭＬ文書２２に記述されていた変換仕様に基づいて、変換ＸＭＬ文書２３のヘッダに、各ＣＳＶ要素毎に、そのＣＳＶ要素名をタグ名とし、その要素内容として、そのＣＳＶ要素に対応する非キー要素の要素名をＣＳＶ形式で繋いだものを、付加情報として付ける。この例では、図４の変換仕様に従って、図５に示すとおり、ＣＳＶ要素名「情報１」については、これに対応する非キー要素の要素名“部署”、“電話”、“ｅｍａｉｌ”、ＣＳＶ要素名「情報２」については、これに対応する非キー要素の要素名“自宅住所”、“自宅電話”、“携帯電話”が、ＣＳＶ形式で繋がれて記述されている。
ＸＭＬ文書は、タグ名で要素内容が意味付けられ、自己記述的な性質を持っている。しかし、ＣＳＶ形式を取り込むと、ＣＳＶ形式の部分はタグが外れるので、ＸＭＬ文書の自己記述性が崩れてしまうが、この付加情報を変換文書に埋め込むことによって、自己記述性が欠如することはない。
つまり、応用ソフト３０において、変換後のＸＭＬ文書を用いて何らかの処理を実行する場合においても、この付加情報を参照することによって、各要素内容に対応する要素名を知ることができる。
次に、入力ＸＭＬ文書２１のルート要素をコピーし、その属性として、当該変換ＸＭＬ文書２３がＣＳＶ変換文書であることを示す「ＣＳＶＣ（ＣＳＶ  Ｃｏｍｐａｃｔｉｎｇ  Ｃｏｎｖｅｒｓｉｏｎ）」を記述すると共に、その変換仕様ＸＭＬ文書２２のファイル名を入れる（ステップＳ２４）。図３の例では、ルート要素は“名簿”であり、また、変換仕様ＸＭＬ文書２２のファイル名は上記の通り「ｓｐｅｃｌ．ｘｍｌ」であるので、図５に示すように〈名簿  ＣＳＶＣ＝”ｓｐｅｃｌ．ｘｍｌ”〉と記述される。尚、ここでは、変換仕様ＸＭＬ文書２２のファイル名を記述したが、逆変換ＸＳＬシート１６のファイル名を記述してもよい。あるいは、ファイル名に限らず、例えばＵＲＬを指定してもよい。
変換ＸＭＬ文書２３は、変換仕様ＸＭＬ文書２２のパラメータの取り方によって幾通りもできるが、変換ＸＭＬ文書２３にその変換仕様ＸＭＬ文書２２のファイル名か逆変換用ＸＳＬシート名を書いておくことによって、元のＸＭＬ文書である入力ＸＭＬ文書２１との対応付けがなされる。
次に、入力ＸＭＬ文書２１のレコード要素以外の部分を変換ＸＭＬ文書２３にコピーする。また、各レコード要素を切り出す（ステップＳ２５）。レコード要素とは、レコードを記述する要素であることを意味するタグ名で囲まれた要素であり、図３の例は、タグ名＜個人＞と＜／個人＞で囲まれた要素である。尚、図３の例では、レコード要素のみ示しているが、実際には、レコード要素以外の何らかの記述がある場合が多いので、特に図示しないが、これを変換ＸＭＬ文書２３にコピーする。
そして、各レコード要素毎に、全てのレコードについて処理を行うまで、つまりステップＳ２６の判定がＹＥＳとなるまで、ステップＳ２７〜ステップＳ２９の処理を繰り返し実行する。図３の例では、まず最初はＡ氏に関するレコードについて処理し、次にＢ氏に関するレコードについて処理し、その後、同様に、全てのレコードについて処理を実行することになる。
ステップＳ２７〜ステップＳ２９の処理は、まず、レコード要素の開始タグを変換ＸＭＬ文書２３にコピーする（ステップＳ２７）。図３の例では、開始タグは、＜個人＞である。次に、レコード内の要素を処理し（ステップＳ２８）、最後にレコード要素の終了タグ（図３では＜／個人＞）を変換ＸＭＬ文書２３にコピーする（ステップＳ２９）。
図８は、ステップＳ２８の処理の詳細フローチャート図である。
同図において、まず、変換仕様ＸＭＬ文書２２を参照して、キー要素は、全て、そのまま、入力ＸＭＬ文書２１から変換ＸＭＬ文書２３にコピーする処理を実行する。すなわち、変換仕様ＸＭＬ文書２２中の「要素の並び」の各要素、すなわち「ｉｔｅｍ」要素を順番に走査して（ステップＳ３１）、その要素名の要素がキー要素であるか否かを判別する（ステップＳ３２）。すなわち、「ｉｔｅｍ」要素のタグの属性ｍｔａｇで指定される文字列が、ｍｔａｇ＝“＿ＯＲＧ”であった場合には、その要素名の要素は、キー要素であると判定する（ステップＳ３２，ＹＥＳ）。
そして、入力ＸＭＬ文書２１の処理対象レコードに記述されているこのキー要素を、そのまま、変換ＸＭＬ文書２３にコピーする（ステップＳ３３）。図３〜図５の例では、例えば、図４において「要素の並び」の最初の「ｉｔｅｍ」要素における要素名「名前」の要素は、属性ｍｔａｇ＝“＿ＯＲＧ”であるので、キー要素と判定する。そして、図３において最初のレコードは「Ａ氏」であるので、このレコードにおけるタグ名「名前」の要素である“＜名前＞Ａ氏＜／名前＞”の部分が、そのまま、変換ＸＭＬ文書２３にコピーされる。以下、同様にして処理を実行し、「要素の並び」の全ての「ｉｔｅｍ」要素について上記処理を実行したら（ステップＳ３４，ＹＥＳ）、ステップＳ３５以降の処理に移る。
ステップＳ３５〜Ｓ４０の処理は、変換仕様ＸＭＬ文書２２を参照して、各ＣＳＶ要素毎に、そのＣＳＶ要素に該当する「ｉｔｅｍ」要素を検索して求め、該当する「ｉｔｅｍ」要素の要素内容、すなわち非キー要素の要素名をＣＳＶ形式で繋いで変換ＸＭＬ文書２３に出力する処理である。まず、変換仕様ＸＭＬ文書２２を参照して、「ＣＳＶ要素の定義の並び」からその要素名（つまり、ＣＳＶ要素名）を順番に走査し（ステップＳ３５）、ＣＳＶ要素があるか否かを判定する（ステップＳ３６）。「ＣＳＶ要素の定義の並び」の要素とは、図４における「ｍｅｒｇｉｎｇ＿ｔａｇ」要素であり、同図では最初は「情報１」が存在するので、ステップＳ３６の判定はＹＥＳとなり、続いて、変換仕様ＸＭＬ文書２２中の「要素の並び」の非キー要素、つまり各「ｉｔｅｍ」要素において、その属性ｍｔａｇで“＿ＯＲＧ”ではなく、対応するＣＳＶ要素名が指定されている「ｉｔｅｍ」要素を順番に走査して、上記ＣＳＶ要素（ここでは「情報１」）に該当する非キー要素を検索する（ステップＳ３７）。
そして、該当する非キー要素を見つける毎に（ステップＳ３８，ＹＥＳ）、この非キー要素の要素内容を、入力ＸＭＬ文書２１から取得して、これをＣＳＶ形式で繋ぐ（ステップＳ３９）。上記ＣＳＶ要素「情報１」に該当する非キー要素、すなわちｍｔａｇ＝“情報１”となっている非キー要素は、図４の例では、まず最初は要素名「部署」であり、「ｐａｔｈ＝“会社情報”」となっているので、入力ＸＭＬ文書２１から、このパスに従って「部署」要素の要素内容「Ａ部」を取得する。同様にして、要素名「電話」、要素名「ｅｍａｉｌ」の要素の要素内容「１２３」、「ａｂｃ＠ｆｊ．ｊｐ」を、そのｐａｔｈに従って入力ＸＭＬ文書２１からその取得して、これらを順次ＣＳＶ形式で繋いでいく。そして、該当する非キー要素が見つからなくなったら（ステップＳ３８，ＮＯ）、上記ＣＳＶ要素名「情報１」をタグ名とし、その要素内容を、上記非キー要素の要素内容をＣＳＶ形式で繋いだものとする新要素（ＣＳＶ要素）を、変換ＸＭＬ文書２３に出力する（ステップＳ４０）。この結果、図５に示す通り、
＜情報１＞Ａ部，１２３，ａｂｃ＠ｆｊ．ｊｐ＜／情報１＞
が、変換ＸＭＬ文書２３に記述される。
次に、再びステップＳ３５の処理に戻り、次のＣＳＶ要素名「情報２」を得て、これについても上記と同様の処理を行なった結果、図５に示す通り、
＜情報２＞Ａ市Ａ町，４５６，７８９＜／情報２＞
が、変換ＸＭＬ文書２３に記述される。
そして、「情報２」の次のＣＳＶ要素は存在しないので（ステップＳ３６，ＮＯ）、当該処理を終了する。以上で、変換ＸＭＬ文書２３の作成が完了する。
以上の変換処理によって、変換ＸＭＬ文書２３におけるレコード内の同階層（この例では第１階層）に全てのＣＳＶ要素（本例では「情報１」と「情報２」）を配置して、「情報１」と「情報２」に、それぞれ「会社情報」と「個人情報」に属する各要素の要素内容を格納するので、例えば応用ソフト３０において、想定外に、非キー要素を使う必要が生じた場合でも、応用ソフト３０で扱い易い構造となっている。尚、この例では、「会社情報」と「個人情報」が同階層であったので、分かり難いかもしれないが、たとえ「会社情報」と「個人情報」とが互いに異なる階層にあったとしても、「情報１」と「情報２」はレコード内第１階層となる。また、上述してあるように、「会社情報」に属する要素の要素内容を全て「情報１」に含める必要はなく、変換仕様ＸＭＬ文書２２によって自由に定義できる。また、既に述べているように、非キー要素の数が多い場合でも、オーバーヘッドが大きくなることを防止できる。
次に、以下、定型ＸＭＬ文書に対する構造変換処理を行なって得られた変換ＸＭＬ文書２３を、逆変換して、元の構造のＸＭＬ文書に戻す処理、すなわち逆変換処理について、詳細に説明する。図２の例では、応用ソフト３０が、蓄積されている複数の変換ＸＭＬ文書２３の中から、例えばクライアントから要求されて検索条件に応じてタグ検索等を行なって得た検索結果である抽出ＸＭＬ文書２４を、逆変換部１２によって逆変換して、結果ＸＭＬ文書２５を出力するので、これに沿って説明する。
まず、逆変換処理の全体フローチャート図は、特に図示しないが、基本的には図６に示す変換フローと、一部を除いてほぼ同じである。異なる点は、ステップＳ１２で入力するＸＭＬ文書、すなわち変換対象のＸＭＬ文書が、抽出ＸＭＬ文書２４であるので、図６のステップＳ１３，Ｓ１４における「入力ＸＭＬ文書」を「抽出ＸＭＬ文書２４」に置き換えればよい。また、抽出ＸＭＬ文書２４が、図７に示す変換処理によって得られたものである場合には、ステップＳ１３のルート要素のコピーの際にその属性は除外してコピーし、また、ステップＳ１４の処理においてヘッダの付加情報は除外してコピーすることになる。
また、当然、ステップＳ１７の処理内容は、図８とは全く異なる。
図９は、逆変換処理におけるステップＳ１７の詳細フローチャート図である。
図示の逆変換処理は、各ＣＳＶ要素毎にその要素内容である文字列を、区切り記号（カンマ‘、’）によって分離して、それぞれ所定の配列に格納しておき、変換仕様ＸＭＬ文書２２中の「要素の並び」の順にキー要素、非キー要素を配置して出力する処理である。
ここでは、図５のＸＭＬ文書を、直接、図４の変換仕様に従って、元の図３のＸＭＬ文書に戻す場合を例にして説明する。よって、この例では、結果ＸＭＬ文書２５は、図３の内容となる。
図９において、まず、変数ｉに初期値‘０’を代入する（ステップＳ５１）。
そして、変換仕様ＸＭＬ文書２２を参照して、「ＣＳＶ要素の定義の並び」からその要素名（つまり、ＣＳＶ要素名）を順番に走査し（ステップＳ５２）、ＣＳＶ要素があるか否かを判定する（ステップＳ５３）。「ＣＳＶ要素の定義の並び」の要素とは、図４における「ｍｅｒｇｉｎｇ＿ｔａｇ」要素であり、同図では最初は「情報１」が存在するので、ステップＳ５３の判定はＹＥＳとなる。
続いて、まず、ｉを＋１インクリメントする（ｉ＝ｉ＋１）。また、変数ｊに初期値‘１’を代入する。そして、抽出ＸＭＬ文書２４を参照して、上記ＣＳＶ要素の要素内容を取得し、これを区切り記号（カンマ‘，’）によって分離して、それぞれ、ｊを＋１インクリメントしながら、配列ｃｏｎｔＡｒｒａｙ（ｉ，ｊ）に格納する（ステップＳ５４）。上記の例では、ｉ＝１となり、抽出ＸＭＬ文書２４における要素「情報１」の要素内容は「Ａ部，１２３，ａｂｃ＠ｆｊ．ｊｐ」であるので、これらを分離し、配列ｃｏｎｔＡｒｒａｙ（ｉ，ｊ）に格納すると、配列（１，１）には“Ａ部”、配列（１，２）には“１２３”，配列（１，３）には“ａｂｃ＠ｆｊ．ｊｐ”が格納される。ＣＳＶ要素「情報２」についても、同様に処理を行なった結果、配列（２，１）には“Ａ市Ａ町”、配列（２，２）には“４５６”，配列（２，３）には“７８９”が格納される。
全てのＣＳＶ要素について上記処理を行なったら（ステップＳ５３，ＮＯ）、変数ｎに、このときのｉの値を代入する（ステップＳ５５）。上記の例では、ＣＳＶ要素「情報２」に関する処理によって、ｉ＝２となっているので、これを変数ｎに代入する。続いて、ｉ＝１〜ｎまでの各々について、ｋ（ｉ）＝１を設定する（ステップＳ５６）。上記の例では、ｉ＝１〜２となるので、ｉ＝１、ｉ＝２の各々について、ｋ（ｉ）＝１を設定する。つまり、ｋ（１）＝１、ｋ（２）＝１となる。
そして、ステップＳ５７〜Ｓ６２の処理を、繰り返し実行する。
まず、変換仕様ＸＭＬ文書２２中の「要素の並び」の各要素を順番に走査して（ステップＳ５７）、「ｉｔｅｍ」要素があると（ステップＳ５８，ＹＥＳ）、この「ｉｔｅｍ」要素の要素名の要素がキー要素であるか否かを判別する（ステップＳ５９）。つまり、「ｉｔｅｍ」要素のタグの属性においてｍｔａｇ＝“＿ＯＲＧ”であった場合には、その要素名の要素がキー要素であると判定する（ステップＳ５９，ＹＥＳ）。キー要素である場合には、抽出ＸＭＬ文書２４内の処理対象レコードにおけるこのキー要素を、結果ＸＭＬ文書２５にコピーする（ステップＳ６０）。図４の例では「要素の並び」の最初のキー要素の要素名は「名前」であるので、抽出ＸＭＬ文書２４内の処理対象レコードがＡ氏に関するレコードであるとすると、この要素名「名前」の要素“＜名前＞Ａ氏＜／名前＞”が、そのまま、結果ＸＭＬ文書２５にコピーされる。
一方、非キー要素である場合（ステップＳ５９，ＮＯ）、つまり、「ｉｔｅｍ」要素のタグの属性ｍｔａｇにおいて、“＿ＯＲＧ”ではなく、ＣＳＶ要素名が指定されている場合には、このＣＳＶ要素名の変換仕様ＸＭＬ文書２２中の出現順番ｉを求め（ステップＳ６１）、配列ｃｏｎｔＡｒｒａｙ（ｉ，ｋ（ｉ））に格納されているデータを、当該非キー要素の要素名と共に、結果ＸＭＬ文書２５に出力する（ステップＳ６２）。
図４では、例えば、「ｉｔｅｍ」要素の並びにおいて、最初に出現する非キー要素は、図示の通り、要素名が「部署」の要素であり、そのタグの属性ｍｔａｇで指定されるＣＳＶ要素名は「情報１」であるので、続いて、「ｍｅｒｇｉｎｇ＿ｔａｇ」要素を参照すると、「情報１」の出現順番は１番目であるので、出現順番ｉ＝１となる。また、この段階では、ｋ（ｉ＝１）は初期設定値‘１’であるので、配列（１，１）に格納されているデータ、すなわち「Ａ部」が、要素名「部署」と共に、結果ＸＭＬ文書２５に書き込まれることになる。勿論、その際、ｐａｔｈを参照する。
また、ステップＳ６２の処理の最後で、ｋ（ｉ）＝ｋ（ｉ）＋１とする。これによって、次にＣＳＶ要素「情報１」に対応する非キー要素が出現した場合には、今度は、配列（１，２）に格納されているデータが出力されることになる。
以上の処理を、変換仕様ＸＭＬ文書２２中の「要素の並び」の全ての「ｉｔｅｍ」要素について実行したら（ステップＳ５８，ＮＯ）、当該処理は終了する。このとき、上記の例では、結果ＸＭＬ文書２５の内容は、図３の内容と同一となっている。
従来では、変換前の元のＸＭＬ文書と、これを変換後に更に逆変換したＸＭＬ文書とを比較すると、内容的には同一だが、要素の並びが変わってしまって、ユーザから見れば文書が変質したように見えていたが、本例の処理では、要素の並びの順番が変わってしまうことはなく、完全に元通りにすることができる。
以上、定型ＸＭＬ文書に対する構造変換／逆変換処理について説明した。
以下、非定型ＸＭＬ文書に対する構造変換／逆変換処理について説明する。
上述してある通り、この処理には、第２の実施例と第３の実施例がある。
まず、図１０に、第２、第３の実施例において入力ＸＭＬ文書２１となる非定型ＸＭＬ文書の一例を示す。
図１０に示す通り、非定型ＸＭＬ文書は、レコード内の要素数、タグ名が可変となる。
図１０の例では、「名前」をキー要素とする場合を考える。また、この例では、「会社」はキー要素として扱ってもよいし、非キー要素として扱ってもよい。
また、非キー要素に関しては、図３では、Ａ氏、Ｂ氏とも同じ要素名、要素数であったのに対して（勿論、Ａ氏、Ｂ氏に限らず、他のレコードも同様）、図１０では、非定型ＸＭＬ文書であるので、タグ名、要素数が異なる。すなわち、Ａ氏に関する非キー要素は、会社情報として要素名“部署”、“住所”、“電話”、“ｅｍａｉｌ”個人情報として要素名“住所”、“電話”、“携帯電話”の要素がある。一方、Ｂ氏に関する非キー要素は、会社情報として要素名“部署”、“住所”、“電話”、“ｅｍａｉｌ”、“ｅｍａｉｌ”、個人情報として、要素名“住所”、“電話”の要素がある。
Ｂ氏は、Ａ氏と比較すると、会社情報として“ｅｍａｉｌ”が２つある一方で、個人情報としての“携帯電話”がない。つまり、Ｂ氏は、ｅｍａｉｌアドレスを２つ持っており、携帯電話は持っていない為に、このような個人情報が入力されたということである。
尚、この例では、入力ＸＭＬ文書２１において二人ともキー要素の要素内容は記述されているが、記述されない場合があってもよい。
以下の説明では、第２、第３の実施例とも、上記図１０の非定型ＸＭＬ文書を入力ＸＭＬ文書２１とする場合について説明する。
まず、第２の実施例について説明する。
図１１は、第２の実施例における変換仕様ＸＭＬ文書２２の一例を示す図である。
同図において、まず、元の文書の要素名「会社情報／会社」を、任意の別名（この例では「勤務先」）に置き換えて、変換後の文書に出力する為の変換仕様について説明する。これは、〈ｒｅｐｌａｃｉｎｇ＿ｔａｇ〉で新要素名「勤務先」を定義し、「要素の並び」における要素「会社」の箇所で、属性でｒｔａｇ＝”勤務先”として指定する。この操作によって、この例のように２層の場合に限らず、３層以上の深い階層であっても、この深い階層にある要素をレコード内１階層目に上げて、応用ソフトで読出し易くすることができる。また、これは、ＣＳＶ形式でまとめる要素が１個の特殊な場合であり、必ずしも１個の場合と複数個の場合とを区別する必要はないが、区別することによって、変換／逆変換の操作をし易くすることができる。
また、図１０の例では、「住所」、「電話」が、それぞれ、２つ存在する。つまり、「会社情報」、「個人情報」の各々に、「住所」、「電話」が存在する。このような場合、要素名だけを変換ＸＭＬ文書２３に出力しても、応用ソフト３０では区別が付かない。この為、先出願では、ｔａｇｓを用いて、「会社情報／住所」、「会社情報／電話」、「個人情報／住所」、「個人情報／電話」という形で出力していたが、これでは、階層構造が深くなるほど、冗長な記述となってしまう。本例では、これに対して、図１１の変換仕様ＸＭＬ文書２２の例のように、「ｉｔｅｍ」要素のタグの属性として、ｎａｍｅ属性を与えている。このｎａｍｅ属性によって、別名を指定して、この別名を変換文書のヘッダで付加情報として記述するようにしている。図１１の例では、例えば、「会社情報／住所」は「会社住所」、「個人情報／住所」は「自宅住所」という別名を与え、図１２に示すヘッダの付加情報には、この別名が記述され、応用ソフト３０はこの別名を用いて任意の処理を行なう。「電話」についても同様である。また、ｅｍａｉｌについても、最大２個記述されるので、図１１に示す通り、別名を与えている。
このように、非キー要素の要素内容をＣＳＶ要素に纏めたときに、一意に指定できる要素名を変換仕様で与え、変換文書にそれを反映させることによって、元文書の要素階層とは別の纏め方、別の要素名で、応用ソフト３０が扱うことができるようになる。尚、これは、第１の実施例において適用してもよい。
また、本例では、図１１に示すように、「ｉｔｅｍ」要素のタグにおいてｆｏｒｍａｔ属性を与えている。図示の例では「会社情報／ｅｍａｉｌ［０］」、「会社情報／ｅｍａｉｌ［１］」、「個人情報／携帯電話」の「ｉｔｅｍ」要素に、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いており、これによって、これらの要素名の要素の要素内容が、入力ＸＭＬ文書２１において固定的な出現をしないことを指定できる。
“固定的な出現をしない”とは、例えば上記図１０にはＢ氏が携帯電話は持っていないので、携帯電話番号を記入しなかった場合のデータを示している。このように、必ずしもその要素名の要素の要素内容が記述されているものではないことを、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”で指定する。
一方、「ｉｔｅｍ」要素において、タグにｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていない場合、その要素名の要素は、必ず要素内容が記述されている。つまり、一般的に、例えば任意のホームページで任意の情報（ここでは、任意のユーザの個人情報）を入力させる際、必須入力項目を指定・表示し、この必須入力項目の中の１つでも入力していない状態で「登録」等を行なおうとすると、エラーとすることが行なわれている。上記ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていない要素は、例えばこの必須入力項目に対応するものと考えてよい。ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性は、キー要素、非キー要素の両方に指定可能である。
但し、固定的な出現をしない場合でも、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性は、必ず指定しなけらばならないとは限らない。この場合、後述する図１４のステップＳ１００、Ｓ１０４の処理における「非定型要素且つ」の条件が無くなる。但し、この場合、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が指定されていないにも係わらず、その要素が存在しない場合に、エラーとする処理等が行なえなくなる。
図１２は、図１０の非定型ＸＭＬ文書を、図１１に変換仕様ＸＭＬ文書２２を用いて構造変換して成る変換ＸＭＬ文書２３の一例を示す図である。
また、図１３は、第２の実施例における構造変換処理における「レコード内の要素の処理」の詳細フローチャート図である。すなわち、第２の実施例においても、構造変換処理全体の処理の流れは、第１の実施例と略同様であるので、全体処理については図６、図７で説明してあるので省略する。そして、ステップＳ１７またはステップＳ２８の処理内容は、第１の実施例とは異なるので、その詳細について、図１３に示して説明する。尚、図１２には、付加情報を付ける処理を行なった場合の変換結果を示している。
但し、図７の処理、すなわち付加情報を付ける処理を行なう場合には、更に、ステップＳ２３の処理内容が多少異なる。すなわち、第２の実施例では、図１１に示す通り、変換文書のヘッダの付加情報で与える非キー要素の要素名の別名を、ｎａｍｅ属性で与えているので、ステップＳ２３の処理は、ｎａｍｅ属性で指定されている別名を、変換ＸＭＬ文書２３に付加情報として出力する処理となる。例えば、図１１において非キー要素「会社情報／住所」について、ｎａｍｅ属性で「会社住所」が指定されているので、図１２に示す通り、ＣＳＶ要素名「場所」において「会社住所」が記述される。他の非キー要素についても同様である。また、図１２には、図７のステップＳ２４の処理によって、ルート要素「名簿」と、その属性に変換文書名が記述されている。尚、ここでは、図１１の変換仕様ＸＭＬ文書２２のファイル名がｓｐｅｃ２．ｘｍｌであったものとする。
このように、ルート要素とヘッダが記述された状態で、図１３の処理によって、図１２の個人タグ内の各種情報が記述される。
図１３において、まず、ステップＳ７１〜Ｓ７５の処理、すなわち変換仕様ＸＭＬ文書２２を参照して、キー要素を全て探し出して、その要素名と要素内容を変換ＸＭＬ文書２３にコピーする処理は、基本的には、図８のステップＳ３１〜Ｓ３４の処理と略同様である。但し、第２の実施例は、入力文書が非定型ＸＭＬ文書であり、非キー要素だけでなく、キー要素も固定的な出現をしない場合がある。これに対応して、ステップＳ７３の処理を行なっている。
ステップＳ７３の処理では、ステップＳ７２において見つけた、キー要素に関する「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いており、且つ入力ＸＭＬ文書２１においてこのキー要素が記述されていない場合には（ステップＳ７３，ＹＥＳ）、このキー要素はコピーしないようにする。
図１０、図１１の例には、ステップＳ７３の判定がＹＥＳとなる例は存在しないが、例えば仮に、図１１において、キー要素「名前」に関する「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いており、且つ図１０において「名前」要素が記述されていなかった場合には、図１２における＜名前＞Ａ氏＜／名前＞の部分は、記述されていないことになる。
また、図１３において、ステップＳ７６〜Ｓ８１の処理、すなわち、変換仕様ＸＭＬ文書２２を参照して、各ＣＳＶ要素毎に、そのＣＳＶ要素に該当する要素を検索して求め、該当する要素の要素内容をＣＳＶ形式で繋いで変換ＸＭＬ文書２３に出力する処理は、基本的には、図８のステップＳ３５〜Ｓ４０の処理と略同様である。但し、第２の実施例は、入力文書が非定型ＸＭＬ文書であり、上記の通り、非キー要素が、固定的な出現をしない場合がある。これに対して、本例では、もし、ある非キー要素の要素内容が存在しない場合には、ステップＳ８０の処理において、空要素を繋ぐようにしている。
例えば、Ａ氏のレコードを処理対象としたときのステップＳ７８，Ｓ７９の処理において、ＣＳＶ要素名「連絡」に該当する非キー要素として、変換仕様ＸＭＬ文書２２の「ｉｔｅｍ」要素中に、「会社情報／ｅｍａｉｌ［１］」に関する「ｉｔｅｍ」要素を見つけたとき（ステップＳ７９，ＹＥＳ）、この非キー要素「会社情報／ｅｍａｉｌ［１］」は、図１０に示す通り、記述されていないので、この場合にはステップＳ８０の処理において空要素を繋ぐ。これによって、図１２に示すＣＳＶ要素名「連絡」の要素内容は、
〈連絡〉１２３，ａｂｃ＠ｆｊ．ｊｐ，，４５６，７８９〈／連絡〉
となる。つまり、新要素名「会社ｅｍａｉｌ１」の要素内容である「ａｂｃ＠ｆｊ．ｊｐ」と、新要素名「個人電話」の要素内容である「４５６」の間は、空要素「，，」で繋がれている。
また、図１３には示していないが、変換仕様ＸＭＬ文書２２中の「要素の並び」における任意の「ｉｔｅｍ」要素において、そのタグの属性でｒｔａｇが指定されている場合には、その要素名を、〈ｒｅｐｌａｃｉｎｇ＿ｔａｇ〉で定義されている新要素名に置き換えて、変換ＸＭＬ文書２３に出力する処理を実行する。これによって、図１２に示すように、「会社情報／会社」が「勤務先」というレコード内１階層目の要素に置き換えられている。これは、ＣＳＶ形式でまとめる要素が１個であるという、特殊な場合である。
以上の処理によって、図１２に示す変換ＸＭＬ文書２３が作成される。図１２に示す通り、この変換文書では、元のＸＭＬ文書である図１０の入力ＸＭＬ文書２１において「会社情報」、「個人情報」の下にあった非キー要素の要素内容を、それぞれ、バラバラに、ＣＳＶ要素「場所」、「連絡」に纏め直している。“バラバラに”とは、例えば「会社情報」の下にあった非キー要素は全てＣＳＶ要素「場所」に纏めるとは限らず、一部は「連絡」に纏めてもよいという意味である。
また、変換ＸＭＬ文書２３には、各ＣＳＶ要素に絡めた要素内容の要素名を、ヘッダの付加情報として記述しているが、その際に、元のＸＭＬ文書では「会社情報」と「個人情報」の下に、それぞれ、同名の要素「住所」と「電話」があったが、これらの名称が重複する要素名に関しては、上記の通り、変換仕様ＸＭＬ文書２２中のｎａｍｅ属性に従って、新たな名前「会社住所」、「会社電話」、「自宅住所」、「自宅電話」を与えている。これは、上記の通り、例えば「会社情報／住所」等のようにＸＰａｔｈで与えても一意の名前になるが、特に階層が深い場合には冗長になる為、別名を与えることによって、応用ソフトで、これらの要素の扱いを容易にできるようになる。また、この例では「会社情報／ｅｍａｉｌ」が最大２個記述されるものと想定している。この為、繰返し出現する「会社情報／ｅｍａｉｌ」に対して「会社ｅｍａｉｌ１」「会社ｅｍａｉｌ２」を新たな名前として与え、各々が一意になるようにしている。
次に、以下、第２の実施例における逆変換処理について説明する。
第２の実施例の逆変換処理は、処理全体の流れは、第１の実施例で説明した逆変換の全体処理と、略同様であるので、特に図示／説明はしない。
図１４は、この逆変換の全体処理中の“レコード内の要素の処理”の詳細フローチャート図である。
図１４の処理において、ステップＳ９１〜Ｓ９５の処理までは、図９のステップＳ５１〜ステップＳ５５の処理と略同様であるので、説明は省略する。但し、ステップＳ９４の処理において、要素内容が空要素である場合にも配列を割り当てる。つまり、例えば、図１２のＡ氏のレコードのＣＳＶ要素「連絡」において、要素内容「４５６」の前に空要素があるが、この空要素にも配列（２，３）を割り当てるので、「４５６」は、配列（２，４）に格納される。
ステップＳ９６以降の処理について、以下に説明する。
まず、ｉ＝１〜ｎまでの各ｉ毎に、ｋ（ｉ）に初期値‘０’を与える（ステップＳ９６）。
ここで、図９のステップＳ５６では初期値‘１’を与えていたが、これを‘０’とした理由について、説明しておく。これは、ｋ（ｉ）の値を＋１インクリメントする処理を、ステップＳ１０３の段階で行なっている点と関連する。これらの処理は、内容的には、図９の処理と殆ど変わらないが、図９ではステップＳ６２の処理において、配列の格納内容を出力すると共に、ｋ（ｉ）の値を＋１インクリメントしていたが、本例のように非定型ＸＭＬ文書を扱う場合には、必ずしも配列の格納内容を出力する処理を行なうとは限らないので（つまり、ステップＳ１０４の判定がＹＥＳとなる）、ステップＳ１０４の分岐の前の段階で、ｋ（ｉ）の値を＋１インクリメントする（ステップＳ１０３）。また、これによって、配列（ｉ，ｋ（ｉ））の格納内容を出力する処理の前にｋ（ｉ）の値が＋１インクリメントされてしまうことに対応して、ステップＳ９６においてｋ（ｉ）の初期値を‘０’にしている。
上記ステップＳ９６の処理後、まず、変換仕様ＸＭＬ文書２２中の「要素の並び」の各「ｉｔｅｍ」要素を順番に走査して（ステップＳ９７）、各「ｉｔｅｍ」要素毎に（ステップＳ９８，ＹＥＳ）、その「ｉｔｅｍ」要素で定義している要素名の要素が、キー要素であるか否かを判定する（ステップＳ９９）。判定方法は、既に説明している。
キー要素である場合には（ステップＳ９９，ＹＥＳ）、続いて、当該「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていて、且つ変換対象入力文書である抽出ＸＭＬ文書２４内の処理対象レコードにおいて、このキー要素名の要素が存在しない場合には（ステップＳ１００，ＹＥＳ）、結果ＸＭＬ文書２５に対して何も出力しないで、ステップＳ９７に戻り、次の要素の処理に移る。一方、当該キー要素に関する「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていない場合、若しくはｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていても抽出ＸＭＬ文書２４に、このキー要素名の要素が存在する場合には（ステップＳ１００，ＮＯ）、このキー要素の要素名を結果ＸＭＬ文書２５にコピーすると共に、抽出ＸＭＬ文書２４内の処理対象レコードに記述されている当該キー要素の要素内容を、結果ＸＭＬ文書２５にコピーする（ステップＳ１０１）。
一方、ステップＳ９９において、非キー要素であると判定された場合（ステップＳ９９，ＮＯ）、つまり、「ｉｔｅｍ」要素のタグの属性ｍｔａｇが、“＿ＯＲＧ”ではなく、ＣＳＶ要素名が記述されている場合には、まず、このＣＳＶ要素名の変換仕様ＸＭＬ文書２２中の出現順番ｉを求め（ステップＳ１０２）、ｋ（ｉ）の値を＋１インクリメントする（ステップＳ１０３）。そして、当該キー要素に関する「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いていて、且つ配列ｃｏｎｔＡｒｒａｙ（ｉ，ｋ（ｉ））に何も格納されていない（空である）場合には（ステップＳ１０４）、結果ＸＭＬ文書２５に対して何も出力しないで、ステップＳ９７に戻り、次の「ｉｔｅｍ」要素の処理に移る。要素内容は、上記の通り“空”であるので何も出力できないが、当該非キー要素の要素名も出力しない。
一方、ステップＳ１０４の判定がＮＯの場合には、配列ｃｏｎｔＡｒｒａｙ（ｉ，ｋ（ｉ））に格納されているデータを、当該非キー要素の要素名と共に、結果ＸＭＬ文書２５に出力する（ステップＳ１０５）。
以上の処理で、例えば図１２に示す変換文書を、図１０に示す元の文書に、戻すことができる。これは、順番も、元通りに戻すことができる。変換仕様ＸＭＬ文書２２中の各「ｉｔｅｍ」要素を、元のＸＭＬ文書の出現順に並べており、且つこの順番通りに処理し、出力しているからである。
尚、図１４には示していないが、変換仕様ＸＭＬ文書２２において「ｉｔｅｍ」要素のタグに属性ｒｔａｇを有する場合、その要素名の要素は、この属性ｒｔａｇで指定される新要素名（図１１、図１２の例では「勤務先」）の要素内容を、抽出ＸＭＬ文書２４から取得して、この要素内容と、元の要素名とを、結果ＸＭＬ文書２５に出力する。
以上説明した第２の実施例によれば、非定型ＸＭＬ文書であっても、第１の実施例と同様の効果が得られる。更に、上述してあるように、ｎａｍｅ属性による効果も得られる。
次に、以下、非定型ＸＭＬ文書に対する２つ目の方法、すなわち第３の実施例について説明する。
第３の実施例を説明する際の具体例は、入力ＸＭＬ文書２１は、上記図１０に示した例と同じであるとし、変換仕様ＸＭＬ文書２２の具体例を図１５に示し、変換ＸＭＬ文書２３の具体例を図１６に示す。
図１５に示す変換仕様ＸＭＬ文書２２の例は、図１１に示す第２の実施例の場合と比較すると、変換ＸＭＬ文書２３のヘッダの付加情報で与える非キー要素の別名を、変換仕様ＸＭＬ文書２２中の非キー要素に関する各「ｉｔｅｍ」要素において、ｎａｍｅ属性で与えるようにしている点は、第２の実施例と同じである。
第２の実施例と異なる点は、変換仕様ＸＭＬ文書２２中の「ｍｅｒｇｉｎｇ＿ｔａｇ」要素において、そのタグ内に属性としてｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”を付けられている場合には、そのＣＳＶ要素に含まれる全ての非キー要素が、固定的な出現をしないことを指定する点である。
これに伴って、ステップＳ２３の処理を行なった場合には、図１６に示すように、非定型な要素をまとめるＣＳＶ要素である「連絡」には、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付けて、ＣＳＶ要素「連絡」内の非キー要素が全て非定型であると見なすように指定する。
図１７は、第３の実施例における構造変換処理における「レコード内の要素の処理」の詳細フローチャート図である。すなわち、第３の実施例においても、第２の実施例と同様に、構造変換処理全体の処理の流れは、第１の実施例と略同様であるので、全体処理については図６、図７で説明してあるので省略する。そして、ステップＳ１７またはステップＳ２８の処理内容は、第１、第２の実施例とは異なるので、その詳細について、図１７に示して説明する。尚、図１６には、付加情報を付ける処理を行なった場合の変換結果を示している。また、図７の処理、すなわち付加情報を付ける処理を行なう場合、ステップＳ２３の処理内容は、第２の実施例と同様である。すなわち、ｎａｍｅ属性で指定されている別名を、変換ＸＭＬ文書２３のヘッダに付加情報として出力する。
図１７において、ステップＳ１１１〜ステップＳ１１７の処理は、図１３のステップＳ７１〜Ｓ７７の処理と同じであるので、その説明は省略する。また、ステップＳ１１８の判定がＮＯとなった場合の処理であるステップＳ１１９〜Ｓ１２２の処理は、図８のステップＳ３７〜Ｓ４０の処理と同じであるので、その説明は省略する。
以下、ステップＳ１１８の判定がＹＥＳとなった場合の処理について説明する。ステップＳ１１８の判定がＹＥＳとなる場合、つまり処理対象のＣＳＶ要素が非定型ＣＳＶ要素である場合とは、「ｍｅｒｇｉｎｇ＿ｔａｇ」要素において、上記「連絡」のように、そのタグ内に属性としてｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”が付されていた場合である。
この場合、変換仕様ＸＭＬ文書２２中の「要素の並び」において、非キー要素を順番に走査して、上記非定型ＣＳＶ要素（ここでは「連絡」）に該当する非キー要素を検索する（ステップＳ１２４）。
そして、該当する非キー要素を見つける毎に（ステップＳ１２５，ＹＥＳ）、入力ＸＭＬ文書２１中にこの非キー要素が記述されているか否かに判定し（ステップＳ１２６）、もし記述されている場合には（ステップＳ１２６，ＹＥＳ）、この非キー要素の出現順番をＣＳＶ形式で繋ぐと共に（ステップＳ１２７）、入力ＸＭＬ文書２１から要素内容を取得して、これをＣＳＶ形式で繋ぐ（ステップＳ１２８）、という処理を繰り返す。
そして、該当する非キー要素が見つからなくなったら（ステップＳ１２５，ＮＯ）、上記非定型ＣＳＶ要素のタグ内の属性ｔａｇｓの属性値としてステップＳ１２７の処理結果を置くと共に（ステップＳ１２９）、このｔａｇｓ属性を有する非定型ＣＳＶ要素のタグと共に、ステップＳ１２８の処理結果を変換ＸＭＬ文書２３に出力する。
図１５、図１６に示す非定型ＣＳＶ要素「連絡」の例では、例えばＡ氏に関するレコードを処理対象としたときには、図１５のステップＳ１２５において、「連絡」に該当する非キー要素として、走査順に、「会社情報／電話」（出現順番１）、「会社情報／ｅｍａｉｌ［１］」（出現順番２）、「会社情報／ｅｍａｉｌ［２］」（出現順番３）、「個人情報／電話」（出現順番４）、「個人情報／携帯電話」（出現順番５）が見つかるが、唯一「会社情報／ｅｍａｉｌ［２］」（出現順番３）のみは、図１０のＡ氏のレコード内に記述されていないので、図１６に示すように、ｔａｇｓ属性を有する非定型ＣＳＶ要素のタグとして、
〈連絡  ｔａｇｓ＝”１，２，４，５”〉〈／連絡〉
その要素内容として
１２３，ａｂｃ＠ｆｊ．ｊｐ，４５６，７８９
が、変換ＸＭＬ文書２３に記述される。
また、上記の通り、ヘッダの付加情報として、ＣＳＶ要素の要素内容に対応する要素名（ここでは、別名になっており、“会社電話、会社ｅｍａｉｌ１、会社ｅｍａｉｌ２、自宅電話、携帯電話”）が、出現順番通りに記述されている。
これによって、新要素であるＣＳＶ要素に纏めてある要素内容とその要素名との対応を取ることができる。例えば要素内容「４５６」に対応するｔａｇｓ属性値は‘４’であるので、付加情報における４番目の要素名「自宅電話」に対応することが分かる。
次に、図１８を参照して、第３の実施例における逆変換処理について説明する。図１８は、第３の実施例の逆変換処理における「レコード内の要素の処理」の詳細フローチャート図である。
図１８におけるステップＳ１４１〜ステップＳ１４９の処理は、ステップＳ１４１〜ステップＳ１４４までと、ステップＳ１４７、Ｓ１４８の処理は、図９のステップＳ５１〜ステップＳ５６の処理と略同様であるが、ステップＳ１４５，Ｓ１４６，Ｓ１４９の処理が追加されている。ステップＳ１４１〜ステップＳ１４４までと、ステップＳ１４７、Ｓ１４８の処理についての説明は、省略または簡略化する。
まず、ステップＳ１４４までの処理によって、処理対象ＣＳＶ要素の要素内容を配列ｃｏｎｔＡｒｒａｙ（ｉ，ｊ）に格納したら、続いて、もしこのＣＳＶ要素が非定型要素であるならば（ステップＳ１４５，ＹＥＳ）、その属性“ｔａｇｓ”の値を分離して、それぞれ、配列ｔａｇＡｒｒａｙ（ｉ，ｊ）に格納する（ステップＳ１４６）。
図１５、図１６の例では、まず、最初に見つかるＣＳＶ要素は「場所」であるが、これは非定型ＣＳＶ要素ではないので、ステップＳ１４５の判定はＮＯとなる。よって、この場合はｉ＝１となるので、処理対象ＣＳＶ要素の要素内容を配列ｃｏｎｔＡｒｒａｙ（１，ｊ）に格納したら、そのまま、ステップＳ１４２の処理に戻る。
一方、次のＣＳＶ要素である「連絡」は、属性としてｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”が付されているので、非定型要素である（ステップＳ１４５，ＹＥＳ）。よって、この場合は、ｉ＝２となるので、処理対象ＣＳＶ要素の要素内容を配列ｃｏｎｔＡｒｒａｙ（２，ｊ）に格納し（ステップＳ１４４）、更にその属性“ｔａｇｓ”の値を分離して、それぞれ、配列ｔａｇＡｒｒａｙ（２，ｊ）に格納する（ステップＳ１４６）。
以上の処理によって、例えばＡ氏のレコードに関しては、配列ｃｏｎｔＡｒｒａｙには、（１，１）にＡ部、（１，２）にＡ市Ａ町、（１，３）にＡ市Ｂ町が格納され、（２，１）に１２３、（２，２）にａｂｃ＠ｆｊ．ｊｐ、（２，３）に４５６、（２，４）に７８９が格納される。また、配列ｔａｇＡｒｒａｙには（２，１）に１、（２，２）に２、（２，３）に４、（２，４）に５が格納される。
次に、この例では、ステップＳ１４７においてｎ＝２となるので、ステップＳ１４８、Ｓ１４９において、ｋ（ｉ）、ｍ（ｉ）の初期値を設定すると、ｋ（１）＝１、ｋ（２）＝１、ｍ（１）＝０、ｍ（２）＝０が設定される。
次に、変換仕様ＸＭＬ文書２２中の「要素の並び」を走査して、ｊ＝１、２，３、・・・の各「ｉｔｅｍ」要素毎に、ステップＳ１５２〜Ｓ１６０の処理を実行して、全ての「ｉｔｅｍ」要素について処理を行なったら（ステップＳ１５１，ＮＯ）、当該処理は終了する。
まず、処理対象の要素、すなわち「要素の並び」のｊ番目の「ｉｔｅｍ」要素が定義している要素名の要素が、キー要素であるか否か判定する（ステップＳ１５２）。判定方法は、既に説明してある。キー要素である場合には（ステップＳ１５２，ＹＥＳ）、ステップＳ１５３、Ｓ１５４の処理を実行する。ステップＳ１５３、Ｓ１５４の処理は、第２の実施例と同様、すなわち図１４のステップＳ１００，Ｓ１０１の処理と略同様であるので、ここでの説明は省略する。
一方、その「ｉｔｅｍ」要素が定義している要素名の要素が、非キー要素である場合（ステップＳ１５２，ＮＯ）、まず、この非キー要素に対応するＣＳＶ要素名の変換仕様ＸＭＬ文書２２中での出現順番ｉを求める（ステップＳ１５５）。続いて、ｍ（ｉ）を＋１インクリメントする（ステップＳ１５６）。そして、上記ＣＳＶ要素が非定型要素であるか否かに応じて、ステップＳ１５８またはステップＳ１５９の何れかに分岐する（ステップＳ１５７）。
図１５に示す例では、最初に見つかる非キー要素は「会社情報／部署」であり、これに対応するＣＳＶ要素名は「場所」であり、このＣＳＶ要素「場所」の出現順番は‘１’であるので、
ｍ（１）＝ｍ（１）＋１＝０＋１＝１
となり、更に、このＣＳＶ要素「場所」は非定型要素ではないので、ステップＳ１５８の処理に移行する。すなわち、配列ｃｏｎｔＡｒｒａｙ（ｉ，ｋ（ｉ））に格納されているデータを、当該非キー要素の要素名と共に、結果ＸＭＬ文書２５に出力する（ステップＳ１５８）。この例では、ｋ（１）は初期値‘１’のままなので、配列ｃｏｎｔＡｒｒａｙ（１，ｋ（１））＝ｃｏｎｔＡｒｒａｙ（１，１）に格納されている「Ａ部」が、当該非キー要素名「部署」と共に、結果ＸＭＬ文書２５に出力される。
そして、ｋ（１）の値が＋１インクリメントされて、‘２’となる。
一方、図１５の例において非キー要素「会社情報／電話」が処理対象となったときには、これに対応するＣＳＶ要素名は「連絡」であり、このＣＳＶ要素「連絡」の出現順番は‘２’であるので、
ｍ（２）＝ｍ（２）＋１＝０＋１＝１
となり、更に、このＣＳＶ要素「場所」は非定型要素なので（ステップＳ１５７，ＹＥＳ）、ステップＳ１５９の処理に移行する。
ステップＳ１５９の処理は、配列ｔａｇＡｒｒａｙに格納されている要素の順番を用いて、順番が入ってない要素は出力しないようにする処理である。例えば、上記「会社情報／電話」の例では、ｍ（２）＝１となっており、配列ｔａｇＡｒｒａｙ（２，１）には‘１’が格納されているので、ステップＳ１５９の判定はＹＥＳとなり、配列ｃｏｎｔＡｒｒａｙ（２，１）に格納されている「１２３」を、その非キー要素名「会社情報／電話」と共に、結果ＸＭＬ文書２５に出力する。そして、ｋ（２）を＋１インクリメントする。図１５において次の非キー要素である「会社情報／ｅｍａｉｌ［０］」も、同様に、ステップＳ１５６でｍ（２）＝２となり、配列ｔａｇＡｒｒａｙ（２，２）には‘２’が格納されているので、ステップＳ１５９の判定はＹＥＳとなる。
一方、次の非キー要素である「会社情報／ｅｍａｉｌ［１］」の場合、ステップＳ１５６でｍ（２）＝３となるが、配列ｔａｇＡｒｒａｙ（２，３）には‘４’が格納されているので、ステップＳ１５９の判定はＮＯとなる。元々、「会社情報／ｅｍａｉｌ［１］」の情報は記述されていないので、上記の処理によって、この要素は出力しないようにできる。また、この場合は、ステップＳ１６０の処理を行なわないので、ｋ（２）は＋１インクリメントされない。よって、「要素の並び」における次の次の要素である「個人情報／電話」に関する処理では、ステップＳ１５９で、再び、配列ｔａｇＡｒｒａｙ（２，３）＝‘４’との比較が行われる。このときは、ｍ（２）＝４となっているので、ステップＳ１５９の判定はＹＥＳとなる。
以上説明した非定型ＸＭＬ文書に対する２通りの手法、すなわち第２の実施例、第３の実施例を、先出願の手法と比較した場合、以下の特徴がある。
まず、先出願では、たとえ短縮文字列を使う場合でも、各レコード毎に逐一短縮文字列をタグ内の属性として指定しなければならず、冗長であると共に、短縮文字列と要素名との対応関係ファイル等を参照しなければならない。
これに対して、第２の実施例では、ヘッダに、付加情報として、出現し得る全ての要素の要素名を記述し、各レコードにおいて、出現しなかった要素は、空要素としているだけで、要素名と要素内容との対応関係を定義できる。
また、第３の実施例では、上記付加情報を用いるが、各レコードのタグ内に属性を記述しなければならない。しかし、この属性は、出現順番をそのまま記述するので、コンピュータによって自動的に属性値を記述することができる。一方、先出願では、別途、対応関係ファイルを定義しなければならないので、手間が掛かる。
また、先出願では、変換後のＸＭＬ文書を応用ソフトで利用しない場合でも、逆変換処理を行なう際に、変換後のＸＭＬ文書内に記述された非キー要素のタグ名を切り出して、このタグ名と要素内容とから、非キー要素を復元していた。一方、第２の実施例、第３の実施例では、変換後のＸＭＬ文書内に非キー要素のタグ名が記述されていなくても、逆変換処理を実行できる。
また、第２の実施例と第３の実施例とを比較した場合の長短は、以下通りである。
第２の実施例の手法は、第１の実施例の手法の延長線上にあると見なすこともできる。第２の実施例では、選択出現候補要素（出現する可能性がある要素）全てについてＣＳＶ形式に併合・分離の操作をするため、選択出現候補要素がいずれも頻繁に出現する場合に有効である。
これに対して第３の実施例の手法は、属性値を用いて要素名と要素内容を対応させるものであり、方法的には複雑になるものの、選択出現候補要素中にめったに出現しないものが多数ある場合に有効となる。
上述した説明では、変換仕様ＸＭＬ文書２２に基づいて、直接、構造変換または逆変換処理を実行する場合について説明したが、上述してある通り、変換仕様ＸＭＬ文書２２に基づいて変換ＸＳＬシート１５、逆変換ＸＳＬシート１６を作成し、これらのＸＳＬシートを用いて、構造変換または逆変換処理を実行する構成であってもよい。この場合でも、実質的な処理内容は、上述したものと同様であるが、ここでは、図１９（ａ）〜（ｄ）に、第１の実施例を例にして、変換／逆変換ＸＳＬシートを用いる場合の概略的な処理手順を示しておくものとする。
尚、ここでは、第１の実施例に対応する例のみ示すが、第２、第３の実施例についても同様である。
まず、図１９（ａ）では、ＸＳＬ変換部１３は、変換仕様ＸＭＬ文書２２を読み込んで、この記述内容から変換仕様を解析して（ステップＳ１７１）、この解析結果と変換ＸＳＬシート生成ＸＳＬシート１４とを用いて、ＸＭＬ文書からＸＭＬ文書への変換の際にそのデータ構造を変換する為のスタイルシートである変換ＸＳＬシート１５を作成する（ステップＳ１７２）。また、同様に、図１９（ｂ）に示すように、ＸＳＬ変換部１３は、変換仕様ＸＭＬ文書２２を読み込んで、この記述内容から変換仕様を解析して（ステップＳ１８１）、この解析結果と、変換ＸＳＬシート生成ＸＳＬシート１４とを用いて、変換ＸＭＬ文書２３または抽出ＸＭＬ文書２４から元のＸＭＬ文書２１の文書形式に戻す為の逆変換処理に用いるスタイルシートである逆変換ＸＳＬシート１６を作成する（ステップＳ１８２）。
図２０、図２１に、それぞれ、図４に示す例の変換仕様ＸＭＬ文書２２を読み込んだ場合に生成される変換ＸＳＬシート１５、逆変換ＸＳＬシート１６の一例を示す。
そして、変換処理を行なう場合には、図１９（ｃ）に示すように、処理対象となる入力ＸＭＬ文書２１とこれに対応する変換ＸＳＬシート１５のファイル名等を指定することで（ステップＳ１９１）、当該変換ＸＳＬシート１５を用いて、実質的に図６のステップＳ１３〜Ｓ１８の処理（ステップＳ１７の処理は図８の処理）に相当する処理が実行されることになる（ステップＳ１９２）。
同様に、逆変換処理を行なう場合には、図１９（ｄ）に示すように、処理対象となる変換ＸＭＬ文書２３（抽出ＸＭＬ文書２４）とこれに対応する逆変換ＸＳＬシート１６のファイル名等を指定することで（ステップＳ２０１）、当該逆変換ＸＳＬシート１６を用いて、実質的に図６のステップＳ１３〜Ｓ１８の処理（ステップＳ１７の処理は図９の処理）に相当する処理が実行されることになる（ステップＳ２０２）。
次に、以下、図２２を参照して、変換仕様ＸＭＬ文書２２を作成する手順について説明する。
図２２に示すように、変換仕様ＸＭＬ文書２２の作成手順は、まず、レコードの要素名を〈ｒｅｃｏｒｄ〉要素で指定する（ステップＳ２１１）。
次に、〈ｉｔｅｍｓ〉の下の〈ｍｅｒｇｉｎｇ＿ｔａｇ〉要素で、新要素名（ＣＳＶ要素名）を指定する（ステップＳ２１２）。その際、第３の実施例の場合であって、上記非定型ＣＳＶ要素を指定する場合には、〈ｍｅｒｇｉｎｇ＿ｔａｇ〉タグにｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付ける。あるいは、第２、第３の実施例において、１個の非キー要素をまとめる新要素を“ｒｔａｇ”で指定したい場合には、〈ｒｅｐｌａｃｉｎｇ＿ｔａｇ〉を記述する。
次に、各「ｉｔｅｍ」要素を、レコード内で要素が出現する順に列挙する（ステップＳ２１３）。その際、「ｉｔｅｍ」要素によって定義する要素が、
・キー要素の場合は、属性ｍｔａｇ＝“＿ＯＲＧ”を指定する。
・非キー要素の場合は、この要素内容を格納すべきＣＳＶ要素名を属性ｍｔａｇで指定する。
・１個の非キー要素をまとめる新要素を指定したい場合には、〈ｒｅｐｌａｃｉｎｇ＿ｔａｇ〉で記述した新要素名の何れかを、属性ｒｔａｇで指定する。
・その要素がレコード内で階層を持つ場合には、その階層を属性ｐａｔｈで指定する。
・応用ソフト３０中で、非キー要素名を別名で扱いたい場合には、属性ｎａｍｅで別名を指定する。
・第２の実施例の場合において、その要素の要素内容が固定的な出現をしないことを指定したい場合には、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付ける。
尚、「レコード内で」という場合には、入力ＸＭＬ文書２１における話であるものとする。
上記のような変換仕様を用いることによって、これに基づいて作成された変換ＸＭＬ文書２３は、応用ソフト３０で扱い易いものとなる。
図２３、図２４の、応用ソフト３０のＪ  Ｓｃｒｉｐｔプログラムの一例を示す図である。
尚、図２３、図２４に示す処理内容は、一般的且つ単純な内容であり、これ自体に特に意味があるわけではないが、以下、図２３、図２４に示すプログラムの処理内容について概略的に説明しておく。図２３、図２４のプログラムは、何れもＡ氏のＣＳＶ新要素「連絡」を読出す例であるが、図２３は図１０に示す変換ＸＭＬ文書、図２４は図１６に示す変換ＸＭＬ文書を処理対象としていることから、多少、プログラムの記述が違っているが、その処理の目的はほぼ同じであるので、以下、図２４のプログラムについてのみ、概略的に説明する。
Ｓｔｅｐ１：  ヘッダの付加情報を読取り、ＣＳＶ要素に纏められた要素名を分離し、要素名の配列に格納する。
Ｓｔｅｐ２：  Ａ氏の非キー要素を纏めたＣＳＶ要素「連絡」を読取り、ＣＳＶ要素に纏められた要素の名前を分離し、要素内容の配列に格納する。
Ｓｔｅｐ３：  ＣＳＶ要素「連絡」の要素内容を読取り、分離して配列に格納する。
Ｓｔｅｐ４：  ＣＳＶ要素「連絡」の属性として、対応する要素名の順番を読取り、分離して配列に格納する。
Ｓｔｅｐ５：  ＣＳＶ要素「連絡」の要素名順番の配列から読出した順番によって要素名配列を読出し、それを引数とする連想配列の連絡に、対応するＣＳＶ要素「連絡」の要素内容を格納する。
尚、図２３には、更に、連想配列ａｓｓｏｃＡｒｒａｙ［“会社電話”］の要素内容を、“１２３”から“２３４”に変更する処理が加わっている。
これらの例で特徴的なことは、付加情報により変換文書が自己記述的になったため、元文書のレコード項目が増え、ＣＳＶ要素に纏める非キー要素が増えたとしても、要素名で要素内容をアクセスしているため、図２３、図２４のプログラムはそのまま使えることである。このようにＸＭＬ文書の自己記述性がもたらす柔軟性を引き継ぐようになる。
以上説明したように、本発明は、基本的に、上記先出願の特徴・効果に加えて、以下に述べる特徴と備える。
（Ａ）応用ソフトが非キー要素を処理対象とする場合の扱い易さについて
上記のように、先出願では、応用ソフトが非キー要素を処理対象とする場合が有り得ることを、想定していない。
本発明では、複数個のＣＳＶ要素を同一階層（例えば、レコード内の第１階層）に配置し、各非キー要素をこれら複数のＣＳＶ要素の何れかに割当てるようにすると共に、その割り当て方は、元のＸＭＬ文書の階層構造に関係なく、自由に割り当てることができる。例えば用途に応じて分類した非キー要素を、用途毎に用意された各ＣＳＶ要素に格納することができる。これによって、応用ソフトウェアで、想定外に、非キー要素を用いるデータ処理を行なう必要が生じた場合でも、扱い易いものとなり、更に、非キー要素の数が非常に多くても、ＣＳＶ要素数を増やし、１つのＣＳＶ要素に格納する非キー要素数を減らすことにより、必要なＣＳＶ要素のみ展開する際に、オーバーヘッドを減らすことができる。
（Ｂ）変換仕様に基づきレコード内要素順序を保存
変換／逆変換後にレコード内の要素の順序を保存するために、変換仕様においてレコード内での要素の順序を定義する。このようにすることで、変換後に順序が不明になっても、逆変換時に順に並べ替えて出力することができ、内容だけでなく、順番も、元通りにすることができる。
（Ｃ）変換文書の自己記述性
一般的に、ＸＭＬ文書は自己記述型であることに特徴がある。
先出願では、非定型のＸＭＬ文書に関して、各レコード毎、各ＣＳＶ要素毎に、逐一、要素名（または短縮文字列）と要素内容との対応関係を、変換後のＸＭＬ文書に記述していた。これによって、逆変換処理の際に、要素名と要素内容とを切り出して、これらを用いて元の非キー要素を復元していた。また、応用ソフトウェアにおいて処理を行なう際に、要素名と要素内容との対応関係が分かる。しかしながら、要素名を記述する場合は冗長となり、冗長とならないように短縮文字列を記述する場合には、別途、要素名と短縮文字列との対応関係を参照する必要があった。
本発明では、変換後のＸＭＬ文書において、全てのレコードに共通の定義として、各ＣＳＶ要素毎に、そのＣＳＶ要素に格納し得る全ての要素の要素名、換言すればそのＣＳＶ要素に係わりレコード内に出現する可能性のある全ての要素の要素名、を出現順に記述した付加情報を与える。
そして、各ＣＳＶ要素毎に、そのＣＳＶ要素に係わる要素の要素内容を順に格納する際に、各レコード毎に、そのレコードにおいてどの要素が記述されていなかったのか示すようにしている。例えば、その要素が記述されていなかった場合には、空要素として、この空要素を他の要素内容と同様にＣＳＶ形式で繋ぐようにする。あるいは、例えば、ＣＳＶ要素のタグの属性として、ＣＳＶ要素内に実際に格納された要素、すなわち実際にそのレコード内に出現した要素の当該ＣＳＶ要素内での出現順番を、ＣＳＶ形式で繋いだものを記述する。
上記の通り、付加情報には、出現する可能性のある全ての要素の要素名を、出現順に記述している。よって、この順番に従って、各要素内容と要素名との対応関係が分かる。また、空要素の位置に対応する要素名、または属性に記述されていない出現順番に対応する要素名の要素は、そのレコードに関しては、変換前のＸＭＬ文書に記述されていないことが分かる。
このようにすることで、応用ソフトウェアが変換後のＸＭＬ文書を用いた処理を実行する際、その付加情報を参照すれば、元文書と同様にデータ処理ができるようになる。また、上記空要素を用いる方法では、更に、ＣＳＶ要素のタグの属性を付ける必要がなくなる。また、本例では、逆変換処理の際に、付加情報を参照する必要はない。よって、応用ソフトウェアでの非キー要素の利用を考えない場合には、付加情報は特に必要ない。
ＥＤＩのデータは、１レコードで数百〜千項目あり、項目数が多過ぎるのでＤＯＭ展開に向かない。文書要素を切り出して時系列に流すだけの標準ＡＰＩ（ＳＡＸ：Ｓｉｍｐｌｅ  ＡＰＩ  ｆｏｒ  ＸＭＬ）を用いており、複雑な文書操作が難しくなっている。しかし、数百の要素は一つ一つの応用ソフトでは全部の要素にアクセスすることはない。本発明によれば、応用ソフトの都合に応じて、その処理に用いる非キー要素を含むグループ（新要素）のみを展開できるので、オーバーヘッドが大きくなることを防止し、実用的になる。また、要素の並び順の見た目も保存する完全な可逆変換とすることができる。
また、階層の深いＸＭＬ文書で、レコード内だけで頻繁に使う要素を、少ない非キー要素数のグループでＣＳＶ要素にまとめれば、一階層要素のＣＳＶ分解だけで読めるので、読出しが速くなる効果もある。ただし、このやり方は、元のＸＭＬ応用ソフトのトランスペアレント性を壊すことになるが、ＣＳＶファイルとして使っていた応用ソフトでの使い方に近くなる。
以上、本発明の実施の形態について説明したが、本発明は、上述した説明の例に限るわけではない。
例えば、上記の例では、非キー要素の要素名、要素内容を、ＣＳＶ形式で繋ぐ際、区切り記号としてコンマを用いて繋いでいる。これは、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）は、本来、コンマを介して、数値や文字列を繋ぐ方法であり、一般的には、区切り記号はコンマに限られる為である。
しかしながら、本発明においては、区切り記号は、コンマに限らないものとする。区切り記号にコンマを用いた場合は、要素内容が金額であって、千の位を表すコンマが数値に付けられる場合は、むしろ、コンマより、”＠”（アットマーク）や”＿”（アンダーバー）を用いることになる。あるいは、めったに出現することがない２文字の文字列でもいい。文字列中にある区切り記号の文字は、実体参照のような識別できる形に置き換えることになる。例えば、コンマは、”＆ＣＭＭ；”と置く。従って、区切り記号は、通常の文字列に、めったに現れない文字／文字列であることが望ましい。
以上述べたように、本発明においては、コンマに限らず、区切り記号／記号列を介して、数値や文字列を繋ぐ方法を、便宜上、ＣＳＶ形式と呼ぶことにする。
また、本発明は、非キー要素複数個を幾つかグループごとにまとめて一つずつの要素にし、応用ソフトがデータ処理する間に一括して扱えるようにする方法である。
このため、非キー要素の要素名をＣＳＶ形式に繋いで、新要素の要素名に置くか、属性に置くかを選ぶことができる。また、非キー要素の要素内容をＣＳＶ形式に繋いで、新たな要素の属性に置くか、要素内容に置くかを選ぶことができる。これらは、データ量や、データ処理の際に新たな要素が幾つ増えるかに関係するが、非キー要素複数個をグループごとにひとまとめにして扱うという本発明の本質からは、新要素の属性、要素内容のどこに置くか、どの方法でも採り得る。
本発明の変換文書中で、（ａ）変換仕様または逆変換ソフトと、（ｂ）ＣＳＶ要素にまとめられた要素の情報を指定した。これらの情報は、元の文書にはなかったものなので、変換文書中にリンクを付けて外部ファイルとして与えてもいい。また、元の文書とは別の情報であるので、変換文書に置くときには、特別な名前空間（ｎａｍｅｓｐａｃｅ）を付して識別できるようにしてもよい。
次に、以下、本発明の第４の実施例について説明する。
上述した通り、第２、第３の実施例では、非定型の構造化文書に対応して、ＣＳＶ要素に纏めた要素も後で応用ソフトが使えるように、用途ごとに複数のＣＳＶ要素を定義して要素内容を格納していた。また、要素名は、ヘッダの付加情報との対応関係を示すだけに留め、各レコードには要素名は入らないので、ＸＭＬ文書の展開時のノード数を減らすことができ、メモリ使用量の削減、展開時間の短縮は図れる効果があった。また、変換仕様のＸＭＬ文書に逆変換時の要素の並び順を指定しており，変換ＸＭＬ文書の要素の並び順を保存して復元できる効果があった。
ところで、非定型ＸＭＬ文書には、上記図１０に示した例のように非定型要素がレコードの一部分にしか現れないタイプ以外にも、例えば図２５に示す製品リストのＸＭＬ文書の例のように、レコード（部品）の種類によってレコード項目が入れ替わるために、非定型要素がレコードの大部分を占めるタイプ（表形式では表現が困難なタイプ）がある。
図２５に示す非定型ＸＭＬ文書の例は、製品カタログの例であり、＜部品＞が１つのレコードを示し、その属性“種類”によってそのレコード（部品）の種類を定義している。この例では、“ＣＰＵ”、“ハードディスク”、“メモリ”の３種類である。そして、部品の種類＝“ＣＰＵ”に係わるレコード項目（要素）のタグ名は、商品名、型番、ＣＰＵ、クロック、キャッシュ容量である。部品の種類＝“ハードディスク”に係わるレコード項目のタグ名は、商品名、型番、ディスク容量、転送速度、回転数である。部品の種類＝“メモリ”に係わるレコード項目のタグ名は、商品名、型番、メモリ容量、ベースクロック、電源電圧となっている。
このように、図２５に示す非定型ＸＭＬ文書の例では、レコード（部品）の種類によってレコード項目が大きく異なっている。つまり、非定型要素が大部分を占めるようになっている。
図２５に示す例のような非定型ＸＭＬ文書に対して上記第２の実施例の手法を適用した場合の変換仕様ＸＭＬ文書２２を図２６に示し、この変換仕様ＸＭＬ文書２２を用いて図２５の非定型ＸＭＬ文書を変換した結果である変換ＸＭＬ文書２３を図２７に示す。
図２６に示す変換仕様ＸＭＬ文書２２の例では、レコード（部品）の種類“ＣＰＵ”、“ハードディスク”、“メモリ”の全てに共通する要素である「商品名」と「型番」はキー要素とし、これら以外の要素を非キー要素とすると共にその全てにｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付している。つまり、非キー要素は、全て非定型要素として指定される。また、ＣＳＶ要素名（ＣＳＶ要素のタグ名）を記述する「ｍｅｒｇｉｎｇ＿ｔａｇ」の要素内容は、それぞれ“ＣＰＵ情報”、“ＨＤ情報”、“メモリ情報”としている。
また、上記各非キー要素に係わる各「ｉｔｅｍ」要素における属性「ｍｔａｇ」では、その非キー要素が関係するレコード（部品）の種類に対応する上記ＣＳＶ要素名を指定する。つまり、例えば、非キー要素「ディスク容量」の場合は、属性「ｍｔａｇ」で“ＨＤ情報”を指定する。
このように、上記図２６の変換仕様ＸＭＬ文書２２では、出現可能な全要素を抱え込むことになる。この為、変換／逆変換時（図１３の処理）の処理負荷が大きくなる。つまり、例えば種類＝“ハードディスク”のレコードに対する処理を例にすると、このレコードに関する非キー要素はディスク容量、転送速度、回転数のみであるにも係わらず、他の非キー要素についても処理を実行する為、処理負荷が重くなる。また、その結果、変換ＸＭＬ文書２３では、図２７に示すように、他の種類、すなわちＣＰＵ情報、メモリ情報に係わる非キー要素は、全て空要素として出力される（例えば、＜ＣＰＵ情報＞，，＜／ＣＰＵ情報＞）ので、無駄に情報量が増えることになる。つまり、全部が空要素のＣＳＶ要素が含まれてしまい、要素数が効果的に削減できない。
一方，逆変換時（図１４の処理）には，非キー要素に関しては、出現可能な全要素の中から要素内容のある要素のみ出力し、空の要素内容の要素は出力を止める処理を行う為、出現可能な全要素の要素内容の有無の検査が必要となるので、やはり、処理負荷が増大する。
上記の例では、レコードの種類は３種類であったが、種類が増えれば増えるほど、処理負荷は増大していく。
このようなタイプの非定型ＸＭＬ文書に対して、第４の実施例では、以下に説明する２つの手法を提案する。
まず、第４の実施例（その１）について説明する。
第４の実施例（その１）では、主に、変換ＸＭＬ文書に無駄な記述、すなわち全部が空要素のＣＳＶ要素が含まれないようにする。
第４の実施例（その２）では、これに加えて更に、変換／逆変換時の処理負荷を軽減する。
まず、第４の実施例（その１）について説明する。
本例では、図２８に示す変換仕様ＸＭＬ文書を用いる。
図２８に示す変換仕様ＸＭＬ文書を、図２６と比較すると、その違いは、「ｍｅｒｇｉｎｇ＿ｔａｇ」要素においてｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付している点である。
ＸＳＬ変換部１３がこの変換仕様ＸＭＬ文書を用いて作成する変換ＸＳＬシート１５の一例を図２９、図３０に示す。また、本例による変換ＸＭＬ文書２３の一例を図３１に示す。
尚、図２９、図３０は、１つの変換ＸＳＬシートを２つに分けて示しているだけであり、変換ＸＳＬシートの前半部分を図２９に、後半部分を図３０に示している。
図２８に示す変換仕様ＸＭＬ文書を用いて変換処理を行った場合、基本的には第２の実施例と略同様の処理を行うことになるが、図１３のステップＳ８１の処理が異なる。すなわち、上記の通り、図２８に示す変換仕様ＸＭＬ文書では、「ｍｅｒｇｉｎｇ＿ｔａｇ」要素にｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付してある。既に説明してあるように、例えばステップＳ７３の処理では、キー要素に関する「ｉｔｅｍ」要素のタグに、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性が付いており、且つ入力ＸＭＬ文書２１においてこのキー要素が記述されていない場合には、このキー要素はコピーして出力する処理は行わないようにする。本例では、これと同様に、ステップＳ８１において、「ｍｅｒｇｉｎｇ＿ｔａｇ」要素にｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付してあり、且つステップＳ８０の処理結果（要素内容をＣＳＶ形式で繋ぐ）が全て空要素であった場合には、ステップＳ８１の処理を行わないようにする。つまり、ステップＳ７８〜Ｓ８０の処理、すなわち要素内容をＣＳＶ形式で繋ぐ処理は行うものの、これを変換ＸＭＬ文書に出力しないようにする。
変換ＸＳＬシートでは、図３０におけるｉｆ  ｔｅｓｔ文、例えば〈ｘｓｌ：ｉｆ  ｔｅｓｔ＝“ｎｏｔ（＄ｃｎｔ０１＝＄ｅｍｐ０１）”〉
が、この処理に相当する。
これによって、変換ＸＭＬ文書は、図３１に示すように、無駄な記述、すなわち全部が空要素のＣＳＶ要素が含まれないようになる。
しかしながら、この方法では、上記の通り、変換ＸＭＬ文書に出力しないものであっても、一旦要素内容をＣＳＶ形式で繋いだ後で要素内容が全て空かどうかのチェックする処理を行うので、無駄な処理が発生する。つまり、上記処理負荷が増大するという問題が十分に解消されていない。
これは逆変換についても同様である。図３２、図３３に逆変換ＸＳＬシートの例を示す。尚、図３２、図３３は、１つの変換ＸＳＬシートを２つに分けて示しているだけであり、逆変換ＸＳＬシートの前半部分を図３２に、後半部分を図３３に示している。
図３２は、レコード部分以外の処理であるので、特に説明しない。
図３３に示す通り、逆変換時においては、各ＣＳＶ要素毎にＣＳＶ形式で纏めた各非キー要素内容を、〈ｖａｒｉａｂｌｅ〉によって変数”ｖａｒ０１０１”〜“ｖａｒ０３０３”に代入する。その際、要素内容が存在しない（空要素）ものについてはＮＵＬＬが入る。
例えば、図２７の文書が逆変換処理対象である場合であって最初のレコード（種類＝“ＣＰＵ”）に対する処理を行う場合には、例えば“ｖａｒ０１０１”には「Ｐｅｎｔｉｕｍ  ３，７００ＭＨｚ，２５６ＭＢ」が代入され、“ｖａｒ０１０２”には「７００ＭＨｚ，２５６ＭＢ」が代入され、“ｖａｒ０１０３”には「２５６ＭＢ」が代入されるが、“ｖａｒ０２０１”〜“ｖａｒ０３０３”にはＮＵＬＬが入ることになる。
そして、ｉｆ  ｔｅｓｔ文によって、各非キー要素毎に、その有無をチェックして出力するか否かを決める。
上記の例では、まず、＜ＣＰＵ＞に関しては、
ｉｆ  ｔｅｓｔ＝”ｓｕｂｓｔｒｉｎｇ−ｂｅｆｏｒｅ（＄ｖａｒ０１０１，’，’）”
によって、“ｖａｒ０１０１”に代入されている「Ｐｅｎｔｉｕｍ  ３，７００ＭＨｚ，２５６ＭＢ」において最初のカンマ（，）の前にはＰｅｎｔｉｕｍ  ３がある、つまりＮＵＬＬ（空要素）ではないので、Ｐｅｎｔｉｕｍ  ３が出力されることになる。
〈クロック〉に関しても、同様に、“ｖａｒ０１０２”に代入されている「７００ＭＨｚ，２５６ＭＢ」において最初のカンマ（，）の前にある７００ＭＨｚが出力されることになる。
〈キャッシュ容量〉に関しては、“ｖａｒ０１０３”には「２５６ＭＢ」が代入されているので、これを出力することになる。
一方、〈ディスク容量〉〜〈電源電圧〉については、変数“ｖａｒ０２０１”〜“ｖａｒ０３０３”にはＮＵＬＬが代入されているので、出力しないことになる。
尚、ｉｆ  ｔｅｓｔ，ｓｕｂｓｔｒｉｎｇ−ｂｅｆｏｒｅ等は、ＸＳＬＴにおいて一般的に知られているものであり、後にまとめて簡単に説明してある。
上記のような処理を行う為、該当するレコード種類以外のレコード項目は無駄にチェックを行う必要があり、処理の高速化を図ることはできない。
これに対して、第４の実施例（その２）では、例えば図３４に示す変換仕様ＸＭＬ文書では、レコードの種類ごとに入れ替わるレコード項目（要素）をそれぞれ分けて並べるとともに、切り替わる条件を付けることによって、変換／逆変換時にその条件によって要素並びを切り替えることで、非定型要素の無駄な有無チェックを除くものである。
つまり、図３４に示す変換仕様ＸＭＬ文書４０では、レコードの種類ごとに出現する要素を分けて指定するようにしており、レコード種類ごとのレコード項目のリスト〈ｉｔｅｍｓ〉は”ｗｈｅｎ”属性の条件付で切り替えるようにしている。”ｗｈｅｎ”属性の属性値は、そのまま変換／逆変換用ＸＳＬシートに記述される切り替え条件として利用される。このため、この属性値はＸＳＬシートの条件式に則って記述される。つまり、変換／逆変換用ＸＳＬシートのプログラム言語の表記法に合わせて、変換仕様ＸＭＬ文書４０における切り替え条件を記述することになる。
逆に、この属性値がそのまま変換／逆変換用ＸＳＬシートに反映されるので、複数個の要素内容、属性値のＡＮＤ、ＯＲを取った複雑な条件指定も可能となる。
図３４に示す変換仕様ＸＭＬ文書を用いて変換／逆変換処理を行うと、全体の処理フローは図６又は図７と同じであるが、そのステップＳ１７又はステップＳ２８の処理の詳細は、図３５の処理となり、更に図３５のステップＳ３０２の詳細フローを図３６〜図３９に示す。変換処理は、図３６又は図３７、逆変換処理は図３８又は図３９を行う。
図３６〜図３９の処理は、図８、図１３、図９、図１４の処理とほぼ同じであるが、異なる点は、“変換仕様中の”が“レコード項目リスト中の”に代わっている点である。つまり、図３５のステップＳ３０１の処理によって、変換仕様ＸＭＬ文書４０中の各レコード項目リスト４１、４２、４３の中から、処理対象のレコードに該当するレコード項目リストが選択されるので、ステップＳ３０２の処理では、変換仕様ＸＭＬ文書４０の全てを用いることなく、選択されたレコード項目リストのみを用いるので、“変換仕様中の”が“レコード項目リスト中の”に代わることになる。
例えば、処理対象が図２５のＸＭＬ文書中の部品種類が“ハードディスク”のレコードである場合には、ステップＳ３０１において変換仕様ＸＭＬ文書４０中のレコード項目リスト４２が選択されることになる。よって、選択されたレコード項目リスト４２についてのみ図８、図１３、図９、図１４の処理を行うこと、すなわち図３６〜図３９の処理を行うことにより、処理対象のレコードには関係のない要素についてまで無駄な処理を行う、ということが無くなり、処理効率が向上し、処理負担が軽減される。
尚、図８、図９は、第１の実施例、すなわち定型ＸＭＬ文書に係わる処理であるが、本例では選択したレコード項目リスト４２内にはｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”となる要素、つまり“固定的な出現をしない”要素は存在しないので、第１の実施例の処理を流用しても構わないことになる。但し、これは一例であり、選択したレコード項目リスト４２内にｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”となる要素が存在する構成であってもよい。この場合、変換ＸＭＬ文書には、第２の実施例のように空要素を出力してもよいし、第３の実施例のように属性に出願順番を記述する出力形式であってもよい。
また、当然、ＸＳＬ変換部１３が、図３４に示す変換仕様ＸＭＬ文書に基づいて、図４０（ａ）のステップＳ３９１、Ｓ３９２、図４０（ｂ）のステップＳ４０１、Ｓ４０２の処理によって、変換ＸＳＬシート１５、逆変換ＸＳＬシート１６を作成し、これらを用いて、変換／逆変換処理を実行するようにしてもよい。
ＸＳＬ変換部１３による処理は、基本的にはＸＳＬの仕様に合わせて置き換えを行うだけであるので特に説明しないが、例えば変換ＸＳＬシート１５生成処理は、図３４、図４１に示す例では、図３４の変換仕様ＸＭＬ文書においてｉｔｅｍｓ要素が出てくる毎に、そのｗｈｅｎ属性の内容（最初のレコードでは“＠種類＝‘ＣＰＵ’”を、そのまま、〈ｘｓｌ：ｗｈｅｎ  ｔｅｓｔ＝に当て嵌めればよい。ｉｔｅｍ要素において属性ｍｔａｇで“＿ＯＲＧ”が指定されているものは、その要素内容を、〈ｘｓｌ：ｃｏｐｙ−ｏｆ  ｓｅｌｅｃｔ＝に当て嵌めればよい。ｉｔｅｍ要素において属性ｍｔａｇでＣＳＶ要素名が指定されているものは、その要素内容を、ｃｏｎｃａｔによって連結すればよい。
図４２に示す逆変換ＸＳＬシートについても、同様であり、ｖａｒｉａｂｌｅ、ｃｏｐｙ−ｏｆ、ｖａｌｕｅ−ｏｆ等の予め用意されているテンプレートに対して、変換仕様ＸＭＬ文書のｍｅｒｇｉｎｇ＿ｔａｇ要素、ｉｔｅｍ要素の属性（“＿ＯＲＧ”やＣＳＶ要素名）に応じて、その要素内容（ＣＰＵ情報、商品名、型番、ＣＰＵ、クロック、キャッシュ容量等）を当て嵌めていけばよい。勿論、ｖａｒｉａｂｌｅ文、ｃｏｐｙ−ｏｆ文の数は、それぞれ、変換仕様ＸＭＬ文書にある非キー要素、キー要素の数に応じたものとする。
そして、変換時には、図４０（ｃ）に示すように、処理対象となる入力ＸＭＬ文書２１とこれに対応する変換ＸＳＬシート１５のファイル名等を指定することで（ステップＳ４１１）、当該変換ＸＳＬシート１５を用いて、実質的に図７のステップＳ２３〜Ｓ２９の処理（ステップＳ２８の処理は図３５と更に図３６又は図３７の処理）に相当する処理が実行されることになる（ステップＳ４１２）。
同様に、逆変換処理を行なう場合には、図４０（ｄ）に示すように、処理対象となる変換ＸＭＬ文書２３（抽出ＸＭＬ文書２４）とこれに対応する逆変換ＸＳＬシート１６のファイル名等を指定することで（ステップＳ４２１）、当該逆変換ＸＳＬシート１６を用いて、実質的に図６のステップＳ１３〜Ｓ１８の処理（ステップＳ１７の処理は図３５と更に図３８又は図３９の処理）に相当する処理が実行されることになる（ステップＳ４２２）。
図４０（ａ）、（ｂ）の処理によって作成される変換ＸＳＬシート１５、逆変換ＸＳＬシート１６の一例を図４１、図４２に示す。尚、図４１においてはその前半部分は図２９と同じであるので省略して示している。同様に、図４２においてはその前半部分は図３２と同じであるので省略して示している。
図４１、図４２では、図３４の変換仕様ＸＭＬ文書中の〈ｉｔｅｍｓ〉で示したレコード種類ごとの要素並びが、〈ｃｈｏｏｓｅ〉−〈ｗｈｅｎ〉〈ｏｔｈｅｒｗｉｓｅ〉の条件によって切り替えられる形式となる。〈ｃｈｏｏｓｅ〉、〈ｗｈｅｎ〉、〈ｏｔｈｅｒｗｉｓｅ〉についてはＸＳＬＴスタイルシートのプログラムとしてよく知られているので、ここでは特に詳細には説明しないが、簡単に説明するならば、〈ｃｈｏｏｓｅ〉はＸＳＬＴにおいて複数の条件を選択して処理する為に用いられるものであり、〈ｃｈｏｏｓｅ〉文において〈ｗｈｅｎ〉は必須、〈ｏｔｈｅｒｗｉｓｅ〉は任意の要素である。ＸＳＬＴプロセッサは、ｘｓｌ：ｗｈｅｎを順番に評価していき、ｘｓｌ：ｗｈｅｎのｔｅｓｔ属性の値が真となる最初のｘｓｌ：ｗｈｅｎ要素のテンプレートのみを処理する。もし該当するｘｓｌ：ｗｈｅｎ要素が１つもない場合には、ｘｓｌ：ｏｔｈｅｒｗｉｓｅ要素のテンプレートを処理するが、これは上記の通り必須要素ではないので、無くても構わない。
他のＸＳＬＴプログラム関数についても、同様に、よく知られているので、ここでは特に詳細には説明しないが、簡単に説明するならば、〈ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ〉によって指定したタグ名の要素の要素内容をＸＭＬ文書から取り出すことができる。また、〈ｖａｒｉａｂｌｅ〉は変数の定義を行う。変数の値を参照するときは、変数名の頭に“＄”を付ける。〈ｃｏｎｃａｔ〉は文字列を繋げて１つの文字列を作るものとして知られている。〈ｃｏｐｙ−ｏｆ  ｓｅｌｅｃｔ〉は、〈ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ〉が指定されたノードの値を文字列として出力するのに対して、ノードを子要素も含めてそのままコピーして出力する。〈ｉｆ  ｔｅｓｔ〉を用いると、単純なｉｆ−ｔｈｅｎ（〜に該当すれば〜を実行する）型の条件処理を行う。文字列の中で特定の文字以降を抜き出すためには〈ｓｕｂｓｔｒｉｎｇ−ａｆｔｅｒ〉を使用する。文字列の中で特定の文字より前を抜き出すためには〈ｓｕｂｓｔｒｉｎｇ−ｂｅｆｏｒｅ〉を使用する。“＠”は属性、“＠＊”は全ての属性を意味する。
図４１、図４２において、上記の通り、切り替え条件である〈ｗｈｅｎ〉のｔｅｓｔ属性値の評価式（例えば“＠種類＝‘ＣＰＵ’”等）は、変換仕様ＸＭＬ文書中で指定した〈ｉｔｅｍｓ〉のｗｈｅｎ属性値の評価式を、そのまま使う。これによって，複数個の要素／要素内容／属性／属性値のＡＮＤ／ＯＲ等の複雑な条件指定が可能になる。
最後に、図３４の変換仕様ＸＭＬ文書の作成フローを図４３に示す。
図４３において、まず、レコードの要素名を〈ｒｅｃｏｒｄ〉要素で指定する（ステップＳ４３１）。次に、全てのレコード項目リストを記述するまで（ステップＳ４３２）、ステップＳ４３３〜Ｓ４３５の処理を繰り返し実行する。
すなわち、まず、レコード要素リストの条件を指定する（ステップＳ４３３）。これは、レコード項目リスト要素〈ｉｔｅｍ〉を記し、そのレコード項目リストの条件を、〈ｉｔｅｍｓ〉の属性ｗｈｅｎに、ＸＳＬ表記で記述する。
次に、ＣＳＶ要素の指定を行う（ステップＳ４３４）。これは、〈ｉｔｅｍｓ〉の下の〈ｍｅｒｇｉｎｇ＿ｔａｇ〉要素によってＣＳＶ要素名を指定する。その際、ｆｏｒｍａｔ＝”ｕｎｆｉｘｅｄ”の属性を付ける。
最後に、レコード項目の指定を行う（ステップＳ４３５）。これは、〈ｍｅｒｇｉｎｇ＿ｔａｇ〉の次に〈ｉｔｅｍ〉要素を並べ、レコード内の要素が出現する順にレコード内要素の要素名を列挙する。属性を対象とする場合は、〈ｉｔｅｍ〉の要素内容として属性を識別する“＠”に続けて属性名を指定する。キー要素の場合は、属性ｍｔａｇ＝“＿ＯＲＧ”を指定する。非キー要素の場合、属性ｍｔａｇで何れかのＣＳＶ要素名を指定する。各要素が非定型ならば、属性ｆｏｒｍａｔ＝“ｕｎｆｉｘｅｄ”で指定する。その要素がレコード内で階層を持つ場合は、その階層を属性ｐａｔｈで指定する。
図４４は、本実施の形態による構造化文書変換方法を実現するコンピュータのハードウェア構成の一例を示す図である。
同図に示すコンピュータ１００は、ＣＰＵ１０１、メモリ１０２、入力装置１０３、出力装置１０４、外部記憶装置１０５、媒体駆動装置１０６、ネットワーク接続装置１０７等を有し、これらがバス１０８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。
ＣＰＵ１０１は、当該コンピュータ１００全体を制御する中央処理装置である。
メモリ１０２は、プログラム実行、データ更新等の際に、外部記憶装置１０５（あるいは可搬型記録媒体１０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、メモリ１０２に読み出したプログラム／データを用いて、上述してある各種処理、機能（図６〜図９、図１３〜図１４、図１７〜図１９等に示す処理等や、図２に示す各機能部の機能）を実現する。尚、データとは、上記各種ＸＭＬ文書、ＸＳＬシート等である。
入力装置１０３は、例えばキーボード、マウス、タッチパネル等である。
出力装置１０４は、例えばディスプレイ、プリンタ等である。
外部記憶装置１０５は、例えば磁気ディスク装置、光ディスク装置、光磁気ディスク装置等であり、上記本発明の各種機能を実現させる為のプログラム／データ等が格納されている。
媒体駆動装置１０６は、可搬型記録媒体１０９に記憶されているプログラム／データ等を読み出す。可搬型記録媒体１０９は、例えば、ＦＤ（フレキシブルディスク）、ＣＤ−ＲＯＭ、その他、ＤＶＤ、光磁気ディスク等である。
ネットワーク接続装置１０７は、ネットワークに接続して、外部の情報処理装置とプログラム／データ等の送受信を可能にする構成である。
図４５は、上記プログラム等を記録した記録媒体、ダウンロードの一例を示す図である。
図示のように、上記本発明の機能を実現するプログラム／データが記憶されている可搬型記録媒体１０９から情報処理装置１００側に読み出して、メモリ１０２に格納し実行するものであってもよいし、また、上記プログラム／データは、ネットワーク接続装置１０７により接続しているネットワーク（インターネット等）を介して、外部のサーバ１１０の記憶部１１１に記憶されているプログラム／データをダウンロードするものであってもよい。
また、本発明は、装置／方法に限らず、上記プログラム／データを格納した記録媒体（可搬型記録媒体１０９等）自体として構成することもできるし、上記プログラム自体として構成することもできる。
【産業上の利用の可能性】
以上、詳細に説明したように、本発明の構造化文書変換／逆変換方法、そのシステム／装置、プログラム等によれば、レコード内の要素を、応用ソフトで扱うキー要素と、それ以外の非キー要素に分けて、キー要素はそのままとし、非キー要素はＣＳＶ形式で繋ぐように変換することで、変換後のＸＭＬ文書を既存の応用ソフトで利用可能とすると共に、汎用の方法としてデータ処理のメモリ使用量、処理時間を削減することができると共に、更に、応用ソフトで非キー要素を扱う事態が生じた場合でもオーバーヘッドが大きくなることなく、あるいは逆変換結果が元のＸＭＬ文書の要素の並びの順となり、あるいは非定型文書においてレコード数が多い場合、非キー要素の要素数が多い場合でも、冗長になることなく、変換後でも自己記述性を維持できるようになる。
2004061713.tif 000003
【図２】
2004061713.tif 000004
【図３】
2004061713.tif 000005
【図４】
2004061713.tif 000006
【図５】
2004061713.tif 000007
【図６】
2004061713.tif 000008
【図７】
2004061713.tif 000009
【図８】
2004061713.tif 000010
【図９】
2004061713.tif 000011
【図１０】
2004061713.tif 000012
【図１１】
2004061713.tif 000013
【図１２】
2004061713.tif 000014
【図１３】
2004061713.tif 000015
【図１４】
2004061713.tif 000016
【図１５】
2004061713.tif 000017
【図１６】
2004061713.tif 000018
【図１７】
2004061713.tif 000019
【図１８】
2004061713.tif 000020
2004061713.tif 000021
【図２０】
2004061713.tif 000022
【図２１】
2004061713.tif 000023
【図２２】
2004061713.tif 000024
【図２３】
2004061713.tif 000025
【図２４】
2004061713.tif 000026
【図２５】
2004061713.tif 000027
【図２６】
2004061713.tif 000028
【図２７】
2004061713.tif 000029
【図２８】
2004061713.tif 000030
【図２９】
2004061713.tif 000031
【図３０】
2004061713.tif 000032
【図３１】
2004061713.tif 000033
【図３２】
2004061713.tif 000034
【図３３】
2004061713.tif 000035
【図３４】
2004061713.tif 000036
【図３５】
2004061713.tif 000037
【図３６】
2004061713.tif 000038
【図３７】
2004061713.tif 000039
【図３８】
2004061713.tif 000040
【図３９】
2004061713.tif 000041
2004061713.tif 000042
【図４１】
2004061713.tif 000043
【図４２】
2004061713.tif 000044
【図４３】
2004061713.tif 000045
【図４４】
2004061713.tif 000046
【図４５】
2004061713.tif 000047
2004061713.tif 000048
2004061713.tif 000049
2004061713.tif 000050
【国際調査報告】
2004061713.tif 000051
2004061713.tif 000052
2004061713.tif 000053
2004061713.tif 000054