IBM の Web サイトに「XML 設計の原則: 要素と属性を使用する場合」というタイトルの記事があります。
厳格なルールはあまりないように見えますが、投稿にはいくつかの優れたガイドラインが記載されています。たとえば、推奨事項の 1 つは、XML プロセッサが属性内のデータを正規化して生のテキストを変更する可能性があるため、データの空白を正規化してはならない場合に要素を使用することです。
さまざまな XML 構造を開発していると、ときどきこの記事を参照していることに気づきます。これが他の人にも役立つことを願っています。
編集 - サイトから:
コアコンテンツの原則
問題の情報が、XML で表現または伝達されている重要な資料の一部であると考える場合は、それを要素に入れます。人間が読める文書の場合、これは通常、読者に伝えられるコアコンテンツを意味します。マシン指向のレコード形式の場合、これは通常、問題のドメインから直接来るデータを意味します。情報が主な通信の周辺または付随的なものであると考える場合、またはアプリケーションが主な通信を処理するのを助けることを純粋に意図している場合は、属性を使用します。これにより、コアコンテンツが補助資料でごちゃごちゃになるのを回避できます。マシン指向のレコード形式の場合、これは通常、問題領域からのメイン データに関するアプリケーション固有の表記を意味します。
例として、私は多くの XML 形式を見てきましたが、通常は企業内で開発されたもので、文書のタイトルが属性に配置されています。タイトルはドキュメントのコミュニケーションの基本的な部分であるため、常に要素のコンテンツに含める必要があると思います。一方で、製品の記述的な記録に、製品の内部識別子が要素として投入されているケースをよく見かけます。これらのケースのいくつかでは、特に ID が非常に長い形式または不可解な形式である場合に、特定の内部製品コードが文書のほとんどの読者または処理者にとって主要な関心事ではないため、属性の方が適切でした。
原則としてデータは要素に、メタデータは属性に含まれると聞いたことがあるかもしれません。上記の 2 つの段落は、実際には同じ原則を表していますが、より意図的であいまいでない言葉で表現されています。
構造化情報の原則
情報が構造化された形式で表現されている場合、特に構造が拡張可能な場合は、要素を使用します。一方、情報がアトミック トークンとして表現されている場合は、属性を使用します。要素は、XML で構造を表現するための拡張可能なエンジンです。ほとんどすべての XML 処理ツールはこの事実に基づいて設計されており、構造化された情報を適切に要素に分割すると、処理ツールが設計を補完し、それによって生産性と保守性が向上することがわかります。属性は、要素で表される情報の単純なプロパティを表現するために設計されています。構造化された情報を属性に押し込んで XML の基本アーキテクチャに反する作業を行うと、見掛け倒しの簡潔さと利便性が得られる可能性がありますが、メンテナンス コストが発生する可能性があります。
日付は良い例です。日付は構造が固定されており、通常は単一のトークンとして機能するため、属性として意味があります (できれば ISO-8601 で表現されます)。一方、個人の名前を表すことは、この原則がデザイナーを驚かせるのを見てきました。属性に名前が含まれているのをよく見かけますが、個人名は要素の内容に含めるべきだと常に主張してきました。個人名は驚くほど多様な構造を持っています (一部の文化では、敬称を省略したり、名前の一部の順序を想定したりすることで、混乱や不快感を引き起こす可能性があります)。また、個人名がアトミック トークンであることはめったにありません。例として、姓や姓で検索またはソートしたい場合があります。フルネームを 1 つの要素のコンテンツに押し込むことは、それを属性に入れることと同じくらい問題があることを指摘しておく必要があります。
個人的には、単純な単一値のプロパティに属性を使用するのが好きです。要素は、(明らかに) 複雑な型または繰り返される値に適しています。
単一値のプロパティの場合、属性を使用すると、ほとんどの API で XML がよりコンパクトになり、アドレス指定がより簡単になります。
よく考え抜かれた要素対属性の議論の 1 つは、英国の GovTalk ガイドラインに由来します。これは、政府関連の XML 交換に使用されるモデリング手法を定義していますが、独自のメリットがあり、検討する価値があります。
要素が XML インスタンスの情報コンテンツの主要な保持者になるように、スキーマを設計する必要があります。属性は、補助的なメタデータ (要素の内容に関する詳細情報を提供する単純なアイテム) を保持するのにより適しています。あいまいさを引き起こす可能性がある他の属性を修飾するために、属性を使用してはなりません。
要素とは異なり、属性は構造化データを保持できません。このため、要素は情報コンテンツの主要な保持者として好まれます。ただし、属性を使用して要素のコンテンツに関するメタデータ (たとえば、日付の形式、測定単位、または値セットの識別) を保持できるようにすると、インスタンス ドキュメントがより単純になり、理解しやすくなります。
生年月日はメッセージで次のように表されます。
<DateOfBirth>1975-06-03</DateOfBirth>
ただし、その生年月日がどのように確認されたかなど、より多くの情報が必要になる場合があります。これは属性として定義でき、メッセージ内の要素は次のようになります。
<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>
以下は不適切です。
<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>
コードが VerifiedBy または ValueSet 属性を修飾しているかどうかは、ここでは明確ではありません。より適切な表現は次のようになります。
<DateOfBirth>
<VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>
<Value ValueSet="ISO 8601">1975-06-03</Value>
</DateOfBirth>
それは主に好みの問題です。グループ化には要素を使用し、可能な場合はデータに属性を使用します。これは、代替手段よりもコンパクトであると考えているからです。
たとえば、私が好む.....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" />
<person name="Travis" surname="Illig" age="32" />
<person name="Scott" surname="Hanselman" age="34" />
</people>
</data>
...それ以外の....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person>
<name>Rory</name>
<surname>Becker</surname>
<age>30</age>
</person>
<person>
<name>Travis</name>
<surname>Illig</surname>
<age>32</age>
</person>
<person>
<name>Scott</name>
<surname>Hanselman</surname>
<age>34</age>
</person>
</people>
</data>
ただし、たとえば 20 ～ 30 文字の範囲内で簡単に表現できないデータがある場合、またはエスケープが必要な引用符やその他の文字が多数含まれている場合は、要素を分割する時が来たと言えます...おそらく CData ブロックを使用します。
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" >
<comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
</person>
<person name="Travis" surname="Illig" age="32" >
<comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
</person>
<person name="Scott" surname="Hanselman" age="34" >
<comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
</person>
</people>
</data>
原則として、私は属性を完全に避けます。確かに、属性はよりコンパクトですが、要素はより柔軟です。柔軟性は、XML のようなデータ形式を使用する最も重要な利点の 1 つです。今日の単一の値は、明日には値のリストになる可能性があります。
また、すべてが要素である場合、特定の情報をどのようにモデル化したかを覚えておく必要はありません。属性を使用しないということは、考えることが 1 つ少なくなることを意味します。
Ned Batchelder による Elements vs. attributesをご覧ください。
要素と属性の利点と欠点の優れた説明と優れたリスト。
彼はそれを次のように要約します。
推奨事項: ビジネス アプリケーションによって生成または消費されるデータには要素を使用し、メタデータには属性を使用します。
重要: 詳細については、以下の @maryisdead のコメントを参照してください。
私の個人的な経験則: 要素がその要素の 1 つだけを含むことができ、それが原子データ (id、名前、年齢、タイプなど) である場合、それは属性でなければなりません。それ以外の場合は要素です。
属性の制限により、属性を使用できる場所と使用できない場所がわかります。属性名は一意である必要があり、その順序は重要ではなく、名前と値の両方にテキストのみを含めることができます。対照的に、要素は一意でない名前を持つことができ、重要な順序を持ち、混合コンテンツを持つことができます。
属性は、オブジェクトのプロパティの名前と値、テーブルの行の列、ディクショナリのエントリの名前と値などの規則に従うデータ構造にマッピングされるドメインで使用できます。(ただし、プロパティがすべての値の型ではない場合や、辞書のエントリが文字列でない場合はそうではありません。)
人間のリーダーが知る必要があるデータの場合は要素を使用し、処理のみの場合 (ID など) は属性を使用する傾向があります。これは、データの大部分がモデル化されているドメインに関連しているため、属性をほとんど使用しないことを意味します。
要素と属性を区別するのに役立つもう 1 つの戦略があります。オブジェクトについて考え、MVC を念頭に置いてください。
オブジェクトは、メンバー (オブジェクト変数) とプロパティ (セッターとゲッターを持つメンバー) を持つことができます。プロパティは、変更通知メカニズムを可能にする MVC 設計で非常に役立ちます。
これが取られる方向である場合、ユーザーが変更できない内部アプリケーション データに属性が使用されます。典型的な例は ID または DATE_MODIFIED です。したがって、要素は、ユーザーが変更できるデータに使用されます。
したがって、司書が最初に書籍アイテム (または雑誌) を追加し、次にその名前の著者 ISBN などを編集できることを考えると、次のようにすると理にかなっています。
<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
<authors count="1">
<author>
<name>John Smith</name>
<author>
</authors>
<ISBN>123456790</ISBN>
</item>