(57)【要約】ＸＭＬ型の使用により、ＸＭＬ（及びＪａｖａ）型システムの組合わせが可能になる。これは、ＸＭＬ文書内のＸＭＬデータを定義するＸＭＬスキーマをＪａｖａ内のＸＭＬ型に翻訳することによって、既存マーシャリング及びアンマーシャリングシステムにおける多くの欠陥を解消する。従来のＸＭＬとＪａｖａとの間の翻訳時の試みとは異なり、ＸＭＬ型として実現されているＸＭＬスキーマは、ＸＭＬに対して完全に忠実であり続け、また複数のＸＭＬデータを操作することができる。更に、ＸＭＬ型は、それら自体とＪａｖａ型との間で容易に変換することができ、タグレベルにおいてＸＭＬ情報を保持している軽量記憶装置によって増分ＸＭＬマーシャリング及びアンマーシャリングを可能にする。この記述は、本発明を完全に記述しておらず、また本発明の範囲を制限することを意図するものでもない。本発明の他の特色、面、及び目的は、明細書、図面、及び特許請求の範囲を検討することによって理解することができる。
2006516781.tif 000002
【特許請求の範囲】
【請求項１】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするためのシステムにおいて、
ＸＭＬデータと、
前記ＸＭＬデータを定義するＸＭＬスキーマと、
Ｊａｖａ内の前記ＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型と、
前記ＸＭＬスキーマから前記ＸＭＬ型を生成することができるコンパイラと、
を含むことを特徴とするシステム。
【請求項２】
前記コンパイラは、ＪａｖａＷｅｂサービスメソッドの定義に基づいて前記ＸＭＬ型を生成することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記コンパイラは、定義ファイルに基づいて前記ＸＭＬ型を生成することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項４】
前記コンパイラは、Ｊａｖａプロジェクトを１またはそれ以上の正規Ｊａｖａ型内へコンパイルすることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項５】
前記ＸＭＬ型は、前記ＸＭＬデータ内の何処をも読むことができる可動カーソルであることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項６】
前記ＸＭＬ型は、前記ＸＭＬデータの固定された部分を参照できる不動値であることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＸＭＬ型は、複数のＪａｖａコンポーネントの間で共用することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＸＭＬ型は、Ｊａｖａ内の前記ＸＭＬデータを更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項９】
前記ＸＭＬ型は、Ｊａｖａ型メソッドを使用してＪａｖａデータにアクセスし、更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＸＭＬ型は、データベースにアクセスし、更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記ＸＭＬ型は、ＸＭＬデータの問合わせ、ＸＭＬ型間の変換、及びＸＭＬデータ文書を通しての繰り返しを含む複数のＸＭＬデータを操作することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１２】
データ型及び前記データの範囲に関する制約、及び前記データ型及び前記ＸＭＬ型の範囲に関する制約を含む前記ＸＭＬデータの正当な型を定義することができるＸＭＬスキーマ、
を更に含むことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記コンパイラは、前記ＸＭＬスキーマから前記ＸＭＬデータの正当な型についての前記ＸＭＬ型に関する制約を生成することができる、
ことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記ＸＭＬ型に関する制約は、前記ＸＭＬ型を検査することができる、
ことを特徴とする請求項１２に記載のシステム。
【請求項１５】
ＸＭＬとＪａｖａとの間で型を変換するシステムにおいて、
Ｊａｖａ型と、
Ｊａｖａ内のＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型と、
ソース型をターゲット型に変換することができるＸＭＬ変換と、
を含み、
前記ソース型及びターゲット型は、前記ＸＭＬ型または前記Ｊａｖａ型の何れであることもできる、
ことを特徴とするシステム。
【請求項１６】
ソース型とターゲット型との間の既存ＸＭＬ変換をルックアップすることができるＸＭＬ変換のグローバルレジストリ、
を更に含むことを特徴とする請求項１５に記載のシステム。
【請求項１７】
ソース型とターゲット型との間の既存ＸＭＬ変換を、名前によってルックアップすることができるＸＭＬ変換のライブラリ、
を更に含むことを特徴とする請求項１５に記載のシステム。
【請求項１８】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするシステムにおいて、
ＸＭＬデータと、
前記ＸＭＬデータを、探索可能なインデックスとして保持することができる軽量ＸＭＬ記憶装置と、
前記軽量ＸＭＬ記憶装置を参照することができ、且つＪａｖａ内の前記ＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型と、
を含むことを特徴とするシステム。
【請求項１９】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするシステムにおいて、
ＸＭＬデータと、
前記ＸＭＬデータを、テキストまたはタグレベルにおいて保持することができる軽量ＸＭＬ記憶装置と、
前記軽量ＸＭＬ記憶装置を参照することができ、且つＪａｖａ内の前記ＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型と、
を含むことを特徴とするシステム。
【請求項２０】
前記軽量ＸＭＬ記憶装置は、前記保持したＸＭＬデータを階層構造として表すことができる、
ことを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記階層構造は、ツリーであることができる、
ことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記ＸＭＬ型は、前記ＸＭＬデータに増分的にアクセスすることができる、
ことを特徴とする請求項１９に記載のシステム。
【請求項２３】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルする方法において、
ＸＭＬスキーマを使用してＸＭＬデータを定義するステップと、
Ｊａｖａ内のＸＭＬ型を介して前記ＸＭＬデータにアクセスするステップと、
コンパイラを使用して前記ＸＭＬスキーマから前記ＸＭＬ型を生成するステップと、
を含むことを特徴とする方法。
【請求項２４】
前記ＸＭＬ型を、ＪａｖａＷｅｂサービスメソッドの定義に基づいて生成するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記ＸＭＬ型を、定義ファイルに基づいて生成するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２６】
Ｊａｖａプロジェクトを、１またはそれ以上の正規Ｊａｖａ型内へコンパイルするステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２７】
前記ＸＭＬ型を、前記ＸＭＬデータ内の何処をも読むことができる可動カーソルとして使用するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２８】
前記ＸＭＬ型を、前記ＸＭＬデータの固定された部分を参照するための不動値として使用するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項２９】
前記ＸＭＬ型を、複数のＪａｖａコンポーネントの間で共用するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３０】
前記ＸＭＬ型を介してＪａｖａ内の前記ＸＭＬデータを更新するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３１】
Ｊａｖａ型メソッドを使用してＪａｖａデータにアクセスし、更新するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３２】
前記ＸＭＬ型を介してデータベースにアクセスし、更新するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３３】
前記ＸＭＬ型を介して、ＸＭＬデータの問合わせ、ＸＭＬ型間の変換、及びＸＭＬデータ文書を通しての繰り返しを含む複数のＸＭＬデータ操作を使用するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３４】
ＸＭＬスキーマを介して、データ型及び前記ＸＭＬ型の範囲に関する制約を含む前記ＸＭＬデータの正当な型を定義するステップ、
を更に含むことを特徴とする請求項２３に記載の方法。
【請求項３５】
前記ＸＭＬスキーマから、前記ＸＭＬデータの正当な型についての前記ＸＭＬ型のデータ型及び範囲に関する制約を生成するステップ、
を更に含むことを特徴とする請求項３４に記載の方法。
【請求項３６】
前記ＸＭＬ型に関する制約を使用して前記ＸＭＬ型を検査するステップ、
を更に含むことを特徴とする請求項３４に記載の方法。
【請求項３７】
ＸＭＬとＪａｖａとの間で型を変換する方法において、
Ｊａｖａ型を使用するステップと、
Ｊａｖａ内のＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型を使用するステップと、
ＸＭＬ変換を介してソース型をターゲット型に変換するステップと、
を含み、
前記ソース型及びターゲット型は、前記ＸＭＬ型または前記Ｊａｖａ型の何れであることもできる、
ことを特徴とする方法。
【請求項３８】
ＸＭＬ変換のグローバルレジストリを介してソース型とターゲット型との間の既存ＸＭＬ変換をルックアップするステップ、
を更に含むことを特徴とする請求項３７に記載の方法。
【請求項３９】
ＸＭＬ変換のライブラリを介してソース型とターゲット型との間の既存ＸＭＬ変換を名前によってルックアップするステップ、
を更に含むことを特徴とする請求項３７に記載の方法。
【請求項４０】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルする方法において、
ＸＭＬデータを、軽量ＸＭＬ記憶装置を介して探索可能なインデックスとして保持するステップと、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照し、前記ＸＭＬデータにアクセスするステップと、
を含むことを特徴とする方法。
【請求項４１】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルする方法において、
軽量ＸＭＬ記憶装置を介して、ＸＭＬデータをテキストまたはタグレベルにおいて保持するステップと、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照し、前記ＸＭＬデータにアクセスするステップと、
を含むことを特徴とする方法。
【請求項４２】
前記保持したＸＭＬデータを、ツリーであることができる階層構造として表すステップ、
を更に含むことを特徴とする請求項４１に記載の方法。
【請求項４３】
前記ＸＭＬ型を介して前記ＸＭＬデータに増分的にアクセスするステップ、
を更に含むことを特徴とする請求項４１に記載の方法。
【請求項４４】
命令を格納している機械可読媒体において、前記命令はプロセッサによって実行された時に、システムに、
ＸＭＬスキーマを使用してＸＭＬデータを定義させ、
Ｊａｖａ内のＸＭＬ型を介して前記ＸＭＬデータにアクセスさせ、
コンパイラを使用して前記ＸＭＬスキーマから前記ＸＭＬ型を生成させる、
ことを特徴とする機械可読媒体。
【請求項４５】
実行された時に、システムに、
ＪａｖａＷｅｂサービスメソッドの定義に基づいて前記ＸＭＬ型を生成させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項４６】
実行された時に、システムに、
定義ファイルに基づいて前記ＸＭＬ型を生成させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項４７】
実行された時に、システムに、
コンパイラを使用してＪａｖａプロジェクトを１またはそれ以上の正規Ｊａｖａ型内へコンパイルさせる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項４８】
実行された時に、システムに、
前記ＸＭＬ型を、前記ＸＭＬデータ内の何処をも読む可動カーソルとして使用させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項４９】
実行された時に、システムに、
前記ＸＭＬ型を、前記ＸＭＬデータの固定された部分を参照する不動値として使用させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５０】
実行された時に、システムに、
前記ＸＭＬ型を、複数のＪａｖａコンポーネントの間で共用させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５１】
実行された時に、システムに、
前記ＸＭＬ型を介してＪａｖａ内の前記ＸＭＬデータを更新させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５２】
実行された時に、システムに、
正規Ｊａｖａ型メソッドを使用してＪａｖａデータにアクセスさせ、更新させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５３】
実行された時に、システムに、
前記ＸＭＬ型を介してデータベースにアクセスさせ、更新させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５４】
実行された時に、システムに、
前記ＸＭＬ型を介して、ＸＭＬデータの問合わせ、ＸＭＬ型間の変換、及びＸＭＬデータ文書を通しての繰り返しを含む複数のＸＭＬデータ操作を使用させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５５】
実行された時に、システムに、
ＸＭＬスキーマを介してＸＭＬデータのデータ型及び範囲に関する制約を含む前記ＸＭＬデータの正当な型を定義させる、
命令を更に含むことを特徴とする請求項４４に記載の機械可読媒体。
【請求項５６】
実行された時に、システムに、
前記ＸＭＬスキーマから前記ＸＭＬデータの正当な型についての前記ＸＭＬ型に関する制約を生成させる、
命令を更に含むことを特徴とする請求項５５に記載の機械可読媒体。
【請求項５７】
実行された時に、システムに、
前記ＸＭＬ型に関する制約を使用して前記ＸＭＬ型を検査させる、
命令を更に含むことを特徴とする請求項５５に記載の機械可読媒体。
【請求項５８】
命令を格納している機械可読媒体において、前記命令はプロセッサによって実行された時に、システムに、
Ｊａｖａ型を使用させ、
Ｊａｖａ内のＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型を使用させ、
ＸＭＬ変換を介してソース型をターゲット型に変換させ、
前記ソース型及びターゲット型は、前記ＸＭＬ型または前記Ｊａｖａ型の何れであることもできる、
ことを特徴とする機械可読媒体。
【請求項５９】
実行された時に、システムに、
ＸＭＬ変換のグローバルレジストリを介してソース型とターゲット型との間の既存ＸＭＬ変換をルックアップさせる、
命令を更に含むことを特徴とする請求項５８に記載の機械可読媒体。
【請求項６０】
実行された時に、システムに、
ＸＭＬ変換のライブラリを介してソース型とターゲット型との間の既存ＸＭＬ変換を名前によってルックアップさせる、
命令を更に含むことを特徴とする請求項５８に記載の機械可読媒体。
【請求項６１】
命令を格納している機械可読媒体において、前記命令はプロセッサによって実行された時に、システムに、
軽量ＸＭＬ記憶装置を介して前記ＸＭＬデータを探索可能なインデックスとして保持させ、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照させ、前記ＸＭＬデータにアクセスさせる、
ことを特徴とする機械可読媒体。
【請求項６２】
命令を格納している機械可読媒体において、前記命令はプロセッサによって実行された時に、システムに、
軽量ＸＭＬ記憶装置を介してＸＭＬデータをテキストまたはタグレベルにおいて保持させ、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照させ、前記ＸＭＬデータにアクセスさせる、
ことを特徴とする機械可読媒体。
【請求項６３】
実行された時に、システムに、
前記保持したＸＭＬデータを、ツリーであることができる階層構造として表させる、
命令を更に含むことを特徴とする請求項６２に記載の機械可読媒体。
【請求項６４】
実行された時に、システムに、
前記ＸＭＬ型を介して前記ＸＭＬデータに増分的にアクセスさせる、
命令を更に含むことを特徴とする請求項６２に記載の機械可読媒体。
【請求項６５】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするためのシステムにおいて、
ＸＭＬスキーマを使用してＸＭＬデータを定義する手段と、
Ｊａｖａ内のＸＭＬ型を介して前記ＸＭＬデータにアクセスする手段と、
コンパイラを使用して前記ＸＭＬスキーマからＸＭＬ型を生成する手段と、
を備えていることを特徴とするシステム。
【請求項６６】
伝送媒体内に実現されているコンピュータデータ信号において、
ＸＭＬスキーマを使用してＸＭＬデータを定義させる命令を含むコードセグメントと、
Ｊａｖａ内のＸＭＬ型を介して前記ＸＭＬデータにアクセスさせる命令を含むコードセグメントと、
コンパイラを使用して前記ＸＭＬスキーマから前記ＸＭＬ型を生成させる命令を含むコードセグメントと、
を含むことを特徴とするコンピュータデータ信号。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ及びデータ型の変換に関する。
【背景技術】
【０００２】
現在、データ型間で変換、またはマーシャルする途上で若干の欠陥が存在している。既存システムにおいては、ユーザは既存のＪａｖａ（登録商標。以下同じ。）型から始めて、システムにＪａｖａ型を反映するＸＭＬスキーマを生成するように、また更に、Ｊａｖａデータを、自動的に生成されるＸＭＬへマーシャルするように依頼する。ＸＭＬをマーシャルする殆どの製品は、ＸＭＬスキーマを生成するためにＪａｖａ−ＷＳＤＬコンパイラのようなコンパイラを通して走る。このようなアプローチの１つの欠陥は、ＪａｖａからＸＭＬへ進むシナリオだけに対処することである。現在のツールは、既存ＸＭＬスキーマを取扱うのに特に適してはおらず、そのスキーマ全体を使用に便宜なＪａｖａ型に変える。
【０００３】
現在のマーシャリング技術に伴う別の問題は、ユーザが単にＸＭＬデータの小さい一部分を見ることを望む時に出現する。ユーザは、データを処理することなく、単に残余のＸＭＬデータを通過させたいと考えているだけかも知れない。現在のマーシャリング技術は、残余のデータを通過させるだけに対しては効果的ではない。ＸＭＬ内の全てのセマンティクスをＪａｖａ内に容易に捕捉することはできないから、典型的には、マーシャリングからアンマーシャリングへ進むことは複雑である。もしユーザがあるメッセージを持ち込み、そのメッセージの小部分を変化させ、そしてそのメッセージをＸＭＬとして再送することを試みれば、ユーザが変化させた部分以外の部分が異なってしまい、他の情報が大量に失われかねない。ＸＭＬが、例えばワイルドカード属性、またはエレメントを含んでいるとしても、これらのワイルドカードは保持されない。エレメント順序に関する情報も失われるか、またはスクランブルされる恐れがあるが、これはもしそのスキーマがエレメント順序に鋭敏であれば問題である。
【発明の開示】
【０００４】
以下に、添付図面を参照して本発明を説明するが、これらの図面は単なる例示に過ぎず本発明を限定するものではない。添付図面においては、類似の要素には類似の番号を付してある。本明細書に使用する“一”実施の形態とは、必ずしも同一の実施の形態を指すものではなく、少なくとも１つを意味しているものであることを理解されたい。
【０００５】
本発明の一実施の形態によるシステム及び方法は、ＸＭＬ文書内のＸＭＬデータを定義するＸＭＬスキーマを、ＸＭＬとＪａｖａとの間でデータをマーシャルする時にＪａｖａ内のＸＭＬ型に翻訳することによって、既存のマーシャリング及びアンマーシャリングシステムの多くの欠陥を解消する。ＸＭＬ型は実際にはＪａｖａ型であり、これは、正規のＪａｖａビーン機能及びデータベースへのアクセスの他に、Ｊａｖａ内のＸＭＬデータに効率的な、型安全な、頑強な、そして便宜な手法でアクセスし、更新することもできる。ユーザによって導入されたスキーマのほぼ100％を取扱う能力を提供する少なくとも１つの実施の形態内においては、１つのアーキテクチャを使用することができる。
【０００６】
ＸＭＬ型を使用することによって、ＸＭＬ型システムとＪａｖａ型システムとの組合わせを可能にすることができる。これは、開発者が疎結合を達成できるような手法で行うことができる。ＸＭＬ型として実現されているＸＭＬスキーマは、ＸＭＬに対して完全に忠実であり続けることができる。開発者にとっては、既存のＪａｖａ型と既存のＸＭＬ型との間の精密な変換を制御することは容易であるかも知れない。ＸＬＭ型は、例えば、ＪａｖａからＸＭＬデータ文書へのスキーマアウェアの強く型付けされたアクセス、コンパクト及びインデックスされたインメモリＸＭＬ記憶装置、高速及び最小（プル）パージング及び（バイナリ）直列化、軽量文書・カーソル走査、Ｘパス及びＸ待ち行列ナビゲーション及び変換、及びシームレスＪａｖａ  ＩＤＥ統合を含む幾つかの技術を結合することによって、Ｊａｖａ／ＸＭＬ境界を処理することができる。
【０００７】
ＸＬＭ向き“Ｊａｖａコードを介してのＸＭＬからＸＭＬへ”例について、図１は、本発明の実施の形態と共に使用することができる単純なＸＭＬスキーマ定義（ＸＳＤ）ファイル例を示している。この特定のＸＭＬスキーマは、購入注文書の型を記述している。このスキーマは、スキーマツールによって生成された、またはユーザによって作成された先在ファイルであることができる。この例においては、無効ＸＭＬ購入注文書情報を“クリーンアップ”するか、または“固定”する必要があるかも知れない。
【０００８】
ＸＳＤのトップは、‘purchase order’と命名されたエレメントのためのスキーマ定義である。エレメントは複素数型として定義され、“line-item”と呼ばれるエレメントを含んでいる。‘unbounded’にセットされた‘maxOccurs’属性が存在するが、これはline-itemを任意回数繰り返すことができることを意味している。各ラインアイテムは、４つのサブエレメント、即ちdesc、itemid、price、及びqtyを有するように示されている。‘desc’サブエレメントはストリングである記述エレメントのことであり、‘itemid’は整数（type int）であるアイテム識別子エレメントのことであり、‘price’は浮動小数点数（type float）である価格エレメントのことであり、そして‘qty’は整数である量エレメントのことである。これらのサブエレメントは、全てスキーマのビルトイン型である。このスキーマは、基本的には、有効購入注文書スキーマをどのように注視すべきかの記述、または表現である。
【０００９】
ＸＭＬ型を使用してプログラムを書くために、ＸＭＬスキーマファイルをＪａｖａプロジェクトに追加することができる。ＸＭＬマーシャリング及びアンマーシャリングのためのシステムの例を、図２に示す。一実施の形態においては、システムは、如何にＪａｖａプロジェクト１０１をコンパイルするかを知っているだけではなく、ＸＳＤファイル１０２をコンパイルすることもできるコンパイラ１００を用いてファイルを処理することができる。ＸＳＤファイルをコンパイルする時に、正規Ｊａｖａ型１０４に加えて、複数のＸＭＬ型１０３を生成することができる。これらのＸＭＬ型は、クラスパスに追加することができる。例えば、“purchase order”と呼ばれるＸＭＬ型は、“purchase-order”と呼ばれるスキーマ型から生成することができる。
【００１０】
図１のスキーマ例からコンパイルされたＸＭＬ型のＪａｖａソースコード表現を、図３に示す。これらのＪａｖａ型を生成するソースは、スキーマファイル自体である。LineItemと呼ばれる型は、ＸＳＤファイル内のpurchase-orderエレメントの内側にネストされているline-itemエレメントに対応する。Ｊａｖａにおいては、ＸＭＬline-itemエレメントは類似する何かに変えることができる。１つの型の内側の各エレメント毎に、Ｊａｖａフィールドを生成することができる。例えば、ＸＳＤ内の“desc”エレメントの場合、各ラインアイテム毎に生成された型内には対応する“getDesc”及び“setDesc”メソッドが存在する。一般に購入注文書の場合、ユーザは個々のラインアイテムを入手するか、または送ることができる。生成された型の名前は、スキーマ名から自動的に導出することができる。各生成された型は、それを生成した関連スキーマ名と共に注釈を付けることができる。各型は、既存ＸＭＬ型を拡張することもできる。
【００１１】
一実施の形態においては、ＸＭＬ型は“XMLObject”と呼ばれる共通ベースＸＭＬ型を実現することができる。このＸＭＬ型は、複数のＸＭＬ向きデータ処理を実行する能力を提供し、以下“XBean”と呼ぶ。XBeanは、XbeanはXMLObjectから受け継ぐので、標準Ｊａｖａビーンではない。XMLObjectは、ＸＭＬ型としてのXMLObjectが各XBean毎にそのオリジナル、または対応するＸＭＬを検索するメソッドを提供するので普通ではない。XBeanは、ＸＭＬに直列化及び非直列化することができ、且つＪａｖａから型安全な手法でアクセスすることができるビジネスデータのようなＪａｖａ型表現データのためのデザインパターンと考えることができる。またXBeanは、これらの型を生成するための注釈付けされたＪａｖａまたは非Ｊａｖａの何れかの自然言語イディオムの小さいセットと考えることもできる。通常、アプリケーション開発者またはコンポーネント開発者がビジネスデータを如何に表すかを決定する時、トレードオフが存在する。もしデータが型安全なＪａｖａで表されていれば、ＸＭＬまたはデータベースへの直列化は扱い難くなる恐れがある。もしデータがＸＭＬとして表されていれば、Ｊａｖａ型への変換も多少は扱い難くなり得る。このことは、もしデータがデータベースからの結果セット内にあれば、他の何れかの型への変換についても同じである。従って、ＸＭＬ及びＪａｖａの両者を渡し、使用し、そして処理するのに便利な単一のカテゴリのＪａｖａ型を提供することが有利である。また更に、同一の型が、データベースアクセス並びにフォーム入力及び確認に便利であると有利である。
【００１２】
図２に示すように、一実施の形態におけるXBeanは、３つの型のビジネスデータ、即ちＸＭＬデータ１０５、Ｊａｖａデータ１０６、及びデータベース１０７の交差点に位置することができる。XBeanは、通信または計算のための何等かのロジックまたは手段を用いることなく、単純にデータを含むことができる。XBeanは、任意の数のイディオムを使用して定義することができる。XBeanを定義した後に、XBeanは種々の文脈に使用することができる。例えば、ＸＭＬスキーマを使用してXBeanを定義し、XBeanをＸＭＬ入力ストリームに付加することによってインスタンスを生成することができる。この場合、生成されたＪａｖａ型を次々に渡して、フレンドリなゲッタ及びセッタを有するＪａｖａビーンとして使用することができる。
【００１３】
例えば、アプリケーション開発者は、以下の内容を有するMyData.schemabeanと呼ぶファイルを定義することができる。
2006516781.tif 000003
このファイルは、XBeanを表す別のメソッドである注釈をベースとするフォーマットの例を示す図４に示すようなメタデータを有するXBean内へコンパイルすることができる。
【００１４】
もし、データが例えばＸＭＬ向きであれば、ユーザは、記述の前に名前が来るのか、または名前の前に記述が来るのかに関心を持つ。本発明によるシステム及び方法によれば、ユーザはオリジナルの、順序付けられたＸＭＬへ戻ることができる。“getXMLCursor”及び“excuteXPath”と呼ばれるメソッドのようなベースXMLObject型上のに幾つかのメソッドの何れかが存在することができる。ＸＭＬ型は、XPathを使用して値を問合わせるメソッド、XQueryを使用して値を変換するメソッド、またはXMLCursorを使用してデータ文書上を繰り返すメソッドを含む複数のＸＭＬデータ操作を有することができる。このベース型は、幾つかの技術を一緒に保持することができる。
【００１５】
若干のメソッドは、任意の時点のＸＭＬが何に見えるかを決定することができる。例えば、ＸＭＬ型は、図５に示すような要求された操作を実行するＷｅｂサービスを実現するために使用することができる。図５に示す例示コードは、全購入注文書内の量を固定するために使用することができる。図５の行１−２において、本メソッドは、ＷｅｂサービスとしてPurchaseOrderXML型を使用する操作を宣言する。ＷｅｂサービスランタイムはＸＭＬ型を認識し、ＸＭＬを完全にパーズすることなく入力メッセージを効率的に渡すことができる。スキーマ内で宣言された他のＸＭＬ型は、emptyItemsと呼ばれるアレイとして行４、５、及び７に示されているLineItemである。コンパイルされたＸＭＬ型は強く型付けされているから、それらは、スキーマファイルに対するPurchaseOrderの確認、及びemptyItems[i].setQty(1)引数の型が整数であることの確認のような、Ｊａｖａコンパイラ検査のような両スキーマの確認を可能にする。
【００１６】
例えば、ユーザは、ラインアイテムが誤って量０にセットされている高ラインアイテムを有する複数の購入注文書を受信するかも知れない。そのユーザは、誰かが量フィールドを０にセットしたままとした時に、システムがその量フィールドを１に変化させるようにこれらの購入注文書を操作することを望むであろう。１つの機能が、XBeanを入力として使用することができ、またXPathを、０に等しい量を有する購入注文書タグの下の何等かのラインアイテムタグを探している購入注文書上で実行することができる。これは、例えば図５の行５以下に示してある。XPathとマッチするノードのリストをユーザへ戻すことができる。このノードのリストは、XBean型へ返す（ユーザはそれがどうなるかを知っている）ことができる。システムは、アレイへ送ることができる１組のラインアイテムを選択する。XPathから結果を入手するとそれらの結果を通して反復し、XBeanメソッドを使用して結果ノードを操作することが可能になる。
【００１７】
強く型付けされたＪａｖａアクセサリは、全てのＸＭＬの用途のためには適切ではないかも知れない。一実施の形態においては、ＸＭＬ型は、ベースＸＭＬ向きXMLObject（例えばXPath、XQuery、XMLCursor、及びXMLReaderを提供する）を拡張することができる。行５上のXMLObject getAllValuesメソッドは入力に対してXPathを実行し、qty＝０を有する全てのラインアイテムエレメントを探知する。行６及び７から、ＸＭＬデータ文書を更新するために、LineItem型を使用できることが理解されよう。型の各インスタンスを文書内の特定ノードと呼び、setQty(1)のようなメソッドが呼出されると、文書のデータが容易な、型安全な手法で処理される。行８において、機能を完了させ、応答メッセージを送るために型がＷｅｂサービスから直接戻される。
【００１８】
本発明の実施の形態によるシステム及び方法は、ユーザがデータを検索するためにXBeanを処理する必要があり得る異なるＸＭＬ型の間における変換を扱うこともできる。例えば、アイテムＩＤをマッチさせるために記述及び価格を変更することによってラインアイテムをクリーンアップする必要があり得る。これは、一実施の形態においては、既存アプリケーションデータベース内の各カタログアイテムをルックアップすることによって行うことができる。この作業は、整数アイテムｉｄを取り、CatalogItemを戻すことができるＪａｖａルックアップメソッドを使用して行うことができる。例えば、
2006516781.tif 000004
このクラスはLineItemＸＭＬ型に類似しているように見えるが、ある比較的小さい差を有している。例えば、CatalogItemは量を有しておらず、アイテムＩＤは“itemID”ではなく、“catalogID”と呼ばれる。実際、CatalogItemはLineItemにかなり類似しているから、若干の状況においては、コードを図６に示すように書くことが望ましいかも知れない。図６においては、複素数ＸＭＬ型、即ちLineItemの値が複素数Ｊａｖａ型、即ちCatalogItemにセットされる。各ＸＭＬ型は、上述したコードをコンパイルして走らせることができるように任意の型を取ることができるセットメソッドを有している。しかしながら、ランタイム中、ユーザは、“CatalogItemからLineItemへのマッピングに変換が定義されていない”と苦情を呈するＸＭＬ変換例外に到達することができる。この場合、ユーザは適切なCatalogItem型名を選択し、対応するＸＭＬ変換を検査することができる。もしユーザがあるアイテムのタイトルをルックアップして‘CatalogItem’と呼ばれるＪａｖａ型を戻す既存ビーンを有していれば、CatalogItemは、ラインアイテムに類似してはいるが先行例とは僅かに異なるCatalogID記述を有していよう。例えば、量フィールドは存在せず、また先にItemIDと呼ばれていたものはCatalogIDと呼ばれている。
【００１９】
本発明の実施の形態によるシステム及び方法においては、各ＸＭＬ変換は、変換のディレクトリ内に格納されているXQueryを使用して実施することができる。各Xqueryは、各々が既知のＸＭＬスキーマを有する１またはそれ以上の型から、特定の型へ変換することができる。line-item型、並びにCatalogItemのためのデフォルト型へピン留めされた入力及び出力型を有する視覚XQueryエディタを使用することができる。XQueryエディタは、システムまたはユーザがitemIDをCatalogIDへ接続することを可能にし、また量を０にすべきことを指示することを可能にする。
【００２０】
CatalogItemクラスのためのデフォルト型宣言の例を、図７に示す。これは、XQueryによって全ての変換を含むディレクトリ内のファイル内へ視覚的に書き込むことができる。XQueryは、如何にしてカタログアイテムを正規ラインアイテム内へ変換するのかをシステムに告げるように定義することができる。このような問合わせの例を図８に示す。図８に太字で示すテキストは、CatalogIDをitemIDへマップし、エキストラフィールドqtyを０にセットするXQueryに対応する。残余は、XQueryをＸＭＬファイル内に保持するエンベロープである。この０値は、図９に示すようにＪａｖａ内において行うことができるように、補正することができる。図９の行１３上に、カタログアイテムがアイテム行内へ送られるようなコード例を見ることができる。ユーザが既存ＡＰＩから到達するカタログアイテムを取り、そのアイテムをXBean（ラインアイテムを表す）内へ到達させることが望ましい。カタログアイテムがラインアイテムとは異なるので、通常はこのようなコードは働かないであろう。
【００２１】
ＸＭＬ変換システムの例を図１０に示す。一実施の形態においては、変換（XQueries）のグローバルレジストリ１１１を、１つのデータ型から別のデータ型へ到達させるために使用することができる。１組のXqueriesを入手した後に、変換システム１１０は、ソース型１０８からターゲット型１０９への変換が存在するか否かを、自動的にルックアップすることができる。別の実施の形態においては、変換のライブラリ１１２を未だ使用することができる。但し、出所型から宛先型へ自動的に変換する代わりに、各変換には名前が与えられる。カタログアイテムが与えられ、正規ラインアイテムをセットする必要がある場合には、ユーザは、セットが呼出される前に、単純に名前によって変換を呼出すことができる。行１３及び１４が太線で示されている図９において、カタログアイテムをラインアイテムへ変換することをシステムに告げる機能呼出しが、‘set’と‘findCatalogItems’との間に存在する。この変換明示を行う１つの理由は、多くのユーザのために、変換の不可視レジストリを要約し過ぎにし、及び “アンダー・ザ・カバーズ”にすることができることである。もしユーザが変換されたデータを有していれば、そのユーザはコード内の変換の名前を実際に見たいであろう。もしユーザが名前を見ることができれば、どの変換が行われ、それがデータにどのように影響したかを決定するためにコードを通してユーザをナビゲートすることができる。これは検査として働くことができるから、ユーザは変換を理解し、コードがそのユーザに属するのか、または他人に属するのかを確かめることができる。
【００２２】
量が補正されたことを確認する代替の方法は、line-item変換を通してCatalogItemを定義し、CatalogItem及び整数量のような２つの入力引数を取ることである。この例から、ソース型及びターゲット型を指示する変換のグローバルレジストリが存在することが理解されよう。ソース及びターゲットは、Ｊａｖａ型であることが許容される。２つの異なる型間の自動翻訳が要求される場合には、レジストリを調べることができる。レジストリは、状況に依存して単一のＪａｖａ型を任意の数の異なるＸＭＬ型にマップできるように使用することができる。またレジストリは、任意の２つの所与の型の間の全てのマッピングに対して１回だけ定義すればよく、それによって容易に再使用可能になるという長所をも有することができる。
【００２３】
若干のシステムにおいては、単一のプログラム中の同時点にスキーマの複数バージョンを取扱う必要があるような困難さがもたらされる。この理由から、各スキーマにバージョン識別子でタグするための準備が存在し得る。関連Ｊａｖａ型及び変換は全て別々に行うことができ、各バージョンはそれ自体の型システムとして処理される。
【００２４】
更に別の例においては、ユーザは、入力としてカタログアイテムを取るＷｅｂサービスを書くか、またはＷｅｂサービスとして“findCatalogItem”のような既存Ｊａｖａ機能を露出させることを望むかも知れない。例えば、既存システムのＷｅｂサービスとしてfindCatalogItemを露出させるように以下のコードを書くことができる。
2006516781.tif 000005
【００２５】
このようなアプローチは、ユーザが、そのユーザのＷｅｂサービスのための適切なＷＳＤＬを定義する場合に受入れ可能になる。不幸にもこれは、所望の結果型を記述する既存ＸＭＬスキーマが存在するような状況である。例えば、結果は、上例におけるように、標準購入注文書line-itemエレメントとして戻すことができる。この場合、実際のＷＳＤＬは既存ＸＭＬスキーマに準拠しない。ＸＭＬ変換を使用して適切なスキーマを作成することを試みることはできるが、既存システムは、都合の良い構文を準備する以外、マップをスキーマに準拠させることを支援しない。しかしながら、本発明の種々の実施の形態による変換レジストリを使用すれば、戻される結果を、容易に適切な型に準拠させることができる。
【００２６】
例えば、コードは次のように変更することができる。
2006516781.tif 000006
上記コードは、CatalogItem型をpo:line-itemエレメントの型にマップする定義されたＸＭＬ変換が存在することを要求する。もし存在しなければ、ＩＤＥが、戻りスキーマ注釈上でエラーを信号する。しかしながら、もし定義された変換が存在すれば、Ｗｅｂサービスメソッドの戻り型は要求されたスキーマに準拠し、必要スキーマは放出されるＷＳＤＬ内に含ませることができる。
【００２７】
“return-schema type＝po:line-item”を含む行の中に見ることができるような例においては、システムはユーザにカタログアイテムを戻すが、ＸＭＬ内にラインアイテムを有することを許容する。システムは、ユーザがXQueriesのレジストリへ進み、XQueryを使用して命令を実行することを可能にする。この実施の形態は、XQueryとＸＭＬマップとの結合、全スキーマの支援、強く型付けされたビュー及びデータのＸＭＬビューの両者への同時アクセスを得るメソッドを提供する。
【００２８】
図１１に示すように、一実施の形態によるシステム及び方法が、ＸＭＬ型１１４としてＸＭＬの一部分をロードする場合、そのＸＭＬ型を軽量内部ＸＭＬ記憶装置１１５内へロードすることができる。これは、W3C ドキュメントオブジェクトモデル（ＤＯＭ）を用いて行うことができるものと類似しているが、オリジナルのＸＭＬに対して完全な忠実度を有することが可能なより軽量な手法で行われる。記憶装置は、探索可能なインデックスとして、またはこの例におけるように、ほぼテキストまたはタグレベルにおいて、ＸＭＬデータ１１３を保持するだけであるから軽量である。従って、ユーザが購入注文書のようなＸＭＬ型を有している場合には、ユーザは簡単にこれらの軽量ＸＭＬ記憶装置の１つの位置へのハンドルを有することができる（これはＸＭＬツリーに似させることができる）。ユーザがその参照を入手する時点には、未だ如何なるマーシャリングも存在していない。ユーザが“getLineItem”、“getLineItem.getDesc”、または“getQty”のようなメソッドを呼出す時にゲッタを呼出すことができる。ゲッタは、マーシャリング、型の決定、及び返答の戻しに使用される。このアプローチは、データの一部分だけが処理されるので、極めて時間効率的であることができる。
【００２９】
若干の実施の形態によるシステム及び方法は、ＸＭＬスキーマ及び対応するＪａｖ型を同期して保持することができる。強く型付けされたＪａｖａを有するユーザは、例えば新しいラインアイテムを追加するか、または量を変化させ始めることができる。もしそのユーザがＪａｖａ型上でXPathパスを走らせることを望めば、現在のデータのフォームにおいてはXPathをＸＭＬデータ文書上で走らせる必要があり得る。この場合、もしユーザがＸＭＬ側上で、または強く型付けされたＪａｖａ側上で文書に変更を行えば、他方の側の適切な部分が無効になりかねない。爾後にユーザがその他方の側を見る時に、先に無効にされた情報をとがめることができる。
【００３０】
ＸＭＬスキーマをコンパイルするためには、スキーマ、またはＸＳＤファイル（“スキーマのためのスキーマ”と呼ばれ、換言すれば、ＸＳＤファイル自体のための適切なスキーマを表すＸＳＤファイル）をパーズする必要があり得る。もしシステムがシステムに渡されたスキーマの100％を取扱うことができるように支援されており、またシステムが都合の良いＪａｖａアクセス可能性を生成すれば、システムがスキーマを読む時にＸＳＤファイルを理解するために、システムはそれ自体が生成した型を使用することが期待できる。ユーザは、スキーマのためのスキーマを取り、システムがＪａｖａを簡単に使用できるようにそれをＪａｖａにコンパイルできるべきである。
【００３１】
図１２に示すような若干の実施の形態によるシステム及び方法においては、何れのデータ、即ちＸＭＬデータの一部分にも少なくとも２つの部分が存在し得る。これらは、データ１１６の正当な（リーガルな）型、及び生データ１１９の意味を含む。データの正当な型は、現在のアプリケーションのためにどの種類のデータを有効として注視しているかを定義する。スキーマは、正当な型のデータに関する極めて特定の詳細を含むことができ、また若干の場合には、データの意味に関するある詳細を含むことができる。データの正当な型を知れば、強く型付けされた手法でそのデータへのアクセスを提供する自動型を生成することが可能になる。これが可能なのは、部分的には、スキーマを所与のデータフィールドの全ての有効サブフィールドを識別できるからである。これにより、ユーザに、１または複数の適切な場所における強く型付けされたＪａｖａアクセスを許可することが可能になる。ユーザがデータをロードし、適切な型のデータを有した後になっても、ユーザはデータが何を意味しているのかを知らないかも知れない。この場合、スキーマコンパイラ１１７を使用して生データを理解することができる。これは、要約文法を取り、その要約文法を構文ツリー内へコンパイルすることが可能なＹＡＣＣ（“更に別のコンパイラコンパイラ”）として知られるものにやや類似している。ＸＭＬが既に構文ツリーであるから、これは問題ではない。しかしながら、ＸＭＬは制約付きの構文ツリーではない。どのノードも、ツリー内のその下にいろいろなエレメントを有することができる。ユーザがスキーマ（ＸＭＬのための文法と考えることができる）を有した後は、ユーザは、任意のノードの下に何を支援しているかを正確に知ることになる。従って、生ＸＭＬ構文ツリーを使用する代わりに、ユーザはスキーマ・制約付きの構文ツリーを利用することができる。
【００３２】
本発明の一実施の形態によるシステム及び方法は、各スキーマを、単純な型を含むＪａｖａ型として維持する。もしユーザが、単純な型の制約であるスキーマを有していれば、それをスキーマ内に指示させることができる。例えば、もしユーザが定義した型が正当な型の整数であれば、それは10,000−99,000の間の５桁の数でなければならない。これは既存システムにおけるように、必ずしも単純な整数型として定義する必要はない。代わりに、情報はＪａｖａ型内へ生成することができる。名前“restricted integer”のようなＪａｖａ型の名前は、スキーマから生成することができる。
【００３３】
本発明によるシステム及び方法によって維持することができる別の不変量は、スキーマ内の少なくとも２つの型（ベース型）が存在する場合に発生する。もしこれらの型の一方が他方の型のベース型であれば、その関係がＪａｖａ内の２つの型を接続する。型付けされたシステムの高忠実度翻訳が、ベース型の保存を可能にすることができる。
【００３４】
コンパイルされたＸＭＬ型制約１１８を使用する確認エンジンを使用して、何れかの関連ＸＭＬ型１２０がＸＭＬに従って有効であるか否かをユーザが決定できるようにすることができる。例えば、ＸＭＬにおいては、購入注文書ラインアイテムは、記述、量、カタログ番号、及び価格を有することができる。また、‘description’はオプションであるが‘catalogItemNumber’はオプションではないことを指示する適切なＸＭＬスキーマ内の制約も存在し得る。Ｊａｖａにおいては、あるフィールドがオプションではない、即ちヌルであり得ないことを指示するメソッドは存在しない。従って、マーシャリングを行う殆どの人々は、ビーンを確認することができない。本発明の実施の形態による確認方法を使用することにより、ＸＭＬ型制約に対するビーンの確認の使用が、及びどの確認問題の通報も可能になる。
【００３５】
若干の実施の形態によるシステム及び方法においては、ＸＭＬ型は、複数のＪａｖａコンポーネントの間で共用することができる。XBeanは、自動的に生成されたＸＭＬ型が、ユーザが定義したコンポーネント作業のために定義される場合のように自動的に放出される。この場合、パラメータ及び戻り値を表すXBeansは、そのコンポーネントのために生成されたＸＭＬ制御インタフェースへの内部クラスとして自動生成させることができる。もしメッセージ型が多くのコンポーネントにまたがって実際に共用されれば、メッセージの各インスタンス毎に私的なXBean型を持つことは無意味であり得る。この場合、コンポーネントのＸＭＬ型が如何に共用されるかを明示的に制御するために、ユーザが定義するコンポーネントを定義する時にXBean型を明示的に参照することを可能にするべきである。例えば、
2006516781.tif 000007
XBean型parameter-xmlのためのようなコンポーネント内の“MyData” を参照することによって、ビーンが引数名に対応するゲッタを有していることを表明することができる。例えば、getAはStringを戻すべきであり、getIはintを戻すべきである。もしこれらの型がラインアップしなければ、翻訳時エラーがもたらされ得る。return-xmlの場合、ビーン型が戻り値であることを、またはその型が戻り値とマッチする単一の特性を有していることを表明することができる。ＸＭＬ型を参照することによって、ＸＭＬスキーマは、このメソッドへの入力及び出力メッセージの型を定義するように参照される。これらのスキーマは、それらが“MyData”のような名前を有しているので、再使用することができる。マップも、ＸＭＬ型とＪａｖａ型との間で参照される。マップは、それが命名された型に付加され、マップを再使用できることから、メタデータとしてMyData型に付加される。
【００３６】
コンポーネント上の明示XBeansを指定する時に入手することができる生成されたＸＭＬ制御インタフェースは、以下のようであることができる。
2006516781.tif 000008
この例においては、命名されたXBean型は、許容されたxmlスキーマを指定するために使用され、生成された内部クラスは存在しない。
【００３７】
XBean型は、ＸＭＬを渡すことができるようになった時にXBeanも渡すことができるように、ベースＸＭＬ型を拡張することができる。更に、どのXBeanもＸＭＬデータ文書に付加することができるので、ＸＭＬが使用可能である場合には、そのデータへの都合の良いアクセスのためにXBeanを作成することができる。若干の実施の形態によるシステム及び方法においては、XBeanは、容易に作成することができ、幾つかの異なる手法で使用することができる。例えば、XBeanは、JWS（ＪａｖａＷｅｂサービス）メソッドの定義を介して暗示的に作成することができる。XBeanは、機能のパラメータリスト及びその機能に関連付けられたマップに基づいて作成することができる。また、XBeanは*.xbeanファイルを使用して明示的に作成することもできる。*.xbeanファイルは、JavaBean＋マップ、またはＸＭＬ＋問合わせ（各々は、注釈を自由に使用することができる）のような、少なくとも２つの異なるインプリメンテーションを有することができる。JWS動作によってビーンを暗示的に作成する例は、以下のようであろう。
2006516781.tif 000009
これは、動作のためのデフォルトマップを使用してXBeanを暗示的に作成するであろう。特定のマップを動作に適用することによって、入力及び出力のためのマップを使用してXBeanが作成される。もしbeanNameが既に定義済みであれば、既存ビーンを使用することができる。ビーンを作成する時に、既存構文を使用する代わりに別の構文を使用することができる。
【００３８】
単純なJavaBean＋Maps *.xbeanファイルは、以下のようであろう。
2006516781.tif 000010
これは、パブリックゲット及びセットメソッド、並びにこのセットの特性のために定義されている標準ＸＭＬを用いて、ファイルを作成するであろう。僅かながらより複雑なファイルは、以下のような付加されたマップを有していよう。
2006516781.tif 000011
上例は、ネイティブストレージとして個々のＪａｖａメンバーを使用する。同じく重要なものは、ネイティブストレージとしてのＸＭＬの使用であることができる。反対の側上で、単純なファイルは値を戻すためにXQueryを使用することができる。これは、以下のようであろう。
2006516781.tif 000012
【００３９】
若干の実施の形態によるシステム及び方法においては、開発者の観点から２つのＸＭＬ型、即ち可動カーソル、及び不動値が存在し得る。カーソルが運動すると、それが見るＸＭＬデータ文書の部分が変化し得るので、ＸＭＬデータ文書内の何処においても動作するように型を設計することができる。一方、不動値は１つの場所に固定することができるので、それらは、それらが参照しているデータ文書の部分のＸＭＬスキーマとマッチする強く型付けされたメソッドを有することができる。図１３は、このような実施の例を示しており、XMLIndex１２１は不動値を表し、XMLCursor１２２または１２３は基本的ＸＭＬデータの可動カーソルを表している。強いＸＭＬ型の実際のインプリメンテーションは、XMLCursorを使用しないが、購入注文書インタフェース１２４は、たとえそれが不動であっても、基本的XMLIndex内へ同種の参照を供給することに注目されたい。
【００４０】
ユーザはPurchaseOrderのような強い型を、あたかもそれが普通のＪａｖａ型であるように使用し、処理することができるが、型の後ろは、基本的ＸＭＬデータに直接アクセスして処理するインプリメンテーションであることができる。例えば、値の直後は強い型内にセットされ、同じ値を、同一セットを探索するためにXPathを使用する何等かのカーソルから使用することが可能である。
【００４１】
図１３に示すモデルは、ＸＭＬデータ文書が保持され、問合わされ、処理され、そして再使用される時に有用であり得る。他の時点においては、データ文書上に決して保持することなく一時使用のためにＸＭＬをストリーム化する必要があり得る。これらの状況においては、ＸＭＬプルパーザのようなXMLReaderクラスが存在し得る。各XMLValueオブジェクトは、XMLReaderを供給することによってそれ自体をストリームアウトすることができる。また、XmlReaderの内容をロードし、インデックスするXMLIndexコンストラクタも存在することができる。
【００４２】
図１４は、ＸＭＬ型ＡＰＩのためのクラス階層ダイアグラムの例を示している。図１４において、隅を丸めたボックスはインタフェースを表し、角のあるボックスはコンクリートクラスを表している。あるファイル、または生の入力ストリームから開始するユーザは、ＸＭＬパーザを使用してＸＭＬをパーズし、次いでパーズされたファイルをＸＭＬインデックスを使用してインデックスすることができる。図には２つのコンクリートクラスだけが示されており、これらのクラスは他の全てのインタフェースを実現するＸＭＬ型のためのファクトリである。
【００４３】
ＸＭＬ型は、コンパイル時にスキーマをＪａｖａ型内へコンパイルすることができる。これは、複素数型及び単純型の両者を含むことができる。XmlString及びXmlDateのようなプリコンパイルされた型は、ＸＭＬスキーマへの組込みの基本型及び単純型のために使用することができる。XMLObject自体は、xsd:anyTypeに対応させることができる。更に、各スキーマ毎に、全てのスキーマからマップを供給するターゲットクラス階層内にポインタ資源を、対応するＪａｖａ型名内に所与の名前と共に生成することができる。
【００４４】
複数のスキーマが同一のＸＭＬ名を有することを許容されているが、同一名を有する異なる型には異なる“XML world”名を用いてタグを付けることができる。１つのワールドだけが、デフォルトワールドであることを許される。型生成を制御する１つの方法は、コンパイルする時に、.xsdファイルに隣接する.xvalファイルを通してである。 ランタイムにおいて、インデックスされたＸＭＬは自動的にスキーマ・アウェアであることができる。スキーマの可視性は、現ClassLoaderに結び付けることができる。可視スキーマのスレッド・ローカルインデックスは維持することができる。完全修飾されたＸＭＬ名を介して新しいスキーマが要求された場合には、ClassLoader.getResourceAsStream呼出しを使用して、デフォルトワールド内のような対応するＪａｖａ型を指すポインタを探知することができる。特定ワールド内のルックアップを行うこともできる。XMLIndexのインプリメンテーションは、このようなスキームを使用して全てのＸＭＬを自動的に型に変形させる。もし“xml world”が指定されていなければ、デフォルトワールドを使用することができる。異なるバージョンのスキーマの使用を可能にする他の代替ビューを指定することもできる。
【００４５】
一実施の形態は、コンピュータ技術に精通していれば理解されるように、本明細書の教示に従ってプログラムされた普通の汎用、または専用ディジタルコンピュータ、または１または複数のマイクロプロセッサを使用して実現することができる。ソフトウェア技術に精通していれば理解されるように、本明細書の教示に基づいて適切なソフトウェアコーディングを容易に準備することができる。本発明は、当分野に精通していれば理解されるように、集積回路を準備することによって、または普通のコンポーネント回路を適切なネットワークに相互接続することによって実現することもできる。
【００４６】
一実施の形態は、コンピュータプログラム製品を含む。これは、命令をその上に／その中に格納している記憶媒体（複数の媒体）であり、且つその中に提示されている特色の何れかを遂行させるためにコンピュータをプログラムするために使用することができる。この記憶媒体は、限定するものではないが、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、及び磁気・光ディスクを含む何等かの型のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、ナノシステム（分子メモリを含む）、または命令及び／またはデータを格納するのに適する何等かの型の媒体またはデバイスを含むことができる。
【００４７】
コンピュータ可読媒体（複数の媒体）の何れか１つに格納されている本発明は、汎用／専用コンピュータまたはマイクロプロセッサのハードウェアを制御するための、及び本発明の結果を使用してコンピュータまたはマイクロプロセッサが人間のユーザまたは他のメカニズムと対話できるようにするためのソフトウェアを含む。このようなソフトウェアは、限定するものではないが、デバイス、ドライバ、オペレーティングシステム、実行環境／コンテナ、及びアプリケーションを含むことができる。
【００４８】
以上の本発明の好ましい実施の形態の説明は、例示のためになされたに過ぎない。本説明は、本発明を網羅してはおらず、本発明を開示した精密な形状に限定することを意図するものではない。当業者には、多くの変更及び変形が明白であろう。特に、上述したシステム及び方法の実施の形態において“型”という概念を、ＸＭＬ及びＪａｖａの両方のために使用しているが、この概念はインタフェース、形状、クラス、オブジェクト、ビーン、及び他の適当な概念のような相当概念と互換的に使用可能であることは明白である。実施の形態は、本発明の原理及びその実際的なアプリケーションを最良に記述し、それによって当業者が本発明を、種々の実施の形態を、企図された特定の用途に適する種々の変更と共に理解できるように選択し、説明したものである。本発明の範囲は、特許請求の範囲及びそれらの従属項によって限定されることを意図している。
【図面の簡単な説明】
【００４９】
【図１】本発明の実施の形態に従って使用することができるＸＭＬスキーマ定義ファイル例を示す図である。
【図２】本発明の実施の形態に従って使用することができるＸＭＬマーシャリング及びアンマーシャリングのためのシステムの例のダイアグラムである。
【図３】本発明の実施の形態に従って使用することができるＸＭＬスキーマからコンパイルされたＸＭＬ型を表すコード例を示す図である。
【図４】本発明の実施の形態に従って使用することができる注釈をベースとするフォーマットのコード例を示す図である。
【図５】本発明の実施の形態に従って使用することができるＷｅｂサービスを実現するコード例を示す図である。
【図６】本発明の実施の形態に従って使用することができる型変換のためのコード例を示す図である。
【図７】本発明の実施の形態に従って使用することができるデフォルト型宣言のためのコード例を示す図である。
【図８】本発明の実施の形態に従って使用することができるＸＭＬ変換のためのコード例を示す図である。
【図９】本発明の実施の形態に従って使用することができるＸＭＬ変換のためのコード例を示す図である。
【図１０】本発明の実施の形態に従って使用することができるＸＭＬ変換システム例のダイアグラムである。
【図１１】本発明の実施の形態に従って使用することができるＸＭＬ記憶装置のためのシステム例のダイアグラムである。
【図１２】本発明の実施の形態に従って使用することができるＸＭＬスキーマのためのシステム例のダイアグラムである。
【図１３】本発明の実施の形態に従って使用することができる型のためのシステム例のダイアグラムである。
【図１４】本発明の実施の形態に従って使用することができる階層ダイアグラム例を示すダイアグラムである。
【図１】
2006516781.tif 000013
【図２】
2006516781.tif 000014
【図３】
2006516781.tif 000015
【図４】
2006516781.tif 000016
【図５】
2006516781.tif 000017
【図６】
2006516781.tif 000018
【図７】
2006516781.tif 000019
【図８】
2006516781.tif 000020
【図９】
2006516781.tif 000021
【図１０】
2006516781.tif 000022
【図１１】
2006516781.tif 000023
【図１２】
2006516781.tif 000024
【図１３】
2006516781.tif 000025
【図１４】
2006516781.tif 000026
【手続補正書】
【提出日】平成18年2月15日(2006.2.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするためのシステムにおいて、
ＸＭＬデータと、
前記ＸＭＬデータを定義するＸＭＬスキーマと、
Ｊａｖａ内の前記ＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型と、
前記ＸＭＬスキーマから前記ＸＭＬ型を生成することができるコンパイラと、
を含むことを特徴とするシステム。
【請求項２】
前記コンパイラは、ＪａｖａＷｅｂサービスメソッドの定義に基づいて前記ＸＭＬ型を生成することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記コンパイラは、定義ファイルに基づいて前記ＸＭＬ型を生成することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項４】
前記コンパイラは、Ｊａｖａプロジェクトを１またはそれ以上の正規Ｊａｖａ型内へコンパイルすることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項５】
前記ＸＭＬ型は、前記ＸＭＬデータ内の何処をも読むことができる可動カーソルであることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項６】
前記ＸＭＬ型は、前記ＸＭＬデータの固定された部分を参照できる不動値であることができる、
ことを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＸＭＬ型は、複数のＪａｖａコンポーネントの間で共用することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＸＭＬ型は、Ｊａｖａ内の前記ＸＭＬデータを更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項９】
前記ＸＭＬ型は、Ｊａｖａ型メソッドを使用してＪａｖａデータにアクセスし、更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＸＭＬ型は、データベースにアクセスし、更新することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記ＸＭＬ型は、ＸＭＬデータの問合わせ、ＸＭＬ型間の変換、及びＸＭＬデータ文書を通しての繰り返しを含む複数のＸＭＬデータを操作することができる、
ことを特徴とする請求項１に記載のシステム。
【請求項１２】
データ型及び前記データの範囲に関する制約、及び前記データ型及び前記ＸＭＬ型の範囲に関する制約を含む前記ＸＭＬデータの正当な型を定義することができるＸＭＬスキーマ、
を更に含むことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記コンパイラは、前記ＸＭＬスキーマから前記ＸＭＬデータの正当な型についての前記ＸＭＬ型に関する制約を生成することができる、
ことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記ＸＭＬ型に関する制約は、前記ＸＭＬ型を検査することができる、
ことを特徴とする請求項１２に記載のシステム。
【請求項１５】
ＸＭＬとＪａｖａとの間で型を変換する方法において、
Ｊａｖａ型を使用するステップと、
Ｊａｖａ内のＸＭＬデータにアクセスすることができるＪａｖａ型であるＸＭＬ型を使用するステップと、
ＸＭＬ変換を介してソース型をターゲット型に変換するステップと、
を含み、
前記ソース型及びターゲット型は、前記ＸＭＬ型または前記Ｊａｖａ型の何れであることもできる、
ことを特徴とする方法。
【請求項１６】
ＸＭＬ変換のグローバルレジストリを介してソース型とターゲット型との間の既存ＸＭＬ変換をルックアップするステップ、
を更に含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
ＸＭＬ変換のライブラリを介してソース型とターゲット型との間の既存ＸＭＬ変換を名前によってルックアップするステップ、
を更に含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルする方法において、  ＸＭＬデータを、軽量ＸＭＬ記憶装置を介して探索可能なインデックスとして保持するステップと、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照し、前記ＸＭＬデータにアクセスするステップと、
を含むことを特徴とする方法。
【請求項１９】
命令を格納している機械可読媒体において、前記命令はプロセッサによって実行された時に、システムに、
軽量ＸＭＬ記憶装置を介してＸＭＬデータをテキストまたはタグレベルにおいて保持させ、
Ｊａｖａ内の前記ＸＭＬ型を介して前記軽量ＸＭＬ記憶装置を参照させ、前記ＸＭＬデータにアクセスさせる、
ことを特徴とする機械可読媒体。
【請求項２０】
実行された時に、システムに、
前記保持したＸＭＬデータを、ツリーであることができる階層構造として表させる、
命令を更に含むことを特徴とする請求項１９に記載の機械可読媒体。
【請求項２１】
実行された時に、システムに、
前記ＸＭＬ型を介して前記ＸＭＬデータに増分的にアクセスさせる、
命令を更に含むことを特徴とする請求項１９に記載の機械可読媒体。
【請求項２２】
ＸＭＬとＪａｖａとの間でデータをマーシャル及びアンマーシャルするためのシステムにおいて、
ＸＭＬスキーマを使用してＸＭＬデータを定義する手段と、
Ｊａｖａ内のＸＭＬ型を介して前記ＸＭＬデータにアクセスする手段と、
コンパイラを使用して前記ＸＭＬスキーマからＸＭＬ型を生成する手段と、
を備えていることを特徴とするシステム。
【国際調査報告】
2006516781.tif 000027