什么时候应该使用XML属性，什么时候应该使用XML元素？

例如

<customData>
  <records>
    <record name="foo" description="bar" />
  </records>
</customData>

或者

<customData>
  <records>
    <record>
      <name>foo</name>
      <description>bar</description>
    </record>
  </records>
</customData>

解决方案

我个人喜欢将属性用于简单的单值属性。元素(显然)更适合于复杂类型或者重复值。

对于单值属性，在大多数API中，属性导致更紧凑的XML和更简单的寻址。

这很大程度上是一个偏好问题。
我尽可能使用Elements进行分组，并使用数据属性，因为我认为这比其他方法更紧凑。

例如我更喜欢.....

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

属性上的限制告诉我们可以在哪里使用和不使用它们：属性名称必须唯一，它们的顺序不能重要，名称和值都只能包含文本。相反，元素可以具有不唯一的名称，具有明显的顺序，并且可以具有混合的内容。

属性在域中可用，在这些域中，属性映射到遵循这些规则的数据结构上：对象上属性的名称和值，表中某行的列，字典中的条目的名称和值。 (但如果属性不是所有值类型，或者字典中的条目不是字符串，则不是)。

考虑更好的元素vs属性论证之一来自英国GovTalk指南。这定义了用于与政府相关的XML交换的建模技术，但是它有其自身的优点，值得考虑。

Schemas MUST be designed so that
  elements are the main holders of
  information content in the XML
  instances. Attributes are more suited
  to holding ancillary metadata – simple
  items providing more information about
  the element content.  Attributes MUST
  NOT be used to qualify other
  attributes where this could cause
  ambiguity. 
  
  Unlike elements, attributes cannot
  hold structured data. For this reason,
  elements are preferred as the
  principal holders of information
  content. However, allowing the use of
  attributes to hold metadata about an
  element's content (for example, the
  format of a date, a unit of measure or
  the identification of a value set) can
  make an instance document simpler and
  easier to understand. 
  
  A date of birth might be represented
  in a message as:

<DateOfBirth>1975-06-03</DateOfBirth>

However, more information might be
  required, such as how that date of
  birth has been verified. This could be
  defined as an attribute, making the
  element in a message look like:

<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>

The following would be inappropriate:

<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>

It is not clear here whether the Code
  is qualifying the VerifiedBy or the
  ValueSet attribute. A more appropriate
  rendition would be:

<DateOfBirth>    
   <VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>     
   <Value ValueSet="ISO 8601">1975-06-03</Value>
 </DateOfBirth>

IBM网站上有一篇标题为" XML设计原理：何时使用元素而不是属性"的文章。

尽管似乎没有很多硬性规定，但在帖子中提到了一些很好的准则。例如，当XML处理器可以规范属性中的数据从而修改原始文本时，建议之一是当数据不能针对空格进行规范时使用元素。

在开发各种XML结构时，我会时不时地参考这篇文章。希望这对其他人也有帮助。

从站点编辑：

核心内容原则

如果我们认为有问题的信息是用XML表示或者传达的基本材料的一部分，请将其放在一个元素中。对于人类可读的文档，这通常意味着正在传达给读者的核心内容。对于面向机器的记录格式，这通常意味着直接来自问题域的数据。如果我们认为该信息是主要通信的附带或者附带信息，或者纯粹是旨在帮助应用程序处理主要通信的信息，请使用属性。这避免了用辅助材料使芯含量杂乱无章。对于面向机器的记录格式，这通常意味着对来自问题域的主数据使用特定于应用程序的符号。

作为示例，我看到了许多XML格式，通常在企业中自行开发，将文档标题放在属性中。我认为标题是文档沟通的基础部分，因此标题应始终位于元素内容中。另一方面，我经常看到这样的情况：将内部产品标识符作为元素扔到产品的描述性记录中。在某些情况下，属性更合适，因为特定的内部产品代码对于文档的大多数阅读者或者处理者而言并不是最重要的，尤其是当ID的格式非常长或者难以理解时。

我们可能已经听说过原理数据放在元素中，元数据放在属性中。上面的两段确实表达了相同的原理，但是用了更多的考虑和更少的模糊语言。

结构化信息原理

如果信息以结构化形式表示，尤其是结构可能是可扩展的，请使用元素。另一方面：如果信息表示为原子标记，请使用属性。元素是用于表达XML结构的可扩展引擎。几乎所有XML处理工具都是围绕这一事实而设计的，如果我们将结构化信息正确地分解为元素，我们会发现处理工具对设计起到了补充作用，从而提高了生产率和可维护性。设计属性是为了表达元素中表示的信息的简单属性。如果通过将结构化信息变成属性而违反XML的基本体系结构，则可能会获得一些简洁性和便利性，但是我们可能会付出维护费用。

日期是一个很好的例子：日期具有固定的结构，通常充当单个标记，因此它作为属性有意义(最好在ISO-8601中表示)。另一方面，代表个人名字是我见过这种原理使设计师感到惊讶的情况。我在属性中经常看到名字，但是我一直认为个人名字应该包含在元素内容中。人名具有令人惊讶的可变结构(在某些文化中，我们可以通过省略敬语或者采用姓名的顺序来引起混乱或者冒犯)。个人名称也很少是原子标记。例如，有时我们可能想按姓氏，有时按姓氏进行搜索或者排序。我应该指出，将全名插入单个元素的内容与将其放入属性一样是有问题的。

通过Ned Batchelder查看元素与属性。

很好的解释，并很好地列出了元素和属性的优缺点。

他将其归结为：

Recommendation: Use elements for data that will be produced or consumed by a business application, and attributes for metadata.

重要说明：请参阅下面的@maryisdead评论，以进行进一步说明。

当数据是人类读者需要了解的数据时，我倾向于使用元素，而当数据仅用于处理时(例如ID)，我倾向于使用元素。这意味着我很少使用属性，因为大多数数据与要建模的领域有关。

这是可以帮助区分元素和属性的另一种策略：考虑对象并牢记MVC。

对象可以具有成员(对象变量)和属性(具有setter和getter的成员)。属性在MVC设计中非常有用，它允许更改通知机制。

如果这是正确的方向，那么属性将用于用户无法更改的内部应用程序数据；经典示例将是ID或者DATE_MODIFIED。因此，元素将用于用户可以修改的数据。

因此，考虑到馆员首先添加书籍(或者杂志)，然后可以编辑其名称作者ISBN等，以下内容才有意义：

<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
    <authors count="1">
        <author>
            <name>John Smith</name>
        <author>
    </authors>
    <ISBN>123456790</ISBN>
</item>