XML属性とXML要素

職場では、別のオフラインアプリケーションにデータを渡すためのXMLファイルを作成するよう求められています。別のオフラインアプリケーションは、データの一部を更新するために、2番目のXMLファイルを作成して返送します。その過程で、XMLファイルの構造について他のアプリケーションのチームと話し合っています。

私が思いついたサンプルは基本的に次のようなものです：

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

他のチームは、これは業界標準ではなく、属性はメタデータにのみ使用する必要があると述べました。彼らは提案しました：

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

最初に提案した理由は、作成されるファイルのサイズがはるかに小さいためです。転送中にファイルに含まれるアイテムは約80000になります。彼らの提案は実際には、私が提案した提案の3倍であることがわかりました。言及された不思議な「業界標準」を検索しましたが、XML属性はメタデータにのみ使用されるべきであることがわかりましたが、議論は実際にはメタデータについてであると述べました。

長い説明（申し訳ありません）の後、メタデータとは何かをどのように判断しますか。また、XMLドキュメントの構造を設計するとき、属性または要素をいつ使用するかをどのように決定する必要がありますか？

私はこの経験則を使用します：

1. 属性は、自己完結型のものです。つまり、色、ID、名前です。
2. Elementは、独自の属性を持っている、または持つことができる、または他の要素を含むものです。

だからあなたは近いです。私は次のようなことをしたでしょう：

編集：以下のフィードバックに基づいて元の例を更新しました。

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

属性に関する問題のいくつかは次のとおりです。

• 属性に複数の値を含めることはできません（子要素は含めることができます）
• 属性は簡単に拡張できません（将来の変更のため）
• 属性は構造を記述できません（子要素は記述できます）
• 属性はプログラムコードで操作するのがより困難です
• 属性値はDTDに対してテストするのは簡単ではありません

データのコンテナーとして属性を使用すると、読み取りや保守が難しいドキュメントが作成されます。要素を使用してデータを記述してみてください。属性は、データに関連しない情報を提供するためにのみ使用してください。

次のようにならないでください（これはXMLの使用方法ではありません）。

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

ソース：http : //www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

「XML」は「eXtensible Markup Language 」の略です。マークアップ言語は、データがテキストであり、構造またはフォーマットに関するメタデータでマークアップされていることを意味します。

XHTMLは、意図したとおりに使用されたXMLの例です。

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

ここで、要素と属性の違いは明確です。テキスト要素はブラウザに表示され、属性はそれらを表示する方法に関する指示です（ただし、そのように機能しないタグがいくつかあります）。

XMLがマークアップ言語としてではなく、「データ」と「メタデータ」の区別が曖昧なデータシリアル化言語として使用されている場合、混乱が生じます。したがって、要素と属性の間の選択は、できないことを除いて多かれ少なかれ恣意的ですで表すです（フェンスターの回答を参照）。

XML要素とXML属性

XMLはすべて合意についてです。 まず、コミュニティまたは業界内の既存のXMLスキーマまたは確立された規則に従います。

本当にゼロからスキーマを定義する状況にいる場合、要素と属性の決定に通知する必要があるいくつかの一般的な考慮事項を次に示します。

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

使用状況によって異なります。データベースから生成された構造化データを表すために使用されるXMLは、最終的にフィールド値が属性として配置されている場合にうまく機能します。

ただし、メッセージ転送として使用されるXMLは、多くの場合、より多くの要素を使用する方が適切です。

たとえば、回答で提案されているこのXMLがあるとしましょう：-

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

次に、ITEMエレメントをデバイスに送信してバーコードを印刷する必要がありますが、エンコーディングタイプの選択肢があります。必要なエンコードタイプをどのように表すのですか？突然、やや遅れて、バーコードが単一の自動値ではなく、印刷時に必要なエンコードで修飾されていることに気付きました。

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

重要なのは、なんらかのXSDまたはDTDを名前空間とともに構築して、構造を固定する場合を除き、オプションを開いたままにしておくのが最善です。

IMO XMLは、それを使用して既存のコードを壊すことなく変更できる場合に最も有用です。

属性と要素に関して、スキーマ設計で次のガイドラインを使用します。

• 長時間実行されるテキストの要素を使用します（通常は文字列または正規化された文字列型の要素）
• 要素に2つの値（eventStartDateとeventEndDateなど）のグループがある場合は、属性を使用しないでください。前の例では、「イベント」の新しい要素があり、startDate属性とendDate属性が含まれている可能性があります。
• 営業日、日時、および数値（例：カウント、金額、レート）は要素である必要があります。
• 最終更新、期限切れなどのビジネス以外の時間要素は属性である必要があります。
• ハッシュコードやインデックスなどのビジネス以外の数値は属性にする必要があります。*型が複雑になる場合は要素を使用します。
• 値が単純なタイプで繰り返されない場合は、属性を使用します。
• xml：idおよびxml：langは、XMLスキーマを参照する属性である必要があります
• 技術的に可能な場合は属性を優先します。

