JP4786695B2 - 構造化文書の構造変換装置 - Google Patents

Description

本発明は、ＸＭＬ文書からＸＭＬ文書への構造変換/逆変換を行なう方法、装置等に に関する。

近年、インターネットを通して、個人、企業、自治体など、あらゆる種類のシステムが相互に通信可能に接続されており、これらのシステムが相互に連携して、Ｗｅｂサービスが提供されたり、ＥＤＩ（Electronic Data Interchange）、ＥＣ（Electronic Commerce）が行われつつある。このために、幅広い情報交換が必要になってきている。

このような状況下において、ＸＭＬ(eXtensible Markup Language)は、データを構造化する柔軟な表現能力を有し、コンピュータによる処理に適しているので、上記のシステム間のデータ交換や各システムでのデータ処理を行う際の、共通基盤のフォーマットとして注目されている。

ＸＭＬは、１９８６年にＩＳＯで標準化されたＳＧＭＬ(Standard Generalized Markup Language)を、インターネットで活用し易くするために、１９９８年２月にその基本仕様ＸＭＬ1.0がＷ３Ｃ(World Wide Web Consortium)において策定されたものである。

従来より用いられているＷｅｂページ作成言語であるＨＴＭＬ(HyperText Markup Language)は、タグが固定で表示に特化したものとなっており、タグ情報を基にコンピュータで情報を処理したいという要件に対応できない問題があった。

これに対して、ＸＭＬは、利用者が自由にタグを定義でき、文書中の文字列に意味付けができる言語構造を有している。このようなＸＭＬで文書を記述した場合、その文書を、タグ情報に基づいてコンピュータで情報処理できる。

尚、ＸＭＬ文書は、その特徴によって、次の２種類の型に大きく分類される。
・データ型ＸＭＬ文書：伝票、予定表など、タグ数が多く、要素内容が短いもの
・文書型ＸＭＬ文書；雑誌、マニュアル、辞典等、要素内容が長い文章になるもの
ここでは、主に、データ型ＸＭＬ文書を対象にするものとする。

ここで、以下の説明で使用される用語について、ＸＭＬ規格に基づき説明しておく。よく知られていることであるが、一対の”<”と”>”で囲まれた文字列を「タグ」、”<文字列>”を「開始タグ」、”</文字列>”を「終了タグ」、開始タグから終了タグまでの文字列全体を「要素」、開始タグと終了タグで挟まれた文字列を「要素内容」、タグ内に記述される要素の名前を「タグ名」(あるいは「要素名」)、要素に対する付加情報を「属性」と呼ぶ。

構造化文書では、その文書中にタグを埋め込む形でデータ構造が記述される。このようにデータ構造をタグとして文書中に埋め込んだ構成を採ることにより、データ項目の追加・削除・変更に対して柔軟性と拡張性が得られるほか、タグ名に、人が読んで意味のある名前を付けることにより、データに視認性を持たせることができる。

ところで、ＸＭＬ文書に対する処理の高速化やメモリ使用量の削減等を図って、ＸＭＬ文書に対する処理能力を向上させる為には、一般に、基盤ソフトウェアの実装の高性能化を図ることが主流になっている。しかし、このような手法のほかに、ＸＭＬ文書自体に予め加工を施しておくことによっても、ＸＭＬ文書に対する処理性能を向上させることが可能である。本発明は、後者の手法（ＸＭＬ文書を加工して処理性能の向上を図る手法）に関連するものであり、ここで、後者の手法に係わる従来技術について説明する。

例えば、非特許文献１には、ＸＭＬ導入時に処理速度が遅くなる問題が発生し、データ構造を変更することにより、問題に対処する事例が開示されている。例えば、住友電工システムズの例(同誌のp.64-65参照)では、同種のデータを、ＣＳＶ（Comma Separated Value）形式で１つにまとめて記述し、まとめられたデータを、ＸＭＬ文書中の１つのタグ中に埋め込むことが開示されている。つまり、「ＸＭＬデータの中に、ＣＳＶ形式のデータを埋め込むようなもの」とした。例えば、ＸＭＬデータの定義情報を変更し、１カ月分のＸＭＬデータを日付順にコンマで区切ってまとめている。

具体的には、
<KOUSU day=”01”>8.0</KOUSU> <KOUSU day=”02”>5.5</KOUSU>…<KOUSU day=”31”>12.8</KOUSU>
というように、別々のタグに記述されていた毎日の実績に関するデータを、
<KOUSU day=”01、 02、…、 31” data=”8.0、 5.5、…、 12.8”></KOUSU>
といった形式で、月単位にまとめるように、元の文書を書き換えている。

このような変更により、１ヶ月分のデータを参照する際には、データベース・サーバーへの照会は１回で済むようになり、ＸＭＬの定義情報の送信も１回送信するだけなので、データ容量も１０分の１に減ったとしている。

また、非特許文献２には、データ量を減らすことを目的とし、レコード形式のＸＭＬ文書を、ＸＭＬ文書の規格を保ったまま、ＸＳＬ変換を用いて、レコード単位にレコード内の全要素をＣＳＶ形式で繋いだＸＭＬ文書に変換することが開示されている。データ処理の負荷を減らすためには、レコード内全要素を１個のＣＳＶ形式に纏めた文書を、専用のＡＰＩによって扱うことを意図している。

具体的には、非特許文献２の手法による変換前・後のＸＭＬ文書は、例えば、図２１（ａ）、（ｂ）に示すようになる。図２１（ａ）は、変換前の元のＸＭＬ文書であり、図２１（ｂ）は、変換後のＸＭＬ文書である。

図示の通り、変換後のＸＭＬ文書は、２つの部分に分けられる。１つは、元のＸＭＬ文書の各タグ名を記述する部分、もう１つは、各要素の内容（１、２、３、４等）をＣＳＶ形式で繋いで記述した部分である。しかし、これは定型ＸＭＬ文書に対応するものであり、非定型ＸＭＬ文書は対象外であった。

ところで、ここで、代表的な構造化文書であるＸＭＬ文書では、何らかの応用ソフトがＸＭＬ文書を扱えるようにするために（検索・更新・削除などの操作を施す）、ＤＯＭ (Document Object Model)と、ＳＡＸ (Simple API for ＸＭＬ)と呼ばれる二つの標準的なインターフェイス(ＡＰＩ: Application Programming Interface)規格が定められている。

ＳＡＸは、メモリ消費が小さく、一般に高速だが、時系列出力で、参照するだけの簡単な処理に向くという特徴を持つ。一方、ＤＯＭは、一般に低速で、メモリ消費が大きいが、文書の要素を階層的なツリー構造に展開するため、複雑な処理内容でもプログラムが組み易いという特徴を持つ。

一般に、ＸＭＬ文書に対して検索・更新・削除などの操作を施す場合、操作対象のＸＭＬ文書を標準ＡＰＩ（ＤＯＭ）でＤＯＭツリーに展開してから、その操作を施すことになる。しかし、ＸＭＬ文書をＤＯＭツリーに展開する際には、元のデータ量の６倍もの膨大な動作メモリ容量が必要となるうえ、使用されない項目（操作対象外の項目）も一緒に展開されてしまうため、展開処理に多大な時間を要している（処理速度、メモリ消費量は、ＸＭＬ文書の要素数に比例する）。

上記非特許文献１、２のような、ＸＭＬ文書を加工して処理性能の向上を図る手法が存在するのは、このような事情があるからである。
しかしながら、上記非特許文献１、２には、以下の問題点があった。

まず、非特許文献１に記載の手法は、データ依存の個別の方法であり、組織的な汎用の方法ではない。すなわち、非特許文献１記載の手法は、データ処理に用いる同種のデータを一つにまとめるものであって、同種のデータを持つ特定のデータに適用する方法であり、改善の効果はデータに依存する。つまり、汎用の方法ではない。

また、非特許文献２に記載の手法は、ＸＭＬ文書のタグを外すことによって、データ量は削減できるが、この方法によって既存の応用ソフトのデータ処理の負荷を軽減することはできない。

