現実世界でのXML Schema

優れた命名規則は小売業界を超えて広まる

この記事では、幅広い分野で採用できるXML使用法を17項目にわたってご紹介します。これらの使用法は、小売店を支援するさまざまな情報テクノロジー (IT) システム間でのXMLメッセージ交換を標準化するために、Association for Retail Technology Standardsが発表したものです。

Paul Golick, Programmer, IBM, Software Group

IXRetailが "XML Best Practices" (最もふさわしいXML使用法) のドキュメントを作成していた間、Paul Golick氏はこのドキュメントの編集者、IXRetail書記、およびIBM Retail Store SolutionsのためにIXRetailとARTS Data Model Committeeへの代表を務めました。



Richard Mader, Executive Director, ARTS

Richard Mader 氏はARTS事務局長、IXRetail役員です。



2002年 1月 01日

あなたの業界では、業界全体にわたってデータを効率的に統合するうえで、最もふさわしいXML Schema使用法を採用しているでしょうか。もうそうでなければ、小売業界の例を参考にできるかもしれません。1993年以来、National Retail Federation (米国小売業協会、NRF) に属するAssociation for Retail Technology Standards (ARTS) は、小売業者がさまざまなアプリケーションを統合し、販売時点 (POS) データをより簡単に扱えるよう、標準的なデータ・モデルを開発し続けてきました。

ARTSの委員会であるInternational XML Retail Cooperative (IXRetail) は、小売店を支援するさまざまなITシステム間でのXMLメッセージ交換を標準化しようとしています。IXRetailは、ARTS Data Model規格の命名と定義をXMLメッセージ用に調整しました。さらにIXRetailは、小売業界やその中の企業が使用するXMLテクノロジーをさまざまな面で標準化してきました。

この記事は元々、NRFの雑誌STORES Magazine の2回分の記事として書かれたものです。この2つの記事のオンライン版へのリンクが、参考文献にあります。以下は、developerWorks読者のために、これらの記事の内容をまとめて改訂したものです。

XML Schema言語

XMLはアプリケーションが必要とする情報を識別するためのフォーマットを提供します。しかし、情報の受け手が本当に必要としている情報かどうかを確実に検証するわけではありません。とはいえ、XMLは、真に必要な情報かどうかの判断を助けるフォーマット構造を提供します。XMLおよび関連するいくつかの仕様に基づいて作られたXML Schema言語は、XML文書のマークアップに使われる名前の共用ボキャブラリーを柔軟な方法で記述します。スキーマを共有することにより、さまざまなアプリケーションは、適切な情報が送受信されていることをパーサーで妥当性検査できます。

IXRetailがXMLを選んだのは、構造化された文書やWebでのデータ交換にXMLを幅広く利用できるからです。XMLおよびXML Schema言語は、ほとんどあらゆる要件を満たす機能を備えた一般的なソリューションとして設計されました。このためXML Schemaはあまりに一般的すぎて、さらに制約を追加しないと実用的ではありません。たとえば、値を記述する方法には数多くの選択肢があります。xs:choice、要素置き換えグループ、抽象的な要素、抽象的なタイプなどさまざまです。これらの選択肢は、それぞれ特徴が異なっています。特定の1つの方法が明らかに最もふさわしい場合もありますが、多くの場合、複数の選択肢が存在します。こうした状況は望ましくありません。XML Schemaのいくつかの便利な機能の中からその都度任意に選んでいると、互いに関連するメッセージや似たようなタイプの間の類似性が損なわれます。そして、メッセージ・システムを保守または拡張しようとする担当者が、勝手気ままに選ばれた方式を残すために無駄な努力を払わなければなりません。IXRetailは多くのケースにおいて「最もふさわしい使用法 (Best Practice)」というガイドラインを設定し、特定の状況でXMLやXML Schema言語のどの機能を使うのが好ましいかを具体的に指定しています。

