どちらを選択するか：XML属性またはサブノード？

データベースからXMLとしていくつかのデータをエクスポートしたい。たとえば、Personはage、nameおよびその他のプロパティを持つことができます。

XML形式を定義するには、2つの選択肢があります。

選択肢＃1：

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

選択肢＃2：

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

それでは、サブノードまたは属性の定義の違いは何ですか？そして、それぞれの選択肢の利点は何ですか？

これに関する明確なドキュメント/ベストプラクティスはありませんが、次のような代替案を検討してください。

要素テキストとして：

• データをマークアップまたはメタデータではなく、テキストコンテンツと見なされるxhtmlなどとしてデータを表示する方が簡単な場合があります。
• 複数存在する場合があります。複数の年齢または名前の行を持つ子コンテンツが必要な場合、属性はこれを許可しません
• 行レベルのメタデータが必要な場合、この属性を使用する<name>か<age>、この目的で使用するかを選択できます

属性として：

• XMLはよりコンパクトです
• XSLTとDocTypesの指定は簡単です
• 空白（パディング、インデント、改行）、またはPCDATAエリア（要素テキスト）に導入できる他のアイテム（コメント、PI）を心配する必要はありません。
• 一つだけ存在することができます！複数のage属性を含む子コンテンツを心配する必要はありません。

私はXMLの操作に多くの時間を費やしてきましたが、私の意見では、純粋なデータ通信のために、可能な限り属性を使用する必要があります。XMLがプレゼンテーション（XSLT、xhtmlなど）に使用される可能性が高い場合は、テキストコンテンツとしてはより適切な場合があります（必ずしもそうではありません）。

XML設計の原則： IBMのUche Ogbujiによる要素と属性をいつ使用するかは、おそらくこの問題に関する最良のリソースの1つです。

決定の核となるのは、属性が「完了」したことです。変更したり、変更したり、ネストしたりすることはできません。これらは順序に依存せず、要素内で区別されます（同じものを2つ持つことはできません）。

これらの制約のいずれかが変更される可能性がある場合、データをXMLの子ノードにします。

あなたの例では、名前と年齢を持つ人がいます。ファーストネーム、ミドルネーム、ラストネーム、そしてニックネームがあります。そして、一部の人々は旧姓、複数のミドルネーム、または敬語を持っています- ジョン・ロナルド・リエル・トールキンをそのような構造にどのように入れますか？

そのため、2つのミドルネームがあり、それらに注文があります。これは、いいえ、属性はこれに最適な選択ではないことを明確に示す必要があります。

_{私は現在それを見つけることができませんが、上記のリンクされたドキュメントには、名前は「将来の記事でマークアップの人々の名前の扱いを拡大したい」につながる少し考えを必要とするものであるという声明があります。誰かがこれについてリードを持っている場合、コメントを残すか、この場所に編集してください。}

一方、年齢はかなり固定された構造を持つものです（整数ではなく誕生日をお勧めします）。そのため、この情報をよく知られた理解された形式で表すことは、属性において意味があります。人には誕生日が1つだけあり、誕生日は1つだけで、保存する「順序付け」はありません。

Uche Ogbujiは、xml形式を適切に設計する際の3つの基本原則を特定しています。以下は、上記のリンクされたドキュメントからの引用を省略したものです。

• 構造化された情報の原理
  情報が構造化された形式で表現されている場合、特に構造が拡張可能な場合は、要素を使用します。一方、情報がアトミックトークンとして表現されている場合は、属性を使用します
• 読みやすさの原則
  情報が人によって読まれ、理解されることを意図している場合、要素を使用します。情報がマシンによって最も容易に理解され、消化される場合、属性を使用します。
• 要素/属性バインディングの原理要素の
  値を別の属性によって変更する必要がある場合は、要素を使用します

そのため、名前には要素が必要です。これらはアトミックトークンではない構造化データであり、コンピューターよりも人間によって読み取られる可能性が高く、名前自体の別の属性によって変更される可能性があります。

日付は属性である必要があります-アトミックトークンであるデータであり、人間よりもコンピューターによって読み取られる可能性が高く（必要に応じて人間の好みの形式に変換されます）、最後に他のユーザーによって変更される可能性は低いですそれらの属性。

rolflの他の考慮事項は、フィールドの数です。
少数を超える属性は混乱し、読みにくくなります（これは、xmlを人間が読めるようにすることを前提としていますが、プログラマーとしては少なくともテストのためにそれを行いたいと考えています）。

また、いずれかのフィールドのデータ構造が時間とともに変化することが予想される場合、それを属性にしないでください。
たとえば、名前フィールド。将来的にはこれが

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

そのようなことが起こると予想される場合、それを属性にすることは、後でコードをリファクタリングすることを意味します。

Personsタグの場合、Personのタグをより多く持つのが普通です。これは理にかなっています。Personのリストには属性ではなく、いくつかのエンティティがあります。

ストーリーはPersonとそのコンポーネントで異なります。Personには名前が含まれていません。名前はPersonの属性なので、新しいタグの代わりに属性に固執します。タグは、アドレスなどの反復的なものがある場合に役立ちますが、属性ではできません。

HTMLコンテキストで考えると、値を持つ名前タグの入力はありませんか？