非特許文献２では、変換文書を扱える特別なＡＰＩソフトを作って、データ処理の負荷を軽減することを想定している。これは、既存のＤＯＭソフトと同様の機能のソフトを別途作成しなければならないことを意味する。この為、この作業は多大の工数を要する。よって、既存のＤＯＭと同様に使われる状況にはなり難い。

また、非特許文献２に記載の手法は、定型（表形式）のＸＭＬ文書のみを想定している。
このような従来技術に対して、本出願の出願人は、特許文献１記載の手法を提案している。

この特許文献１の発明では、レコード形式のＸＭＬ文書においてレコード内要素が、応用ソフトのデータ処理の対象項目（キー要素）と、非対象項目（非キー要素）に分けられて、変換の際には、キー要素はそのままにし、非キー要素の内容をＣＳＶ形式で纏めて新たな一つの要素（ＣＳＶ要素と呼ぶ）とするＸＭＬ文書に変換することを提案している。ＸＭＬ文書が非定型の場合は、新要素に纏めた要素の要素名をＣＳＶ形式にしたものを属性に付ける。この変換（以下では、ＣＳＶ圧縮変換と呼ぶ）は、ＸＳＬ変換として実行する。

このＣＳＶ圧縮変換は、データ処理の対象項目であるキー要素は、ＣＳＶ形式にはしないで、そのままとするので、応用ソフトに僅かな修正を施すだけで適用可能となる。また、非キー要素のタグを削除して、その要素内容を一つの新要素に纏めることで、元文書のタグを減らした要素数に応じて、ＸＭＬ文書処理のメモリ使用量の削減、メモリ展開時間、処理時間の短縮することができる。
特開２００３−２０３０６７号公報 「見えてきた万能幻想の真実 ＸＭＬの"常識"を覆す」、日経コンピュータ誌 2001.3.12号、ｐ５２−ｐ７１ "Building an ＸＭＬ Bloat Buster using ZＸＭＬＸＭＬ Compression Mehod" by Alain Trotter； [平成１４年２月１８日検索]、インターネット＜ＵＲＬ：http://www.ASPToday.com/＞ または、概要として＜ＵＲＬ：http://www.ＸＭＬ.com/pub/r/904＞

上記のように、特許文献１の発明では、それ以前の従来技術に比べて、特に応用ソフトウェアが変換後のＸＭＬ文書を処理することに関して優れた手法を提案している。
しかしながら、特許文献１の発明にも、未だ、改良の余地が残っていた。特に、変換対象のＸＭＬ文書が非定型ＸＭＬ文書（レコード内の要素数、タグ名が可変であるもの）であった場合に、改良の余地が大きかった。

これについて、本出願の出願人は、更に、特願2003-165735号（以下、先願と呼ぶ）の発明を提案している。
先願では、定型ＸＭＬ文書を構造変換する為に、変換後のＸＭＬ文書における新要素を複数定義し、構造変換対象のＸＭＬ文書におけるレコード内の各要素についてデータ処理の対象となるキー要素であるか否かを指定すると共に該キー要素以外の要素である各非キー要素を上記複数の新要素の何れに割り当てるかを定義し、この定義により上記各要素を、上記レコード内で出現する順に、上記キー要素はそのまま変換後のＸＭＬ文書に記述し、上記各非キー要素に関してはその要素内容を該当する新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後のＸＭＬ文書に出力する。

また、先願では、非定型ＸＭＬ文書を構造変換する為に以下の３つの手法を提案している。
第１の手法では、非定型ＸＭＬ文書を扱う場合、変換後のＸＭＬ文書は、そのヘッダとして、新要素名（ＣＳＶ要素名）と、それに纏める非キー要素の要素名（出現する可能性のあるもの全て）を列挙した付加情報が付けられる。そして、各レコード毎に、出現した非キー要素の要素内容を、ＣＳＶ要素にＣＳＶ形式で繋いで格納する。その際、出現しなかった非定型要素に関しては、空要素として繋ぐ。一方、逆変換時には、空要素は出力しないようにする。図２２に元文書、図２３に変換文書の例を示す。

ここでは、変換仕様は示さないが、“書籍番号”、“図書名”がキー要素、“著者名”、“登録日”、“最終更新日”が非キー要素として定義付けられているものとする。更に、“著者名”は４人まで出現可能性があるものとしている。また、新要素（ＣＳＶ要素）のタグ名は“情報”と定義されている。これより、図２３に示すように、付加情報ヘッダには、ＣＳＶ要素“情報”に関して、上記非キー要素のタグ名（著者名[１]〜著者名[４]、登録日、最終更新日）がＣＳＶ形式で繋がれて記述される。そして、最初のレコードでは、著者は一人であるので、著者名[２]〜著者名[４]に関しては空要素（図示の,,,,）が記述される。２番目のレコードでは、著者は３人であるので、著者名[４]に関しては空要素（図示の,,）が記述される。

第２の手法では、第１の手法との違いのみを述べる。すなわち、変換後のＸＭＬ文書には、第１の手法では出現しなかった非キー要素に関しては空要素が記述されるのに対して、第２の手法では、出現した非キー要素の上記付加情報における順番が、ＣＳＶ要素のタグの属性として記述される（これもＣＳＶ形式で繋いで記述される）。

元文書が上記図２２である場合、第２の手法による変換後のＸＭＬ文書は図２４に示すようになる。図示の例では、ＣＳＶ要素“情報”のタグの属性tagに、出現した非キー要素の上記付加情報における順番が、ＣＳＶ形式で繋いで記述されている。すなわち、付加情報ヘッダには、第１の手法と同様、著者名[１]、著者名[２]、著者名[３]、著者名[４]、登録日、最終更新日が記述されているので、順番は、著者名[１]が１番目、最終更新日が６番目となる。そして、最初のレコードでは、著者が一人であるので、出現した非キー要素は、１番目、５番目、６番目のものであり、図示の通り、属性tagには１，５，６が記述される。

第３の手法では、レコード内の項目がレコード内の条件によって入れ替わるタイプの非定型ＸＭＬ文書であっても構造変換を行えるようにするものである。このタイプの非定型ＸＭＬ文書の一例を図２５に示し、これを図２７又は図２８の変換仕様を用いて構造変換した変換ＸＭＬ文書を図２６に示す。この構造変換は、図２７又は図２８に示す変換仕様ＸＭＬ文書に基づいて行われる。ＣＳＶ圧縮形式を指定するために、図２７では非定型ＣＳＶ要素を指定する変換仕様、図２８では条件分岐を指定する変換仕様を用いる。

図２５に示す例では、構造変換対象のレコードの種類は１種類（部品）であるが、その属性（種類）の属性値が、ＣＰＵ、ハードディスク、メモリの何れであるかによって、そのレコード内のデータ項目が相互に異なるものとなっている。要素<商品名>と要素<型番>は全てのレコードで共通であるが、それ以外が相互に異なる。すなわち、種類＝“ＣＰＵ”の場合には、要素<ＣＰＵ>、<クロック>、<キャッシュ容量>、種類＝“ハードディスク”の場合には、要素<ディスク容量>、<転送速度>、<回転数>、種類＝“メモリ”の場合には、要素<メモリ容量>、<ベースクロック>、<電源電圧>となっている。

このようなデータ構造のＸＭＬ文書に対して、上記第１、第２の手法でも一応構造変換することは可能である。しかし、無駄に空要素を出力することになり、図２６のような変換結果は得られない。更に処理負荷が重くなる。

これに対して、第３の手法（その１）では例えば図２７に示す変換仕様を用いる。この変換仕様では、変換後のＸＭＬ文書において複数の非キー要素を纏める新要素の要素名（ＣＳＶ要素名）を規定する<csv-tag>においても属性format＝“unfixed”を規定し、且つ構造変換処理において各ＣＳＶ要素毎に対応する非キー要素を纏めた結果、全て空要素であった場合には、そのＣＳＶ要素は変換ＸＭＬ文書に出力しないようにする。これにより、無駄に空要素を出力することは無くなるが、処理負荷が重くなる問題には対応できない。