スキーマがアプリケーションに与えることのできる保証のレベルを左右するのは、スキーマがアプリケーションの要件をXMLメッセージの要件にどれほどうまく変換できるかです。XML Schema言語は、XMLメッセージの各コンポーネントに対する最も一般的な制約を記述することができます。場合によっては、あらゆる「ふさわしい」メッセージを正しく検証し、あらゆる「ふさわしくない」メッセージを拒否するような最適のスキーマを作ることも可能です。

しかし、こうした最適のスキーマをたとえ使用できる場合でも、不適切なメッセージを何らかの形でアプリケーションに処理させるべきでしょう (たとえば、標準化されたスキーマで列挙型の妥当な値がかなり動的に変化するような場合)。さらに、XML Schema言語では記述できない制約もあります。このため、XMLスキーマを使って妥当性検査できるからと言って、入力データの妥当性をアプリケーションに検査させる必要性がなくなるわけではありません。

アプリケーションがメッセージを受け入れるかどうかでそのメッセージの良しあしが決まるのと同様に、スキーマが一定の基準に合致している場合、それは良いスキーマだと見なされます。問題は、どんな基準に照らし合わせるかです。

基準の一部は単純明快に見えます。XML Schema言語に準拠するツールは、その言語で書かれたスキーマを処理できます。つまり、W3CのXML Schema仕様を使うことが1つのガイドライン (指針) のように思えます。ところが、事はそれほど単純ではありませんでした。W3CがXML Schema言語を正式に採用したのはつい最近です。この言語は最初から複雑だったうえに、その後もますます複雑になっているので、成功しないだろうと予測した人が多数います。しかし、非常に広い範囲にわたる利用分野を扱うためには、こうした複雑さが必要だったのです。

どんなXMLおよびXML Schema仕様が「ふさわしい」かの基準は、それらの仕様がどう使われるかに大きく左右されます。たとえW3CのXML Schema仕様を使うと合意した場合でも、規格をどのように仕様に適用するのが「ふさわしい」かを定めた単一の基準など存在しないかもしれません。ましてや、「最もふさわしい」基準を決定するのはもっと困難でしょう。しかし、適用分野を特定の環境に限ることができるならば、十分な協議と合意によって、その環境でXMLや関連する標準をどのように使用するのが最善かの基準を定められるかもしれません。この場合、特定の環境とは、小売店の業務を支援する情報技術アプリケーション間、あるいは小売店を小売業者に統合する情報技術アプリケーション間で行われるデータ交換のことです。


最もふさわしい使用法

