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

其他回答

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

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

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

“XML”代表“可扩展标记语言”。标记语言意味着数据是文本,用关于结构或格式的元数据标记。

XHTML是按预期方式使用XML的一个例子:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

这里,元素和属性之间的区别很明显。文本元素显示在浏览器中,属性是关于如何显示它们的指令(尽管有一些标记不是这样工作的)。

当XML不是作为标记语言,而是作为数据序列化语言使用时,就会出现混淆,在这种情况下,“数据”和“元数据”之间的区别更加模糊。因此,元素和属性之间的选择或多或少是任意的,除非不能用属性表示(参见feenster的回答)。

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

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

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

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

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

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

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