これに対して、第３の手法（その２）では例えば図２８に示す変換仕様を用いる。この変換仕様では、各属性値毎に分けて、その属性値に対応する要素の変換仕様を記述する。そして、<items>要素のwhen属性によって切換え条件（分岐条件）を指定することにより、属性値に応じて、使用する変換仕様を選択させる。尚、この変換仕様からＸＳＬＴスタイルシートを生成した場合には、<choose>-<when><otherwise>の条件によって切り替えられる形式となる。

上記先願では、非定型ＸＭＬ文書を扱うことができるが、一度に変換できるのは構造変換対象のレコードの種類が１種類である場合に限られていた。また、第３の手法では、データ項目が条件によって入れ替わる（相互に一部異なる）場合に対応できたが、これはレコードの種類は１種類であるが、属性によってデータ項目（要素）が変わる場合に対応するものであった。

しかしながら、ＸＭＬでは、非表形式でレコードのネストや、複数種のレコードを持つ等の複雑な非定型のデータ構造が採れる。先願の手法では、このような複数種類のレコードに渡る複雑な構造を持つＸＭＬ文書には対応できなかった。

本発明の課題は、例えば非表形式でレコードのネストや複数種のレコードを持つデータ構造を有するＸＭＬ文書に対しても、ＣＳＶ圧縮等の構造変換を行うことができるようにし、以ってこのような構造のＸＭＬ文書を応用ソフトウェアで容易に処理可能とすることができる構造化文書の構造変換装置、構造化文書変換方法、プログラム等を提供することである。

開示の構造変換装置は、構造化文書を構造変換する構造変換装置であって、前記構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合、前記各条件に対応してそのレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義する変換様定義手段と、該変換仕様定義手段による前記各定義に基づいて、前記データ構造を持つ構造化文書を構造変換する構造変換手段とを有するように構成する。

上記構造化文書は例えばＸＭＬ文書であり、同一種類のレコードであっても、各レコード毎に、何等かの条件によってそのレコード内に出現する要素が可変となる場合がある。これに対して、上記第３の構造変換装置では、各条件毎に対応して変換操作定義を行うと共に、何れを適用するかの条件分岐を定義する。これより、構造変換処理において、各レコード毎にレコード内の条件を参照して、この条件に応じた変換操作定義により構造変換を行うことができる。

また、例えば、前記構造化文書はＸＭＬ文書であり、前記変換仕様定義もＸＭＬ文書で定義し、前記変換仕様を定義するＸＭＬ文書から、該変換仕様定義をＸＳＬＴ文法で記述したＸＳＬＴスタイルシートを生成するスタイルシート生成手段を更に有し、前記構造変換手段は該ＸＳＬＴスタイルシートを用いて前記構造変換を行うＸＳＬＴプロセッサである。

例えば上記変換仕様定義は、ＸＳＬＴスタイルシートの文法と緊密に連携させた表記法で記述しておく。これにより、逐一ＸＳＬＴスタイルシートを記述しなくても、上記変換仕様を定義したＸＭＬ文書から容易にＸＳＬＴスタイルシートを自動生成できる。更に、これにより、標準のＸＳＬＴプロセッサで構造変換処理を実行することができ、ほとんどのＸＭＬ文書システムに対して上記構造変換処理を適用できる。

また、上述した本発明の各構成により行なわれる機能と同様の制御をコンピュータに行なわせるプログラムを記憶したコンピュータ読み取り可能な記憶媒体から、そのプログラムをコンピュータに読み出させて実行させることによっても、前述した課題を解決することができる。つまり、本発明は、このようなプログラム自体としても構成することができるし、当該プログラムを記録した記録媒体（特には可搬型記録媒体）として構成することもできる。

本発明の構造化文書の構造変換装置、構造化文書変換方法、プログラム等によれば、例えば非表形式でレコードのネストや複数種のレコードを持つデータ構造を有するＸＭＬ文書に対しても、ＣＳＶ圧縮等の構造変換を行うことができるようになる。よって、このような構造のＸＭＬ文書が応用ソフトウェアで容易に処理可能となる。また、この構造変換を行わせる為の変換仕様は、ＸＳＬＴスタイルシートの文法と緊密に連携させた表記法で表記する。これにより、変換仕様からＸＳＬＴスタイルシートを生成する処理を簡単・スムーズに行えるようになる。

以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例の構造化文書変換方法をコンピュータ等で実行する処理全体の概略的な流れ及びその構成を示す図である。

図１において、データ構造変換/逆変換機構１０は、本例の構造化文書変換方法を実現するコンピュータであり、構造変換部１１、逆変換部１２、ＸＳＬ変換部１３を有する。データ構造変換/逆変換機構１０は、入力される変換仕様ＸＭＬ文書２２に基づいて、入力ＸＭＬ文書２１を変換ＸＭＬ文書２３へと構造変換し、その逆に複数の変換ＸＭＬ文書２３の中から選択された変換ＸＭＬ文書２３である抽出ＸＭＬ文書２４を、元の構造のＸＭＬ文書（結果ＸＭＬ文書２５）へと逆変換する。

入力ＸＭＬ文書２１は、変換対象のＸＭＬ文書である。尚、ＸＭＬ文書は構造化文書の一例であり、これに限るものではない。
変換仕様ＸＭＬ文書２２は、変換/逆変換の為の変換仕様を与えるＸＭＬ文書である。すなわち、多様な種類のＸＭＬ文書に対して、各ＸＭＬ文書に応じたスタイルシート、すなわちＸＳＬ（Extensible Stylesheet Language）シート（ＸＳＬＴスタイルシートともいう）をいちいち作成するのは、極めて面倒で手間が掛かるものである。そこで、この手間を省く為に、本例では（先願等と同様）ＸＭＬ文書のデータ構造を変換するための仕様を記述したＸＭＬ文書、すなわち変換仕様ＸＭＬ文書２２を作成しておく。

この変換仕様ＸＭＬ文書２２によって与えられる変換仕様に基づいて、構造変換部１１が入力ＸＭＬ文書２１を変換ＸＭＬ文書２３へと構造変換し、逆変換部１２が抽出ＸＭＬ文書２４を結果ＸＭＬ文書２５へと逆変換する。また、このように変換仕様に基づいて、直接、変換/逆変換処理を実行する方法でもよいが、特に、大量のデータを変換するときに、レコードごとに変換仕様を読み取って判断する処理が必要となる。

これに対して、ＸＳＬ変換部１３が、変換仕様ＸＭＬ文書２２と、変換ＸＳＬシート生成ＸＳＬシート１４（特許文献１における自動変換スタイルシート）とに基づいて、変換実行手順を指示する変換ＸＳＬシート１５（データ構造変換用スタイルシート）と、逆変換実行手順を指示する逆変換ＸＳＬシート１６（逆変換用スタイルシート）を生成するようにしてもよい。尚、変換ＸＳＬシート生成ＸＳＬシート１４は、厳密には、変換ＸＳＬシート１５生成用のものと、逆変換ＸＳＬシート１６生成用のものとがあるが、ここでは特に区別せずに扱うものとする。但し、この例に限らず、最初から、変換／逆変換ＸＳＬシート１５，１６を作成させるようにしてもよい。

そして、構造変換部１１または逆変換部１２が、これら生成したＸＳＬシート１５または１６を用いて、変換処理または逆変換処理を実行するようにしてもよい。一度、ＸＳＬシート１５、１６を生成してから変換/逆変換をすることによって、大量のデータを変換するときにレコードごとに変換仕様を読み取って判断する操作が不要になるため、高速で実行することができるようになる。

また、このように変換/逆変換の実行手順をＸＳＬＴスタイルシートで与えるようにすれば、標準のＸＳＬＴプロセッサで変換/逆変換を実行することができ、ほとんどあらゆる種類のＸＭＬ文書システムにおいて、本例による変換/逆変換処理を実行できる。この場合、データ構造変換/逆変換機構１０（構造変換部１１、逆変換部１２）は、実際には、例えば１つの標準のＸＳＬＴプロセッサ（構造化文書変換プロセッサ）によって実現される。

また、応用ソフト３０は、何らかの処理（例えばタグ検索）等を行うアプリケーション・プログラムであり、変換ＸＭＬ文書２３は、この応用ソフト３０で処理し易いデータ構造となるように構造変換されている。

