Question

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

e.g。

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

或

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

Answer 1

IBM的网站上有一篇名为“Principles of XML design: When to use elements versus attributes”的文章。

虽然似乎没有很多严格的规则，但在帖子中提到了一些很好的指导方针。例如，其中一个建议是在数据不能针对空白空间进行规范化时使用元素，因为XML处理器可以规范化属性中的数据，从而修改原始文本。

当我开发各种XML结构时，我发现自己不时会引用这篇文章。希望这对其他人也有帮助。

编辑 - 来自网站：

核心内容原则

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

作为一个例子，我见过许多XML格式，通常是在企业中本土化的，文档标题放在属性中。我认为标题是文档传播的一个基本部分，它应该始终在元素内容中。另一方面，我经常看到内部产品标识符作为元素被抛出到产品的描述性记录中的情况。在某些情况下，属性更合适，因为特定的内部产品代码对于大多数读者或文档的处理者来说不是主要的兴趣，特别是当ID是非常长或不可思议的格式时。

您可能听说过元素中的原理数据，属性中的元数据。上面两段确实表达了相同的原则，但是更加刻意和不那么模糊的语言。

结构化信息原则

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

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

Answer 2

更好的思考元素与属性参数之一来自UK GovTalk guidelines。这定义了用于与政府相关的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>

Answer 3

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

对于单值属性，属性可以在大多数API中实现更紧凑的XML和更简单的寻址。

Answer 4

这在很大程度上取决于偏好。我尽可能使用Elements进行数据分组和数据属性，因为我认为这比替代方案更紧凑。

例如，我更喜欢......

<?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>

Answer 5

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

此外，如果所有内容都是一个元素，您就不必记住如何对任何特定信息进行建模。不使用属性意味着你可以少考虑一下。

Answer 6

Ned Batchelder查看Elements vs. attributes。

很好的解释和元素和属性的利弊列表。

他归结为：

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

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

Answer 7

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

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

Answer 8

我的个人经验法则：如果一个元素只能包含其中一个，并且它的原子数据（id，name，age，type等等），它应该是一个属性，否则就是一个元素。

Answer 9

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

Answer 10

这是另一种可以帮助区分元素和属性的策略：思考对象并牢记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>

XML属性与元素

10 个答案: