目次


スキーマ・バリデータを活用したXMLのスタイル・ガイドライン

基本的なデータの検証にXML Schemaの妥当性検証を使って開発時間を短縮する

Comments

どうしたら無効なデータがシステムに入り込むのを防げるでしょうか?バウンドチェックをする検証ルーチンを手書きでコーディングすべきでしょうか。システムの入り口にXMLを使えば、この範囲でXML Schemaバリデータは信じられないほど時間を節約してくれるのです。これはXML SchemaだけでなくDTDのバリデータでも同じことが言えます。

DTDのバリデータは、基本的な構造に関する妥当性検証を行います。エラーを見つけたときには「この必要な要素がありません」とか、「あの要素が二度あってはいけません」と言ったエラー・メッセージを発します。ただ、DTDはデータ型の記述、再利用するための機構、名前空間などをサポートしていません。XML Schemaバリデータはもっとキメが細かく、こうした隙間を埋めるものです。

データの妥当性検証を手書きでコーディングするよりも、同じ目的ならXML Schemaのルール を定義することを検討してみてください。実行時にスキーマ・バリデータはルールを読み込み、入力されたデータがルールに合っていなければ危険信号を発してくれるのです。

この手法には多くの利点があります。XMLスキーマのルールは、プログラミング言語に依存しません。それらの文法は、データ駆動型でW3C標準に従っています。これは、妥当性検証のコードを手書きするよりもずっと速くルールをコード化してくれるということです。さらに、構成要素や開発者が違っていても、システムにおける妥当性検証のルック・アンド・フィールを容易に標準化することができるでしょう。

それに加え、XMLスキーマの妥当性検証を使うことで利用者があなたのXML APIを非常に良く理解できるようになります。手書きで作ったデータの妥当性検証はAPIを使う側にとって必ずしも使いやすいものとは言えません。手書きの場合、妥当性検証のコードが複数のソースファイルに分散している上、文書化されていないことは往々にしてあることです。データの妥当性を完全に記述した良質なXMLのスキーマがあれば、利用者はデータの妥当性ルールを思い描くことができ、APIもよく理解できるものです。利用者はソースコードに分け入る必要はなく、スキーマ上の新しいルールの一つ一つを知りさえすれば良い訳です。

ただし、XMLの構成方法によっては、スキーマ・バリデータの利点を完全に生かすことができない場合もあります。以降の説明で、XMLの構成方法に関する良くある事例を理解すれば、このような問題を回避できるようになるでしょう(DTDでもXML Schemaでも共通した問題です)。この記事ではさらに、妥当性検証ルールを定義するためのベスト・プラクティス(良い例)とワースト・プラクティス(悪い例)について説明します(これらはXML Schemaに関するもののみで、DTDには当て嵌まりません)。最後に現時点で入手可能なスキーマ・バリデータが持つ、いくつかの制限を簡単に紹介したいと思います。

XML文法なのかXMLメッセージ・セットなのか?

このようなXML文書には注意を払うべきです。

<ele>
<DataElement variable="CustomerName" value="Smith"/>
<DataElement variable="AccountBalance" value="100.00"/>
<DataElement variable="TransDate" value="12/22/1996"/>
</ele>

苛立たしいことですが、このXMLにはまったく間違いはありません。けれどもこのスタイルは、不必要なまでに手書きコーディングでのデータ検証が必要なものとなっています。例を挙げた方がこの問題が良く分かるでしょう。バグのある、この例を考えてみてください。

<ele>
<DataElement variable="CustomerName" value="Smith"/>
<DataElement variable="AccountBalance" value="100.00"/>
<DataElement variable="TransDate" value="12/22/1996"/>

</ele>

どうしたらこのバグがシステムに入り込むのを防げるでしょうか?このバグを取り去るのにデータの妥当性検証を手書きでコーディングしなければなりません。言うまでもなく、無効な日付や無効な数字も除去する必要があります。どんなシステムに入力されるにせよ、データには十分な妥当性の検証が必要になります。ところがこのXMLでは、データだけでなく変数名の妥当性まで検証するように求めているので、プログラマはシステム中でよく使われる変数名の正しい綴りまで正確に記憶しなければならないのです。将来どうなるか分からないようなXMLの要素とプログラマのスペルミスまでも処理するのは簡単なことではありません。ではここで、そんな例を初めから書いてみましょう。

<ele>
<DataElement variable="" value=""/>
<DataElement variable="" value=""/>
<DataElement variable="" value=""/>
<DataElement variable="" value=""/>
</ele>

この空白のキャンバスは薄気味の悪いものです。引用符の間には一体何が入るのでしょうか?・・・。このXMLは金融関連の取引を表すものでしょうか、それともスキューバ・ダイビング用品の取引を表すものでしょうか?・・・。日付の正しい書式はどうなっているのでしょうか?・・・。(あなたが、このデータを処理するコードをあれこれ調べるのを厭わないと言うのでない限り)このXMLコードには不明なものが多すぎます。こうした疑問に答えるのに、チームのメンバーがどれほどの時間を浪費すればよいのでしょうか?

このスタイルにも一点だけ良い点があります。使っている変数を追加したり変更したり(多分 IsCustomerActive のような新しい変数を追加するでしょう)したい場合でも、ドキュメントの構造を決めているスキーマを変更するのに時間がかからないのです。単に新しい変数名をXMLのタグに追加するだけ、それで完了です。

ただし、この柔軟性は非常に高くつきます。システムが不正データにずっと弱くなってしまうのです。このような問題に対処するために再構成したXMLは、以下のようなものです。

<AccountInquiry>
<CustomerName>Smith</CustomerName>
<AccountBalance>100.00</AccountBalance>
<TransDate>12/22/1996</TransDate>
</AccountInquiry>

もうこのメッセージには、スキューバ・ダイビング用品はありません。これならば、各タグに(正しく定義された書式で)データ型を指定することができます。なおかつ、スキーマ・バリデータが前に述べたバグに対して例外をスローする責任を持ってくれます。それに、このバリデータは不正な日付や数字に関するエラーをスローする責任まで負ってくれるのです。そして最後に、業界標準を使って完全にその本質を記述した構造を利用者に提供できるので、あなたは利用者から感謝されるでしょう。

有り余るような創造力があり、 <DataElement>variable="" 、それに value="" があれば、ほとんどどんなデータ構造でも定義できますが、これが問題の発端でした。目標は非常に明確なビジネス取引ができることだったのですが、私は結局汎用的な <DataElement> を使ってしまいました。この、汎用のXML構造と特定のXML構造の差は重要です。XML構造の2つの異なったスタイル間の区別を明確にしておきましょう。

  • いろいろなアプリケーションに適する汎用的なXML構造は、XML文法である。
  • 単一目的用途の特定なXML文書は、一種のXMLメッセージ・セットである。

XML文法とXMLメッセージ・セットはまったく違う代物です。どのようなスキーマであっても、双方を記述することはなく、どちらか一方についてだけ記述されます。一般的にスキーマはインスタンス文書に制約を加えるものです。ただしXML文法のスキーマでは創造性を発揮する余地が多分に残されています。XML文法のスキーマは、低レベルで非常に間口が広く、妥当とされるインスタンス文書の数はほとんど無制限と言えるほどです。それにもかかわらず、XML文法で妥当とされるXMLはサイズや形に非常に大きな幅があります。MathMLとUIMLの2つは、数百を数えるスキーマの中での良い例です( 参考文献 )。MathMLでは数学的な式を表現できます(どんな数式でも作れるのです)。UIMLも同じです(設計したいあらゆるUIアプリケーションを考えてみてください)。

一方メッセージ・セットのスキーマでは、ほとんど創造性を発揮する余地はありません。上記取引での4つのタグで作れる口座照会がどれだけあるか考えてみてください(ここで創造性を発揮できるのは税務署の職員くらいでしょう)。メッセージ・セットは厳格な妥当性検証用に作られています。同じメッセージに対する妥当なインスタンス文書は、お互いに驚くほど似ています。Interactive Financial Exchange (IFX: 金融データ交換のための通信規約)メッセージ・セットの妥当なメッセージを考えてみてください。これは金融関連の取引をモデル化したものです。顧客更新の妥当なメッセージは大体同じようなタグのセットを含むものです。Open Travel Alliance (OTA: 旅行業界における商取引の規約)も似た例です。(IFXとOTAについてさらに詳しい情報は 参考文献 を見てください。)

教訓としてはこういうことです。「制約が多いものの記述には、XML文法を使わずXMLメッセージ・セットを使え。」XML文法を使うと、山のようなデータの妥当性検証のためにコードを手書きする羽目になり身動きが取れなくなってしまうでしょう。

ルールの例外?

そうは言ったものの、あいまいなデータ構造も貴重ではあるのです。例えば、SOAPメッセージのスキーマにはアプリケーションが記述したメッセージ(SOAPボディ)が無いものはありません(ペイロード内にボディは必須だが、その内容は、アプリケーションによって異なる)。これにはXML Schemaの any 機能をこんな風に使います・・・

<complexType name="Body">
<!-- This is a placeholder for your message payload.-->
<!-- Use a WSDL file to define the structure.       -->
<any minOccurs="0" maxOccurs="*" /> <anyAttribute/> 
</complexType>

この仕掛けは、利用者に対して使用方法を伝えるのに役立ちます。「ここでーす。アプリケーション固有のものはここに入れてくださーい。」と皆に教えてくれているのです。決して、「スキーマの妥当性検証を無視して自分の首を絞めろ」と言っているのではありません。結局のところ、SOAPは上記ボディ要素の構造と検証ルールを規定する代替手段として、WSDLファイルを提供するのです。SOAPサーバーのような一部のコンポーネントは、他人が作ったXML構造に対応する必要があります。ただし、これがスキーマの妥当性検証を棚上げする言い訳だと思い違いしないで下さい。妥協することなくスキーマの妥当性検証を行いながら、柔軟性を生かすためには、このSOAP/WSDLパターンに従うことです。これに関してより詳細な説明は、Dare Obasanjo著による、XML Schemaの柔軟性に関する記事を見てください( 参考文献 )。

属性と要素のテキストに注意

こんな風に手直ししたXMLを見てください。

<Message msgType="AccountInquiry">
<CustomerName>Smith</CustomerName>
<AccountBalance>100.00</AccountBalance>
<TransDate>12/22/1996</TransDate>
</Message>

何が変わったのでしょうか?・・・ルートの <AccountInquiry> の代わりに今度は、 <Message msgType="AccountInquiry"> があります。スキーマ・バリデータに妥当性検証させるつもりならば、これは間違いです。それがなぜかを説明しましょう。同じメッセージ・セット ProductInquiry で次のようなメッセージを作ってみると、どこが悪いかより明確になるでしょう。

<Message msgType="ProductInquiry">
<ProductName>DEPOSIT</ProductName>
<BankName>Fred's Bank</BankName>
<TransDate>12/22/1996</TransDate>
</Message>

<Message> 要素には2つの違った意味があります。紛らわしいことに、一つは口座を、もう一つは製品を意味しています。最初に <Message> は、口座データを持つ必要があり、しかも口座データだけを持つと宣言します。それから心変わりして、同じ要素 <Message> が製品データを持つ必要があり、しかも製品データだけを持つと宣言します。 <Message> のためのスキーマは、すべてのメッセージに対して、すべての口座と製品の要素をオプションとして持っているはずです。すべてがオプションだとすると、例えば製品メッセージに重要な製品データが足りないときでもバリデータは、ぽかんとしているだけで何もしないでしょう。そういうデータが足りないときには、バリデータに警告を鳴らさせるようにしたいし、妥当性検証を自分で手書きしたくもないですよね。こうした問題はすべて、属性のメッセージ型を msgType="ProductInquiry" の様にコード化したことから起きました。次のように、この同じ情報を要素のテキストにコード化しても、同じ状況に陥ることになります。

<MessageType>AccountInquiry<MessageType>
<Message>
<CustomerName>Smith</CustomerName>
<AccountBalance>100.00</AccountBalance>
<TransDate>12/22/1996</TransDate>
</Message>

またしてもこれでは、 <Message> 要素に過度の負担をかけることになります。そうするのが常に悪いわけではありませんが、この場合にはスキーマ・バリデータの出番を不本意に抑えてしまっています。このジレンマを解決するには、 <Message><AccountInquiry><ProductInquiry> に置き換えます。そして次に、スキーマの各要素に適当な子要素を割り当てます。

要は属性や要素のテキストを使うときは、慎重であれと言うことです。メッセージに何が必要で何が必要でないかを規定しようとしている時に属性や要素のテキストは役には立ちません。 <Message> のような単一要素に過度の意味を持たせる悪しき習慣にもつながります。

属性がすべて悪いわけではありません。どのように属性を使うべきかと言うのは簡単ではありませんが・・・ただ残念なことに、どこに使ってはいけないかを挙げるのは簡単なのです。スキーマ・バリデータの主目的は構造の妥当性検証であり、これに関して属性はあまり関係が無いと言うことを忘れてはいませんか。バリデータがXMLのどこか別の部分の妥当性を判断するのに属性値を使うのは稀です(XML Schemaの IdentityKeyRef 機能は希な例外です)。スキーマの妥当性検証において、属性が二流の役割に追いやられているのはこのためです。同じことが要素のテキストについても言えます。

これらはめったに使われませんが、いくつかの(他のスキーマ言語を使った)技法を使うことで属性や要素のテキストをうまく扱うことができます(Jeni Tennison、Roger L. Costello、Bob DuCharmeらによる関連の成果を 参考文献 で紹介しています)。

XML文法とXMLメッセージ・セットの違いを念頭に置いておいてください。違いが分かっていることで、スキーマ・バリデータを生かしてXMLを構成できるようになります。さらに、XMLの属性がスキーマの妥当性検証では、限定された役割しか持たないことも忘れないでください。

ここまでは、スキーマ・バリデータを使うためのお膳立てとして、XMLをどのように構成すべきかを説明しました。これ以降では、XML Schemaの検証ルールを定義する良い例(ベスト・プラクティス)に焦点を当てます。また以降では、XML Schemaについて説明しています(XMLスキーマとXML Schemaの違いに注意してください)。

UMLにこだわるな

ソフトウェア開発者は長年、ビジネス・メッセージをモデル化してきました。XML以前、私が所属したグループでは、ビジネス・メッセージをUML (Unified Modeling Language:統一モデリング言語)でモデル化していましたが、UMLでは常に何かしらが欠けていました。たいていのUML表記法は、文書化するためのものに過ぎません。自分でモデル化した制約の妥当性を検証したいときには、自分で妥当性検証用のコードを書くしかありませんでした。これらの制約を(一度は表記法のために、もう一度はコード自身のために)2回もコード化する苦痛を考えてみてください。

XMLのスキーマは、この問題を解決します。単に表記を追加するだけで、実行時に妥当性検証ができるようになります。次の妥当性検証のルールは、XML Schema でモデル化することが容易であり、ビジネス・メッセージを明確に表現できるものです。

  • そのデータは必須なのか任意なのか
  • データ長: 例えば、顧客番号が特定の文字列長なのか、最小文字列長あるいは、最大文字列長を指定する必要があるのか・・・など
  • ワイルドカード・マスク: 例えば、顧客番号は、接頭辞としての2桁のアルファベットと何桁かの数字で構成される・・・など
  • 列挙と数値範囲: 例えば、ある文字列属性の内容はAかCかDでなければならない、ある数値は1から500の間でなければならない・・・など
  • 多重度: 2つの実体間の関係に多重度を指定できます。例えば、かご編み教室の各クラスには20人から30人の生徒がいる必要がある・・・などです。こうした制約を開発時に付加しておくことで、スキーマ・バリデータは、実行時に無効なデータを拒絶します。31番目の生徒がクラスに加わろうとすると、スキーマ・バリデータが例外を発します。

