xml - XML スキーマを設計するためのベストプラクティスは何ですか?

Question

私はアマチュアソフトウェア開発者 (私はまだ学界にいます) として、XML 文書のスキーマをいくつか書きました。私は、XML のセマンティクスが正確に何であるかを完全に確信しているわけではないため、見た目の悪い XML 文書の原因となる設計ミスに日常的に遭遇します。

私の仮定：

<property> value </property>

プロパティ = 値

<property attribute="attval"> value </property>

属性という特別な記述子を持つプロパティ。

<parent>
  <child> value </child>
</parent>

親には、値「値」を持つ特性「子」があります。

<tag />

「タグ」はフラグであるか、テキストに直接変換されます。これについてはよくわかりません。

<parent>
  <child />
</parent>

「子」は「親」を表します。「子」はフラグまたはブール値です。これについてもよくわかりません。

デカルト座標を表すようなことをしたい場合、あいまいさが生じます。

<coordinate x="0" y="1" />

<coordinate> 0,1 </coordinate>

<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>

これらの選択肢のうち、最も正しいものはどれですか? XML スキーマ設計の現在の概念に基づいて、3 番目の方法に傾倒しますが、実際にはわかりません。

xml スキーマを効果的に設計する方法を簡潔に説明しているリソースは何ですか?

score 25 · Accepted Answer

一般的な (しかし重要な!) 推奨事項の 1 つは、複数の論理データを 1 つのノード (テキストノードであれ属性ノードであれ) に格納しないことです。そうしないと、通常はフレームワークから無料で取得する XML 構文解析ロジックに加えて、独自の構文解析ロジックが必要になります。

したがって、あなたの座標の例で <coordinate x="0" y="1" /> は <coordinate> <x>0</x> <y>1</y> </coordinate> 、両方とも私にとって合理的です。

しかし<coordinate> 0,1 </coordinate>、これは 2 つの論理データ (X 座標と Y 座標) を 1 つの XML ノードに格納するため、あまり良くありません。コンシューマーは XML パーサーの外部でデータを解析する必要があります。また、カンマで文字列を分割するのは非常に簡単ですが、最後に余分なカンマがあるとどうなるかなど、あいまいな点がまだいくつかあります。

score 17 · Accepted Answer

チュートリアルを参照してください:

「XML スキーマ: ベストプラクティス」Roger Costello著。

私もお勧めします：

Priscilla Walmsleyの著書「 Definitive XML Schema」。
Jeni TennisonのXML スキーマページ

score 11 · Accepted Answer

オプション＃2を回避するために、以下のcdragonのアドバイスに同意します。1 番と 3 番のどちらを選択するかは、主にスタイルの問題です。エンティティの属性と見なすものには属性を使用し、データと見なすものには要素を使用するのが好きです。分類が難しい場合もあります。とはいえ、どちらも「間違っている」わけではありません。

また、スキーマ設計のトピックに取り組んでいる間、(要素と型の両方の) 再利用の (最大の) 優先レベルに関して 2 セントを追加します。これにより、これらのエンティティの外部 "論理" 参照も容易になります。たとえば、データベースに格納されているデータディクショナリです。

"Garden of Eden" スキーマパターンは最大限の再利用を提供しますが、最も多くの作業を伴うことに注意してください。この投稿の最後に、ブログシリーズで取り上げた他のパターンへのリンクを示します。

•エデンの園アプローチ http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

すべての要素をグローバルに定義するモジュラーアプローチを使用し、ベネチアンブラインドアプローチと同様に、すべての型定義をグローバルに宣言します。各要素は、ノードの直接の子としてグローバルに定義され、その type 属性は、指定された複合型の 1 つに設定できます。

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"/> 
<xs:element name="BookInformation" type="BookInformationType"/> 
  <xs:complexType name="BookInformationType"/> 
    <xs:sequence> 
      <xs:element ref="Title"/> 
      <xs:element ref="ISBN"/> 
      <xs:element ref="Publisher"/> 
      <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="PeopleInvolvedType"> 
    <xs:sequence> 
      <xs:element name="Author"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:element name="Title"/> 
  <xs:element name="ISBN"/> 
  <xs:element name="Publisher"/> 
  <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/> 
</xs:schema>

このアプローチの利点は、スキーマを再利用できることです。要素と型の両方がグローバルに定義されているため、両方を再利用できます。このアプローチは、再利用可能なコンテンツを最大限に提供します。欠点は、スキーマが冗長であることです。これは、特に拡張性とモジュール性に関連して、スキーマ要素と型の範囲、および他のスキーマでのそれらの使用について想定する余裕がない一般的なライブラリを作成する場合に適切な設計です。

すべての異なるタイプと要素には単一のグローバル定義があるため、これらの正規粒子/コンポーネントをデータベース内の識別子に 1 対 1 で関連付けることができます。一見すると、テキストの XSD パーティクル/コンポーネントとデータベースとの間の関連付けを維持するのは面倒な継続的な手動タスクのように思えるかもしれませんが、SQL Server 2005 は実際には、次のステートメントを介して正規のスキーマコンポーネント識別子を生成できます。

