Question

提交人提到以下内容（强调我的）：

XML元素与属性
<person sex="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>
<person>
  <sex>female</sex>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>
在第一个例子中，性是一种属性。在最后，性是一个元素。两个示例都提供相同的信息。

没有关于何时使用属性以及何时使用元素的规则。属性在HTML中很方便。 在XML中我的建议是避免它们。改为使用元素。

避免使用XML属性？

使用属性的一些问题是：


属性不能包含多个值（元素可以）

属性不能包含树结构（元素可以）

属性不易扩展（用于将来的更改）


属性难以阅读和维护。使用元素数据。使用属性来获取与数据无关的信息。

作者的观点是一个着名的，或者这是XML中的最佳实践？

应该避免使用XML中的属性吗？

W3Schools还提到了以下内容（强调我的）：

元数据的XML属性

有时会将ID引用分配给元素。这些ID可用于识别XML元素，其方式与HTML中的ID属性非常相似。这个例子证明了这一点：
<messages>
  <note id="501">
    <to>Tove</to>
    <from>Jani</from>
    <heading>Reminder</heading>
    <body>Don't forget me this weekend!</body>
  </note>
  <note id="502">
    <to>Jani</to>
    <from>Tove</from>
    <heading>Re: Reminder</heading>
    <body>I will not</body>
  </note>
</messages>
上面的ID只是一个标识符，用于标识不同的注释。它不是音符本身的一部分。

我在这里要说的是元数据（有关数据的数据）应该存储为属性，并且数据本身应该存储为元素。

Answer 1

属性或元素的使用通常取决于您尝试建模的数据。

例如，如果某个实体是数据的 PART ，那么建议将其作为一个元素。例如，员工的姓名是员工数据的重要组成部分。

现在，如果您想传达 METADATA 有关数据（提供有关数据的其他信息的内容）但实际上并不是数据的一部分，那么最好将其作为属性。例如，假设每个员工都有一个后端处理所需的GUID，然后使其属性更好。（GUID不会向看到xml的人传达真正有用的信息，但可能是其他目的所必需的）< / p>

没有任何规则可以说某事应该是属性或元素。

没有必要不惜一切代价来避免属性。有时它们比元素更容易建模。这实际上取决于您尝试表示的数据。

Answer 2

在OP之后五年，我的0.02正好相反。让我解释。

在对类似数据和属性进行分组时使用元素那个数据。
不要将元素用于一切。
如果数据重复（1到多），则可能是元素
如果数据从不重复，只有在相关时才有意义别的，这是一个属性。
如果数据没有其他属性（即名称），则它是属性
将类似元素组合在一起以支持集合解析（即/ xml /字符）
重用类似的元素名称以支持解析数据
从不，永远，使用元素名称中的数字来显示位置。（即character1，character2）这种做法使解析变得非常困难（参见＃6，解析代码必须/ character1，/ character2等，而不仅仅是/字符。

考虑另一种方式：

首先将所有您的数据视为属性。
将属性逻辑分组到元素中。如果您知道自己的数据，则很少需要将属性转换为元素。您可能已经知道何时需要元素（集合或重复数据）
逻辑上将元素组合在一起
当您遇到需要扩展的情况时，请根据上述过程的逻辑结构添加新元素/属性。添加一个新的子元素集合不会“破坏”您的设计，并且随着时间的推移将更容易阅读。

例如，看一个简单的书籍和主要人物集合，标题将永远不会有“孩子”，这是一个简单的元素。每个角色都有一个名字和年龄。

    <book title='Hitchhiker&apos;s Guide to the Galaxy' author='Douglas Adams'>
        <character name='Zaphod Beeblebrox' age='100'/>
        <character name='Arthur Dent' age='42'/>
        <character name='Ford Prefect' age='182'/>
    </book>

    <book title='On the Road' author='Jack Kerouac'>
        <character name='Dean Moriarty' age='30'/>
        <character name='Old Bull Lee' age='42'/>
        <character name='Sal Paradise' age='42'/>
    </book>

你可能会说一本书可能有多位作者。好的，只需通过添加新的作者元素进行扩展（可选择删除原始的@author）。当然，你已经破坏了原有的结构，但在实践中它非常罕见，并且易于解决。假设单个作者的原始XML的任何消费者都必须进行更改（他们可能正在更改其数据库以将作者从“book”表中的列移动到“author”表）。

<book title='Hitchhiker&apos;s Guide to the Galaxy'>
    <author name='Douglas Adams'/>
    <author name='Some Other Guy'/>
    <character name='Zaphod Beeblebrox' age='100'/>
    <character name='Arthur Dent' age='42'>
    <character name='Ford Prefect' age='182'/>
</book>

Answer 3

最重要的是，将信息放入属性可以减少冗长的XML。

比较

<person name="John" age="23" sex="m"/>

反

<person>
    <name>
        John
    </name>
    <age>
        <years>
            23
        </years>
    </age>
    <sex>
        m
    </sex>
</person>

是的，这有点偏颇和夸张，但你明白了

Answer 4

我用谷歌搜索确切的问题。首先，我登陆了这篇文章http://www.ibm.com/developerworks/library/x-eleatt/index.html。虽然，对于这样一个简单的问题，感觉太长了。无论如何，我已经阅读了关于这个主题的所有答案，但没有找到令人满意的总结。因此，我回到后一篇文章。以下是摘要：

我何时使用元素，何时使用属性来显示信息？

