85

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 は、異なるメモを識別するための単なる識別子です。ノート自体の一部ではありません。

ここで言いたいのは、メタデータ (データに関するデータ) は属性として格納する必要があり、データ自体は要素として格納する必要があるということです。

4

13 に答える 13

66

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

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

ここで、データ（データに関する追加情報を提供するもの）に関するMETADATAを伝達したいが、実際にはデータの一部ではない場合は、それを属性にすることをお勧めします。たとえば、各従業員がバックエンド処理に必要なGUIDを持っているとすると、それを属性にする方が適切です（GUIDは、xmlを見ている人に本当に役立つ情報を伝えるものではありませんが、他の目的で必要になる場合があります）

何かが属性または要素であるべきだと言うような規則はありません。

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

于 2009-07-08T08:33:12.847 に答える
42

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

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

別の方法で考えます：

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

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

    <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 のコンシューマーは、とにかく変更する必要があります (おそらく、DB を変更して、著者を「book」テーブルの列から「author」テーブルに移動します)。

<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>
于 2014-09-10T11:32:31.597 に答える
28

特に重要なことは、属性に何かを入れると、XML の冗長性が低くなるということです。

比較

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

に対して

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

はい、それは少し偏見があり誇張されていましたが、要点はわかります

于 2009-07-08T11:55:00.287 に答える
7

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

これは、要素の場合には当てはまりません。名前/値マップを一連の要素にいつでも変換できますが、その逆は当てはまりません。たとえば、次のようになります。

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

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

このような形式で情報を更新するために使用される 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;
}
于 2009-07-08T17:01:21.973 に答える
5

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

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

于 2009-07-09T02:36:05.100 に答える
3

それはすべて、XMLが何に使用されるかに依存します。ほとんどがソフトウェアとマシン間の相互運用である場合（Webサービスなど）、一貫性を保つためだけにすべての要素を使用する方が簡単です（WCFなどの一部のフレームワークもそのように優先します）。それが人間の消費を対象としている場合、つまり主に人々によって作成および/または読み取られる場合、属性を適切に使用すると、読みやすさが大幅に向上します。XHTMLはその妥当な例であり、XSLTおよびXMLスキーマでもあります。

于 2009-07-08T08:33:27.043 に答える
3

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

attribute="1 2 3 7 20"

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

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

于 2009-07-08T08:33:32.253 に答える
1

著者の指摘は正しいです（属性に値のリストが含まれている場合を除く）。問題は、あなたが彼のポイントを気にするかどうかです。

それはあなた次第です。

于 2009-07-08T08:29:50.123 に答える
0

あなたはおそらく意味論的な方法で問題を見ることができます。

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

すなわち：要素のID、私はそれを要素の属性として置きます。

しかし、ドキュメントの属性を解析している間、要素よりも多くの頭痛の種を引き起こす可能性があるのは事実です。

すべてはあなたとあなたがあなたのスキーマをどのように設計するかに依存します。

于 2009-07-08T08:35:23.170 に答える
0

XML 形式を決定する際に留意すべきもう 1 つの点があります。私の記憶が正しければ、"id" 属性の値はすべて数値であってはならず、XML の名前の規則を満たす必要があります。もちろん、値は一意でなければなりません。これらの要件を満たさないファイルを処理する必要があるプロジェクトがあります (他の点ではクリーンな XML ですが)。これにより、ファイルの処理がより複雑になりました。

于 2009-07-09T02:04:35.953 に答える
0

w3schools を避けるべきなのは、この種のごみのためです。どちらかといえば、それは彼らが JavaScript について持っているぞっとするようなものよりもさらに悪いことです。

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

于 2009-07-08T11:45:09.807 に答える