ここで、先願の変換仕様ＸＭＬ文書（ＸＳＬシート）では２種類のテンプレートを持つことになっていた。すなわち、構造変換処理対象のレコードの種類は１種類とし、(i) 対象レコード外をコピーするテンプレート、(ii) 対象レコード内を構造変換処理するテンプレートより成っていた。

これに対して、本手法では、変換仕様ＸＭＬ文書２２に、複数種類のレコードに対応させて各々構造変換処理を行う為のテンプレート（変換操作定義）を記述し、ＸＳＬシート（ＸＳＬＴスタイルシート）の文法に即して、これら複数のテンプレート間の関係付けを記述する。つまり、変換仕様ＸＭＬ文書２２にレコード間の引用関係をも記述し、それによって各テンプレート間を関係付ける。また、上記の通り、変換仕様ＸＭＬ文書２２からＸＳＬシートを自動的に生成するようにしてもよい。このＸＳＬシートは、複数テンプレートを持ち、それらの間が関係付けられたものとなる。

本手法では、以下に記す（１）〜（３）の３種類のデータ構造のうち少なくとも１以上のデータ構造を有する入力ＸＭＬ文書２１であっても、構造変換（ＸＭＬ−ＸＭＬ変換）を行える。
（１）上位階層に複数要素名の（複数種類の）レコードが出現するデータ構造
上記データ構造を有する入力ＸＭＬ文書２１に対しては、本例の第１の手法により、以下の（ａ）、（ｂ）のようにする。
（ａ）処理対象レコード要素名を複数個併記して、それらのレコードをプッシュ処理とし、それらのレコード外をコピーするようにしたテンプレートを生成する。プッシュ処理により、同種のレコードが任意回繰り返す場合でも、１回の指定で対応することができる。

・変換仕様ＸＭＬ文書２２での複数のレコード要素名の併記は、例えば下記のようにする。
<record> 対象レコード要素名1｜対象レコード要素名2｜対象レコード要素名3｜…</record>
ここで、プッシュ処理とは、出現する可能性のあるノードの種類それぞれに対してテンプレート規則を書き、<xsl:apply-templates>で任意のテンプレートを呼び出して、そのテンプレートによる処理を実行させるものである（パターンマッチングによって、呼び出すテンプレートを決定する）。まるで、プロセッサが「誰か、これを処理したい方いませんか」と言いながら、ノードをドアの外に押し出している(push)みたいだから、プッシュ処理と呼ばれる。
（ｂ）各種レコードを処理するテンプレートを、一致処理のテンプレートとして生成する。

つまり、プッシュ処理により呼び出される側のテンプレートが、例えば変換仕様ＸＭＬ文書２２から生成した変換ＸＳＬシート１５において、例えば以下のようになるようにする。

<xsl: template match =”対象レコード要素名”>
変換操作
</xsl: template>
尚、変換操作（ＣＳＶ圧縮）自体は、上記従来技術の手法、あるいは先願の何れの手法を用いてもよく、ここでは特に具体例は示さない。

こうすることにより、各処理対象レコード毎に、そのレコード要素名に対応する処理テンプレートが自動的に適用される。
（２）レコードが子レコードを持つデータ構造
上記データ構造を有する入力ＸＭＬ文書２１に対しては、本例の第２の手法により作成された変換仕様ＸＭＬ文書２２から生成した変換ＸＳＬシート１５が、例えば以下の内容を有するようにする。

上記（ｂ）の各種レコードを処理するテンプレート内で、
<xsl: apply-template select=”対象の子レコード要素名”/>
として、子レコード処理のテンプレートをプッシュ処理で呼び出すようにする。

尚、当然、対応する子レコード要素名の処理テンプレートも作成されている。プッシュ処理をすることにより、任意回数繰り返す子レコードに、１回の指定で対応することができる。
（３）レコードのデータ項目の大半が入替わるデータ構造（条件分岐）
上記データ構造を有する入力ＸＭＬ文書２１に対しては、本例の第３の手法により作成された変換仕様ＸＭＬ文書２２から生成した変換ＸＳＬシート１５が、例えば以下の内容を有するようにする。

レコード処理のテンプレートで、下記のようにして条件に合わせたテンプレートを１回だけ引用するプル処理とする。
<xsl: call-template name=” 引用テンプレート名”/>
尚、当然、対応する名前付きテンプレート（上記（ｂ））も作成されている。

ここで、プル処理とは、名前を指定して特定のテンプレートを呼び出す処理であり、ノードをドアの外に押し出して(push)他のテンプレートに引き取らせる代わりに、ノードを引き込んで(pull)自らそれを処理するから、プル処理と呼ばれる。

尚、上記プッシュ処理、プル処理については、例えば下記のＩＢＭのホームページ等で紹介されている。
http://www-6.ibm.com/jp/developerworks/xml/020726/j_x-xdpshpul.html
このホームページでは、プッシュ処理、プル処理は、プッシュ・スタイル、プル・スタイルとして紹介されており、出現順序や繰返し数が不明な場合はプッシュ・スタイルを用いることが開示されている。

上記先願で変換対象とする非定型ＸＭＬ文書は、上記図２２で説明したように、レコード内に出現する可能性がある非キー要素は決まっているが、各レコード毎にはそのレコード内で出現する非キー要素が何であるかは不定であった。

一方、本手法で変換対象とするＸＭＬ文書（入力ＸＭＬ文書２１）は、上記（１）〜（３）の何れか１つ以上のデータ構造を有するものである。例えば図２には、上記（１）及び（２）のデータ構造を有するＸＭＬ文書の例を示す。また、図６には、上記（３）のデータ構造を有するＸＭＬ文書の例を示す。

先願の手法では、これらのデータ構造を有するＸＭＬ文書は構造変換できなかったが、本手法では構造変換可能となる。
以下、まず図２に例について説明する。

図２の例の入力ＸＭＬ文書２１に対しては、例えば図３に示す変換仕様ＸＭＬ文書２２に記述されている構造変換定義に従って構造変換（ＸＭＬ−ＸＭＬ変換）することが可能となり、その結果、例えば図５に示す変換ＸＭＬ文書２３が得られる。あるいは、図３の変換仕様ＸＭＬ文書２２から図４に示す変換ＸＳＬシート１５を自動生成してこれを用いて上記変換を行うようにしてもよい。尚、ここでは図示していないが、逆変換処理、逆変換ＸＳＬシート１６についても同様にして行える。

図２に示す入力ＸＭＬ文書２１は、上記（１）及び（２）のデータ構造、すなわちレコード要素<調査> が子レコード要素<特許> を持ち、且つ同一階層に複数種類のレコード要素<調査>、<参考文献> を持つデータ構造を有している。

尚、本手法の特徴は各レコード間の関係定義とそれによる分岐、呼出し等にあり、各レコード毎の変換処理は、図２、図６に示す例では各レコード内は定型になっているので従来技術（特許文献１等）を用いればよく、例示はしていないが、もし各レコード内が非定型になっている場合には上記先願の第１〜第３の何れかの手法を用いればよい。

以上述べたように、以下の説明では、各レコード内の変換処理については特に説明せず、上記本手法の特徴について説明するものとする。
まず、図２７に示したように、先願の変換ＸＭＬ文書では、<items>要素は１個であり、１つのレコードの変換操作しか指定できなかった（つまり、<record>部品</record>のみ）。

これに対して、図３に示す本手法の変換仕様ＸＭＬ文書２２では、まず、複数種のレコード要素名「調査」、「参考文献」を<record>要素に併記して指定するとともに(図示の調査｜参考文献)、それぞれのレコードの変換処理を<items record=”調査”または”参考文献”>要素として記述している。

また、レコード要素<調査>の子レコード要素<特許>に関しては、レコード要素<調査>に関する変換処理記述の最後に、子レコ−ド要素<特許>が現れることを記述している。つまり、図示の例では、
<items record=”調査”>中で、
<item ctag=”-RECORD”>特許</item>
と記述することで、当該item要素のctag属性で子レコードへの分岐であることを指定し、子レコードの要素名を要素内容で指定するようにしている。これを受ける子レコードの変換処理は、<items record=”特許”>要素として記述している。

