web-dev-qa-db-ja.com

XMLで要素または属性を使用する必要がありますか？

W3SchoolsのXML属性 について学んでいます。

著者は次のことに言及しています（強調鉱山）：

XML要素と属性

<person sex="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

<person>
  <sex>female</sex>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

最初の例では、性別が属性です。最後に、性は要素です。どちらの例も同じ情報を提供します。

属性を使用するタイミングと要素を使用するタイミングに関するルールはありません。 HTMLでは属性が便利です。 XMLでは、それらを避けることをお勧めします。代わりに要素を使用してください。

XML属性を避けますか？

属性の使用に関する問題の一部は次のとおりです。

  • 属性に複数の値を含めることはできません（要素に含めることができます）
  • 属性にはツリー構造を含めることはできません（要素には含めることができます）
  • 属性は簡単に拡張できません（将来の変更のため）

属性の読み取りと保守は困難です。データに要素を使用します。データに関係のない情報の属性を使用します。

著者の見解は有名なものですか、それともXMLのベストプラクティスですか？

XMLの属性は避けるべきですか？

W3Schoolsは次のことも言及しました（強調鉱山）：

メタデータのXML属性

ID参照が要素に割り当てられる場合があります。これらのIDは、HTMLのID属性とほぼ同じ方法でXML要素を識別するために使用できます。この例はこれを示しています。

<messages>
  <note id="501">
    <to>Tove</to>
    <from>Jani</from>
    <heading>Reminder</heading>
    <body>Don't forget me this weekend!</body>
  </note>
  <note id="502">
    <to>Jani</to>
    <from>Tove</from>
    <heading>Re: Reminder</heading>
    <body>I will not</body>
  </note>
</messages>

上記のIDは、異なるノートを識別するための単なる識別子です。ノート自体の一部ではありません。

ここで言いたいのは、メタデータ（データに関するデータ）は属性として保存されるべきであり、データ自体は要素として保存されるべきだということです

xmlxml-attribute
67
Ibn Saeed

通常、属性または要素の使用法は、モデル化しようとしているデータによって決まります。

たとえば、特定のエンティティがデータの[〜＃〜] part [〜＃〜]である場合、それを要素にすることをお勧めします。たとえば、従業員の名前は従業員データの重要な部分です。

ここで[〜＃〜] metadata [〜＃〜]データ（データに関する追加情報を提供するもの）について伝えたいが、実際にはデータの一部ではない場合は、それを属性にします。たとえば、各従業員がバックエンド処理に必要なGUIDを持ち、それを属性にする方が良いとしましょう。しかし、他の目的には必要かもしれません）

何かが属性または要素であるべきだというルールはありません。

属性をすべてのコストで回避する必要はありません。要素よりもモデル化が簡単な場合があります。それはあなたが表現しようとしているデータに本当に依存しています。

55
Prashanth

OPから5年後の0.02は正反対です。説明させてください。

  1. 同様のデータとそのデータの属性をグループ化するときに要素を使用します。
  2. すべてに要素を使用しないでください。
  3. データが繰り返される場合（1対多）、それはおそらく要素です
  4. データが繰り返されず、他の何かに関連付けられている場合にのみ意味がある場合、それは属性です。
  5. データに他の属性（つまり、名前）がない場合、それは属性です
  6. 似たような要素をグループ化して、コレクションの解析をサポートします（つまり、/ xml/character）
  7. データの解析をサポートするために同様の要素名を再利用します
  8. 決して、ever、要素名に数字を使用して位置を示します。 （つまり、character1、character2）この方法では、解析が非常に困難になります（＃6を参照、コードの解析には/ characterではなく/ character1、/ character2などが必要です）。

別の方法を考えた：

  • allデータを属性として考えることから始めます。
  • 属性を要素に論理的にグループ化します。データがわかっている場合は、属性を要素に変換する必要はほとんどありません。エレメント（コレクション、または繰り返しデータ）がいつ必要になるかは、おそらく既に知っているでしょう。
  • 要素を論理的にグループ化する
  • 展開する必要があるケースに遭遇したら、上記のプロセスの論理構造に基づいて新しい要素/属性を追加します。子要素の新しいコレクションを追加してもデザインが「壊れる」ことはなく、時間の経過とともに読みやすくなります。

