(57)【要約】【課題】  ＳＶＧやＸＨＴＭＬなどＸＭＬを基にした言語の多くは、外部のデータをリンク参照する機能を持つが、その記述の方法は言語ごとに異なっている。そのため、ＸＭＬファイルと参照されたファイルをパッケージして単一のファイルとするにはその言語専用のツールが必要であった。【解決手段】  リンク参照の記述を指定してパッケージを行なう方法を用いることで、汎用的なＸＭＬパッケージ処理を実現する。【選択図】  図１７
2007011473.tif 000002
【特許請求の範囲】
【請求項１】
構造化文書のリンク参照を意味するノードの識別情報を保持しておく識別情報保持手段と、
前記識別情報保持手段に対して新たに識別情報を追加する識別情報追加手段と、
構造化文書のノード情報を受け取る手段と、
受け取ったノードの情報と前記識別情報保持手段によって格納された識別情報とを比較する手段と、
比較の結果一致している場合にはそのノードに記述された情報を構造化文書がリンク参照しているデータの場所とみなし、その場所にあるデータを読み出す手段と、
構造化文書のノード情報から構造化文書を生成する手段と、
前記生成手段によって生成した構造化文書と前記読み出し手段によって読み込んだデータとを単一データ実体として結合する手段と、
を有することを特徴とする構造化文書作成装置。
【請求項２】
前記構造化文書作成装置は構造化文書のフォーマットとしてＸＭＬを用い、ノードの識別情報として要素名、属性名、名前空間を用いることを特徴とした請求項１に記載の構造化文書作成装置。
【請求項３】
前記構造化文書作成装置は、構造化文書の出力の際に、単一データからのデータ復元に必要な情報を埋め込む処理を行うことを特徴とした請求項１に記載の構造化文書作成装置。
【請求項４】
前記構造化文書作成装置は、構造化文書がリンク参照しているデータを受け取り、構造化文書と該データとを単一のデータにまとめる手段をもつことを特徴とした請求項１に記載の構造化文書作成装置。
【請求項５】
前記構造化文書作成装置は、あらかじめ一つまたは複数種類のノードを指定しておき、その指定に該当するノードに記述されたデータを取り出して単一のデータにまとめることを特徴とした請求項１に記載の構造化文書作成装置。
【請求項６】
前記構造化文書作成装置は、ネットワークの送信機能を持ち、作成した単一データをネットワーク上の他の機器に送信することを特徴とした請求項１に記載の構造化文書作成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は構造化文書の処理に関する。
【背景技術】
【０００２】
構造化文書とは、計算機での管理や処理のために文書中に文書の構造を示すタグを入れたものであり、その例としてＨＴＭＬ（Hyper Text Markup Language, http://www.w3.org/MarkUp/）、ＸＭＬ（Extensible Markup Language, http://www.w3.org/XML/）などがある。ＨＴＭＬでは"<"と">"で囲まれたものを開始タグ、"</"と">"で囲まれたものを終了タグとして用いており、例えば「これは<b>HTML</b>の例です」、という記述は"HTML"という文字列を太字で出力することを意味している。
【０００３】
ＸＭＬもＨＴＭＬと同様に"<"と">"で囲まれたものを開始タグ、"</"と">"で囲まれたものを終了タグとして扱うが、ＨＴＭＬと異なりタグの名前と意味は自由に定義することができる。このＸＭＬを用いて規定された言語としてSVG（Scalable Vector Graphics, http://www.w3.org/Graphics/SVG/）やXHTML（http://www.w3.org/MarkUp/）などがある。
【０００４】
これらの構造化文書の多くは、外部のデータをリンク参照する機能を持っている。例えばＨＴＭＬでは、「<a href="http://www.example.org">リンク</a>」という記述は"リンク"という文字列を表示し、その部分を指定するとhttp://www.example.orgにたどることを意味し、「<img src="fig.jpg">」という記述はfig.jpgという画像ファイルを読み出し、その画像を表示することを意味している。
【０００５】
このように外部のデータをリンク参照している構造化文書は、文書単一ではなくリンク参照しているデータも含めて処理を行なう必要な場合が多い。論理的に一つの文書を複数の文書に分けることは、文書の再利用性の向上などに役立つが、逆にデータの移動や複製の際に、複数のデータをまとめて扱わなければならないため、扱いにくいものに成る。このような場合には、データを一つのデータにまとめておき、必要な場合に展開できる形式にしておくと利便性が増す。このように複数のデータからなる文書を一括して扱えるようにひとまとめに結合したデータを本特許では単一データ実体と呼ぶ。また、この単一データ実体を単一のファイルとしてまとめることをパッケージと呼ぶ。
【０００６】
複数のデータをパッケージする方法としてはZIP、LZH、tarがあり、単一データ実体をデータストリームとしてネットワーク上に送信する場合はMIME (Multipurpose Internet Mail Extensions, RFC2045: http://www.ietf.org/rfc/rfc2045.txt) という方式が広く用いられている。
【０００７】
こうした複数のデータをまとめる処理を行なう場合、従来は対象となるデータ群をすべて人間が手動で指示していた。
【０００８】
またＨＴＭＬの場合では、外部のデータを参照するためのノード（img要素のsrc属性やa要素のhref属性など）は仕様として定まっており、そのノードに記述されたデータを自動的にたどることが可能であり、パッケージしたいＨＴＭＬデータを指定することで、自動的にすべての参照データを含めてパッケージすることが可能である。
【０００９】
又、従来例としては、例えば特許文献１をあげることが出来る。
【特許文献１】特開平11-288412号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしXMLのようにより一般化された構造化文書の場合は、上記のような仕様で定められたノードをたどるという方法は使えない。XMLではリンク参照を示すノードが仕様として定められているわけではない。例えばXHTMLではimg要素のsrc属性、またSVGではimage要素のxlink:href属性となっており、それぞれの言語に合わせたツールが必要になる。さらにXMLは誰でも独自に言語を作成することができる、という特徴があるため無数の言語があり、従来のようにそれぞれの言語に合わせたツールを作成すると、多大な労力がかかる。
【００１１】
また、自動的にリンク参照の記述を認識する方式として、属性値やタグに囲まれた文字列中の特定の拡張子（.jpgや.htmlなど）を探す、という方法も考えられるが、このような方法では偶然に.jpgなどの文字列があった場合などに精度が落ち、またimg要素のsrc属性で書かれたファイルはパッケージするが、a要素のhref属性で書かれたファイルはパッケージしない、などの柔軟な処理ができないという欠点がある。
【００１２】
本発明の目的は、ソフトウェアの再開発をすることなく簡単な設定ファイルを用意するだけで複数のXMLボキャブラリに対応が可能な、XML単一データ実体作成処理装置を提供することである。
【課題を解決するための手段】
【００１３】
前記目的を達成する本発明の構造化文書作成装置は、
構造化文書のノード情報を受け取る手段と、
受け取ったノード情報から構造化文書を生成する手段と、
構造化文書のリンク参照を意味するノードの識別情報を保持しておく識別情報保持手段と、
前記識別情報保持手段に対して新たに識別情報を追加する識別情報追加手段と、
受け取ったノードの情報と前記識別情報保持手段によって格納された識別情報とを比較する手段と、
比較の結果一致している場合にはそのノードに書かれた情報を構造化文書がリンク参照しているデータの場所と見なし、その場所にあるデータを読み出す手段と、
構造化文書と前記読み出し手段で読み込んだデータとを単一のデータにまとめる手段
を備えたものである。
【発明の効果】
【００１４】
本発明の方式を用いれば、ＸＭＬを扱うアプリケーションを再開発することなく、簡単な設定を行うだけでさまざまなＸＭＬボキャブラリに対応が可能な、ＸＭＬ単一データ実態を作成することが可能になる。
【００１５】
また、単一データ実体をパッケージ処理して単一のファイルにすることにより、複数のデータからなる構造化文書の送受信やコピーと言った処理を容易に行うことが可能になる。
【００１６】
さらに、複数のデータをまとめるだけでなく、ＸＭＬデータの作成時にデータを参照する際に必要な情報を埋め込む処理を行うことが可能になる。
【発明を実施するための最良の形態】
【００１７】
（実施例１）
本発明の第一の実施形態を説明する。これは複数のボキャブラリを扱うことのできる機器において、外部のファイルをリンクしているＸＭＬ文書を一つのファイルとしてまとめて出力するものである。
【００１８】
第一の実施形態の構造化文書作成装置のブロック図を図１に示す。ＣＰＵ１０１はシステム制御部であり装置全体を制御する。ＲＯＭ１０２はＣＰＵの制御プログラムや各種固定データを格納するものである。ＲＡＭ１０３はＳＲＡＭ、ＤＲＡＭなどで構成され、プログラム変数などを格納するものである。記憶部１０４はハードディスクなどで構成され、ファイルデータを格納するものである。ＸＭＬ作成部１０５はＸＭＬの要素名や属性名、属性値といったＸＭＬのノードの情報を受け取り、その情報を基に実際のＸＭＬ文書を生成するものである。ノード情報格納部１０６はリンク参照を示すノードの情報を格納するものである。データ読み出し部１０７は、ＸＭＬ文書のノードで指定されたファイルやその一部を記憶部１０４などから読み出すものである。パッケージデータ作成部１０８は複数のデータから単一のデータを生成するものである。ＳＶＧ作成部１０８とＸＨＴＭＬ作成部１０９はそれぞれＳＶＧやＸＨＴＭＬのデータを生成するものである。ただし、これらはＳＶＧやＸＨＴＭＬを作成する基となるデータ、例えばＳＶＧ作成部であればベクトルデータ情報を作成するものであり、実際にＸＭＬ文書としてのＳＶＧデータを作成する際は、作成したい要素名や属性名、属性値の情報をＸＭＬ作成部１０５に渡すことでＸＭＬの作成を行う。例えばＳＶＧ作成部やＸＨＴＭＬ作成部はそれぞれベクトル画像やウェブサイトを作成するアプリケーション、ＸＭＬ作成部はＸＭＬを作成するＣ言語のライブラリやＪａｖａ（登録商標）のクラスとして実装される。
【００１９】
本例ではノード情報格納部にはあらかじめ、図１８に示すデータが格納されているものとする。これはＳＶＧのデータはimage要素のxlink:href属性が外部ファイルへのリンク参照を示し、ＸＨＴＭＬのデータはimg要素のsrc属性がリンク参照を示していることを表す。
【００２０】
この機器においてＪＰＥＧやＰＮＧなどのラスタ画像を含むＳＶＧやＸＨＴＭＬを、単一のファイルとして出力する。
【００２１】
ＳＶＧ作成部１０８において図２に示す画像データを作成したものとする。これは一つの矩形とＪＰＥＧのラスタ画像からなり、この矩形とラスタ画像の情報がＲＡＭ１０３上に格納される。またこのラスタ画像は記憶部１０４に保持されているＪＰＥＧファイルであり、ビットマップのデータではなくＪＰＥＧファイルのファイル名（fig.jpg）を保持している。実際に出力するＳＶＧデータは図５のようになるが、この段階ではまだＲＡＭ１０３上に図４に示すデータが、アプリケーションや機器、オペレーティングシステムに応じた内部情報として保持されている。またＳＶＧ作成１０８は実際に出力する要素名や属性名の情報を持っており、ＸＭＬ作成部１０５に出力したい要素名や属性名、画像の内部情報を渡すことで実際のＳＶＧデータを作成する。
【００２２】
ＸＭＬ作成部１０５の処理の流れを図３に示す。まずリンク参照を示すノードの情報を受け取る。ＸＭＬ作成部は空のパッケージデータを出力する（３０１）。次に出力したいＸＭＬデータのノード情報（ノードの種類、要素名、属性名、属性値など）を受け取り（３０２）、受け取ったノードの情報とリンク参照情報格納部１０６に格納されているデータとを比べる（３０３）。最初に受け取るデータは要素名：svgというデータであり、これは一致しないためそのままＸＭＬの要素、つまり"<svg>"という文字列として出力される。次に受け取るデータは要素名：rectと属性としてx, y, width, heightの情報だが、これも一致しないためそのままＸＭＬの要素として出力される。次に要素名：image, 属性x=100, 属性y=60, 属性xlink:href="fig.jpg"というデータを受け取る。この要素名image, 属性名xlink:hrefは３０１で受け取ったデータと一致するため、この属性値fig.jpgは外部のデータへのリンク参照を示していることがわかる。そこでこのfig.jpgという情報を保持しておく（３０４）。このようにすることで、図６のデータを出力する。次にリンク参照しているデータがあるかを調べ（３０７）、それらを読み出して（３０８）出力する（３０９）。この例ではfig.jpgをリンクしていることがわかっているため、このファイルを読み出して出力する。結果として図７に示すデータを出力し、SVGのデータとリンク参照しているデータを単一のデータとしてまとめたファイルを生成することができる。
【００２３】
ＳＶＧ作成部と同様ＸＨＴＭＬ作成部も外部のデータをリンクするＸＭＬデータを作成する。例として図８に示す文書を出力するものとすると、実際に出力するＸＨＴＭＬは図９のようになる。ＸＨＴＭＬでは外部ファイルをリンクするノードして、画像のリンクを示すimg要素のsrc属性があり、このＸＨＴＭＬにおいてはabc.pngというファイルを参照している。このような場合でも、img要素のsrc属性が外部リンクへの参照を表す、という情報を持っているため、まったく同じ手順を踏むことでＸＨＴＭＬと画像データをまとめた単一のファイルを出力することができる。
【００２４】
以上の処理を行うことで、簡単設定をノード情報格納部に置くことのみで、複数のＸＭＬボキャブラリに対応したＸＭＬパッケージデータの作成を行うことが可能となる。
【００２５】
（実施例２）
次に本発明の第二の実施形態を説明する。これはＸＭＬデータとそのデータに含むべきバイナリデータをパッケージしてネットワーク上の別の機器に送信するものである。
【００２６】
第二の実施形態の構造化文書作成装置の構成を図１０に示す。１００１から１００８は図１における１０１から１０８と同様のものである。ネットワークインタフェース１００９はＬＡＮなどのネットワークに接続し、他の機器とのデータの送受信を行うインタフェースである。ＸＭＬアプリケーション１０１０は、ＸＭＬを作成して他の機器に送信を行うアプリケーションである。またデータのパッケージ方法としてMIME Multipart/Related方式を用いるものとする。MIME Multipart/Relatedのデータは複数のパートからなり、それぞれのパートにはContent-IDという識別子が付いている。
【００２７】
この構造化文書作成装置は図１１に示すネットワークに接続されている。１１０１がこの構造化文書作成装置であり、ネットワーク１１０２を通して受信機器１１０３に送信する。
【００２８】
この装置が図１２に示すＸＭＬデータを他の機器に送信するものとする。このデータは一般に仕様が公開されているデータではなく、独自のフォーマットである。このため、ＸＭＬ作成装置はどのノードがリンク参照を示すかについての情報をもっていない。このＸＭＬデータではbinData要素のhref属性がリンク参照をあらわすものとする。つまりこのデータはabc.datというファイルを参照している。
【００２９】
この構造化文書処理装置の処理の流れを図１３（ＸＭＬデータ作成処理）と図１４（ＭＩＭＥデータ作成処理）に示す。まずＸＭＬ作成部はリンク参照を示すノードを受け取る（１３０１）。ここではbinData要素のhref属性となる。次に空のＭＩＭＥデータを作成し（１３０２）、ＸＭＬデータ部分用のパートを作成する（１３０３）。次にアプリケーションからノードの情報を受け取り、リンク参照のノードでなければそのままＸＭＬのノードとして出力する（１３０５、１３０８）。ノード１２０２はリンク参照を示すノードのため、このノードを受け取ったときは、まず一意のＩＤを生成する（１３０６）。これはＭＩＭＥのパートのContent-IDになるものである。ここでは"cid:cid001"というIDが生成されたものとする。さらに生成したＩＤを利用して、このノードの変換を行う。これはこのノードがＭＩＭＥ内のどのパートを参照しているかを示すためのものである。この場合はhref="cid001"となる。またこのファイル名とIDを保持しておく（１３０７）。そして変換されたノードをＸＭＬのノードにして出力する（１３０８）。ノード１２０３についても同様の処理を行う。このパートにはIDとして"cid:cid002"というＩＤが付いたものとする。
【００３０】
ここまでの段階で出力されたデータを図１５に示す。ＭＩＭＥのデータ中にパート（１５０）が一つ存在し、そのデータ部分１５０２にＸＭＬデータがある。このＸＭＬデータは図１２に示す元のＸＭＬデータとは異なり、ファイル名をあらわす部分がＩＤ名に変換されている。
【００３１】
またこの段階で、図１６に示すデータを保持している。これはＸＭＬデータが参照しているデータのファイル名と、それを格納するＭＩＭＥのパートのＩＤ名のデータである。
【００３２】
次にリンク参照されているデータの出力を図１４に従って行う。処理していないファイルがある場合には、新規にＭＩＭＥのパートを作成し（１４０３）、保持していたＩＤである"cid001"をつける。次に保持していたファイル名abc.datのデータを読み出し（１４０４）、作成したパートのデータとして出力する（１４０５）。これを保持していたデータすべてについて行う。
【００３３】
このようにして作成された結果を図１７に示す。ＭＩＭＥデータは３つのパート１７０、１７１、１７２からなり、変換されたＸＭＬデータ、abc.dat、def.datが格納されている。
【００３４】
このデータをネットワークインタフェース１００７を用いて他の機器に送信する。受信側の機器は通常どおりＸＭＬデータを処理し、リンク参照の部分については記述されているContent-IDのデータを用いることで、参照しているデータを正しく処理することが可能である。
【００３５】
以上の処理を行うことで、新たなＸＭＬボキャブラリを作成しても、リンク参照を示すノードの情報を伝えるだけで、パッケージ処理が可能になる。
【００３６】
なお、本実施例では説明の簡略化のために、ノードの識別に要素名と属性名のみを用いたが、より正確に行うにはＸＭＬ名前空間（http://www.w3.org/TR/REC-xml-names/）を用い、要素の名前空間ＵＲＩ，要素名、属性の名前空間ＵＲＩ，属性名の４つの情報を用いるのが望ましい。
【００３７】
また本実施例ではパッケージの方式としてＭＩＭＥを用いたが、本発明はＭＩＭＥだけでなく、Ｚｉｐやｔａｒなどの方式を用いることも可能である。
【図面の簡単な説明】
【００３８】
【図１】第一の実施例における構造化文書作成装置の構造を示すブロック図。
【図２】第一の実施例で作成するSVG。
【図３】第一の実施例の構造化文書作成装置の処理の流れを示す流れ図。
【図４】ＳＶＧ処理装置が持つ内部データの概念図。
【図５】出力するＳＶＧデータ。
【図６】ＳＶＧデータ処理時のパッケージデータの概念図。
【図７】第一の実施例における出力結果。
【図８】第一の実施例で作成するＸＨＴＭＬデータ。
【図９】出力するＸＨＴＭＬデータ。
【図１０】第二の実施例における構造化文書作成装置の構造を示すブロック図。
【図１１】ネットワーク図。
【図１２】作成するＸＭＬデータ。
【図１３】ＸＭＬデータの出力処理を示す流れ図。
【図１４】リンク参照データの出力処理を示す流れ図。
【図１５】ＸＭＬデータ出力段階でのパッケージデータの概念図。
【図１６】ＸＭＬデータ出力段階で保持しているファイル名とＩＤのデータ。
【図１７】第二の実施例における出力結果の概念図。
【図１８】第一の実施例のノードデータ保持部が保持しているデータ。
【図１】
2007011473.tif 000003
【図２】
2007011473.tif 000004
【図３】
2007011473.tif 000005
【図４】
2007011473.tif 000006
【図５】
2007011473.tif 000007
【図６】
2007011473.tif 000008
【図７】
2007011473.tif 000009
【図８】
2007011473.tif 000010
【図９】
2007011473.tif 000011
【図１０】
2007011473.tif 000012
【図１１】
2007011473.tif 000013
【図１２】
2007011473.tif 000014
【図１３】
2007011473.tif 000015
【図１４】
2007011473.tif 000016
【図１５】
2007011473.tif 000017
【図１６】
2007011473.tif 000018
【図１７】
2007011473.tif 000019
【図１８】
2007011473.tif 000020