尚、上記<items record=“調査”または“特許”または“参考文献”>要素として記述しているものが、各レコード種類毎に対応する変換処理テンプレートであり、このテンプレートの内容自体は上述してある通り先願の何れかの手法を用いればよい。また、尚、図３等におけるcsv_tag、ctagは、先願におけるmerging_tag、mtagのことである。

ここで、ＸＭＬ文書の変換処理またはＸＳＬシート生成処理では、先願と同様、予め、上記記述に対応する処理が行われるように作りこまれている。
すなわち、例えば、構造変換部１１が変換仕様ＸＭＬ文書２２を直接用いて構造変換（ＸＭＬ−ＸＭＬ変換）を行う場合には、上記レコード名の併記により出現する可能性のあるレコード種類を認識し、その後、入力ＸＭＬ文書２１を順次読み込んで、いずれかの対象レコード名に遭遇する毎に、対応する変換処理テンプレートを選択し、このテンプレートを用いて変換処理を行う。また、変換仕様における<item ctag=”-RECORD”>レコード名</item>により、当該レコード名のレコード種類に対応するテンプレートを用いて、当該レコード名のレコードの変換処理を行う。

一方、上記ＸＳＬシート生成処理に関して、ＸＳＬ変換部１３は、図３に示す変換仕様ＸＭＬ文書から図４に示す変換ＸＳＬシート（及びここでは図示しない逆変換ＸＳＬシート）を生成する為の処理機能を有している。

つまり、ＸＳＬ変換部１３は、変換仕様ＸＭＬ文書２２において上記
<record> 調査｜参考文献 </record>
があると、これを図４に示す
<xsl:when test=”descendant-or-self::*{調査 | 参考文献}”>
の条件文を含む一連の記述（例えば図１２のＢの部分；後に説明する）に置き換える。

この一連の記述によれば、<調査>、<参考文献>要素以外の部分をコピーし、<調査>、<参考文献>要素を見つけた場合、プッシュ処理でそのテンプレートを呼び出す処理が行われる。

また、ＸＳＬ変換部１３は、変換仕様ＸＭＬ文書２２における上記<items record=”レコード名”>要素は、<xsl:template match=”レコード名”>に置き換える。
これより、レコード要素<調査>、<参考資料>は、それぞれ、<xsl:template match=”調査”または“参考資料”>のテンプレートで処理される。尚、各テンプレートの内容（ＣＳＶ圧縮操作）は、既に述べたように従来技術や先願のＸＳＬシートの形式に変換できるので、ここでは省略して示すが、後に省略していない完全版を示すものとする。

以上述べたように、プッシュ処理分岐は変換仕様の<record>要素に、各レコード処理のtemplateは<items record=“調査”または“参考資料”>中の要素並びに、対応付けて変換ＸＳＬシート１５が生成される。

また、変換仕様ＸＭＬ文書２２中の上記<item ctag=”-RECORD”>特許</item>は、図４に示すように、<xsl:template match=”調査”>のテンプレート内で、<xsl:apply-template select=”特許”>要素に置き換える。

これにより、入力ＸＭＬ文書２１中に子レコード要素<特許>を見つけた場合には、プッシュ処理で分岐し、<xsl:template match=”特許”>のテンプレートで処理される。
以上述べた図３の変換仕様を用いてＸＭＬ文書の構造変換を行うことにより、図２に示す入力ＸＭＬ文書２１は図５に示す変換ＸＭＬ文書２３に変換される。尚、変換後のＸＭＬ文書の内容については、本手法の説明には特に関係ないので、省略する。

次に、以下に、入力ＸＭＬ文書２１が上記（３）のデータ構造を有する場合、つまり、レコード内の条件によってレコード内の要素が入れ替わるデータ構造の場合の処理について説明する。

図６に、上記（３）のデータ構造を有する入力ＸＭＬ文書２１の例を示す。
また、図６の例の入力ＸＭＬ文書２１に対しては、例えば図７に示す変換仕様ＸＭＬ文書２２を用いることでＸＭＬ文書の構造変換が可能となり、その結果、例えば図９に示す変換ＸＭＬ文書２３が得られる。あるいは、図７の変換仕様ＸＭＬ文書２２から図８に示す変換ＸＳＬシート１５（不図示の逆変換ＸＳＬシート１６も）を自動生成してこれを用いて上記変換を行うようにしてもよい。

図６に示す入力ＸＭＬ文書２１は、レコードの種類は１種類（<部品>のみ）であるが、各レコード毎に、その要素<種類>の要素内容に応じて、そのレコード内の要素が変わるタイプのＸＭＬ文書である。ここでは、<種類>の要素内容として、ＣＰＵ、メモリ、ＨＤＤ等があるものとし、これらの何れであるかによって、そのレコード内の要素並びが変わるものとする。図示の例では、<種類>の要素内容がＣＰＵである場合には、そのレコード内の要素並びは<型番><チップ><クロック>となり、メモリである場合には<型番><容量><電源電圧>となり、ＨＤＤである場合には<型番><容量><転送速度>となるものとする。

これより、図７に示す変換仕様では、まず、要素<種類>の要素内容が何であるかによって条件分岐するように指定している。例えばＣＰＵを例にすると、
<item ctag=”-BRANCH” case=“種類＝‘ＣＰＵ’”>process-a</item>
により、ctagで条件分岐を指令し、case属性で条件を与え、判定結果がtrueならば、process-aの名前を持つテンプレートに分岐することを指定している。case属性の条件は、要素名「種類」の要素の要素内容が「ＣＰＵ」であるか否かを調べている。これはメモリ、ＨＤＤについても同様である。

この条件分岐を受ける変換処理は、<items name=”process-a”>要素のテンプレートとして記述している。尚、既に述べている通り、各テンプレートの内容については特に説明しない。

ＸＳＬ変換部１３は、図７に示す変換仕様ＸＭＬ文書から図８に示す変換ＸＳＬシートを生成する。この生成処理において、上記変換仕様上の条件分岐指定は、<部品>を処理するテンプレートである<xsl:template match=”部品”>中で、条件分岐 <xsl:choose><xsl:when test=”○○”>文として生成される。

例えば上記変換仕様上の一例である
<item ctag=”-BRANCH” case=“種類＝‘ＣＰＵ’”>process-a</item>
は、図８における
<xsl:when test=“種類＝‘ＣＰＵ’”><xsl:call-template name=”process-a”/>
として生成され、ＸＳＬシートに記述される。

これは、変換仕様におけるcase属性の条件が、ＸＳＬシートのwhen文のtest条件にそのまま入る形になっている。このため、複雑な条件にもＸＳＬ変換文法規則内で広く対処することができるとともに、変換用ＸＳＬシートの生成の実装を容易にすることができる。更に、条件分岐は１回限りの処理なので、プル処理としてcall-template文で呼び出す。この条件分岐を受ける変換処理は、<items name=”process-a”>要素の並びに記述される。

先願特許（その３）では、複数種類のレコードに対応する場合、例えば各々異なるレコード種類のレコードを有する複数の入力ＸＭＬ文書を用意し且つこれら各入力ＸＭＬ文書に対応した各変換仕様ＸＭＬ文書を作成することになる。そして、これら各変換仕様ＸＭＬ文書毎にそれぞれ内部で各条件に応じた処理を作り込むことになる（つまり、１つのテンプレート内に条件分岐、各条件に応じた処理を埋め込む）。これに対して、本手法では、各条件に応じた構造変換処理テンプレートを用意し、分岐処理をテンプレートのプル処理として行うように構成するため、例えば上記図３の変換仕様と組み合わせれば、複数種のレコードを有するデータ構造のＸＭＬ文書でも扱えるようになる。また、ある種類のレコードに関して上記各条件に応じた構造変換処理テンプレートを作成した後、別の種類のレコードに関して構造変換処理を記述する際に、同じ条件処理があった場合、既に作成済みの構造変換処理テンプレートを引用することができるので、変換仕様作成作業の手間が軽減でき、また作成を柔軟に行えるようになる。

