70

什么时候应该使用 XML 属性，什么时候应该使用 XML 元素？

例如

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

或者

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

10 回答 10

38

IBM 的网站上有一篇题为“ XML 设计原则：何时使用元素与属性”的文章。

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

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

编辑 - 从网站：

核心内容原则

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

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

您可能听说过元素中的主要数据，属性中的元数据。上面两段确实表达了相同的原则，但语言更刻意，更少模糊。

结构化信息原理

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

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

于 2008-10-05T21:46:30.263 回答
17

我个人喜欢将属性用于简单的单值属性。元素（显然）更适合复杂类型或重复值。

对于单值属性，属性导致在大多数 API 中更紧凑的 XML 和更简单的寻址。

于 2008-09-30T09:06:54.873 回答
17

更深思熟虑的元素与属性参数之一来自英国 GovTalk 指南。这定义了用于与政府相关的 XML 交换的建模技术，但它有其自身的优点，值得考虑。

必须设计模式以使元素成为 XML 实例中信息内容的主要持有者。属性更适合保存辅助元数据——提供有关元素内容的更多信息的简单项目。属性不得用于限定可能导致歧义的其他属性。

与元素不同，属性不能保存结构化数据。出于这个原因，元素被首选作为信息内容的主要持有者。但是，允许使用属性来保存有关元素内容的元数据（例如，日期的格式、度量单位或值集的标识）可以使实例文档更简单、更容易理解。

出生日期可能在消息中表示为：

 <DateOfBirth>1975-06-03</DateOfBirth>

但是，可能需要更多信息，例如如何验证该出生日期。这可以定义为一个属性，使消息中的元素看起来像：

<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>

以下是不合适的：

<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>

这里不清楚代码是限定 VerifiedBy 还是 ValueSet 属性。更合适的翻译是：

 <DateOfBirth>    
   <VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>     
   <Value ValueSet="ISO 8601">1975-06-03</Value>
 </DateOfBirth>
于 2008-10-05T21:26:35.173 回答
7

这在很大程度上是一个偏好问题。我尽可能使用元素进行分组和数据属性，因为我认为这比替代方案更紧凑。

比如我更喜欢......

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...代替....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

但是，如果我的数据在 20-30 个字符内不容易表示或包含许多引号或其他需要转义的字符，那么我会说是时候分解元素了……可能使用 CData 块。

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>
于 2008-09-30T09:18:29.247 回答
7

作为一般规则，我完全避免使用属性。是的，属性更紧凑，但元素更灵活，而灵活性是使用 XML 等数据格式的最重要优势之一。今天是一个单一的价值，明天可以成为一个价值列表。

此外，如果一切都是元素，那么您永远不必记住您是如何对任何特定信息进行建模的。不使用属性意味着您需要考虑的事情更少。

于 2011-08-04T11:53:11.977 回答
4

查看Ned Batchelder 的元素与属性。

很好的解释和元素和属性的优点和缺点的一个很好的列表。

他将其归结为：

建议：将元素用于将由业务应用程序生成或使用的数据，并将属性用于元数据。

重要提示：请参阅下面的@maryisdead 评论以获得进一步说明。

于 2009-01-28T05:59:10.240 回答
2

属性的限制告诉您在哪里可以使用和不能使用它们：属性名称必须是唯一的，它们的顺序不能很重要，名称和值都只能包含文本。相比之下，元素可以有不唯一的名称，有重要的顺序，并且可以有混合的内容。

属性可用于映射到遵循这些规则的数据结构的域中：对象属性的名称和值、表行中的列、字典中的条目。（但如果属性不是所有值类型，或者字典中的条目不是字符串，则不是。）

于 2008-10-01T00:28:58.980 回答
2

我个人的经验法则：如果一个元素只能包含其中一个，并且它是一个原子数据（id、名称、年龄、类型等），那么它应该是一个属性，否则就是一个元素。

于 2013-01-05T23:51:10.277 回答
1

当它是人类读者需要知道的数据和仅用于处理时的属性（例如ID）时，我倾向于使用元素。这意味着我很少使用属性，因为大部分数据与正在建模的域相关。

于 2009-03-11T23:02:55.173 回答
1

这是另一个有助于区分元素和属性的策略：考虑对象并牢记 MVC。

对象可以具有成员（对象变量）和属性（具有 setter 和 getter 的成员）。属性对于 MVC 设计非常有用，允许更改通知机制。

如果这是采用的方向，则属性将用于用户无法更改的内部应用程序数据；经典示例将是 ID 或 DATE_MODIFIED。因此，元素将用于用户可以修改的数据。

因此，考虑到图书馆员首先添加图书项目（或杂志），然后可以编辑其名称作者 ISBN 等，以下内容是有意义的：

<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
    <authors count="1">
        <author>
            <name>John Smith</name>
        <author>
    </authors>
    <ISBN>123456790</ISBN>
</item>
于 2010-04-29T00:16:17.453 回答