XML 属性与元素[重复]

2024-02-22

什么时候应该使用 XML 属性以及什么时候应该使用 XML 元素?

e.g.

<customData>
  <records>
    <record name="foo" description="bar" />
  </records>
</customData>

or

<customData>
  <records>
    <record>
      <name>foo</name>
      <description>bar</description>
    </record>
  </records>
</customData>

有一篇文章的标题是“XML 设计原则:何时使用元素与属性 http://www.ibm.com/developerworks/xml/library/x-eleatt.html” 在 IBM 网站上。

尽管似乎没有太多硬性规定,但帖子中提到了一些很好的指导原则。例如,建议之一是当您的数据不能针对空白进行规范化时使用元素,因为 XML 处理器可以规范属性内的数据,从而修改原始文本。

我发现自己在开发各种 XML 结构时时常参考这篇文章。希望这对其他人也有帮助。

编辑-来自网站:

核心内容原则

如果您认为相关信息是 XML 中表达或传达的基本材料的一部分,请将其放入元素中。对于人类可读的文档,这通常意味着正在传达给读者的核心内容。对于面向机器的记录格式,这通常意味着直接来自问题域的数据。如果您认为这些信息是主要通信的外围或附带信息,或者纯粹旨在帮助应用程序处理主要通信,请使用属性。这可以避免核心内容被辅助材料弄乱。对于面向机器的记录格式,这通常意味着来自问题域的主要数据的应用程序特定符号。

举个例子,我见过许多 XML 格式,通常是企业自行开发的,其中文档标题放置在属性中。我认为标题是文档交流的基本组成部分,因此它应该始终位于元素内容中。另一方面,我经常看到内部产品标识符作为元素放入产品的描述性记录中的情况。在其中一些情况下,属性更合适,因为特定的内部产品代码并不是文档的大多数读者或处理者的主要兴趣,特别是当 ID 具有非常长或难以理解的格式时。

您可能听说过数据在元素中、元数据在属性中的原则。上面两段确实表达了同样的原则,但语言更加深思熟虑,不那么模糊。

结构化信息原理

如果信息以结构化形式表达,特别是如果结构可以扩展,则使用元素。另一方面:如果信息表示为原子标记,请使用属性。元素是用 XML 表达结构的可扩展引擎。几乎所有 XML 处理工具都是围绕这一事实设计的,如果您将结构化信息正确地分解为元素,您会发现您的处理工具补充了您的设计,从而提高了生产力和可维护性。属性旨在表达元素中所表示信息的简单属性。如果您通过将结构化信息硬塞到属性中来反对 XML 的基本体系结构,您可能会获得一些似是而非的简洁性和便利性,但您可能会付出维护成本。

日期就是一个很好的例子:日期具有固定的结构,通常充当单个标记,因此它作为属性是有意义的(最好用 ISO-8601 表示)。另一方面,在代表个人姓名时,我发现这一原则令设计师感到惊讶。我经常在属性中看到名称,但我一直认为个人名称应该在元素内容中。人名的结构令人惊奇地多变(在某些文化中,省略敬语或假定姓名各部分的顺序可能会造成混乱或冒犯)。个人姓名也很少是原子标记。例如,有时您可能想按名字搜索或排序,有时按姓氏搜索或排序。我应该指出,将全名硬塞到单个元素的内容中与将其放入属性中一样有问题。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

XML 属性与元素[重复] 的相关文章

随机推荐