以下、ＸＳＬ変換部１３が、変換仕様ＸＭＬ文書２２から変換ＸＳＬシート１５と逆変換ＸＳＬシート１６を生成する処理について説明する。
図１０に変換仕様を基に変換用ＸＳＬシートを生成する処理のフローチャート図を示す。また、図１０のステップＳ１６の詳細フローチャート図を図１１に示す。これら図１０、図１１に示す処理は、主にテンプレート間の関係付けをする処理を示すものであり、変換、逆変換で共通である。

また、図４、図８にはＸＳＬシートの概略を示したが、その完全版を図１２、図１５と図１６に示す。また、それぞれの逆変換シートを、図１３と図１４、図１７と図１８に示す。すなわち、図１２は図３の変換仕様に基づいて生成される変換ＸＳＬシート１５、図１３と図１４は、図３の変換仕様に基づいて生成される逆変換ＸＳＬシート１６である。尚、図１３と図１４は１つの逆変換ＸＳＬシートを２つに分けて示しているだけである。同様に、図１５と図１６は図７の変換仕様に基づいて生成される変換ＸＳＬシート１５、図１７と図１８は、図７の変換仕様に基づいて生成される逆変換ＸＳＬシート１６である。尚、図１５と図１６、図１７と図１８は、それぞれ、１つの逆変換ＸＳＬシート／逆変換ＸＳＬシートを２つに分けて示しているだけである。

以下、図１０、図１１に示す処理について、必要に応じて図１２〜図１８も参照して説明する。
図１０において、ＸＳＬ変換部１３は、変換仕様ＸＭＬ文書２２を読み込み（ステップＳ１１）、まず、変換ＸＳＬシート１５のＸＭＬ宣言文、開始タグ等の固定部分を生成する（ステップＳ１２）。これにより、図１２、図１３、図１５、図１７に示すＡの部分が作成される。

次に変換仕様中の<record>要素の要素内容を対象レコード群として設定し（ステップＳ１３）、対象レコード要素群以外の部分をコピーし、対象レコード群をプッシュ処理するテンプレートを作成する（ステップＳ１４）。上位階層に複数種のレコード要素がある場合、図３のように、<record>要素に併記してあるため、これをそのままテンプレートの条件とすることで、そのレコード群をプッシュ処理依頼するテンプレートとすることができる。

上記ステップＳ１４の処理により、図３の変換仕様に対しては、図１２、図１３に示すＢの部分が作成される。尚、これは、変換、逆変換とも同じ内容となるので、同一符号（Ｂ）を付してある。また、ステップＳ１４の処理により、図７の変換仕様に対しては、図１５、図１７に示すＣの部分が作成される。尚、ＢとＣとでは、Ｂでは複数レコード併記（［調査｜参考文献］）され、Ｃでは［調査］のみである点が異なるだけである。

尚、Ａ、及びＢとＣの大部分は、予め雛型（変換ＸＳＬシート生成ＸＳＬシート１４）として保持しておくようにしてもよい。つまり、ＢやＣにおける［ ］の中身（レコード名）だけを、変換仕様に応じて変えるだけで済むようにしてもよい。

そして、ステップＳ１６により各<items>要素毎に図１１の処理を実行することを繰返し行い、全ての<items>要素について図１１の処理を実行したら（ステップＳ１５，ＹＥＳ）、最後に変換／逆変換ＸＳＬシートに終了タグを記述して（ステップＳ１７）、ＸＳＬシート生成処理を終了する。

ここで、上記Ａ、Ｂの部分について説明しておく。ここでは図１２を例にして、そのＡ、Ｂの部分について説明する。
まず、Ａの部分のうち図示のＡ’の記述は、「ルートノードに対して、定義されているテンプレート全てを適用する」ことを意味する。テンプレート全てとは、Ｂのテンプレートと、調査、特許、参考文献の各々に関するテンプレート（図示のＨ、Ｉ、Ｅの部分）の計４つのテンプレートである。

次に、Ｂの部分について説明する。まず、よく知られているようにXPathの仕様において軸とノードテストと述部から成る表記法があり、例えば“軸::ノードテスト［式］”という表記法が知られている。この表記法に従って、Ｂ部における
“descendant-or-self::＊［調査｜参考文献］”
の部分が記述されている。

軸の表記法の一種であるdescendant-or-selfは、カレントノード、及びカレントノードの子ノード、更に子ノードの子ノード（孫ノード；以下、まとめて子孫ノードという）というように、カレントノードとその全ての子孫のノードを再帰的に選択させるものである。ノードテストの表記法の一種である＊は軸の子ノード全てを指す。そして、式として、調査と参考文献のＯＲ条件が記述されている。

これよりＢの部分による処理は、以下の通りとなる。
(a)自ノード又はその子孫ノードに<調査>又は<参考文献>がある場合には、カレント要素を属性込みでコピーした後に、全ての子ノードに上記全てのテンプレートを適用させる。

(b)そうでなければ、自ノード及びその子孫ノードをコピーする。
上記Ｂの部分の処理を図２の例に適用した場合、まず最初に対象となるノードは<技術調査>であり、これは自ノードは<調査>でも<参考文献>でもないが、その子ノードに<調査>と<参考文献>があるので、上記(a)に該当し、カレント要素を属性込みでコピーした後に、その子ノードである<テーマ>、<調査>、<参考文献>の各々について再帰的に全てのテンプレートを適用する。尚、これは、階層が何階層であっても全ての階層の全てのレコードについて適用されることになる。

まず、<テーマ>に対して全てのテンプレートＢ，Ｈ，Ｉ，Ｅを適用しようとすると、テンプレートＨ，Ｉ，Ｅの適用条件にはmatchしないので、テンプレートＢのみ適用することになり、この場合上記(b)に該当するので、自ノード及びその子孫ノードをコピーする（但し、<テーマ>には子孫はないので自ノードのみとなる）。

次に、<調査>に対して全てのテンプレートＢ，Ｈ，Ｉ，Ｅを適用しようとすると、テンプレートＨの適用条件にmatchし、またテンプレートＢを適用した場合上記(a)に該当するが、前者は具体的な要素名指定であるのに対して、後者はワイルドカード指定である為、テンプレート適用の優先度は前者のほうが高い。よって、テンプレートＨのみを適用する。

その際、テンプレートＨ内にはテンプレートＩへのプッシュ処理があるので、その各子ノード<特許>に対してテンプレートＩが適用される。
最後に、<参考文献>に関しては、上記<調査>と同じ理由によりテンプレートＥのみが適用されることになる。

以下、図１１に示す処理について説明する。
図１１の処理は、まず、<items>要素の属性が、recordかnameかによって、それぞれ、<xsl:template match=”record属性値”>か<xsl:template name=”name属性値”>で始まるテンプレートを作成する（ステップＳ２１〜Ｓ２４）。これらは、レコードのプッシュ処理と条件分岐のプル処理に当たる。尚、図示していないが、属性がない<items>要素の場合には、<xsl:template match=”record要素の要素内容”>で始まるテンプレートを作成する。

次に、当該<items>内の各<item>要素を走査し（ステップＳ２５）、各<item>要素毎に、ステップＳ２７，Ｓ２９，Ｓ３１，Ｓ３３，Ｓ３４の何れかの条件に従って、ステップＳ２８，Ｓ３０，Ｓ３２，Ｓ３５，Ｓ３６の何れかの処理を実行する。

ここで、<item>要素は、ctag属性値でその機能が識別されるようにしてある。
これより、ctag属性値が”-ORG”の場合は（ステップＳ２７，ＹＥＳ）、キー要素として処理する（ステップＳ２８）。図７の最初の<items>要素内の最初と二番目の<item>要素がこれに該当し、図１６、図１７に示すＤの部分が生成される。

または、ctag属性値が<csv_tag>の要素内容（ＣＳＶ要素名）と一致するものである場合は（ステップＳ２９，ＹＥＳ）、非キー要素として処理する（ステップＳ３０）。この非キー要素の処理、あるいは上記キー要素の処理は、先願と同様であるので、ここでは説明を省略する。