こうしたルールをスキーマに加えることで、自動的に文書化と実行時妥当性検証ができることになります。これは素晴らしいことです。UMLだけでは、とてもこんなことはできません。実際、UMLで同じことをするには、わかりにくい OCL (Object Constraint Language:オブジェクト制約言語) や OCLコード・ジェネレータをどこからか引っ張り出してくる必要があります。OCLの詳細に関しては 参考文献 を見てください。

XML Schemaを使う上での良い例と悪い例

必須要素と任意要素のモデル化

取引上の必須要素と任意要素のモデル化にXML Schema を使いなさい。

良い例: ビジネス・メッセージに要素が必要であれば、XML Schemaでそれをモデル化しなさい。そうすることで意図しないデータがシステムに入り込んだときに、スキーマ・バリデータが警告を発します(ですから自分で手間をかけずにすみます)。また、このスキーマは、このような定義がされているものであると利用者に対して説明しています。

<xsd:element name="FirstName" type="xsd:string"
minOccurs="1"/>

悪い例: システム下流のどこかの部分でデータが無いために処理に失敗するような場合、スキーマ上でデータ項目が任意であったためと言うことがあります。ここにXML Schemaにおける任意要素があります。

<xsd:element name="FirstName" type="xsd:string"
minOccurs="0"/>

一見しただけでは、この背景にある論理は納得の行くもののように思えます。もし、このデータ要素を任意から必須に変更するとしたら、システムのどこかでエラー処理が重複することになるでしょう。もしあなたが、このような経路をたどるのであれば、APIの利用者はエラーを見つけるのにかなりの時間を浪費することになります。こんなシナリオを考えてみてください・・・

  1. ユーザは、そのデータ項目が無いままで取引き情報を準備し、送信します(スキーマには、その項目が必須であると書かれていない)
  2. システムの他の部分がエラーを返す
  3. ユーザがエラー・メッセージを解読し、やがて、ある必須要素が足りないことを発見する
  4. ユーザが必須データ項目を追加し、取引き情報を再送する
  5. ユーザが問題なく実行できることを確認する

どの要素が必須かをスキーマ上に明示することで、こうした余計な手間の大部分を避けることができます。

日付/時間データ型のモデル化

ビジネス・メッセージ中にある日付と時間を表現するために、 xsd:dateTime を使いなさい。

良い例: 日付の書式は、XML Schema の仕様書で明確に定義されています。

<xsd:element name="BirthDate" type="xsd:dateTime"/>

悪い例: 次の例は、ユーザに適切な日付の書式(年は何桁にするのか、月は英字なのか数字なのか・・・などなど)を見つけることを強要することになるので、良くありません。

<xsd:element name="BirthDate" type="xsd:string"/>

スキーマを文書化する

良い例: XML Schemaの annotationノードを使えば、より一層ビジネス・メッセージの要素および、ビジネス・メッセージ自体を表現することができます。例えば・・・

<xsd:element name="Amount" type="xsd:integer">
   <xsd:annotation>
         <xsd:documentation>
               Use this element to specify the amount that should be transferred
         </xsd:documentation>
   </xsd:annotation>
</xsd:element>

こうした形式で文書化すれば、スキーマやXMLのインスタンス文書の両方を作成する助けになります。

悪い例: スキーマを文書化しない場合、ユーザには2つの選択肢しかありません。ソースコードをくまなく調べるか、別のドキュメントを参照するかのどちらかです。工夫したつもりでソースコードに入れ込んだちょっとした知恵の固まりが(たとえそれが正しいものであっても)、解読するのに何時間もかかったりするものです。スキーマと説明文書を別にしてしまうと、スキーマ内部の説明文書と違って更新されなくなる恐れが高くなります。

