2024-09-15 07:00:01

XML属性vs XML元素

在工作中,我们被要求创建XML文件来将数据传递给另一个脱机应用程序,然后该应用程序将创建第二个XML文件来传递回去,以更新我们的一些数据。在这个过程中,我们一直在与另一个应用程序的团队讨论XML文件的结构。

我提出的样本基本上是这样的:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

另一个团队说,这不是行业标准,属性应该只用于元数据。他们建议:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

我建议使用第一个方法的原因是,创建的文件的大小要小得多。在传输过程中,文件中将有大约80000个项目。事实上,他们的建议比我的建议大三倍。我搜索了提到的神秘的“行业标准”,但我能找到的最接近的是XML属性应该只用于元数据,但争论的焦点是什么才是实际的元数据。

在冗长的解释(抱歉)之后,如何确定什么是元数据,以及在设计XML文档的结构时,如何决定何时使用属性或元素?


当前回答

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

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

请记住,XML应该是机器可读的,而不是人类可读的,对于大型文档来说,XML压缩得非常好。

其他回答

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

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

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

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

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

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

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

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

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

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

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

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

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

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