たとえば、本と主要なキャラクターの単純なコレクションを見ると、タイトルには「子供」はいません。これは単純な要素です。すべてのキャラクターには名前と年齢があります。

    <book title='Hitchhiker&apos;s Guide to the Galaxy' author='Douglas Adams'>
        <character name='Zaphod Beeblebrox' age='100'/>
        <character name='Arthur Dent' age='42'/>
        <character name='Ford Prefect' age='182'/>
    </book>

    <book title='On the Road' author='Jack Kerouac'>
        <character name='Dean Moriarty' age='30'/>
        <character name='Old Bull Lee' age='42'/>
        <character name='Sal Paradise' age='42'/>
    </book>

本には複数の著者がいる可能性があると主張できます。 OK、新しいauthor要素を追加して展開します（オプションで元の@authorを削除します）。確かに、元の構造は壊れていますが、実際には非常にまれであり、簡単に回避できます。単一の著者を想定した元のXMLのコンシューマーは、いずれにしても変更する必要があります（おそらく、著者を「book」テーブルの列から「author」テーブルに移動するためにDBを変更します）。

<book title='Hitchhiker&apos;s Guide to the Galaxy'>
    <author name='Douglas Adams'/>
    <author name='Some Other Guy'/>
    <character name='Zaphod Beeblebrox' age='100'/>
    <character name='Arthur Dent' age='42'>
    <character name='Ford Prefect' age='182'/>
</book>
21
William Walseth

特に重要なことは、属性に物事を入れると、冗長なXMLが少なくなることです。

比較する

<person name="John" age="23" sex="m"/>

に対して

<person>
    <name>
        John
    </name>
    <age>
        <years>
            23
        </years>
    </age>
    <sex>
        m
    </sex>
</person>

はい、それは少し偏見と誇張でしたが、あなたはポイントを得る

19
flybywire

Googleを使用して正確な質問を検索しました。最初にこの記事 http://www.ibm.com/developerworks/library/x-eleatt/index.html に行きました。しかし、単純な質問自体には長すぎると感じました。とにかく、私はこのトピックに関するすべての回答を読みましたが、満足のいく要約が見つかりませんでした。そのため、後者の記事に戻りました。概要は次のとおりです。

要素を使用するのはいつですか、情報のビットを提示するために属性を使用するのはいつですか？

  • 問題の情報自体を要素でマークアップできる場合は、それを要素に入れます。
  • 情報が属性形式に適しているが、同じ要素上で同じ名前の複数の属性になってしまう可能性がある場合は、代わりに子要素を使用します。
  • 情報がID、IDREF、ENTITYなどの標準DTDのような属性タイプである必要がある場合は、属性を使用します。
  • 情報を空白に対して正規化しない場合は、要素を使用します。 （ XMLプロセッサは属性を正規化します 属性値の生テキストを変更できる方法で。）

コアコンテンツの原理

問題の情報がXMLで表現または伝達されている重要な資料の一部であると考える場合は、それを要素に入れてください。情報が主要な通信の周辺的または付随的であると考えられる場合、またはアプリケーションが主要な通信を処理するのを純粋に意図している場合は、属性を使用します。

構造化情報の原理

情報が構造化された形式で表現されている場合、特に構造が拡張可能な場合は、要素を使用します。情報がアトミックトークンとして表現される場合、属性を使用します。

読みやすさの原理

情報を読んで理解することを目的としている場合は、要素を使用します。情報がマシンによって最も容易に理解され、消化される場合、属性を使用します。

要素/属性バインディングの原理

別の属性によって値を変更する必要がある場合は、要素を使用します。 [..]ほとんどの場合、ある属性に別の属性を変更させるのは恐ろしい考えです。

これは、この記事の重要な部分の短い要約です。すべてのケースの例と完全な説明を参照する場合は、元の記事を参照してください。

10
Gajus

属性モデルのマッピング。要素の属性セットは、値がテキストまたはシリアル化可能な値の型である名前/値マップに直接同形化します。たとえば、C＃では、任意のDictionary<string, string>オブジェクトをXML属性リストとして表すことができ、その逆も可能です。

これは、要素の場合には特に当てはまりません。名前/値マップはいつでも要素のセットに変換できますが、逆はそうではありません。例：

<map>
   <key1>value</key1>
   <key1>another value</key1>
   <key2>a third value</key2>
</map>

これをマップに変換すると、2つのことが失われます。key1に関連付けられた複数の値と、key1の前にkey2が表示されるという事実です。

このような形式で情報を更新するために使用されるDOMコードを見ると、これの重要性がより明確になります。たとえば、次のように書くのは簡単です。