CREATE XML SCHEMA COLLECTION

http://technet.microsoft.com/en-us/library/ms179457.aspx

逆に、正規粒子からスキーマを構築するために、SQL Server 2005 は

SELECT xml_schema_namespace function

http://technet.microsoft.com/en-us/library/ms191170.aspx

ca·non·i·cal 数学関連。(方程式、座標などについて) 「最も単純な、または標準的な形式で」 http://dictionary.reference.com/browse/canonical

その他の、構築はより簡単ですが、再利用可能性が低く、「非正規化/冗長」なスキーマパターンには次のものがあります。

•ロシアンドールアプローチhttp://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

スキーマには、単一のグローバル要素 (ルート要素) があります。他のすべての要素とタイプは、それぞれのタイプがその上のタイプに適合するため、名前を付けて、徐々に深くネストされます。この設計の要素はローカルで宣言されているため、インポートまたはインクルードステートメントを使用して再利用することはできません。

•サラミスライスアプローチ http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

すべての要素はグローバルに定義されますが、型の定義はローカルに定義されます。このようにして、他のスキーマは要素を再利用できます。このアプローチでは、ローカルに定義されたタイプを持つグローバル要素が、要素のコンテンツの完全な説明を提供します。この情報「スライス」は個別に宣言されてから集約され、他のスキーマを構築するためにつなぎ合わされることもあります。

•ベネチアンブラインドのアプローチ http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

どちらも単一のグローバル要素を使用するという点で、ロシアンドールのアプローチに似ています。ベネチアンブラインドアプローチは、すべての型定義をグローバルに命名および定義することによるモジュラーアプローチを記述します (要素をグローバルに宣言し、型をローカルに宣言するサラミスライスアプローチとは対照的です)。グローバルに定義された各タイプは、個々の「スラット」を記述し、他のコンポーネントで再利用できます。さらに、ローカルで宣言されたすべての要素は、スキーマの上部にある elementFormDefault 属性の設定に応じて、名前空間を修飾することも、名前空間を修飾しないこともできます (スラットは「開く」または「閉じる」ことができます)。

score 3 · Accepted Answer

XML はデザインの点でやや主観的です。要素と属性をどのように配置するかについての正確なガイドラインがあるとは思いませんが、要素を使用して「もの」を表し、属性を使用して単一の属性/プロパティを表す傾向があります。そのうちの。

座標の例に関しては、どちらも完全に受け入れられますが、私の傾向は、<coordinate x="" y=""/>やや簡潔であり、それらが多数ある場合はドキュメントが少し読みやすくなるためです。

ただし、最も重要なことは、スキーマの名前空間です。(a) あること、および (b) 将来変更して新しいバージョンを発行できるように、そこにバージョンがあることを確認してください。バージョンは、日付または数値のいずれかです。

http://company.com/2008/12/something/somethingelse/
urn:company-com:2008-12:something:somethingelse

http://company.com/v1/something/somethingelse/
urn:company-com:v1:something:somethingelse

score 3 · Accepted Answer

XML 文書モデルの設計方法について、適切な学習リソースを知りません (スキーマは、文書モデルを指定する形式的な方法にすぎません)。

私の意見では、XML に関する重要な洞察の 1 つは、XML は言語ではなく、構文であるということです。また、各ドキュメントモデルは個別の言語です。

文化が異なれば、それぞれ独自の方法で XML を使用します。W3C 仕様の中でも、XSLT のダッシュ区切り名には Lisp の匂いがし、XML スキーマの camelCaseNames には Java の匂いがします。同様に、アプリケーションドメインが異なれば、異なる XML イディオムが必要になります。

HTMLやDocBookなどの物語的なドキュメントモデルでは、印刷可能なテキストをテキストノードに配置し、メタデータを要素名と属性に配置する傾向があります。

SVGなどのよりオブジェクト指向のドキュメントモデルは、テキストノードをほとんどまたはまったく使用せず、代わりに要素と属性のみを使用します。

ドキュメントモデルの設計に関する私の個人的な経験則は、次のようになります。

混合コンテンツを必要とするタグのないスープのようなものである場合は、HTML と DocBook をインスピレーションの源として使用してください。他のルールは、それ以外の場合にのみ関連します。
値が複合または階層になる場合は、要素を使用します。スペースで区切られた単純なシーケンスである IDREFS などの確立されたイディオムを除いて、XML データをさらに解析する必要はありません。
値が複数回発生する必要がある場合は、要素を使用します。
値をさらに絞り込む必要がある場合、または後で充実させる必要がある場合は、要素を使用します。
値が明らかにアトミック (ブール値、数値、日付、識別子、単純なラベル) であり、多くても 1 回しか発生しない場合は、属性を使用します。

別の言い方をすると、次のようになります。

物語であれば、それはオブジェクト指向ではありません。
オブジェクト指向の場合は、オブジェクトを要素としてモデル化し、アトミック属性を属性としてモデル化します。

編集: 一部の人々は、属性を完全に無視することを好むようです。何も問題はありませんが、ドキュメントが肥大化し、手動で読み書きするのが不要になるため、嫌いです。

