xml - XML属性とXML要素

Question

職場では、データを別のオフラインアプリケーションに渡すための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ドキュメントの構造を設計するときに、属性または要素をいつ使用するかをどのように判断する必要がありますか？

score 149 · Accepted Answer

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

属性は、自己完結型の何かです。つまり、色、ID、名前です。
要素は、それ自体の属性を持っているか、持っている可能性があるか、他の要素を含むものです。

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

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

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

score 39 · Accepted Answer

「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 がマークアップ言語としてではなく、「データ」と「メタデータ」の区別がよりあいまいなデータシリアル化言語として使用されると、混乱が生じます。したがって、要素と属性の間の選択は、属性で表現できないものを除いて、多かれ少なかれ恣意的です（フィーンスターの回答を参照）。

score 33 · Accepted Answer

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>

score 23 · Accepted Answer

使い方にもよるかもしれません。データベースから生成された構造化されたデータを表すために使用される 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 は、それを使用する既存のコードを壊さずに変更できる場合に最も役立ちます。

score 10 · Accepted Answer

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

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

属性の設定は、次のものを提供することです。

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

属性の使用ができない場合があるため、技術的に可能な場合は追加しました。たとえば、属性セットの選択です。たとえば、(startDate と endDate) xor (startTS と endTS) を使用することは、現在のスキーマ言語では不可能です。

XML スキーマが「すべて」のコンテンツモデルを制限または拡張できるようになったら、おそらくそれをやめます。

score 9 · Accepted Answer

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

score 8 · Accepted Answer

この質問に対する普遍的な答えはありません（私は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これは醜く、混乱を招く可能性があります。

score 6 · Accepted Answer

他の人は、属性と要素を区別する方法について説明しましたが、より一般的な観点からすると、結果の XML が小さくなるため、すべてを属性に入れることは間違っています。

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

score 5 · Accepted Answer

オブジェクトのプロパティを格納するための両方のメソッドは完全に有効です。実用的な考慮事項から離れる必要があります。次の質問に答えてみてください。

どの表現がより高速なデータ解析/生成につながりますか？
どの表現がより高速なデータ転送につながりますか？
読みやすさは重要ですか？

..。

score 5 · Accepted Answer

百万ドルの質問！

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

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

score 5 · Accepted Answer

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

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

XML は人間が読めるものではなく、機械で読めるものであるべきであり、大きなドキュメントの場合、XML は非常にうまく圧縮されます。

score 4 · Accepted Answer

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

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

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

score 4 · Accepted Answer

それは主に好みの問題です。グループ化には要素を使用し、可能な場合はデータに属性を使用します。これは、代替手段よりもコンパクトであると考えているからです。

たとえば、私が好む.....

<?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>

score 4 · Accepted Answer

苦労して得たオブジェクト指向の直感を活用してみませんか? 通常、どれがオブジェクトで、どれがオブジェクトの属性であるか、またはどのオブジェクトが参照されているかを考えるのは簡単です。

オブジェクトとして直感的に理にかなっているものは、要素として収まります。その属性 (またはプロパティ) は、xml または属性を持つ子要素のこれらの要素の属性になります。

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

score 2 · Accepted Answer

いくつかの悪い情報に対するほんの2、3の修正：

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

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

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

属性を使用すると、XMLとJSONの競争力を維持できます。ファットマークアップ：ファットマークアップ神話を一度に1カロリーずつトリミングするを参照してください。

score 1 · Accepted Answer

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

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

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

このように記述された XML スキーマは簡潔です。

のようなケースを見るたびに<car><make>Ford</make><color>Red</color></car>、「作成者は make 要素内にサブ要素があると思っていたのだろうか?」と思います。 <car make="Ford" color="Red" />大幅に読みやすくなり、空白がどのように処理されるかについては疑問の余地がありません。

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

score 0 · Accepted Answer

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

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

XMLとして純粋なデータがある場合、明確な違いはあまりありません。データは、マークアップの間に、または属性として存在する可能性があります。

=>ほとんどのデータはマークアップの間にあるはずです。

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

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

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

score -1 · Accepted Answer

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

score -1 · Accepted Answer

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

私がこれまでに使用したのは、アセット URL のファイル拡張子を定義するときだけでした。

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

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

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

xml - XML属性とXML要素

20 に答える 20

XML 要素と XML 属性

Related

Reference