我总是对这类讨论的结果感到惊讶。对我来说，有一个非常简单的规则来决定数据是否属于属性或内容，即数据是否具有可导航的子结构。

例如，非标记文本总是属于属性。总是这样。

列表属于子结构或内容。随着时间的推移，可能包含嵌入式结构化子内容的文本属于内容。(根据我的经验，在使用XML进行数据存储或交换时，这种带有标记的文本相对较少。)

以这种方式编写的XML模式非常简洁。

每当我看到像<car><make>Ford</make><color>Red</color></car>这样的情况时，我就会想“咦，作者认为make元素中会有子元素吗?”<car make="Ford" color="Red" />可读性明显更好，关于如何处理空白等问题毫无疑问。

考虑到空格处理规则，我相信这是XML设计者的明确意图。

这可能取决于你的用法。用于表示从数据库生成的结构化数据的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可以在不破坏现有代码的情况下进行伸缩时，它是最有用的。

属性的一些问题是:

属性不能包含多个值(子元素可以) 属性不容易扩展(用于将来的更改) 属性不能描述结构(子元素可以) 属性更难以用程序代码操作 属性值不容易根据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

如果有疑问，KISS——当您没有明确的理由使用属性时，为什么要混合使用属性和元素呢?如果稍后决定定义一个XSD，那么最终也会更简洁。然后，如果稍后决定从XSD生成类结构，也会更简单。

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>

我同意芬斯特的观点。如果可以的话，远离属性。元素是进化友好的，并且在web服务工具包之间具有更强的互操作性。您永远不会发现这些工具包使用属性序列化您的请求/响应消息。这也是有意义的，因为我们的消息是web服务工具包的数据(而不是元数据)。