尚、上述したように、図１０、図１１の処理は変換と逆変換とで共通だが、変換と逆変換では、非キー要素の処理が変わる。これも先願で説明してあるが、簡単に説明するならば、キー要素は、変換の場合、元文書の要素をそのままコピーし、逆変換の場合も変換文書に元文書と同じ要素を逆変換文書にコピーするだけになる。一方、非キー要素の場合は、変換の場合、ctag属性値（ＣＳＶ要素）にＣＳＶ形式で<item>要素の内容をまとめる操作を行い、逆変換の場合、ctag属性値のＣＳＶ要素の要素内容を分離して<item>要素の内容に入れ込む操作を行うことになる。

例えば図３におけるレコードＣの変換仕様を例にすると、変換に関しては、図１２に示すＥの部分が生成されることになる。すなわち、ＣＳＶ要素名が「文献csv」の新要素に対応付けて、入力ＸＭＬ文書２１におけるタグ名題名，出典，備考の各要素の要素内容（ＸＭＬの文法、ＸＭＬ解説社、200306発行）が、ＣＳＶ形式で繋がれて変換ＸＭＬ文書２３に出力されるようにする以下の命令文が生成されることになる。
<文献csv><xsl:value-of select=”concat(題名,‘,’出典,‘,’備考)”/></文献csv>
一方、逆変換に関しては、図１４に示すＦの部分のように、select=“substring-before/after・・・等を用いて、上記ＣＳＶ形式で繋がれた各要素内容を分離する操作を行う命令文が生成されることになる。

また、ctag属性値が”-RECORD”である場合は（ステップＳ３１）、子レコードが指定されているので、この<item>要素より<xsl:apply-templates select=”<item>要素内容”/>を生成する。つまり、子レコードの処理テンプレートをプッシュ処理で呼び込む命令文を生成する（ステップＳ３２）。

あるいは、ctag属性値が”-BRANCH”の場合は（ステップＳ３３，ＹＥＳ）、条件分岐が指定されていることになる。よって、続いて、この<item>要素のcase属性値を調べる。そして、このcase属性値が”otherwise”でなければ（ステップS３４，ＮＯ）、ステップＳ３５の処理を実行する。

ステップＳ３５の処理は、まず、今回の処理対象の<item>要素が一連の条件分岐の<item>要素群の最初の<item>要素であるか否かを調べ、最初の場合だけ<xsl:choose>文を置く。そして、最初であるか否かは関係なく、以下の条件判定及びプル処理の命令文を生成する。

<xsl:when test=”case属性値”>
<xsl:call-template name=”<item>の要素内容”/></xsl:when>
一方、もしcase属性値が”otherwise”である場合は（ステップＳ３４，ＹＥＳ）、
<xsl:otherwise>
<xsl:call-template name=”<item>の要素内容”/>
</xsl:otherwise>
を生成し、更に</xsl:choose> と続けて、一連の条件分岐文を終了する。

これによって、図７の変換仕様に示す４つの条件分岐文の一連の流れが、図１６、図１７に示すＧの部分の<xsl:choose>文として生成される。
以上の処理を各<item>要素について実行し、<items>内の全ての<item>要素の処理が終了したら（ステップS２６，ＹＥＳ）、テンプレートの閉じタグ</xsl:template>を記述して図１１の処理は終了する。

以上説明したように、本手法によれば、例えば非表形式でレコードのネストや複数種のレコードを持つデータ構造を有するＸＭＬ文書に対しても、ＣＳＶ圧縮等の構造変換を行うことができるようになる。よって、このような構造のＸＭＬ文書が応用ソフトウェアで容易に処理可能となる。また、この構造変換を行わせる為の変換仕様は、ＸＳＬＴスタイルシートの文法と緊密に連携させた表記法で表記する。これにより、変換仕様からＸＳＬＴスタイルシートを生成する処理を簡単・スムーズに行えるようになる。

図１９は、本実施の形態による構造化文書変換方法を実現するコンピュータのハードウェア構成の一例を示す図である。
同図に示すコンピュータ１００は、ＣＰＵ１０１、メモリ１０２、外部記憶装置１０５、媒体駆動装置１０６等を有し、これらがバス１０８に接続された構成となっている。また、更に、ネットワーク接続装置１０７を有する構成であってもよい。同図に示す構成は一例であり、これに限るものではない。

ＣＰＵ１０１は、当該コンピュータ１００全体を制御する中央処理装置である。
メモリ１０２は、プログラム実行、データ更新等の際に、外部記憶装置１０５（あるいは可搬型記録媒体１０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、メモリ１０２に読み出したプログラム／データを用いて、上述してある図２の構造変換部１１、逆変換部１２、ＸＳＬ変換部１３の機能（ＸＳＬ変換部１３に関しては図１０、図１１に示すフローチャート処理）を実現する。

外部記憶装置１０５は、例えば磁気ディスク装置、光ディスク装置、光磁気ディスク装置等であり、上記本発明の各種機能を実現させる為のプログラム／データ等が格納されている。このデータとしては、例えば、図２に示す変換ＸＳＬシート生成ＸＳＬシート１４、変換ＸＳＬシート１５、逆変換ＸＳＬシート１６等である。また、外部から入力ＸＭＬ文書２１、変換仕様ＸＭＬ文書２２、抽出ＸＭＬ文書２４等のデータが入力されると、これを一時的に記憶する。

媒体駆動装置１０６は、可搬型記録媒体１０９に記憶されているプログラム／データ等を読み出す。可搬型記録媒体１０９は、例えば、ＦＤ（フレキシブルディスク）、ＣＤ−ＲＯＭ、その他、ＤＶＤ、光磁気ディスク等である。

ネットワーク接続装置１０７は、ネットワークに接続して、外部の情報処理装置とプログラム／データ等の送受信を可能にする構成である。
図２０は、上記プログラム等を記録した記録媒体、ダウンロードの一例を示す図である。

図示のように、上記本発明の機能を実現するプログラム／データが記憶されている可搬型記録媒体１０９から情報処理装置１００側に読み出して、メモリ１０２に格納し実行するものであってもよいし、また、上記プログラム／データは、ネットワーク接続装置１０７により接続しているネットワーク（インターネット等）を介して、外部のサーバ１１０の記憶部１１１に記憶されているプログラム／データをダウンロードするものであってもよい。

また、本発明は、装置／方法に限らず、上記プログラム／データを格納した記録媒体（可搬型記録媒体１０９等）自体として構成することもできるし、上記プログラム自体として構成することもできる。

（付記１）
構造化文書を構造変換する構造変換装置であって、
前記構造化文書が同一階層に複数種類のレコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作間の呼び出し関係を定義する変換仕様定義手段と、
該変換仕様定義手段による前記各定義に基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する構造変換手段と、
を有することを特徴とする構造変換装置。

（付記２）
構造化文書を構造変換する構造変換装置であって、
前記構造化文書が複数種類のレコードを有すると共に構造変換対象の任意のレコードが子レコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に、前記子レコードを有する任意のレコードのレコード種類に対応した変換操作定義中に、該子レコードのレコード種類に対応した変換操作間の呼び出し関係を定義する変換仕様定義手段と、
該変換仕様定義手段による前記各定義に基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する構造変換手段と、
を有することを特徴とする構造変換装置。

（付記３）
構造化文書を構造変換する構造変換装置であって、
前記構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合、前記各条件に対応してそのレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義する変換仕様定義手段と、
該変換仕様定義手段による前記各定義に基づいて、前記データ構造を持つ構造化文書を構造変換する構造変換手段と、
を有することを特徴とする構造変換装置。

（付記４）
前記レコード内の要素を圧縮変換する変換操作の定義は、変換後の構造化文書における新要素を複数定義し、前記レコード内の各要素についてデータ処理の対象となるキー要素であるか否かを指定すると共に該キー要素以外の要素である各非キー要素を前記複数の新要素の何れに割り当てるかを定義するものであり、
前記構造変換手段は、この定義により、前記各要素を、前記レコード内で出現する順に、前記キー要素はそのまま変換後の構造化文書に記述し、前記各非キー要素に関しては、その要素内容を、該当する前記新要素毎にＣＳＶ形式でまとめたものを各新要素の要素内容として変換後の構造化文書に記述することを特徴とする付記１〜付記３の何れかに記載の構造変換装置。