相互排他的なデータ項目のモデル化

良い例: 多くのビジネス・メッセージは、相互に排他的なデータ項目を含んでいるものです。例えば、メッセージの1つのインスタンスには、想定される2つ(あるいはそれ以上)の要素のうち、1つの要素だけが存在できるような場合です。こうした項目を1つのXML Schemaの要素として、こんな風に表します・・・

<xsd:choice>
   <xsd:element name="DestinationAccount" type="AccountKeyType"/>
   <xsd:element name="SourceAccount" type="AccountKeyType"/>
</xsd:choice>

こうすることによって、次の2つのXML断片のみが許されることになります。

<MyMessage>
<DestinationAccount/>
</MyMessage>

か、あるいは・・・

<MyMessage>
<SourceAccount/>
</MyMessage>

スキーマ・バリデータは、次のような断片を拒絶するでしょう。

<MyMessage> 
<!-- fails, because only DestinationAccount or SourceAccount is allowed -->
<DestinationAccount/>
<SourceAccount/>
</MyMessage>
<MyMessage>
<!-- fails, because neither DestinationAccount nor SourceAccount are present -->
</MyMessage>

悪い例: なじみのないXML Schema構文は避けてしまいがちです。ただ、そうするとビジネス・メッセージ中のデータ項目間の相互排他的な関係を強制するようなコードを、自分で書く羽目になってしまいます。また、データの重要な側面(選択的な排他要素の有無)を隠してしまうことにもなります。これでは、相互排他的な関係の有無が、ソースコードを見られる人にしか分からなくなってしまいます。

列挙

良い例: XML Schemaの列挙を使えば、ユーザがある特定の変数に対する妥当な値を見つけやすくなります。

<xsd:element name="TransactionIndicator">
   <xsd:simpleType>
      <xsd:restriction base="xsd:string">
         <xsd:enumeration value="FORCE_POST"/>
         <xsd:enumeration value="BACKDATE"/>
      </xsd:restriction>
   </xsd:simpleType>
</xsd:element>

もし、ある特定の変数に対する妥当な値が(LDAPやRDBMSのような)データ・ソースに保存されているような場合は、妥当な値をどう列挙すべきかXML Schema の documentation で明示すべきです。

<xsd:element name="TransactionIndicator" type="xsd:string">
   <xsd:annotation>
      <xsd:documentation>
Use business message "TransactionIndicatorInquiry" 
to discover the valid values for this attribute.
      </xsd:documentation>
   </xsd:annotation>
</xsd:element>

悪い例: 省略形で列挙するのは賢明ではありません。どんな値を使うべきなのかユーザには分かりません。

<xsd:element name="TransactionIndicator">
   <xsd:simpleType>
      <xsd:restriction base="xsd:string">
         <xsd:enumeration value="F"/>
         <xsd:enumeration value="B"/>
      </xsd:restriction>
   </xsd:simpleType>
</xsd:element>

更に悪い例: もし、変数が一定の妥当値を持つ場合には、それを(次のように)ユーザから隠してはいけません。

<xsd:element name="TransactionIndicator" type="xsd:string"/>

こうしてしまうと、ユーザは隣の人に聞くか試してみるか、それとも他の資料かソースコードを調べまくるかしかありません。

スキーマによる妥当性検証の欠点

XML Schemaのバリデータだけでなく、ほとんどのスキーマ・バリデータは、アプリケーションの価値を高めるものです。ただし、スキーマ・バリデータ一般に問題が無いわけではありません。まず、スキーマ・バリデータのメッセージは説明的ではありますが、ユーザにとって分かりやすいものではありません。例えば次のような感じです・・・

[Error] greetings.xml:1:12: Element type
"greetings" must be declared.

