XML属性と要素
XML属性をいつ使用し、XML要素をいつ使用する必要がありますか？
例えば.
<customData>
<records>
<record name="foo" description="bar" />
</records>
</customData>
または
<customData>
<records>
<record>
<name>foo</name>
<description>bar</description>
</record>
</records>
</customData>
IBMのWebサイトには、「 XML設計の原則：要素と属性をいつ使用するか 」というタイトルの記事があります。
多くの厳格で速いルールはないようですが、投稿にはいくつかの良いガイドラインがあります。たとえば、推奨事項の1つは、XMLプロセッサが属性内のデータを正規化して未加工のテキストを変更できるため、データを空白に対して正規化してはならないときに要素を使用することです。
さまざまなXML構造を開発する際に、この記事を随時参照しています。これが他の人にも役立つことを願っています。
編集-サイトから：
コアコンテンツの原理
問題の情報がXMLで表現または伝達されている重要な資料の一部であると考える場合は、それを要素に入れてください。人間が読めるドキュメントの場合、これは一般に、読者に伝えられているコアコンテンツを意味します。マシン指向のレコード形式の場合、これは通常、問題のドメインから直接来るデータを意味します。情報が主要な通信の周辺的または付随的であると考えられる場合、またはアプリケーションが主要な通信を処理するのを純粋に意図している場合は、属性を使用します。これにより、補助コンテンツでコアコンテンツが乱雑になるのを防ぎます。マシン指向のレコード形式の場合、これは通常、問題領域のメインデータに関するアプリケーション固有の表記法を意味します。
例として、私は多くのXML形式を見てきました。通常は、企業で自社開発され、ドキュメントタイトルが属性に配置されています。タイトルは、ドキュメントのコミュニケーションの基本的な部分であり、常に要素コンテンツに含まれている必要があると思います。一方で、内部製品IDが要素として製品の記述レコードにスローされるケースを見てきました。これらのケースの一部では、特にIDが非常に長い形式または不明な形式である場合、特定の内部製品コードがドキュメントのほとんどの読者または処理者にとって主要な関心事ではないため、属性がより適切でした。
原理データが要素に、メタデータが属性に含まれていることを聞いたことがあるかもしれません。上記の2つの段落は実際には同じ原則を表していますが、より意図的であいまいな表現ではありません。
構造化情報の原理
情報が構造化された形式で表現されている場合、特に構造が拡張可能な場合は、要素を使用します。一方、情報がアトミックトークンとして表現されている場合は、属性を使用します。要素は、XMLで構造を表現するための拡張可能なエンジンです。ほとんどすべてのXML処理ツールはこの事実に基づいて設計されており、構造化された情報を要素に適切に分解すると、処理ツールが設計を補完し、生産性と保守性が向上することがわかります。属性は、要素で表される情報の単純なプロパティを表現するために設計されています。構造化された情報を属性に変換することによりXMLの基本アーキテクチャに反して作業する場合、かなり簡潔で便利になる可能性がありますが、おそらくメンテナンスコストがかかります。
日付は良い例です。日付は構造が固定されており、通常は単一のトークンとして機能するため、属性として意味があります（できればISO-8601で表現）。一方、個人名を表すことは、この原則がデザイナーを驚かせているのを見た場合です。私は属性に名前をよく見ますが、個人の名前は要素のコンテンツに含めるべきだといつも主張しています。個人名の構造は驚くほど可変です（一部の文化では、敬語を省略したり、名前の一部の順序を仮定したりすることで混乱や攻撃を引き起こす可能性があります）。個人名がアトミックトークンになることはめったにありません。例として、時々、姓または名前で検索またはソートしたい場合があります。属性に入れるのと同じように、単一の要素のコンテンツにフルネームをシューホーンするのは問題があることを指摘する必要があります。
よく考えられた要素と属性引数の1つは、 K 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>
個人的には、単純な単一値プロパティに属性を使用するのが好きです。要素は（明らかに）複合型または反復値により適しています。
単一値のプロパティの場合、属性により、ほとんどのAPIでよりコンパクトなXMLとシンプルなアドレス指定が可能になります。
一般的なルールとして、私は属性を完全に避けます。はい、属性はよりコンパクトですが、要素はより柔軟であり、XMLのようなデータ形式を使用する最も重要な利点の1つは柔軟性です。今日の単一の価値とは、明日の価値のリストになる可能性があります。
また、すべてが要素である場合、特定の情報をどのようにモデル化したかを覚えておく必要はありません。属性を使用しないということは、考えるべきことが1つ減ることを意味します。
それは主に好みの問題です。可能な場合はデータのグループ化と属性に要素を使用しますが、これは代替よりもコンパクトであると考えています。
たとえば、私が好む.....
<?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>
要素と属性 Ned Batchelderによるチェックアウト。
要素と属性の利点と欠点の良い説明と良いリスト。
彼はそれを要約すると：
推奨事項：ビジネスアプリケーションによって生成または消費されるデータの要素、およびメタデータの属性を使用します。
重要：詳細については、以下の@maryisdeadのコメントをご覧ください。
属性の制限は、使用できる場所と使用できない場所を示しています。属性名は一意である必要があり、順序は重要ではなく、名前と値の両方にテキストのみを含めることができます。対照的に、要素は一意ではない名前を持ち、重要な順序を持ち、コンテンツを混在させることができます。
属性は、これらの規則に従うデータ構造にマッピングされるドメインで使用できます。オブジェクトのプロパティ、テーブルの行の列、辞書のエントリの名前と値。 （ただし、プロパティがすべての値型ではない場合や、辞書のエントリが文字列ではない場合ではありません。）
私の個人的な経験則：要素がそのモノの1つだけを含むことができ、そのアトミックデータ（id、名前、年齢、タイプなど）であれば、それは属性でなければなりません。
人間の読者が知る必要があるデータの場合は要素を使用し、処理専用の場合は属性を使用する傾向があります（IDなど）。これは、データの大半がモデル化されているドメインに関連しているため、属性をほとんど使用しないことを意味します。
要素と属性を区別するのに役立つ別の戦略を次に示します。オブジェクトについて考え、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>