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

存储对象属性的两种方法都是完全有效的。你应该放弃实用主义的考虑。试着回答以下问题:

哪种表示方式可以更快地生成数据解析? 哪种表示法可以更快地传输数据? 可读性重要吗? .．.

这是个价值百万美元的问题!

首先，现在不要太担心性能。您会惊讶于优化的XML解析器解析XML的速度有多快。更重要的是，您对未来的设计是什么:随着XML的发展，您将如何保持松耦合和互操作性?

更具体地说，您可以使元素的内容模型更加复杂，但扩展属性则更加困难。

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

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

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

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

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

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

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

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

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

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

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

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