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属性

XML是关于协议的。首先遵循社区或行业中任何现有的XML模式或已建立的约定。

如果你真的需要从头定义你的模式，这里有一些关于元素与属性决策的一般考虑:

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

2014-04-17 12:56:33

其他回答

在我的模式设计中，我使用了以下关于属性和元素的指导原则:

Use elements for long running text (usually those of string or normalizedString types) Do not use an attribute if there is grouping of two values (e.g. eventStartDate and eventEndDate) for an element. In the previous example, there should be a new element for "event" which may contain the startDate and endDate attributes. Business Date, DateTime and numbers (e.g. counts, amount and rate) should be elements. Non-business time elements such as last updated, expires on should be attributes. Non-business numbers such as hash codes and indices should be attributes.* Use elements if the type will be complex. Use attributes if the value is a simple type and does not repeat. xml:id and xml:lang must be attributes referencing the XML schema Prefer attributes when technically possible.

属性的优先级是它提供了以下内容:

唯一的(该属性不能出现多次) 顺序不重要上面的属性是可继承的(这是“所有”内容模型在当前模式语言中不支持的) 额外的好处是它们不那么冗长，占用的带宽也更少，但这并不是更喜欢属性而不是元素的真正原因。

我在技术上可能的情况下添加了属性，因为有时不可能使用属性。例如，属性集选择。例如，对于当前的模式语言，使用(startDate和endDate) xor (startTS和endTS)是不可能的

如果XML Schema开始允许限制或扩展“所有”内容模型，那么我可能会放弃它

2010-12-16 07:33:25

这可能取决于你的用法。用于表示从数据库生成的结构化数据的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可以在不破坏现有代码的情况下进行伸缩时，它是最有用的。

2008-09-30 10:24:12

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

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

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

2009-01-15 19:22:35

如何利用我们来之不易的面向对象的直觉?我通常发现，思考哪个是对象，哪个是对象的属性，或者它指的是哪个对象是很直接的。

任何直观上作为对象有意义的东西都应该作为元素。它的属性(或属性)将是xml中这些元素的属性或带有attribute的子元素。

我认为对于更简单的情况，比如在例子中，面向对象的类比可以很好地找出哪个是元素，哪个是元素的属性。

2011-02-09 13:08:51

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