（付記５）
前記構造化文書はＸＭＬ文書であり、前記変換仕様定義もＸＭＬ文書で定義し、
前記変換仕様を定義するＸＭＬ文書から、該変換仕様定義をＸＳＬＴ文法で記述したＸＳＬＴスタイルシートを生成するスタイルシート生成手段を更に有し、
前記構造変換手段は該ＸＳＬＴスタイルシートを用いて前記構造変換を行うＸＳＬＴプロセッサであることを特徴とする付記１〜付記４の何れかに記載の構造変換装置。

（付記６）
前記構造化文書が同一階層に複数種類のレコードを有するデータ構造を持つ場合の前記複数の変換操作定義の呼び出し定義は、前記ＸＳＬＴスタイルシートにおいて該複数の変換操作定義の何れかへのプッシュ処理として記述されることを特徴とする付記５記載の構造変換装置。

（付記７）
前記構造化文書が複数種類のレコードを有すると共に構造変換対象の任意のレコードが子レコードを有するデータ構造を持つ場合の前記子レコードのレコード種類に対応した変換操作定義の呼び出し定義は、前記ＸＳＬＴスタイルシートにおいて該子レコードの変換操作定義へのプッシュ処理として記述されることを特徴とする付記５記載の構造変換装置。

（付記８）
前記構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合の前記条件分岐の定義は、前記ＸＳＬＴスタイルシートにおいてプル処理として記述されることを特徴とする付記５記載の構造変換装置。

（付記９）
構造化文書を構造変換する構造変換方法であって、
前記構造化文書が同一階層に複数種類のレコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換することを特徴とする構造変換方法。

（付記１０）
構造化文書を構造変換する構造変換方法であって、
前記構造化文書が複数種類のレコードを有すると共に構造変換対象の任意のレコードが子レコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に、前記子レコードを有する任意のレコードのレコード種類に対応した変換操作定義中に、該子レコードのレコード種類に対応した変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換することを特徴とする構造変換方法。

（付記１１）
構造化文書を構造変換する構造変換方法であって、
前記構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合、前記各条件に対応してそのレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記データ構造を持つ構造化文書を構造変換することを特徴とする構造変換方法。

（付記１２）
コンピュータに、
構造変換対象の構造化文書が同一階層に複数種類のレコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する機能、
を実現させるためのプログラム。

（付記１３）
コンピュータに、
構造変換対象の構造化文書が複数種類のレコードを有すると共に構造変換対象の任意のレコードが子レコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に、前記子レコードを有する任意のレコードのレコード種類に対応した変換操作定義中に、該子レコードのレコード種類に対応した変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する機能、
を実現させる為のプログラム。

（付記１４）
コンピュータに、
構造変換対象の構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合、前記各条件に対応してそのレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記データ構造を持つ構造化文書を構造変換する機能、
を実現させる為のプログラム。

（付記１５）
コンピュータに、
構造変換対象の構造化文書が同一階層に複数種類のレコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する機能、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。

（付記１６）
コンピュータに、
構造変換対象の構造化文書が複数種類のレコードを有すると共に構造変換対象の任意のレコードが子レコードを有するデータ構造を持つ場合、各レコード種類毎に対応してそのレコード種類のレコード内に出現する要素を圧縮変換する変換操作を定義すると共に、前記子レコードを有する任意のレコードのレコード種類に対応した変換操作定義中に、該子レコードのレコード種類に対応した変換操作間の呼び出し関係を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記同一階層に複数種類のレコードを有するデータ構造を持つ構造化文書を構造変換する機能、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。

（付記１７）
コンピュータに、
構造変換対象の構造化文書が各レコード内の条件によってそのレコード内の要素が変わるデータ構造を持つ場合、前記各条件に対応してそのレコード内に出現する要素を圧縮変換する変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義した変換仕様ＸＭＬ文書またはＸＳＬＴスタイルシートに基づいて、前記データ構造を持つ構造化文書を構造変換する機能、
を実現させるプログラムを記録した前記コンピュータ読取り可能な記録媒体。

本例の構造化文書変換方法をコンピュータ等で実行する処理全体の概略的な流れ及びその構成を示す図である。 本手法で変換対象とする非定型ＸＭＬ文書の例（その１）である。 図２のＸＭＬ文書に対応する変換仕様ＸＭＬ文書の例である。 図３の変換仕様ＸＭＬ文書から生成される変換ＸＳＬシートの概略である。 図２のＸＭＬ文書を構造変換した変換ＸＭＬ文書の例である。 本手法で変換対象とする非定型ＸＭＬ文書の例（その２）である。 図６のＸＭＬ文書に対応する変換仕様ＸＭＬ文書の例である。 図７の変換仕様ＸＭＬ文書から生成される変換ＸＳＬシートの概略である。 図６のＸＭＬ文書を構造変換した変換ＸＭＬ文書の例である。 ＸＳＬ変換部の処理フローチャート図である。 図１０のステップＳ１６の処理の詳細フローチャート図である。 図３の変換仕様に基づいて生成される変換ＸＳＬシートの例である。 図３の変換仕様に基づいて生成される逆変換ＸＳＬシート（１／２）である。 図３の変換仕様に基づいて生成される逆変換ＸＳＬシート（２／２）である。 図７の変換仕様に基づいて生成される変換ＸＳＬシート（１／２）である。 図７の変換仕様に基づいて生成される変換ＸＳＬシート（２／２）である。 図７の変換仕様に基づいて生成される逆変換ＸＳＬシート（１／２）である。 図７の変換仕様に基づいて生成される逆変換ＸＳＬシート（２／２）である。 コンピュータ・ハードウェア構成図である。 プログラムを記録した記録媒体、及びプログラムのダウンロードを示す図である。 従来の構造変換の例であり、（ａ）は変換元、（ｂ）は変換後のＸＭＬ文書である。 先願における構造変換対象のＸＭＬ文書の例（その１）である。 先願の第１の手法により図２２のＸＭＬ文書を構造変換した変換ＸＭＬ文書の例である。 先願の第２の手法により図２２のＸＭＬ文書を構造変換した変換ＸＭＬ文書の例である。 先願における構造変換対象のＸＭＬ文書の例（その２）である。 図２５のＸＭＬ文書を構造変換した変換ＸＭＬ文書の例である。 先願の第３の手法（その１）による変換仕様ＸＭＬ文書である。 先願の第３の手法（その２）による変換ＸＭＬ文書である。

符号の説明

１０ データ構造変換/逆変換機構
１１ 構造変換部
１２ 逆変換部
１３ ＸＳＬ変換部
１４ 変換ＸＳＬシート生成ＸＳＬシート
１５ 変換ＸＳＬシート
１６ 逆変換ＸＳＬシート
２１ 入力ＸＭＬ文書
２２ 変換仕様ＸＭＬ文書
２３ 変換ＸＭＬ文書
１００ コンピュータ
１０１ ＣＰＵ
１０２ メモリ
１０５ 外部記憶装置
１０６ 媒体駆動装置
１０７ ネットワーク接続装置
１０８ バス
１０９ 可搬型記録媒体
１１０ 外部のサーバ
１１１ 記憶部

Claims (1)

1. 構造化文書を構造変換する構造変換装置であって、
   前記構造化文書が各レコードタグ又は子レコードタグの、要素名又は要素内容によってレコード内に含まれる要素名が異なるデータ構造を持つ場合、複数のレコードのそれぞれのレコードタグ又は子レコードタグの、要素名又は要素内容に対応して、該要素名又は要素内容に対応する要素名を有する要素を圧縮変換する複数の変換操作を定義すると共に該複数の変換操作定義の何れを適用するかの条件分岐を定義する変換仕様定義手段と、
   該変換仕様定義手段による前記各定義に基づいて、前記データ構造を持つ構造化文書を構造変換する構造変換手段と、
   を有することを特徴とする構造変換装置。

Images