これはエンドユーザに見せるような代物ではありません。それに、エラー・メッセージを複数の言語(英語、中国語、フランス語、日本語など)で表現できるものはほとんどありません。同様に、エラー・メッセージの日付や時間、通貨単位などがローカライズされていません。また、大部分のバリデータは、最初のエラーが見つかると、エラーの報告を止めてしまいます。すべてのエラーが一度に分かれば素晴らしいのですが・・・。最後に、スキーマ・バリデータには、いまだに性能上の問題があります。Castorや、XSD、JAXBなどのデータ・バインディング機能では、こうした性能上の問題に対応しようとしていますし、XMLインターフェースを利用しない場合でも、これらの機能でスキーマの検証ルールが使いやすくなります。もう既に、優れたSOAP実装であるApache Axis ( 参考文献 ) とCastorでスキーマの妥当性検証を行うことができるのです。

まとめ

データ構造の記述にスキーマを使う場合(特にXML Schemaを使う場合)には、サードパーティ製の優れたツールを利用することができます。ただし、スキーマ・バリデータがきちんと動作するようにXMLメッセージを構成するには、一仕事が必要です。ここで説明したXMLのスタイル・ガイドラインを守れば、一石二鳥なのです。第一にデータ検証の一部を自分で書いたコードではなく、スキーマ・バリデータに任せることができ、あなたの時間と費用が節約できることになります。第二に、XMLを作っている人達が、あなたのXMLインターフェースについてよく理解できるということです。インターフェースの記述をいい加減にしてしまうと、そのXMLを作る人たちが、あなたの机の前に行列を作ることになり、その対応にあなたの貴重な時間を浪費する羽目になるでしょう。

謝辞
この記事のために助言を下さった方々に感謝いたします。特にColin Reeves (FNFのシニア・テクニカル・ライター兼編集者)には、編集に力を貸していただきました。


ダウンロード可能なリソース


関連トピック

  • XML Schemaの妥当性検証ルールについての詳細は、実例が豊富なW3Cの XML Schema Part 0: Primer を見てください。
  • ちょっとした手間で、未定義の構造のための場所を確保しておくようなXML Schemaを設計することができます。これにより、柔軟性を確保しつつスキーマの妥当性検証が行えます。これに反して、柔軟性のために名前と値のペアを使うとスキーマでの妥当性検証の余地が無くなります。 XMLスキーマの柔軟性 について書かれたDare Obasanjoの記事を読んでみてください。
  • SOAPを使いますか?・・・ この素晴らしい記事 (developerWorks 2003年9月)を読んでApache AxisにCastor による XML Schemaの妥当性検証を付加してみてください。Casterによって生成されたスキーマの妥当性検証コードは、パーサによるスキーマの妥当性検証よりも実行速度が速いのもです。
  • この記事で紹介したいくつかの手法で、属性や要素のテキストに関わる制限を回避してください。下記の記事は、XMLのスキーマを拡張する方法について説明しています。
  • XML文法を定義する2つのスキーマ、 MathML UIML を見てみてください。非常にオープンなこれらのスキーマのスタイルは、3GLプログラミング言語に似ています。
  • 下記のWebサービス標準を扱うときには、この記事で説明したガイドラインを守ってください。
  • スキーマに検証ルールを追加すると、スキーマ・バリデータは、実行時に無効となるデータのすべてを報告します。UMLはそのようには動きません。分かりづらい Object Constraint Language (OCL) のようなものでも使わない限り、実行時のエラーを知り得ないでしょう。
  • IBMalphaWorksから XML Schema Quality Checker をダウンロードしてください。W3C XML Schema言語で書かれたXML Schemaを入力として受け取り、スキーマ言語の不適当な使用がないか診断します。
  • developerWorks XMLゾーン には、ほかにも多くのXML関連の参考文献が掲載されています。
  • XML及び関連技術において IBM 認定開発者 になる方法についてはこちらを参照してください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=241341
ArticleTitle=スキーマ・バリデータを活用したXMLのスタイル・ガイドライン
publish-date=11112003