score 1 · Accepted Answer

Java プロジェクトでは、JAXBを使用して XML を自動的に解析し、それをオブジェクト構造に変換することがよくあります。他の言語についても、似たようなものがあると思います。適切なジェネレーターは、選択したプログラミング言語でオブジェクト構造を自動的に作成できます。これにより、多くの場合、システム間の通信用に移植可能な XML 表現を保持しながら、XML の処理がはるかに簡単になります。

このような自動マッピングを使用すると、スキーマが大幅に制約されることがわかります<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>。変換で特別な魔法を行いたくない場合は、この方法を使用することをお勧めします。Coordinate最終的には、2 つの属性xとy、スキーマで宣言された適切な型を持つクラスになります。

score 1 · Accepted Answer

XML ベースのフォーマットを設計するときは、何を表現しているのかを考えておくとよい場合がよくあります。目的に合った XML データのモックを作成してみてください。要件を満たす満足のいくものを手に入れたら、スキーマを開発してそれを検証します。

フォーマットを設計するとき、私はデータコンテンツを保持するための要素と、ID、名前、タイプ、または要素に含まれるデータに関するその他のメタデータなどの特性をデータに適用するための属性を使用する傾向があります。

その点で、座標の XML 表現は次のようになります。

<coordinate type="cartesian">
  <ordinate name="x">0</ordinate>
  <ordinate name="y">1</ordinate>
</coordinate>

これは、さまざまな座標系に対応します。それらが常にデカルトであることがわかっている場合、より良い実装は次のようになります。

<coordinate>
  <x>0</x>
  <y>1</y>
</coordinate>

もちろん、後者の場合、各要素の型を宣言する必要があるため、より冗長なスキーマになる可能性があります (ただし、これらの要素に対して実際に難しい作業を行うために複雑な型が定義されていることを願っています)。

プログラミングと同じように、同じ目的を達成するために複数の方法が存在することがよくありますが、多くの状況で正しいことも間違っていることもありません。重要なことは、他の人があなたのスキーマを見たときに、あなたが達成しようとしていたことを理解できるように、一貫性を保ち、直感的になるようにすることです。

常にスキーマをバージョン管理し、スキーマに対して記述された XML がそれを示すようにする必要があります。XML を適切にバージョン管理しないと、古いスキーマに記述された XML をサポートしながら、スキーマに追加を作成することは非常に困難になります。

score 0 · Accepted Answer

デカルト座標を処理する場合、属性フォームの方が扱いやすいことがわかりました。私のプロジェクトでは複数の名前空間が必要になる傾向があり、名前空間間で座標型の定義を共有すると、サブ要素形式で見苦しくなります。サブ要素形式では、サブ要素を修飾するか、ベース要素またはルート要素で名前空間を調整するか、デフォルトで非修飾要素名（つまり、名前空間を非表示にする）にする必要があります。

score 0 · Accepted Answer

以下は、XML 文法を設計する方法の優れたリストです。

上記のように、それは主観的な実践ですが、このサイトでは、「このパターンを使用して問題 X を解決する」…または「長所と短所は…」などの有用な指示を提供しています。

score 0 · Accepted Answer

あなたが表現しようとしているデータの関係を見てください。これが私が見つけた最良のアプローチです。

score 0 · Accepted Answer

私はしばしば同じ問題に苦しんでいますが、実際には問題ではなく、xml は単なるデータです。

そうは言っても、私は通常、「ノードについて何かを言っている場合は属性であり、そうでない場合は子ノードである」というアプローチを好みます。

あなたの例では、私は行きます：

<coordinate>
    <x>0</x>
    <y>1</y>
</coordinate>

x と y は座標のプロパティであり、実際には xml についてではなく、それによって表されるオブジェクトについて述べているためです。

score 0 · Accepted Answer

構造が複雑か単純かによると思います。
x と y に独自の詳細がない限り、x と y を属性として作成します。

物事を定義するために使用される HTML またはその他の形式のマークアップ (WPF の場合は XAML、フラッシュの場合は MXML) を見て、子ノードに対する属性として何かが選択される理由を理解できます)。

x と y を繰り返さない場合は、属性にすることができます。

座標に複数の x と y があるとしましょう。xml では、ノードに同じ名前の複数の属性を許可していないと思います。その場合、子ノードを使用する必要があります。

score 0 · Accepted Answer

表現したいすべての値に対して要素またはサブ要素を使用することには、本質的に問題はありません。

主な考慮事項は、属性を使用する方がきれいな場合があるということです。要素は特定の名前の属性を 1 つしか持てないため、カーディナリティは 1:1 のままです。データを子要素として表している場合は、好きなカーディナリティを使用できます (または、後で拡張することもできます)。

上記の Rob Wells の回答は正しいです。それは、モデル化しようとしている関係によって異なります。

明らかに 1 対 1 の関係しかない場合は、属性がよりクリーンになる可能性があります。

xml - XML スキーマを設計するためのベスト プラクティスは何ですか?

14 に答える 14

Related

Reference

xml - XML スキーマを設計するためのベストプラクティスは何ですか?