属性の設定では、次のものが提供されます。

• 一意（属性は複数回出現できません）
• 順序は関係ありません
• 上記のプロパティは継承可能です（これは、「すべて」のコンテンツモデルが現在のスキーマ言語でサポートしていないものです）
• おまけは、冗長性が低く、使用する帯域幅が少ないことですが、要素よりも属性を優先する理由にはなりません。

属性を使用できない場合があるため、技術的に可能な場合に追加しました。たとえば、属性セットの選択肢。たとえば、現在のスキーマ言語では、（startDateおよびendDate）xor（startTSおよびendTS）は使用できません。

XMLスキーマが「すべての」コンテンツモデルの制限または拡張を許可し始めたら、おそらくそれを削除します

疑問がある場合は、KISS-属性を使用する明確な理由がないのに、なぜ属性と要素を混在させるのか。後でXSDを定義することを決定した場合、それも最終的にはクリーンになります。その後、XSDからクラス構造を生成することを決定した場合でも、それはより簡単になります。

この質問に対する普遍的な答えはありません（私はW3C仕様の作成に深く関わっていました）。XMLは多くの目的に使用できます。テキストのようなドキュメント、データ、宣言型コードは、最も一般的な3つです。データモデルとしてもよく使用します。これらのアプリケーションには、属性がより一般的な側面と、子要素がより自然な側面があります。また、さまざまなツールの機能を使用して、使いやすくしたり、使いにくくしたりすることもできます。

XHTMLは、属性が自然に使用される領域の1つです（たとえば、class = 'foo'内）。属性には順序がないため、一部の人がツールを開発しやすくなる場合があります。OTOH属性は、スキーマがないと入力が難しくなります。また、名前空間付きの属性（foo：bar = "zork"）は、さまざまなツールセットで管理するのが難しい場合もあります。しかし、一般的な混合を確認するには、いくつかのW3C言語を見てください。SVG、XSLT、XSD、MathMLはよく知られた言語の例であり、すべてに属性と要素の豊富な供給があります。一部の言語では、一方向ではなくそれを行うこともできます。

<foo title="bar"/>;

または

<foo>
  <title>bar</title>;
</foo>;

これらは構文的に同等ではなく、処理ツールで明示的なサポートが必要であることに注意してください）

私のアドバイスは、アプリケーションに最も近い領域での一般的なプラクティスを確認し、どのツールセットを適用するかを検討することです。

最後に、名前空間と属性を区別してください。一部のXMLシステム（Linqなど）は、名前空間をAPIの属性として表します。IMOこれは醜く、混乱する可能性があります。

他のものは、属性を要素から区別する方法をカバーしましたが、結果として生じるXMLをより小さくするので、すべてを属性に入れるより一般的な観点からは間違っています。

XMLはコンパクトになるようには設計されていませんが、移植可能で人間が読めるように設計されています。転送中のデータのサイズを小さくしたい場合は、他のもの（googleのプロトコルバッファーなど）を使用してください。

百万ドルの質問！

まず、パフォーマンスについてあまり気にしないでください。最適化されたxmlパーサーがどのくらい速くxmlをリッピングするかに驚かれることでしょう。さらに重要なことに、将来の設計は何ですか。XMLが進化するにつれて、疎結合と相互運用性をどのように維持しますか？

より具体的には、要素のコンテンツモデルをより複雑にすることができますが、属性を拡張することは困難です。

オブジェクトのプロパティを保存する両方の方法は完全に有効です。実用的な考慮事項から逸脱する必要があります。次の質問に答えてみてください：

1. どの表現がより高速なデータの解析/生成につながりますか？

2. どの表現がより高速なデータ転送につながりますか？

3. 読みやすさは重要ですか？

   ...

データには要素を使用し、メタデータ（要素のデータに関するデータ）には属性を使用します。

要素が選択文字列の述語として表示される場合は、それが属性であることを示す良い兆候があります。同様に、属性が述語として使用されない場合、メタデータは役に立たない可能性があります。

XMLは人間が読める形式ではなく、機械で読める形式になっていることに注意してください。大きなドキュメントの場合、XMLは非常によく圧縮されます。

