使用元素作为数据，使用属性作为元数据(关于元素数据的数据)。

如果一个元素在选择字符串中显示为谓词，那么很明显它应该是一个属性。同样地，如果一个属性从未被用作谓词，那么它可能不是有用的元数据。

请记住，XML应该是机器可读的，而不是人类可读的，对于大型文档来说，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

其他人已经介绍了如何区分属性和元素，但是从更一般的角度来看，把所有东西都放在属性中，因为这会使生成的XML更小，这是错误的。

XML的设计不是为了紧凑，而是为了便于移植和人类可读。如果您想减少传输中的数据大小，则使用其他方法(例如谷歌的协议缓冲区)。

随着时间的推移，属性很容易变得难以管理，相信我。我个人总是远离他们。元素对于解析器和用户来说更加显式和可读/可用。

我唯一一次使用它们是定义资产url的文件扩展名:

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

我想如果你100%知道属性不需要扩展，你就可以使用它们，但你知道多少次。

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

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

这在HTML中非常明显，属性和标记的差异可以清楚地看到:

所有数据都在标记之间 属性用于描述数据的特征(例如格式)

如果只有XML格式的纯数据，区别就不那么明显了。数据可以位于标记之间，也可以作为属性。

大多数数据应该位于标记之间。

你可以把数据分为两类:数据和“元数据”，其中元数据不是记录的一部分，你想要呈现，但像“格式版本”，“创建日期”等。

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

有人也可以说:“使用属性来描述标记，使用标记来提供数据本身。”