如果有问题的信息本身可以用元素标记，请将其放在元素中。
如果信息适用于属性表单，但最终可能在同一元素上作为同名的多个属性，请改用子元素。
如果要求信息采用标准的类似DTD的属性类型，例如ID，IDREF或ENTITY，请使用属性。
如果信息不应针对空白区域进行标准化，请使用元素。（XML processors normalize attributes以可以更改属性值原始文本的方式。）

核心内容原则

如果您认为有问题的信息是其中的一部分在XML中表达或传达的基本材料，把它放在一个元素中。如果您认为该信息是外围的或主要通讯附带，或纯粹是为了帮助应用程序处理主要通信，使用属性。

结构化信息原则

如果信息以结构化形式表达，尤其是如果结构可以是可扩展的，使用元素。如果信息是表示为原子令牌，使用属性。

可读性原则

如果该信息旨在被人阅读和理解，使用元素。如果信息最容易被理解和被机器消化后，使用属性。

元素/属性绑定原则

如果您需要将其值修改为另一个元素，请使用该元素属性。 [..]让一个属性修改另一个属性几乎总是一个可怕的想法。

这是文章重要部分的简短摘要。如果您希望查看每个案例的示例和完整描述，请参阅原始文章。

Answer 5

属性模型映射。元素上的一组属性直接同构化到名称/值映射中，其中值是文本或任何可序列化的值类型。例如，在C＃中，任何Dictionary<string, string>对象都可以表示为XML属性列表，反之亦然。

这显然不是元素的情况。虽然您始终可以将名称/值映射转换为一组元素，但事实并非如此，例如：

<map>
   <key1>value</key1>
   <key1>another value</key1>
   <key2>a third value</key2>
</map>

如果您将其转换为地图，则会丢失两件事：与key1相关联的多个值，以及key1之前key2出现的事实。

如果您查看用于以这种格式更新信息的DOM代码，这一点的重要性将变得更加清晰。例如，写这个是微不足道的：

foreach (string key in map.Keys)
{
   mapElement.SetAttribute(key, map[key]);
}

该代码简明扼要。与之形成对比，比如说：

foreach (string key in map.Keys)
{
   keyElement = mapElement.SelectSingleNode(key);
   if (keyElement == null)
   {
      keyElement = mapElement.OwnerDocument.CreateElement(key);
      mapElement.AppendChild(keyElement);
   }
   keyElement.InnerText = value;
}

Answer 6

这完全取决于XML的用途。当它主要是软件和机器之间的互操作时 - 例如Web服务，如果只是为了保持一致性（并且某些框架更喜欢它，例如WCF），则更容易使用所有元素。如果它是针对人类消费的目标 - 即主要是由人创造和/或阅读 - 那么明智地使用属性可以提高可读性; XHTML就是一个合理的例子，也是XSLT和XML Schema。

Answer 7

我通常在属性为元数据的基础上工作 - 即有关数据的数据。我避免的一件事是将列表放在属性中。例如

attribute="1 2 3 7 20"

否则，您需要额外的解析级别来提取每个元素。如果XML提供列表的结构和工具，那么为什么要自己强加另一个。

您可能希望优先编码属性的一种情况是通过SAX解析器处理速度。使用SAX解析器，您将获得一个包含元素名称和属性列表的元素回调。如果您使用了多个元素，那么您将获得多个回调（每个元素一个）。当然，这有多大的负担/时间用于辩论，但也许值得考虑。

Answer 8

您无法将CDATA放入属性中。根据我的经验，您迟早要将单引号，双引号和/或整个XML文档放入“成员”中，如果它是一个属性，您将诅咒使用属性的人元素。

注意：我的XML经验主要涉及清理其他人。这些人似乎遵循古老的格言“XML就像暴力。如果使用它还没有解决你的问题，那么你还没有用到足够的。”

Answer 9

这是属性是关于数据的数据的示例。

数据库按其ID属性命名。

数据库的“type”属性表示在数据库标记内找到的内容。

  <databases>

      <database id='human_resources' type='mysql'>
        <host>localhost</host>
        <user>usrhr</user>
        <pass>jobby</pass>
        <name>consol_hr</name>
      </database>

      <database id='products' type='my_bespoke'>
        <filename>/home/anthony/products.adb</filename>
      </database>

  </databases>

Answer 10

作者的观点是正确的（除了属性可能包含值列表）。问题是你是否关心他的观点。

取决于你。

Answer 11

您可能会以语义方式看到问题。

如果数据与元素关联得更紧密，那么它就是一个属性。

即元素的ID，我将它作为元素的属性。

但确实，解析文档属性可能会导致比元素更多的麻烦。

一切都取决于你，以及你如何设计你的架构。

Answer 12

这是因为那种垃圾你应该避免上学。如果有的话，那就比他们对JavaScript的骇人听闻的东西还要糟糕。

作为一般规则，我建议内容 - 即预期由最终用户使用的数据（无论是人类阅读，还是接收处理信息的机器） - 最好包含在内容中。元件。元数据 - 例如与一段内容相关联的ID，但仅限于内部使用的值，而不是显示给最终用户 - 应该属于一个属性。

Answer 13

在决定使用XML格式时，请记住以下事项：如果我没记错，“id”属性的值不能全部为数字，它们必须符合XML中的名称规则。当然，价值观必须是独一无二的。我有一个项目必须处理不符合这些要求的文件（尽管它们在其他方面是干净的XML），这使得处理文件更加复杂。

我应该在XML中使用元素还是属性？

XML元素与属性

避免使用XML属性？

元数据的XML属性

13 个答案: