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

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

列表属于子结构或内容。随着时间的推移，可能包含嵌入式结构化子内容的文本属于内容。(根据我的经验，在使用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可以在不破坏现有代码的情况下进行伸缩时，它是最有用的。

这两种方式都有争议，但您的同事认为XML应该用于“标记”或围绕实际数据的元数据，这一点是正确的。对您来说，在用XML建模域时，有时很难确定元数据和数据之间的界限。实际上，我所做的是假装标记中的任何内容都是隐藏的，只有标记之外的数据是可读的。这份文件在这方面有意义吗?

XML是出了名的庞大。对于运输和存储，如果你能负担得起处理能力，强烈建议压缩。XML压缩得很好，有时压缩得非常好，因为它具有重复性。我曾经把大文件压缩到不到原始大小的5%。

支持您立场的另一点是，当其他团队在争论样式时(大多数XML工具处理全属性文档就像处理全#PCDATA文档一样容易)，您在争论实用性。虽然不能完全忽视风格，但技术优点应该更重要。

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

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

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

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

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

我的经验是这样的:

属性是自包含的东西，例如颜色、ID、名称。 元素是具有或可能具有自己的属性或包含其他元素的东西。

你的也很接近了。我会这样做:

编辑:根据下面的反馈更新了原始示例。

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

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