どちらにしても議論の余地がありますが、XMLは実際のデータの「マークアップ」またはメタデータに使用する必要があるという意味で、同僚は正しいと言えます。XMLでドメインをモデル化するときに、メタデータとデータの間の線がどこにあるかを判断するのが難しい場合があるという点で、あなたは正しいです。実際には、マークアップ内のすべてが非表示になり、マークアップ外のデータのみが読み取れるふりをしています。文書はそのように意味をなしていますか？

XMLは非常にかさばるものです。輸送と保管については、処理能力に余裕がある場合は圧縮を強くお勧めします。XMLは反復性が高いため、圧縮率が高く、時には驚異的なほど圧縮率が高くなります。大きなファイルを元のサイズの5％未満に圧縮しました。

あなたの立場を強化するもう1つのポイントは、他のチームがスタイルについて議論している間（ほとんどのXMLツールは、すべての属性のドキュメントをall-＃PCDATAドキュメントと同じくらい簡単に処理するため）、実用性を主張しているということです。スタイルを完全に無視することはできませんが、技術的なメリットはより重きを置く必要があります。

それは主に好みの問題です。可能な場合は、データをグループ化するための要素とデータの属性を使用しています。

例えば私は.....を好む

<?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内のこれらの要素の属性、または属性を持つ子要素になります。

単純なケースでは、オブジェクト指向の例のように、どちらが要素でどれが要素の属性であるかを理解するのに問題はありません。

いくつかの悪い情報に対するいくつかの修正：

@John Ballinger：属性には任意の文字データを含めることができます。<>＆ "'は、それぞれ＆lt;＆gt;＆amp;＆quot;および＆apos;にエスケープする必要があります。XMLライブラリを使用すると、XMLライブラリが自動的に処理します。

地獄、属性には、画像などのバイナリデータを含めることができます。本当に必要な場合は、それをbase64でエンコードしてdata：URLにするだけです。

@feenster：IDSまたはNAMESの場合、属性にはスペースで区切られた複数のアイテムを含めることができます。これには数値が含まれます。Nitpickyですが、これによりスペースを節約できます。

属性を使用すると、XMLをJSONと競合させることができます。Fat Markup：Fat Markup Mythを一度に1カロリーずつトリミングするを参照してください。

このような議論の結果にはいつも驚かされます。私にとって、データが属性に属しているかコンテンツに属しているかを決定するための非常に単純なルールがあり、それはデータがナビゲート可能なサブ構造を持っているかどうかです。

したがって、たとえば、非マークアップテキストは常に属性に属します。常に。

リストはサブ構造またはコンテンツに属します。時間の経過とともに埋め込まれた構造化サブコンテンツを含む可能性のあるテキストは、コンテンツに属します。（私の経験では、XMLをデータの保存または交換に使用する場合、マークアップ付きのテキストは比較的少ないです。）

この方法で記述されたXMLスキーマは簡潔です。

のようなケースを目にするときはいつでも<car><make>Ford</make><color>Red</color></car>、「作者はmake要素内にサブ要素があると思っていましたか？」 <car make="Ford" color="Red" />大幅に読みやすくなり、空白がどのように処理されるかについては問題ありません。

空白処理規則だけを考えると、これはXML設計者の明確な意図だったと思います。

これは、属性とマークアップの違いが明確にわかるHTMLでは非常に明確です。

1. すべてのデータはマークアップの間にあります
2. 属性は、このデータを特徴付けるために使用されます（例：フォーマット）

純粋なデータをXMLとして持っているだけの場合、明確な違いはあまりありません。データは、マークアップ間または属性として使用できます。

=>ほとんどのデータはマークアップの間に立つ必要があります。

ここで属性を使用する場合：データを2つのカテゴリに分けることができます：データと「メタデータ」。メタデータはレコードの一部ではなく、表示したいが、「フォーマットバージョン」、「作成日」など。 、など

<customer format="">
     <name></name>
     ...
</customer>

「属性を使用してタグを特徴付け、タグを使用してデータ自体を提供する」と言うこともできます。

私はフェンスターに同意します。可能であれば、属性に近づかないでください。要素は進化に適しており、Webサービスツールキット間でより相互運用できます。属性を使用して要求/応答メッセージをシリアル化するこれらのツールキットはありません。メッセージはWebサービスツールキットのデータ（メタデータではない）であるため、これも意味があります。

属性は、時間の経過とともに簡単に管理するのが難しくなる可能性があります。私はいつも彼らから離れています。要素ははるかに明示的で、パーサーとユーザーの両方が読み取り/使用できます。

アセットURLのファイル拡張子を定義するために使用したのは、次の場合のみです。

<image type="gif">wank.jpg</image> ...etc etc

属性を100％展開する必要がないことがわかっている場合は、それらを使用できますが、何回知っていると思いますか。

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>