(57)【要約】不正なXMLタグがみつかったときにユーザーにそのエラーをすぐ知らせるのではなく先読み／戻り読みをする、確率に基づく検証方法を使ったシステムおよび方法が開示される。このシステムおよび方法は、ひとかたまりのXMLコード内のエラー位置を指摘するために使える確率に基づく値を提供し、確率値を使って最も確からしいエラー位置を示すことができる。
2007501464.tif 000002
【特許請求の範囲】
【請求項１】
スキーマを与え、
インスタンス文書を与え、
前記インスタンス文書を前記スキーマと比較し、
前記インスタンス文書がエラーセクションを含んでいるかどうかを前記比較ステップに基づいて判定し、
エラーがあれば、該エラーセクションに関係している可能性のある当該スキーマの論理セクションが複数あるかどうかを判定し、
前記複数の論理セクションのそれぞれについて、当該エラーセクションとそれぞれの論理セクションとの間の関係を示す確率値を決定する、
ことを有することを特徴とする、マークアップ言語文書中のコードを検証するための方法。
【請求項２】
前記スキーマが拡張可能マークアップ言語（XML）スキーマであることを特徴とする、請求項１記載の方法。
【請求項３】
前記複数の論理セクションが<choice></choice>タグ対の下位要素を含むことを特徴とする、請求項２記載の方法。
【請求項４】
前記下位要素が少なくとも二つの<sequence></sequence>グループを含むことを特徴とする、請求項３記載の方法。
【請求項５】
前記複数の論理セクションのそれぞれについて前記確率値をユーザーに提供するステップをさらに有することを特徴とする、請求項１記載の方法。
【請求項６】
前記論理セクションのそれぞれについての前記確率値に基づいて当該エラーセクションが前記複数の論理セクションのうちのどれに一致すべきかを予測するステップをさらに有することを特徴とする、請求項１記載の方法。
【請求項７】
前記複数の論理セクションのそれぞれについての前記確率値が、当該スキーマのそれぞれの論理セクションと比較したときに当該エラーセクション内に現れる正しいタグの数を、前記それぞれの論理セクションの中にあるタグの総数で割った比に基づいていることを特徴とする、請求項１記載の方法。
【請求項８】
スキーマを与えるためのコンピュータ可読コードと、
インスタンス文書を与えるためのコンピュータ可読コードと、
前記インスタンス文書を前記スキーマと比較するためのコンピュータ可読コードと、
前記インスタンス文書がエラーセクションを含んでいるかどうかを前記比較ステップに基づいて判定するためのコンピュータ可読コードと、
エラーがある場合にそのエラーセクションに関係している可能性のある当該スキーマの論理セクションが複数あるかどうかを判定するためのコンピュータ可読コードと、
前記複数の論理セクションのそれぞれについて当該エラーセクションとそれぞれの論理セクションとの間の関係を示す確率値を決定するためのコンピュータ可読コード、
とを有するコンピュータプログラムを保存しているコンピュータ可読媒体。
【請求項９】
前記スキーマが拡張可能マークアップ言語（XML）スキーマであることを特徴とする、請求項８記載のコンピュータ可読媒体。
【請求項１０】
前記複数の論理セクションが<choice></choice>タグ対の下位要素を含むことを特徴とする、請求項９記載のコンピュータ可読媒体。
【請求項１１】
前記下位要素が少なくとも二つの<sequence></sequence>グループを含むことを特徴とする、請求項１０記載のコンピュータ可読媒体。
【請求項１２】
前記複数の論理セクションのそれぞれについて前記確率値をユーザーに提供するためのコンピュータ可読コード、
をさらに有することを特徴とする、請求項８記載のコンピュータ可読媒体。
【請求項１３】
前記論理セクションのそれぞれについての前記確率値に基づいて当該エラーセクションが前記複数の論理セクションのうちのどれに一致すべきかを予測するためのコンピュータ可読コード、
をさらに有することを特徴とする、請求項８記載のコンピュータ可読媒体。
【請求項１４】
前記複数の論理セクションのそれぞれについての前記確率値が、当該スキーマのそれぞれの論理セクションと比較したときに当該エラーセクション内に現れる正しいタグの数を、前記それぞれの論理セクションの中にあるタグの総数で割った比に基づいていることを特徴とする、請求項１１記載のコンピュータ可読媒体。
【請求項１５】
スキーマおよびインスタンス文書を受信するためのインターフェースと、
メモリと、
前記インターフェースおよび前記メモリに結合されたプロセッサとを有しており、
前記プロセッサが、前記スキーマに照らして前記インスタンス文書を検証し、前記インスタンス文書がエラーセクションを含んでいるかどうかを前記比較に基づいて判定し、エラーがあれば、該エラーセクションに関係している可能性のある当該スキーマの論理セクションが複数あるかどうかを判定し、前記複数の論理セクションのそれぞれについて、当該エラーセクションとそれぞれの論理セクションとの間の関係を示す確率値を決定する、ための前記メモリに保存されているコードを実行するよう構成されていることを特徴とする、マークアップ言語文書中のコードを検証するための装置。
【請求項１６】
前記スキーマが拡張可能マークアップ言語（XML）スキーマであることを特徴とする、請求項１５記載の装置。
【請求項１７】
前記複数の論理セクションが<choice></choice>タグ対の下位要素を含むことを特徴とする、請求項１６記載の装置。
【請求項１８】
前記下位要素が少なくとも二つの<sequence></sequence>グループを含むことを特徴とする、請求項１７記載の装置。
【請求項１９】
さらにディスプレイを有し、前記プロセッサがさらに前記複数の論理セクションのそれぞれについて前記確率値をユーザーに提供するためのコードを実行するよう構成されていることを特徴とする、請求項１５記載の装置。
【請求項２０】
前記プロセッサがさらに前記論理セクションのそれぞれについての前記確率値に基づいて当該エラーセクションが前記複数の論理セクションのうちのどれに一致すべきかを予測するためのコードを実行するよう構成されていることを特徴とする、請求項１５記載の装置。
【請求項２１】
前記複数の論理セクションのそれぞれについての前記確率値が、当該スキーマのそれぞれの論理セクションと比較したときに当該エラーセクション内に現れる正しいタグの数を、前記それぞれの論理セクションの中にあるタグの総数で割った比に基づいていることを特徴とする、請求項１５記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に、本発明はXMLプログラミングに関するものである。より特定的には、本発明はXML文書の確率に基づく検証のための方法およびシステムに関する。
【背景技術】
【０００２】
XML（Extensible  Markup  Language［拡張可能マークアップ言語］）はより柔軟かつ適応性のある情報同定を提供することによりWWW（World  Wide  Web［ワールドワイドウェブ］）の機能性を改善するために設計された。XMLが拡張可能と称されるのは、HTML（Hyper  Text  Markup  Language［ハイパーテキストマークアップ言語］）のような固定されたフォーマットではないからである。HTMLが単一の、あらかじめ定義されたマークアップ言語であるのに対し、XMLは「メタ言語」である。すなわち、XMLは他の諸言語を記述するための言語である。XMLはユーザーが制限のない量の文書について自らのカスタマイズされたマークアップ言語をデザインすることを許容する。XMLがこのような仕方で利用できるのは、XMLがSGML（Standard  Generalized  Markup  Language［汎用マークアップ言語規約］）というテキストマークアップシステムのための国際標準「メタ言語」（ISO8879:1985）で書かれているからである。
【０００３】
XMLは、文書型を定義したり、SGMLで定義された文書の簡略化されたオーサリングおよび管理を可能にしたり、ウェブを通じた文書の伝送および共有を容易にしたりといった、ウェブ上でのSGMLのストレートな利用を可能にするために設計された。XMLはXML仕様に記載されており、SGMLの方言をなしている。XML開発における一つの目標は、HTMLと同じようにウェブ上で受信され、処理されるような汎用SGMLを創り出すことだった。したがって、XML設計における設計上の特徴のうちには、実装が容易であることとSGMLおよびHTML両方との相互運用性とがあった。XMLはウェブページでの利用のためだけに設計されたわけではない。XMLは多くの異なる種類の情報を保存するために利用されるべく設計された。重要なXMLの用途としては、そのままでは通信できない多様なコンピューティングシステムの間で情報を伝送するために情報をカプセル化することを含む。
【０００４】
XMLにより、団体や組織は、化学、電子工学、金融、工学などといったある分野内の情報を交換するために自らのカスタマイズされたマークアップアプリケーションを作成することができる。それぞれのカスタマイズされたマークアップアプリケーションはW3C  XMLスキーマ定義言語の特定のXMLスキーマと称される。XMLスキーマは、XML文書の階層構造（ツリーともいう）がどのようなもので個々の要素／属性があらかじめ定義された値を有するべきかどうか、XML文書に課される制約条件は、などといったことを定義する。
【０００５】
XMLスキーマは、たとえば均一でないシステムにネットワークを通じてアクセス／伝送されることのできるさまざまなデータベースを作成するのに使うことができる。データベースの作成においては、完全性制約条件と結びついたデータモデルを使うことでそのデータの構造および内容が必要条件を満たすことを保証することができる。XMLファイルは読んだり編集したりするのが容易になるように設計される。XMLファイルはまた、異なるシステムや異なるアプリケーションの間でのデータ交換が容易になるようにも設計される。しかし、これらの要因はいずれも、データが特定のフォーマットである必要性に反することでありうる。検証は、XMLデータが特定の所定の構造に従っており、アプリケーションにとって予測可能な仕方で受信できるという確証を可能にする。データ検証の基準となるこの構造を与えるにはいくつもの異なる方法がある。それにはDTD（Document  Type  Definition［文書型定義］）およびXMLスキーマが含まれる。
【０００６】
スキーマ文書とは構造を含む文書であり、インスタンス文書とは実際のXMLデータを含む文書である。本質的には、スキーマ文書は単に別のXML文書の構造を記述する所定の要素（element）および属性（attribute）をもつXML文書である。あらゆるXML文書は要素から成り立っている。スキーマ文書中である要素を定義することは、その要素に名前を付けてある型（type）を割り当てるという問題である。この型指定はカスタムの型を参照してもよいし、XMLスキーマ勧告（XML  Schema  Recommendation）において挙げられている組み込み型の一つを参照してもよい。
【０００７】
この環境における一つの重要な問題は、XMLスキーマは、<choice>タグを使って下位要素の選択をすることを許容するということである。図１は<choice>を使って“character”の内容を指定するXMLスキーマを説明するコードブロックを示した図である。これは、<choice></choice>タグ対に関しては２つの<sequence></sequence>タグ対のうちの一方を選ぶことができることを意味している。
【０００８】
図２および図３は２つの（インスタンス）文書の例を示している。いずれも図１に示したXMLスキーマに照らして有効なものである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
検証結果を提供する検証エンジンは従来から知られている。検証結果は、インスタンス文書が特定のXMLスキーマに照らして有効であるか否かを示す。しかし、多重レベルのサブツリーをもつ大きなスキーマが実装されていると、小さなエラーが非常に混乱させる検証結果につながることがあり、インスタンス文書のデバッグに多大な労力が必要である。
【００１０】
たとえば、XMLスキーマはDICOM（Digital  Imaging  and  Communication  in  Medicine［医用デジタル撮像通信］）規格の情報を表すのに使われうる。そのようなDICOM規格のXML文書が作成されるときには、このXML文書を検証するために適切なXMLスキーマを使うことができる。DICOM規格のような非常に込み入ったXMLスキーマ表現については、非常に込み入ったXML文書内でエラー候補をみつけるためには精密な検証を行うことが本質的である。従来の検証方法は、<choice>タグを使って選択をするという状況の下でXML要素の正しさを判定しながらも精密に動作するものではない。
【００１１】
したがって、これらのことを含むさまざまな不都合な点を克服するような方法およびシステムを提供することが望ましい。
【課題を解決するための手段】
【００１２】
本発明の一つの側面は、不正なXMLタグがみつかったときにユーザーにそのエラーをすぐ知らせるのではなく、先読み／戻り読みをする、確率に基づく検証方法を使ったシステムおよび方法を提供する。この方法は、ひとかたまりのXMLコードを見て可能なあらゆるエラー位置を確率付きで特定することによるエラー位置の指示を用いた確率に基づく呈示を提供するので、従来の検証方法よりも精確である。
【００１３】
本発明のある実施形態は、マークアップ言語文書中のコードを検証するための方法に向けられている。その方法は、スキーマおよびインスタンス文書を与え、前記インスタンス文書を前記スキーマに照らして検証し、前記インスタンス文書がエラーセクションを含んでいるかどうかを前記検証ステップに基づいて判定する、ステップを含む。エラーがあれば、そのエラーセクションに関係している可能性のある当該スキーマの論理セクションが複数あるかどうかの判定がなされる。そして該複数の論理セクションのそれぞれについて、当該エラーセクションとそれぞれの論理セクションとの間の関係を示す確率値が決定される。
【００１４】
本発明のもう一つの実施形態は、スキーマを与えるための、インスタンス文書を与えるための、前記インスタンス文書を前記スキーマと比較するための、前記インスタンス文書がエラーセクションを含んでいるかどうかを前記比較ステップに基づいて判定するための、エラーがある場合にそのエラーセクションに関係している可能性のある当該スキーマの論理セクションが複数あるかどうかを判定するための、および該複数の論理セクションのそれぞれについて当該エラーセクションとそれぞれの論理セクションとの間の関係を示す確率値を決定するためのコンピュータ可読コード、を含むコンピュータプログラムを保存しているコンピュータ可読媒体に向けられている。
【００１５】
以上に述べたことを含む本発明のさまざまな特徴および利点は、現在のところ好ましい実施形態の以下の詳細な記述を付属の図面と併せて読むことでさらに明らかとなるであろう。詳細な記述と図面は単に本発明を説明するものであって、限定するものではない。本発明は付属の請求項およびその等価物によって定義される。
【発明を実施するための最良の形態】
【００１６】
本発明の実施形態を説明するために、従来の検証エンジンの不都合な点を一つ議論する。図４は、図１のXMLスキーマに照らして有効でないインスタンス文書の例を説明するコードブロックを示す図である。
【００１７】
インスタンス文書１（図２）およびインスタンス文書３（図４）を比較すれば、インスタンス文書３がタイプミスを含んでいる、すなわち“first-name”でなく“last-name”になっていることが見て取れる。
【００１８】
インスタンス文書３の作成者は文書１にあるように“first-name”を使うことを意図していたものと考えられる（便宜上、図４ではこのことを“error:”というコメントで示してある）。従来の検証エンジンを使ってインスタンス文書３を検証した場合、検証結果は、XML作者の意図に反してタグ“<friend-of>”のところにタグ“<birth-year>”がくるべきであると示すことになる。従来の検証エンジンは、先読みをして、インスタンス文書３が本当にスキーマ１（図１）に示した<choice></choice>タグ対の中の二番目の<sequence></sequence>に一致すべきであるかどうかを判定することはしない。これは、インスタンス文書３の<character>要素がタグ<last-name>で始まっているので、従来の検証エンジンは<choice></choice>タグ対の中の二番目の<sequence></sequence>が次にくるべきであると示してしまうからである。
【００１９】
これに関し、XML文書を検証するための従来のXML検証エンジン（たとえばXML  Spy、eXcelon  Stylus  Studio、Xerces）は、二番目の<sequence></sequence>が次にくるべきであると示す検証出力を生成することになる。しかし、そのような検証結果が文書作成者が実際に意図したことではないこともある。非常に込み入ったXML文書を検証するときにはそのような検証出力は混乱を生じ、インスタンス文書における本当のエラーをみつける手間を増すだけである。
【００２０】
図５は、本発明に基づくコンピュータ可読媒体上のコードの代表例としての実施形態を描くフロー図である。図５はXML文書の検証を改善するための方法の実施形態を詳細に示している。
【００２１】
当該方法は、ステップ１００でユーザーがあるインスタンス文書をあるスキーマに照らして検証しようとすることで開始される。ステップ１１０では、そのインスタンス文書がXMLスキーマに照らして検証される。この比較の間にエラーが検出されなければ（ステップ１２０）、インスタンス文書はスキーマに照らして有効である（ステップ１３０）。ステップ１２０でエラーが検出された場合、スキーマ中に複数の論理セクションがあるかどうかが判定される。たとえば、図１に示したスキーマでは、<choice></choice>タグ対は二つの<sequence></sequence>グループを含んでいる。<sequence></sequence>グループのそれぞれが論理セクションである。代替となる<sequence></sequence>グループをもつ<choice></choice>タグ対がスキーマ中に含まれなければ、ステップ１５０でエラーレポートが出力されることになる。
【００２２】
ブロック１６０で、当該方法は「先読み／戻り読み」と「確率に基づく」検証処理とを含んでいる。従来の検証エンジンは単にXMLスキーマに照らしてあるXML文書の最初の不正タグの候補をみつけるだけであるのに対し、当該方法はさまざまな要素（たとえば<choice></choice>タグ対）内のXMLのかたまりの他の／残りの論理セクションを先読みおよび／または戻り読みする。可能なエラー位置一つ一つについて確率が決定される。
【００２３】
この点に関し、インスタンス文書に矛盾または誤りが検出されると、確率に基づく処理ブロック１４０はエラーを含むXMLコードのかたまりをたとえば<choice></choice>タグ対の中のあらゆる選択と比較し、各選択についてエラー確率を計算する。
【００２４】
この実施形態では、確率を計算するための公式は次のようになる：
（確率）＝（スキーマのある論理セクションと比較したときに当該インスタンス文書内に現れる正しいタグの数）／（前記論理セクションの中にあるタグの総数）
たとえば、次のXMLコードのかたまりは（図１のXMLスキーマを考える場合）下線部分にエラーを含んでいる。
【００２５】
<last-name>Snoopy</last-name>
<friend-of>Peppermint
Patty</friend-of>
<since>1950-10-04</since>
<qualification>extroverted
beagle</qualification>
上で議論したように、図１に示されたスキーマには二つの論理セクションがある。すなわち、一番目と二番目の<sequence></sequence>グループである。上記のXMLコードのかたまりを図１の<choice></choice>タグ対の中の一番目の<sequence></sequence>と比較すると、エラー確率は3/4と決定される。すなわち、このかたまりは総数４つのうち３つの正しいタグを含んでいる。上記のXMLコードのかたまりを図１の<choice></choice>タグ対の中の二番目の<sequence></sequence>と比較すると、エラー確率は1/4と決定される。すなわち、このかたまりは総数４つのうち一つ正しいタグを含んでいる。
【００２６】
3/4および1/3という二つの確率の値を示されたとき、XML文書の作成者は適正にエラー位置を判断することができる。3/4＞1/3であるから、上記のXMLコードが図１のXMLスキーマにおける一番目の<sequence></sequence>タグ対に一致すべきであることがより確からしい。
【００２７】
この確率情報は、ユーザーが検討できるよう、本発明に基づく検証エンジンからの検証出力レポートの出力（ステップ１７０）に含められることができる。たとえば、エラーに遭遇したとき、検証エンジンはたとえば<choice></choice>タグ対の中であらゆる選択を読み、各選択について確率を計算し、これらの値をユーザーが判断できるよう印刷／表示することができる。検証エンジンはまた、ユーザーのために、確率因子の高さに基づいてそのエラーコードがどの論理セクションに一致すべきかを自動的に予測してくれることもできる。
【００２８】
上述した方法１００に関連した機能動作はメモリに保存され、プロセッサによって実行される一つまたは複数のソフトウェアプログラムに全体として、あるいは部分的に実装することができる。該ソフトウェアプログラムは、XML文書検証エンジンの一部でそれによってアクセスされるものでもよい。
【００２９】
プロセッサはネットワークへの情報インターフェースを含んでいてもよい。ネットワークは、たとえばインターネットのような世界規模のコンピュータ通信ネットワーク、広域ネットワーク、大都市圏ネットワーク、構内ネットワーク、ケーブルネットワーク、衛星ネットワークまたは電話ネットワークなどでもよいし、これらの、そしてその他の種類のネットワークの部分または組み合わせでもよい。情報インターフェースは前記ネットワークに結合されたサーバーおよび／またはクライアント機でありうる。
【００３０】
プロセスはメモリ内に保存されたスキーマおよびインスタンス文書にアクセスしてもよいし、ネットワークおよび／またはCDもしくはフロッピー（登録商標）ディスクインターフェースのような記憶インターフェースを通じた入力を介してアクセスしてもよい。
【００３１】
他の実施形態では、方法１００の諸側面を実装するためのソフトウェア命令の代わりに、あるいはそれと組み合わせてハードウェア回路を使うこともできる。
【００３２】
本発明の上述した方法および実装実施形態は例としての方法および実装である。実際の実装は議論した方法とは異なりうる。さらに、当業者は本発明へのその他さまざまな改良および修正を思いつくかもしれない。それは付属の請求項において述べられる本発明の範囲にはいるであろう。
【００３３】
本発明はその本質的な特徴から外れることなくその他の具体的な形態において実施することもできる。記載された実施形態はあらゆる面において単に説明するものと考えられるものであって、制限するものではない。
【図面の簡単な説明】
【００３４】
【図１】XMLスキーマを説明するコードブロックを示す図である。
【図２】図１のXMLスキーマに照らして有効なインスタンス文書の一例を説明するコードブロックを示す図である。
【図３】図１のXMLスキーマに照らして有効なインスタンス文書のさらに別の一例を説明するコードブロックを示す図である。
【図４】図１のXMLスキーマに照らして有効でないインスタンス文書の検証レポートの例を説明するためのコードブロックを示す図である。
【図５】本発明に基づく方法実施形態のフロー図である。
【図１】
2007501464.tif 000003
【図２】
2007501464.tif 000004
【図３】
2007501464.tif 000005
【図４】
2007501464.tif 000006
【図５】
2007501464.tif 000007
【国際調査報告】
2007501464.tif 000008
2007501464.tif 000009