foreach (string key in map.Keys)
{
   mapElement.SetAttribute(key, map[key]);
}

そのコードは簡潔で明確です。対照的に、言う：

foreach (string key in map.Keys)
{
   keyElement = mapElement.SelectSingleNode(key);
   if (keyElement == null)
   {
      keyElement = mapElement.OwnerDocument.CreateElement(key);
      mapElement.AppendChild(keyElement);
   }
   keyElement.InnerText = value;
}
5
Robert Rossney

属性にCDATAを入れることはできません。私の経験では、遅かれ早かれ一重引用符、二重引用符、および/またはXML文書全体を「メンバー」に入れたいと思うでしょう。それが属性であれば、代わりに属性を使用した人に呪いをかけます要素の。

注：XMLでの私の経験は、主に他の人々のクリーンアップに関係していました。これらの人々は、「XMLは暴力のようなものです。XMLを使用しても問題が解決しない場合は、十分に使用していない」という古い格言に従っているようです。

3
Coxy

これは、属性がデータに関するデータである例です。

データベースは、ID属性によって名前が付けられます。

データベースの「タイプ」属性は、データベースタグ内で検出されると予想されるものを示します。

  <databases>

      <database id='human_resources' type='mysql'>
        <Host>localhost</Host>
        <user>usrhr</user>
        <pass>jobby</pass>
        <name>consol_hr</name>
      </database>

      <database id='products' type='my_bespoke'>
        <filename>/home/anthony/products.adb</filename>
      </database>

  </databases>
3
Anthony Scaife

それはすべて、XMLの用途に依存します。ほとんどがソフトウェアとマシンの間の相互運用-Webサービスなど、一貫性のためだけにすべての要素を使用する方が簡単です（また、一部のフレームワークは、WCFなど）それが人間の消費を対象としている場合-すなわち、主に人々によって作成および/または読む-そして、属性の賢明な使用は、読みやすさをかなり改善することができます; XHTMLはその合理的な例であり、XSLTとXMLスキーマでもあります。

3
Pavel Minaev

私は通常、属性がメタデータ-つまり、データに関するデータであることに基づいて作業します。避けるべきことの1つは、属性にリストを入れることです。例えば.

attribute="1 2 3 7 20"

それ以外の場合は、各要素を抽出するための追加レベルの解析があります。 XMLがリストの構造とツールを提供する場合、なぜ別のものを自分で課すのか。

属性を優先してコーディングしたいシナリオの1つは、SAXパーサーによる処理速度です。 SAXパーサーを使用すると、要素名と属性のリストを含む要素コールバックを取得できます。代わりに複数の要素を使用していた場合、複数のコールバックを取得します（各要素に1つ）。これがどれだけの負担/時間を費やすかはもちろん議論の余地がありますが、おそらく検討する価値があります。

3
Brian Agnew

作成者のポイントは正しいです（ただし、属性に値のリストが含まれる場合があります）。問題は、彼のポイントを気にするかどうかです。

それはあなた次第です。

1
John Saunders

W3schoolsを避ける必要があるのは、そのようなゴミのためです。どちらかといえば、それは彼らがJavaScriptについて持っているぞっとするようなものよりもさらに悪いことです。

一般的なルールとして、コンテンツ（つまり、エンドユーザーが消費することが予想されるデータ（人間の読書であろうと、処理のための情報を受け取るマシンであろうと））は、要素内に含めるのが最適です。メタデータ（たとえば、コンテンツに関連付けられているが、エンドユーザーへの表示ではなく内部使用にのみ価値があるID）は、属性に含める必要があります。

0
NickFitz

おそらくセマンティックな方法で問題を見ることができます。

データが要素とより緊密にリンクされている場合、それは属性になります。

すなわち、要素のID、私はそれを要素の属性として置くでしょう。

しかし、ドキュメントの属性を解析する際に、要素よりも頭痛の種になる可能性があるのは事実です。

すべてはあなたとスキーマの設計方法に依存します。

0
HyLian

XMLフォーマットを決定する際に注意すべきもう1つの点があります。正しく思い出すと、「id」属性の値はすべて数値ではなく、XMLの名前のルールを満たしている必要があります。そしてもちろん、値は一意でなければなりません。これらの要件を満たさないファイルを処理する必要があるプロジェクトがありますが（他の点ではクリーンなXMLです）、ファイルの処理がより複雑になりました。

0
Grimarr