以下にリストする最もふさわしい使用法のガイドラインは、IXRetail Technical Committeeによって承認されたものです。以下では、IXRetailの委員会Best Practices Subcommitteeによって承認された順番にガイドラインを並べています。この順番には、それ以外の特別な意味はありません。各ガイドラインを太字で示し、それに続いて、その理由を説明したコメント、またはこの記事の著者によるコメントが書かれています。ただし、IXRetailが承認したのはガイドラインのみです。その後のコメントは承認されたわけではありません。これらのガイドラインは今後の使用状況に応じて調整される可能性があり、新しいガイドラインが追加される可能性もあります。ARTSがこれらの使用法を定めたのは、ARTSによる標準化されたXMLスキーマの開発に役立てるためです。小売アプリケーションの開発者たちが来たるべきARTS標準を使用できるようになるまでの間、開発者たちの指針とするために、ARTSはこれらの使用法を公表しました。小売以外の分野のアプリケーション開発者も、これらのガイドラインに従えばXMLスキーマの一貫性を高めることができるでしょう (仕様の承認者をIXRetail以外の別の名前に置き換えればいいだけです)。

  1. 割り当てるすべてのXML名には、単語間にスペースやハイフンを使わない "UCCキャメル・ケース" を採用する。この種類のキャメル・ケース (ラクダ型表記) を使えば、複合名のそれぞれの単語の最初の文字が大文字にされる (名前の最初の文字を含む)。
    これによって、名前は (スペースを含まないため) XMLとして有効になるだけでなく、小文字ばかりのテキストよりも読みやすくなります。UCCキャメル・ケースによる名前は、たとえばInventoryControlDocument となります。(一部の組織は、主に属性名として、たとえばinitialLowerCase のように名前の最初に小文字を使用するLCCキャメル・ケースを採用してきました。IXRetailはこれを承認していません。UCCかLCCか、それとも両者を使用するべきかを、要素、属性、タイプの名前空間がそれぞれ異なるXML Schemaで決定することは不可能です。)
  2. タグの長さよりも、読みやすさの方が重要。
    長いタグを使ってXML文書を過度に長くしすぎないようIXRetailは注意を促しているものの、ユーザーが正しいタグを選ぶことは重要です。たとえば、ID_DPT_POS よりもPOSDepartmentID の方が望ましいです。(さらに、「メッセージング・インフラストラクチャー」によってメッセージが圧縮されることが予想されます。)
  3. 少数の例外を除いて、要素、属性、タイプの名前に省略形や頭字語を使ってはならない。例外はGTINIDPOS で、それぞれGlobal Trade Item Number、Identifier、Point of Saleを表す。
    ARTS Data Modelの論理ビューでは省略形を使用しません。明示された例外のみが許可されます。このガイドラインは、XMLメッセージのコンポーネントの名前に関しても適切なガイドラインと見なされています。(これらの例外は明らかに、小売業界特有のものです。他の業界では別の省略形を許可するでしょう。)
  4. 可能であれば、属性名からエンティティー名を取り除くべきである。
    ARTS Data Modelでは、属性名の接頭部としてエンティティー名がしばしば使われます。こうすれば、リレーショナル・データベース・モデルで外部キーのインポートが容易になります。しかし、XMLメッセージの階層構造ではあいまいさを避けるべきであり、エンティティー名の繰り返しは無益です。エンティティー名を繰り返すとタグが長くなります。このガイドラインはARTS Data Modelのエンティティーと属性に言及していますが、XMLの要素名と属性名の両方に当てはまります。つまり、Data Modelの属性がXMLメッセージの要素や属性に対応します。(ガイドライン8はこのガイドラインと関連し、このガイドラインを一般化したものです。)
  5. DTDその他のスキーマ言語ではなく、W3CのXML Schema仕様を使用する。
    XML Schemaではローカル要素名が可能ですが、DTDの場合、すべての要素名がグローバルに固有でなければなりません。(このようなガイドラインが採用された理由の1つは、オープン・ソースの妥当性検査パーサーを使って構文解析が自動化される可能性があることです。)
  6. 列挙型の値は名前のみを使用し、数字を使用しない。列挙型値の名前は、要素名や属性名に関するガイドラインに準拠しなければならない。適切な名前がすでに存在する場合、IXRetailの新しい名前を作成するよりも、その名前を使用すべきである。国際標準やコンソーシアムの仕様よりも、ISO規格を優先する。
    自然言語の単語で構成される名前は、その値の意味を示唆します。数字を使った列挙は、互換性のない非標準的な拡張を招きます。(このガイドラインに対しては、名前だけを許可すれば自然言語の使用を強制してしまうとの批判があります。これらの名前に使う言語は、メッセージング・システムを保守および拡張する担当者にとって最も役立つものを選択するべきです。しかし、これらの名前は、ITシステムによってさまざまな方法で処理される情報を互いに区別するだけにとどめるべきです。ユーザーに対しては、各ユーザーが選択した言語で常にメッセージを提供すべきです。このガイドラインがあるからと言って、ユーザー・インターフェースをおろそかにすべきではありません。)
  7. 列挙型値の名前は、英単語のみで構成すべきである。
    単語を適切に選べば、自然言語に基づく名前は意味を示唆します。しかし数値は意味を示唆しません。英単語を使用するARTS Data Modelから派生した名前と整合性を保つことには効果があります。要素、属性、列挙値としてエンド・ユーザーに表示される単語は、エンド・ユーザーにとっての使いやすさ (ユーザビリティー) を考えて選ぶべきであり、ユーザーがたとえ英語の話し手であっても翻訳する必要があるかもしれません。XMLメッセージをそのまま扱うのは、システムのデバッグを行うプログラマーだけにすべきです。(このようなガイドラインを必要としない業界や、別の言語を選択する業界があるかもしれません。しかし言語を選択しない場合、なぞめいた「言葉」が使われて、数値と同程度にわかりにくくなる可能性があります。)
  8. 名前には、その上位構造の名前を繰り返して使用すべきではない。
    コンテナー (上位構造) は適切なコンテキストを提供します。その名前をコンポーネント (下位構造) の名前に使用すると冗長になり、コンポーネント・タグを不必要に長くします。たとえば、<Customer> 要素の下に<Name> 要素を含めても差し支えありませんが、上位構造の名前 (Customer) を繰り返す<CustomerName> 要素は含めるべきではありません。(推奨4はこれと関連していますが、データ・モデル用語を使っています。頻繁な繰り返しの使用もまた考慮されましたが、明らかに望ましくない使用法につながりました。)
  9. IXRetailの指定するすべてのスキーマは、宣言するグローバル名をただ1つの名前空間、つまりIXRetailの名前空間 (http://www.nrf-arts.org/IXRetail/namespace/) に置くべきである。
    IXRetailの名前を1つの名前空間に置くことにより、ユーザーが他のソースから入手するスキーマ仕様と名前が衝突するのを避けることができます。複数の名前空間を使用しないことによって、IXRetailは、同等の宣言や定義が意図せずに発生するのをより良く防止できます。IXRetailは、この名前空間内のそれぞれのグローバル名の宣言や定義が固有であることを検査できます。このガイドラインは、他の名前空間を使用するスキーマ文書のインポートを制限しているわけではありません。(IXRetail自体を1つの名前空間に限定することにより、IXRetailは自らの名前空間に追加する名前を注意深く検討することになります。IXRetailが追加のメッセージ・スキーマを標準化するにつれて、この名前空間は拡大することが予想されます。他のガイドラインがグローバル名の使用を制限しているので、このガイドラインを順守するのは難しくはありません。IXRetailの名前空間URIを利用する仕様を承認できるのはIXRetailだけですから、他の仕様承認者は独自の名前空間URIをそれぞれ採用しなければなりません。このURIの最後にあるスラッシュつまりソリダス文字 ["/"] についても、討議されました。多くの標準的な名前空間では、名前の最後にこの文字を使用しません。このURIを提供したレジストラーは、特定のファイルを表さないIDを提供するよう依頼されました。識別されるリソースが時間の経過とともに変わる可能性があるからです。そこで、レジストラーはディレクトリーのURIを提供しました。しかし名前空間は概念上のリソースであり、そのURIは名前空間の場所を示すためではなく、名前を付けるために使用されます。名前空間はファイルでもディレクトリーでもないので、そのURIがソリダスで終わるかどうかは重要ではありません。)
  10. IXRetailの生成するそれぞれのXMLインスタンス文書は、デフォルト名前空間を指定すべきである。デフォルト名前空間はIXRetail名前空間でなければならない。
    デフォルト名前空間を使用することで、その名前空間を名前の接頭部として明示する必要がなくなります。こうして、IXRetail名前空間からの名前を使用するタグは短くなります。さらに、デフォルト名前空間を使うことによって、IXRetailの指定したXMLスキーマ文書のユーザーに対してふさわしい例を示すことにもなります。(このガイドラインは「XMLインスタンス文書」と「XMLスキーマ文書」に当てはまることに注意してください。ある特定のメッセージ (たとえばサンプル対話シナリオ) を指定する文書は、標準化されたメッセージ・タイプ用のスキーマを指定する文書とは区別されます。この区別によって、標準化されたものと、標準の適用例とが明確に区別されます。ただスキーマを参照するだけで新しい宣言を何も追加しないXMLメッセージは、この意味ではXMLインスタンス文書です。)
  11. IXRetailの生成するそれぞれのXMLスキーマ文書は、デフォルト名前空間と対象 (ターゲット) 名前空間を指定すべきである。どちらもIXRetail名前空間でなければならない。
    これによって、IXRetail名前空間からの名前を整合性のある形で参照するようになります。こうするには、W3CのXML Schema仕様の名前に明示的に接頭部を付ける必要がありますが、単にスキーマが長くなるだけで、インスタンス文書の長さは変わりません。さらに、XML Schemaや関連するXML規格で定義されたすべての名前は、互いに整合性のある形で処理されます。W3Cによって標準化された名前には常に接頭部が付けられるからです。(前のガイドラインと同様に、スキーマ文書とインスタンス文書とは区別されます。つまり、XMLスキーマ文書とは、新しい属性または要素の宣言を追加するXML文書です。)
  12. タイプを再使用できそうだとドメイン専門家が判断する場合、simpleTypeまたはcomplexTypeをElement 宣言の中で匿名で定義するよりも、名前空間でグローバルに定義すべきである。
    通常、タイプ名はタグの中で使用されませんから、タグを不必要に長くせずに適切なドメインを識別するために、適切なルートや修飾子を連結してタイプ名にすることができます。これは要素名とは異なります。要素名は常にタグの中で使用されます。したがって、グローバル要素名という代替方法ではタグが長くなるでしょう。(具体的な要素のタイプをxsi:type を使って指定する場合のように、タイプ名がインスタンス文書の中で使われる場合があります。その場合、タイプ名の長さはメッセージの長さに影響します。)
  13. ネストされた (入れ子の) 要素をスキーマで使用する場合、グローバル要素を参照するref 属性ではなく、type 属性、あるいはインライン型定義 (simpleTypeかcomplexType) を使用すべきである。
    可能な限り、名前を短く保つためにローカル要素の命名を使用すべきです。IXRetail名前空間のグローバル部分は、意味が明確に定義された名前のために予約されるべきです。このようなグローバル名は、使用領域を識別するために、適切なルートや修飾子を使って構成されるべきです。(ガイドライン12は、宣言や定義を再使用するよう提案されている場合に当てはまります。ガイドライン12はグローバル要素よりもグローバル・タイプの方が望ましいと述べています。メッセージの最も外側の要素にはグローバル名を使うのが適切でしょう。こうすれば、そのメッセージが他のすべてのメッセージから区別されます。メッセージ内に含まれる要素は、その上位メッセージのコンテキストを常に保ちます。)
  14. IXRetailの生成するスキーマの各バージョンごとに、他のどんなスキーマやバージョンのURI値とも異なる独自のURI値をschemaLocation 属性用に使用すべきである。そのURIの階層はARTS-NRFに適合すべきである (それぞれのschemaLocation は、http://www.nrf-arts.org/IXRetail/schemaLocation/ に従属するUTF-8ファイルのURIになる)。<xs:schema> 開始タグのversion 属性を指定すべきであり、その値はschemaLocation URI値と同じストリングにすべきである。schemaLocationversion への値の割り当ては、スキーマの承認、確立、およびリリースと関連付けるべきである。さらに、これらの値には、W3Cが使用するパターンに従って、リリース日付も含めるべきである。
    IXRetailスキーマの最初のバージョンであっても、何らかのバージョン管理メカニズムを使用すべきです。妥当性検査パーサー用に標準化されたスキーマ検出メカニズムと同様のバージョン・メカニズムを使用するのが望ましいです。名前の中にリリース日付を含めるW3Cのパターンは、たとえばhttp://www.w3.org/TR/2001/REC-xmlschema-2-20010502です。(XMLの場合、準拠するすべてのXMLプロセッサーはUTF-8をサポートしなければなりません。さらに、UTF-8はほとんどのテキスト処理ツールで表示または読み取りできます (そのようなツールの多くはUTF-16をうまく処理できません)。このガイドラインで想定されている開発手順は、すべての組織において適切とは限りません。中には、この提案のようにversion を使ってschemaLocation を示唆するのが不可能なバージョン識別規則をすでに確立している組織もあるでしょう。)
  15. 適切な場合には、新しい名前を発明する代わりにARTS XML Dictionaryの名前を使用する。
    ARTS XML Dictionaryは、ARTS Data Modelの論理ビューのエンティティー名および属性名から派生した名前のリストです。ARTS Data Modelのコンテキストは、これらの名前に有効なセマンティクスを与えます。ただし、名前は他のすべてのガイドラインに沿うように選択および使用する必要があります。IXRetailスキーマの名前もまた、ARTS XML Dictionaryに追加されるでしょう。(このガイドラインの意図は、以前からあるデータベース分野を拡張するためにXMLテクノロジーを利用することです。これまでにIXRetailとARTSのスタッフは、データ辞書および関連するData Model仕様の変換に多大の努力を払ってきました。こうした変換には大きな努力が払われましたが、小売業界で広く発達している情報の流れやプロセスとXML仕様とが確実に密接に結び付けられるようになりました。これらの変換がなければ、要件の検証がもっと必要になったことでしょう。さらに、業界のリーダーたちは優先度の高い要件を競争相手に知られたくないため、要件の収集と検証は標準化プロセスの中でおそらく最もペースの遅い部分でしょう。)
  16. 名前空間の中でグローバルな名前を選ぶとき、宣言または定義の対象となっている物事の具体的な意味を表す複雑な名前を使用する。
    このガイドラインの目的は、具体的な意味を持つ一般的な用語を不適切に使わないようにすることです。もしグローバル名が単純であれば、特定のドメイン、業界セグメント、または地理上の地域に限定された要件を満たすようタイプが選ばれているにもかかわらず、ユーザーはこれを幅広く利用できると考えてしまうかもしれません。たとえば、LineItem (品目名) のようなグローバル具象タイプは定義すべきではありません。セールス品目と入札品目とでは、情報の構成要素が大きくちがうからです。(このガイドラインはローカル名には当てはまりません。ローカル名の場合、使用されるコンテキストによっても意味が表され、同じ名前を別のコンテキストや意味で使用することも可能です。)
  17. IXRetail名前空間以外の名前空間からの名前には、整合性のある接頭部を使用する。IXRetail名前空間には接頭部を使用しない。以下のような接頭部および定義のみを使用すべきである。
    • xml (XML規格で定義されている)
    • xmlns (XML規格の「Namespaces (名前空間)」で定義されている)
    • xs http://www.w3.org/2001/XMLSchema
    • xsi http://www.w3.org/2001/XMLSchema-instance

    デフォルト名前空間と接頭部の整合性を保てば、組み込まれるスキーマはインライン・テキスト組み込みと同じ意味を持つようになります。こうすれば、意味に関して妥当性検査パーサーの解釈と人間の解釈が同じになります。(ガイドライン10と11は、IXRetail名前空間をデフォルト名前空間として指定するよう述べています。このため、そのグローバル名には接頭部が必要ありません。上記以外の接頭部が承認されて、このガイドラインに付け加えられるかもしれません。)

これらのガイドラインの目的は、標準化されたXMLスキーマの開発を支援することです。これらの基本的な特徴としては、記述的な値にするため、および既存の業界標準との継続性を保つためにどんな名前を選ぶか、メッセージを適切なサイズに保つためにローカル名を使用していること、今後の変更計画などです。我々の検討した成果が何らかの形で読者の要件を満たすことを望んでいます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=241328
ArticleTitle=現実世界でのXML Schema
publish-date=01012002